云计算软件开发工程师是干什么的？

谢谢邀请

云计算SDN软件开发工程师

岗位要求：

1、通信、计算机、自控、电子、软件等相关专业本科以上学历；

2、具备Linux平台C/C++/Java/Python语言研发经验；

3、深入理解计算机体系结构；

4、具备网络通信或者云计算、IaaS产品研发经验；

5、具备较强的逻辑思维能力和学习能力。具备较强的英文阅读和沟通能力。对新领域技术敏感，乐于分享；

6、具有良好的沟通能力及团队合作精神，责任心强，有一定的承压能力。

符合以下汪激条件者优先:

1、具有SDN控制器设计或开发经验，或者Openstack网络相关组尺纤件分析、开发经验；

2、具有多线程开发，大规模JAVA分布式系统开发经验陵陵仿；

3、精通Openstack、Cloudstack、OpenDaylight、ONOS、OpenvSwitch等任意一项开源技术；

4、精通 VMWare、KVM、Hyper-V、Xen等任意一项虚拟化技术；

5、具备丰富的网络领域知识，精通TCP/IP网络协议、路由协议或者安全领域知识。

岗位职责：

1、从事云计算数据中心网络虚拟化、数据中心广域网互联以及云安全相关SDN技术的研究和开发工作；

2、研究和跟随SDN领域技术发展趋势和标准，分析和参与Openstack、ODL、ONOS以及Openvswitch等开源项目；

3、研究和分析云计算领域用户对网络虚拟化、自动化的需求，负责SDN相关应用开发。

ONOS和ODL分别由运营商和厂商主导，所代表的利益不同，也就分别选择了两种不同的SDN演进方式。前者更贴近于SDN诞生之初时狭义的SDN概念，即通过OpenFlow将控制平面和转发平面完全分离，网络设备只是进缓枝行转发的黑盒子，通过Controller完成一切计算。ONOS所选择的理念与运营商自己的利益息息相关，只有将控制能力拿到自己手里，才能在整条产业链上逐步摆脱设备厂商的控制。通过使用更为廉价的转发设备替代原有的厂商设备，一方面在眼下增加自己与设备厂商的议价砝码，另一方面长远看能大大降低网络的建设和维护成本。相比较而言，ODL则采取了更为平缓的SDN演进方式，从理念上更为贴近广义的SDN，即不局限于OpenFlow协议，不局限于完全将控制平面从转发设备上剥离，通过已有的网络协议将部分的控制逻辑放到Controller上。这样的理念使广义的SDN技术的嫌哪衫落地更容易成为现实，一方面通过保护运营商、企业等设备厂商客户的既有投资，使客户可以真正感受到SDN技术的实际效果。另一方面，通过在现有设备上扩展已有的网络协议，厂商能够使自己的设备在不用伤筋动骨就能保有竞争力，避免自己在SDN的革命中被迅速甩下。

从技术上讲，SDN Controller实际上解决的是南向与设备的通信问题和北向向APP提供的资源问题，网络运芹腔营者根据自己网络的业务特点提出的控制逻辑则需要开发APP来实现。从南向接口上看，ONOS目前成熟的南向接口只有OpenFlow，而ODL Helium版则支持OpenFlow、OVS-DB、MP-BGP、PCEP、NETCONF/YANG等极为丰富的南向接口以连接不同类型的设备。从北向接口上看，ODL采用的MD-SAL使得设备资源可以通过YANG model直接转换为RESTConf API，而ONOS还在某种程度上停留在ODL最初版本使用的AD-SAL架构，API需要在plugin设计时单独考量。当然除此之外，Controller的性能与Scale out也是必须面对的问题。对此，ONOS确实抓住了ODL尚未解决的问题，从一开始就从这两方面抢占先机，拨人眼球。不过从二者实现上都采用了JAVA的Karaf框架来看，性能与Scale out问题在根本上也不会存在先天的差别，面对海量计算采用Cluster会是最终的解决方法，而实际上两个控制器都提供了相应的Cluster部署方案。唯一的问题可能是ODL还需要应对多种南向接口带来的额外消耗，但ODL提供的是南向接口的可选能力，实际部署上也很少会出现多种协议共存的情况。

但值得一提的是，尽管ONOS主推OpenFlow，但在其Wiki上也列出了合作厂商正在ONOS上开发PCEP、TL1等南向接口，所以也许不久之后我们就会看到ONOS也开始支持各种各样的南向接口了

说明：翻译自 ONOS wiki 的 System Components ，自学使用

ONOS的架构由功能层组成。如下图所示：

服务 service 是功能的一个单元，由多个组件组成，这些组件通过软件堆栈在层之间创建垂直切片。我们将组成服务的组件集合称为 子系统 subsystem 。在本指南中，我们将术语“service”和“subsystem”互换使用。

ONOS定闷毁义了几种主要服务：

下图说明了现有和未来部署计划中ONOS的各种子系统：

子系统的每个组件都位于三个主要层之一中，并且可以由它们实现的一个或多个Java接口来标识。

下图总结了子系统组件的关系。图中的顶部和底部虚线分别表示由北向和南向API创建的层间边界。

Provider是ONOS堆栈的最低层，通过特定于协议的库与网络形成接口，并将 ProviderService 作为与core层的接口。

协议感知Provider负责使用各种控制和配置协议与网络环境进行交互，并将特定于服务的感觉数据提供给核心。提供者还可以从其他子系统收集数据，将其转换为特定于服务的数据。

一些Provider可能还需要接受来自核心的控制命令，并使用适当的协议特定手段将其应用于网络。这些通过 Provider 接口馈入Provider。

Provider与 ProviderId 关联。 ProviderId 可以提供Provider族的可外部化的身份，即使在其被卸载或Provider被卸载之后，设备和其他模型实体也可以与负责其存在的Provider的身份保持关联。

ProviderId 带有URI方案名称，以允许将设备与备用提供商系列的提供商进行松散配对，并且无需访问Provider本身就可以做到这一点。

一个subsystem可能与多个Provider相关联。在这种情况下，Provider被指定为 primary 或 ancillary 。Primary provider拥有与其服务关联的实体，而ancillary provider则将其信息作为overlays提供。如果任何overlay导致与underlay信息冲突，则此方法将优先考虑主要provider信息。

Device Subsystem就是这样一种能够支持多个provider的服务。

Manager是驻留在core的组件，它从provider接收信息并将其提供给应用程序和其他服务。它公开了几个接口：

Manager服务接口的使用者可以通过查询服务同步接收信息，也可以作为事件侦听器异步接收信息（例粗罩毕如，通过使用 ListenerService 的 Service 的一部分接口注册事件并实现用于接收事件的 EventListener 接口）。

同样在core内并且与Manager密切相关，Store还具有索引、持久化和同步Manager收到的信息的任务。这包括通过与其岩芹他ONOS实例上的存储直接通信来确保跨多个ONOS实例的信息的一致性和鲁棒性。在 Cluster Coordination（集群协调） 中可以找到更多有关分布式环境中存储的讨论。

Application通过 AdminService 和 Service 接口使用并 *** 作管理器汇总的信息。Application具有很多功能，可以从在Web浏览器中显示网络拓扑到设置网络流量的路径。

每个应用程序都与一个唯一的 ApplicationId 关联。ONOS使用此标识符来跟踪与Application关联的上下文（例如，任务和目标，例如意图和流程规则）。为了获得有效的ID，Application向 CoreService 进行注册并提供其名称，该名称应遵循反向DNS表示法，例如 org.onlab.onos.fwd 。

ONOS中信息分发的两个基本单位是事件和描述。与服务一样，事件和描述与特定的网络元素和概念相关联。一旦创建，两者都是不可变的。

描述用于通过南向API传递有关元素的信息。例如， HostDescription 包含有关主机的MAC和IP地址及其在网络中的位置（VLAN ID和设备/端口连接点）的信息。描述通常由一个或多个模型 object （各种网络组件的ONOS表示）组成。

Manager使用Event来通知其侦听器有关网络中的更改，Store使用Event来通知其对等对象分布式设置中的Event。Event由事件类型和由模型对象构建的主题组成。例如，可以使用 DeviceEvent 通知 DeviceListeners 设备（主题）已检测到（ DEVICE_ADDED ），丢失（ DEVICE_REMOVED ）或设备的某些方面已更改（ DEVICE_UPDATED ）等。

Event是由Store根据Manager的输入生成的。生成事件后，就会通过 StoreDelegate 接口将Event分配给感兴趣的侦听器，该接口最终会调用 EventDeliveryService 。实际上， StoreDelegate 将Event移出商店，并且 EventDeliveryService 确保事件仅到达感兴趣的侦听器。由于它们的交互方式，这两个组件驻留在Manager中，其中Manager的向商店提供 StoreDelegate 的实现类。

Event Listener是实现 EventListener 接口的任何组件。 EventListener 子接口 Event 按其侦听的子类的类型进行分类。典型的实现方式是事件侦听器是管理器或应用程序的内部类，根据接收到的事件从中调用适当的服务。这将子系统外部事件的处理限制在子系统的管理器或应用程序（即应处理它们的逻辑位置）中。

下图详细说明了上图，以显示“Descriptions”，“Events”和此处描述的组件之间的关系。

模型对象是各种网络元素和属性的ONOS协议无关表示。事件将这些表示作为主题主体。这些表示是根据系统核心在“描述”中找到的信息构建的。

有关网络表示的进一步讨论可以在 Representing Networks（表示网络） 中找到。

---