SDN实战团分享（三十三）：Hurricane分布式实时处理系统架构及SDN领域的应用
作者：互联网
在此之前，他曾在思科系统（中国）研发中心云产品研发部工作，并参与了大规模分布式系统的服务器后端、前端以及SDK的设计与研发工作，在分布式系统设计与实现、性能调优、高可用性和自动化等方面积累了丰富的敏捷实践与开发经验。他主要从事C/C++开发工作，致力于高性能平台架构的研究与开发。此外，对JavaScript、Lua以及移动开发平台等也有一定研究。著有《分布式实时处理系统：原理、架构和实现》，并译有《Storm实时数据处理》《高级C/C++编译技术》《JavaScript编程精解（原书第2版）》。
最近关注的重点包括：性能优化、机器学习、深度学习和框架设计
随着互联网与计算机的普及，我们可以通过传统途径或者互联网收集到大量的数据，而我们在日常工作中对这么大量数据的处理需求也与日俱增。日常遇到的数据种类非常多，从结构化的表格数据、到半结构化非结构化的文本图像，我们需要掌握更多的技能与工具来学会如何处理这些数据。尤其在机器学习越来越热的今天，我们更加有必要学会如何处理这些数据，比如近两年最火的恐怕就是深度学习，而深度学习又非常依赖数据量，很多时候网络再怎么精心设计，再怎么使用技巧，也不如数据量来得实在。比如在我们这里经常需要为此处理大量的文本和图像数据。但是在这个过程中，我们发现总是在做很多重复的工作。总结一下，日常的工作模式抽象出来基本就是这么几件事：
1.将需要处理的数据输出到一个列表文件（或者存到数据库里），每一项就是一个任务
2.处理程序中开启多个Worker线程，并为每个线程分配任务，线程执行自己的任务，并将结果输出出来
3.处理程序还需要记录处理了哪些数据，哪些成功，哪些是异常的。
4.需要将这么多个处理程序连接在一起完成数据处理任务。
可以发现，这个需求其实就是一个简单的生产者-消费者模式，我们其实是在建立一个任务队列，然后让Worker来取任务并执行任务。为了简化这项工作，自己写了一个简单的消息队列以及生产者消费者的抽象，让程序专注于数据处理的逻辑。用户只需要建立一个MessageQueue（消息队列），一个Feeder（消息源），一个Consumer（消息处理单元），并且实现Feeder和Consumer的具体逻辑（可以使用函数对象或者lambda表达式）。这样就可以简化日常的任务，但是，经过长时间的工作发现这样还是远远不够的，我们还需要经常处理这些事情：
我们来分别看一看：
1.如何分配任务？一开始我们采取的是按序号分配任务，每个任务执行连续一批任务。后来发现这样会遇到很多问题，不如使用生产者消费者模式让Worker自己领取任务。但是由于缺乏统一的调度者，因此无法确保整体具有最高的计算效率。
2.如何处理任务失败？我们一开始的方法是将成功任务和失败任务分别放到两个独立列表里，每次一个任务结束后都要重新处理失败的任务，有非常多手动工作。
3.程序常常会因为各种原因在一半中断（未完全测试的程序可能有内存泄漏，内存越界，即时程序没有问题也可能会发生进程误杀甚至是断电等狗血的事情），因此我们需要保存任务状态，下次启动程序的时候可以自动跳过已经成功处理过的任务。
4.当数据过多的时候需要手动分割数据放在几个机器上执行，部署和手动管理成本很高。
后来我们发现Apache Storm的数据处理方式很适合解决这些问题。但是非常可惜，一方面出于性能考虑，另一方面为了更加容易地调用本地C++程序，这种基于Java的方式并不是那么方便，每次还需要编写JNI来接入我们的C++代码。
于是，我发现我们需要自己建立一套系统来解决这个问题。这套系统中包含这些东西：
▪使用NodeJS编写的网络爬虫，因为NodeJS单线程异步非阻塞，简化了高性能爬虫的编写工作。
▪使用MongoDB存储数据，因为MongoDB是文档型数据库，而且可以无模式，处理图像和网页数据的时候非常方便。
▪使用Caffe来进行训练和数据处理，由于我们的机器并不是特别多，这种情况下Caffe可以提供比Tensorflow更好的性能。
▪Hurricane实时处理系统（http://github.com/samblg/hurricane 或 http://hurricane-project.net），是Storm的计算模型在C++11中的实现，不过做了部分简化和调整，以适应我们自己的工作。
这里面的关键就是Hurricane这个系统：
这张图就是Hurricane的计算模型，Hurricane实时处理系统是一个基于流的分布式实时处理平台，其计算模型是Topology。每个Topology都是一个网络，该网络由计算任务和任务之间的数据流组成。
该模型中Spout负责产生新的元组，Bolt负责处理前一级任务传递的元组，并将处理过的元组发送给下一级。Spout是元组的生成器，而Bolt则是元组的处理单元。每个任务都会将数据封装为元组传递给其他的任务。在系统中任务被定义为Task。Task是对计算任务的统一抽象，规定了计算任务的统一接口。Spout和Bolt都是Task的特殊实现。为了处理这种分布式的计算模型，我们设计了自己的分布式系统架构，如下图所示：
最上方的是President，这是整个集群的管理者，负责存储集群的所有元数据，所有Manager都需要与之通信并受其控制。下方的是多个Manager，每个Manager中会包含多个Executor，每个Executor会执行一个任务，可能为Spout和Bolt。
从任务的抽象角度来讲，每个Executor之间会相互传递数据，只不过都需要通过Manager完成数据的传递，Manager会帮助Executor将数据以元组的形式传递给其他的Executor。
Manager之间可以自己传递数据（如果分组策略是确定的），有些情况下还需要通过President来得知自己应该将数据发送到哪个节点中。
在这个基础架构与计算模型之上，我们还设计了一套上层接口Squared：
左侧是Hurricane基本的计算模型，在该计算模型中，系统是一个计算任务组成的网络。我们需要考虑每个节点的琐屑实现。
但如果在日常任务中，使用这种模型相对来说会显得比较复杂，尤其当网络非常复杂的时候。
为了解决这个问题，看一下右边这个计算模型，这是对我们完成计算任务的再次抽象。
▪第一步是产生语句的数据源
▪然后每条语句需要使用名为SplitSentence的函数处理将句子划分为单词
▪接下来根据单词分组，使用CountWord这个统计操作完成单词的计数。
▪所以这个接口的本质是将网络映射成了简单的数据操作流程。
解决问题和讨论问题都会变得更为简单直观，现在我们来看看Hurricane在SDN领域的应用。
现有网络中，对流量的控制和转发都依赖于网络设备实现，且设备中集成了与业务特性紧耦合的操作系统和专用硬件，这些操作系统和专用硬件都是各个厂家自己开发和设计的。
SDN是一种新型的网络架构，它的设计理念是将网络的控制平面与数据转发平面进行分离，从而通过集中的控制器中的软件平台去实现可编程化控制底层硬件，实现对网络资源灵活的按需调配。在SDN网络中，网络设备只负责单纯的数据转发，可以采用通用的硬件;而原来负责控制的操作系统将提炼为独立的网络操作系统，负责对不同业务特性进行适配，而且网络操作系统和业务特性以及硬件设备之间的通信都可以通过编程实现。
SDN 基本架构：
通常来说，我们可以把SDN架构拆分成以下几个部分组成：（相信大家都非常熟悉了）
1、Data Plane：由网络基本设备组成，通过D-CPI（data-controller plane interface）为Controller Plane提供服务。
2、Controller Plane：SDN控制器转发应用程序的请求，并在网络设备之间转发，而具体信息则通过SDN上层应用管理和控制。应用程序通过A-CPI（或NBI）访问服务。对于SDN控制器来说，它负责在有限硬件或网络资源的前提下更合理为应用程序分配资源。
3、SDN application：该层通过A-CPI访问和控制网络请求。
那么，Hurricane实时处理系统在这一整套SDN架构中可以承担什么样的角色呢？没错，消息控制和转发，hurricane提供了高性能的网络I/O和消息队列特性，并在分布式系统结构上抽象了多种消息分发和处理的能力。因此，我们可以利用hurricane 来完成消息转发和控制。不仅如此，Hurricane还通过President提供了exactly-once支持，因此它能够确保在整个分布式系统当中消息被处理一次，而且一定被处理，这样一来，就为可靠性方面提供了框架层面的保证。
Hurricane可以利用其高实时和可靠的特性，作为整个SDN的中央控制单元，一边接收消息，一边根据流量和其他情况自动计算消息与资源分配的解决方案，快速根据实际需求调整网络配置。用户只需要简单修改策略，Hurricane会自动更新整个网络中的策略并完成网络资源的实时调整，完成消息和配置的快速分发。
现在，我们来一起看看Hurricane是如何实现exactly-once语义的。
Hurricane中的每个元组有一个“确认编号（ackid）”，Bolt处理完一个元组后需要调用ack成员函数或者fail成员函数，调用ack表示Bolt成功处理了该Bolt，调用fail表示处理失败。Bolt处理信息会被传递给元组的来源任务（Spout或者Bolt），如果出现处理失败的元组，Storm会取消整个流（从Spout发出的元组以及根据其计算得到的整个元组树），并重新计算所有任务。每个元组还会有一个超时事件，如果一个任务发出元组后一定时间内没有收到ack或者fail信息，会主动认为该任务失败，并按照收到fail消息的情况处理该元组。
最后，Hurricane还有一些其他分布式实时处理系统不太关注的功能，这些功能十分关键，特别是对一些特定领域，比如SDN。
一个功能是数据的保序处理。比如在处理金融和交易业务这类数据的时候，数据处理结果和数据处理顺序密切相关。在SDN中，我们也要考虑到那些和顺序密切相关的消息和任务，如果将分布式系统中的保序控制完全交给开发者来做是非常复杂且不易控制的，而在系统内部日志处理这种任务中也需要用到保序，因此我们需要确保部分数据处理的顺序问题。如果所有的消息处理都进行保序会使整个系统变成顺序执行，那就和单机执行没有太大区别了，也是不适用于SDN的。因此Hurricane采用了不同的保序模式，将数据处理分成两个部分，一个是“处理”阶段，一个是“提交”阶段。处理阶段是数据处理和顺序无关的部分，大部分数据处理任务都在此时发生。提交阶段是需要将数据处理结果提交到数据库或真正触发业务的时候，这个时候如果不确保处理顺序才会发生问题。因此支持保序的Bolt必须要定义是否是用于提交任务的Bolt，Hurricane会在此类Bolt上支持保序。
另一个特性是多语言支持。因为在实际项目中我们会根据实际情况选择开发语言，C++并不永远是最合适的语言，因此支持其他语言调用Hurricane并与Hurricane集成是必要的。Hurricane目前都是用最高效的接口实现与其他语言的互操作，以减少互操作带来的性能消耗。目前Hurricane支持C语言、Java语言、Python语言和JavaScript接口。
感兴趣的同学，可以访问http://github.com/samblg/hurricane、http://hurricane-project.net和https://item.jd.com/11965338.html了解更多内部细节。
最后的最后，特别感谢@明明是我 （明明）在我准备这次分享过程中给予的大力帮助！今天的分享就到这，感谢大家的耐心。
SDN实战团分享（三十二）：ZStack架构及其网络功能简介
SDNLAB君• 17-03-16•1047 人围观
编者按：本文系SDN实战团技术分享系列，我们希望通过SDNLAB提供的平台传播知识，传递价值，欢迎加入我们的行列。
分享嘉宾：王为，ZStack技术总监，目前负责ZStack产品网络相关技术工作，在OpenStacksequence和云网络业界活跃多年，积极推动SDN在云计算中的应用和整合，多次在OpenStack Summit、Arch Summit上分享云计算架构设计与云网络技术发展等主题的演讲。
最近关注的重点包括：E***/VXLAN，OVN，Vyos，Contrail
大家好，我叫王为，目前在 ZStack 负责网络技术的一些工作。之前在 SDN 群里也做过一次分享，分享的内容是 VXLAN 的技术进展，偏技术一些；这次打算分享更多的想法与大家多多讨论。
先说些题外话
SDN 群里大牛很多，从平时讨论中学习到不少，我的背景相对更偏云计算一些，我对 SDN 的角度可能也与大家有一些不同。
举例来说，前段时间发生了一个关于 VPC 的大讨论，从吃瓜群众到技术大神纷纷被炸了出来参与讨论，可如果我们只说 VPC 最基本这些点：VPC 间相互隔离、允许自由的定义自己的网络各种资源，其实在 SDN 中很久前无论基于软件还是硬件都有实现。
VXLAN 的 RFC 在 2014 年就发布了正式版，OTV 更早，如果你去查 OVS 的代码记录，12 年底 Kyle Mestery（之前还是 OpenStack Neutron 的 PTL）就提了 VXLAN 支持的代码。
总之，NVGRE/VXLAN 等协议之争似乎很早就开始，也在很久之前已然结束，OpenStack Neutron 里你在很久之前就可以体验到任意选取 IP 段、配置网络资源，一些厂商的定制版甚至能够帮你任意设计多层的复杂拓扑。然而当VPC 讨论出来之时，可以看到很多人、用户对网络的了解实在让 SDN 背景的朋友汗颜。
为什么造成这种现象呢，我觉得可能有几方面原因：
技术和业界应用脱节，特别是国内很多客户部署规模下，对高大上的技术不感冒；
SDN 技术往往很难单独体现价值，除非在运营商等专业网络环境，大部分用户对自己的需求很难有明确的描述；
很多时候客户就想要“一把梭”，而不是仔细考量网路规模、技术价值、未来扩展这些
所以当我们探讨技术的前景、能力、想象空间的时候，可能也不妨考虑下这些，这样才能避免手持屠龙技但发现无用武之地或很难标准化地落地到客户的局面。
回到技术上哈，由于一众开源 IaaS 软件的流行，搭一个 IaaS 或者自己做一点定制已经变成一个入门门槛越来越低的事情，但这并不意味着 IaaS 本身越来越简单，有很多挑战其实是需要长时间解决的：
第一是执行路径长。有一句经典的话，叫做 IaaS 就是管理数据中心的 MetaData，这个活听起来没那么难——数据库存取数据，通过消息中间件或者其他可以远程执行的什么东西传递命令，idea 有了，就缺个程序员了。
用户想一键启动一个虚拟机，实则需要调配计算、存储、网络各类资源•、配置参数、跟踪状态、避免竞争一大堆活，而且需求可能不是启动一个虚拟机，而是一批可能上千个虚拟机，这对无论系统架构还是性能都提出了很大挑战。
熟悉 Linux 的同学都知道很多开源 IaaS 绕不开 libvirt、iptables、openvswitch、net namespace 这些东西，但是这些来自 Linux 生态系统的礼物有时并不万能.
一些程序没有 API，难以编程；
一些程序状态复杂且不提供全局的查询，需要自己的 Agent 小心翼翼的跟踪；
一些程序设计时没有考虑并发问题，需要系统自行控制运行的并行度，不然就是 Bug 横生。
更惨的是，这些程序乃至内核有时还会有自身的 Bug 或者设计缺陷或者在一些场景下性能跟不上。这些事情在小规模下都不太容易遇到，看起来都 work，但一旦拿来做一些严苛的测试，很快一个问题引发十个问题，体验极差，恢复困难。
再一个就是升级问题。升级几乎是各种复杂系统都绕不开的老大难，只要涉及分布式，升级难度就提高一倍；如果是微服务的，难度再提升一倍，举个例子 OpenStack 几十个项目，不知几百近千个进程运行在你的一百台服务器上，堆满了上千行的配置文件，想想都头大。
最后再说一个问题就是扩展的事情。特别是集成第三方厂家、产品这类事情，IaaS 由于要管理数据中心所有资源，这个活太大，往往需要一些帮手，比如我们在云计算里引入 ODL 的集成管理网络，引入 Ceph 管理存储，再集成一下 LDAP 整合企业账户，再整合一下 Zabbix 的监控系统，光举着一个例子就很痛苦了，如果考虑到 IaaS 面对的不是一个 ODL，而是可能有 OVN、ONOS、Calico 这些，还可能是 ACI、VTS、Contrail 等等，抽象和整合都具有很大挑战。
因为我对 OpenStack 比较熟所以常举一些 OpenStack 的例子哈，OpenStack 现在是光环最鼎盛的开源 IaaS，支持厂商众多，但是经过这么多年，一些问题依然很突出——抽象不满足厂商需求，比如 FWaaS，受到所有防火墙厂商的吐槽，由于路径长而导致在并发场景下不稳定，参考 ODL 上一个版本对 OpenStack 集成的设计和 Dragonflow 上个版本。
由于配置文件复杂，用户迷失在配置文件里，如果说配通了一个一定是要装裱起来流传在公司其他同事电脑里，万一哪天不 Work，就还得找之前那个哥们再研究研究，这并不是说 OS 设计有什么问题，相反我觉得很厉害，整合了数百个厂家的能力，联合几千号开发者，架构设计上必然有可圈可点之处，但是只能说 OpenStack 采取了一种它走的思路。ZStack 因为一些后发优势，参考吸取了很多其他 IaaS，从设计之初定下来一些原则。
尽量简单，到现在，ZStack 依然可以从官网上下载一个 war Java 安装包，一键部署，如果你用了定制版镜像（免去安装远程包的问题），大概十几分可能就好了。有人说其他 IaaS 很多经过优化或者厂商封装也可以啊，但是表象看起来类似，内里其实区别很大。安装了 ZStack 的管理节点上只有一个 ZStack 进程，这样避免了很多服务依赖、内部执行因为环境原因发生错误等等问题。
同样是“微服务”架构，ZStack 说实话看起来一点都不像，这是因为 ZStack 的微服务是基于线程的，得益于 Java 语言的成熟，ZStack 用线程来做微服务好问题。怎么实现呢？我们认为微服务的核心好处在以下几点：
信息流转透明——这样你可以很方便地观察服务状态、加入自己的插件
解耦——每个服务专心自己的事情，对外暴露有限的接口，提升模块本身的健壮
参考这些，我们通过在系统中运行独立消息中间件，线程通过中间件而不是内部通讯，每个服务达成独立的 jar 包，通过 build 工程整合在一起，由线程池调度执行，一样完成了这些好处，而且规避了配置复杂、管理复杂的一些问题。
说到消息中间件，我知道搞过 OpenStack 在生产环节的同学可能印象深刻，很多对 IaaS 或者分布式系统的调优都很注重消息这方面，ZStack 的用法比较特别：——没有使用动态队列。
我们分析了 OS 中消息中间件常成为瓶颈的原因，与动态队列关系很大，ZStack 通过静态队列、一致性哈希调度消息，很大程度避免了这些问题，因此说 ZStack 在很小的资源占用下完成上万的物理机资源管理毫不夸张——内部 CI 也常常会做这些测试，当然也有别的设计原因，后面也会提到。
不提上万个物理机，一千个物理机各种服务如果相互通信就是个很恐怖的事情，如果你用一些比较重的消息实现的话，特别是 RabbitMQ 这种有 Broker 的设计，ZStack 在 Agent 通信上选择了 HTTP 这种无状态、轻量级的方式，说实话 Debug 方便、库成熟，效果很好，无状态服务、异步消息可以说是 ZStack 架构的几个特点，在最近公众号发的一些文章也有讲到。
刚才提到了一致性哈希，是存储中比较常用的一个东西，在 ZStack 中，主要用来保证对同一个服务的操作总落到一个节点上，这样避免对资源操作上频繁加减全局锁。
只要能确保落在同一个节点上，通过内存锁或者队列，可以极大地提高系统的 API 吞吐，如上面第二个图所示，500个线程的线程池可以服务 10000 以上的并发 API 请求，由于 ZStack 是开源的，代码里有模拟器系统，大家好奇的话也可以自己尝试测试。
然而有个问题，管理平面性能很强，并不代表底层资源操作也很快, 这就系要无锁队列通过并发度来控制，避免对底层资源压榨太厉害，反而报出很多 Bug，尤其是像 iptables 这种很久以前开发的，一些地方没有适应现代高并发的调用这种场景。
这个是以前别人的分享数据，模拟器反映的是控制平面性能，真实环境下带了底层实际操作的效果，还有一个常见问题，就是组合、关联查询，由于 IaaS 中管理的资源众多，管理员可能需要查询在 条件 A 下查到的资源 B 关联的资源 C 的父资源的 D 属性，ZStack 在设计早起就考虑了这个问题，并通过技术手段允许用户任意组合、管理几乎所有条件。
所以之前号称 400 万个查询条件，无数个组合条件，由于 API 一直在增长，所以现在可能更多了，说到 API，ZStack 的 API 是消息式为主，同时提供 Restful 的，为什么这样做也会在后边谈与网络集成是说到。
下面聊一聊扩展性
Plugin-Driver 不是什么新鲜事，就不多说了，ZStack 由于内部是全异步——消息驱动的，每个消息会通过消息中间件流转，因此第三方集成时完全可以通过监听、发送消息而与系统交互，而消息在 ZStack 中往往不是触发一个什么过程，而是 Flow。
如果下载下来 ZStack 的代码，你会发现业务逻辑全都在一个个 Flow 里，这样做的目的是确保整个系统的稳定性，通过 Flow 控制流程，随时考虑失败的情况，这个 Flow 可以通过 XML 控制，方便扩展或者第三发代码的集成。
说完资源的创建，可以在说说删除，IaaS 中有很多资源，这些资源往往相互关联，如果你随意删除一个资源，很可能会得到一个提示，因为与 XX 资源关联，不允许删除，这样做自然也有道理——一来规避资源大规模误删风险，二来省下好多问题，但考虑到企业实际中不乏整个区域的搬迁、整片网络的迁移，整个账号的删除，ZStack 还是提供了一个集连删除的框架。
每个资源都会根据其依赖关系自动生成一个关联树，这样当你确定要删除或变更一个顶层资源时，下面的资源都会随之变化，而不是直接告诉你不可以修改——因为关联着 XX，等你删 XX，又提示关联着 YY……关于 ZStack 的测试系统我就不多说了，虽然其实也很有意思，但毕竟说了这么多还没到网络我都不好意思了。
谈谈网络。
计算存储网络里，目前大部分云计算项目、产品最痛的莫过于网络
一来所有问题都会先被误认为网络不通——虚拟机挂了，ping 不通；存储挂了，网不通；简直是云时代背锅侠，
二来网络解决的是连接的问题，不像其他资源相对独立、耦合
由于复杂系统的状态繁多，想在 IaaS 中解决好网络并不容易，简单来讲，IaaS 中的网络有几个流派。先说开源的，一派是自己撸一个网络管理系统，比如 OpenStack neutron，完全为 OpenStack 而生，对自身支持功能最丰富，利用 Linux 上丰富的软件资源，而且由于是默认选项，占用了不少客户，当然，这里主要说的是 Neutron + OVS，在纯软方案中用户还是不少的。
另外一种名头不那么正，但也是冲着云计算来的，比如 OVN、DragonFlow，前者由 OVS 社区开发，雄心壮志很多，但说实话挑战也同样不上特别是在信息同步、高可用这些问题。因为 OVS 以前是个单机程序，不需要考虑这些，自然经验没那么丰富，至今应用案例相对少，后者做的早一点，也曾被寄予厚望，架构上也不乏亮点，但支持功能数量和原生还是少一些，虽然发展情况也不错，但名气还是小了一些，除此之外又一个清新脱俗的存在那就是 (Open)Contrail，Contrail 做的很早，称赞者多，部署者少，在很多方面，Contrail 至今走在前列，但由于开源版与商业版的关系、本身的复杂性等等原因，我觉得在虽然在吃瓜群众中了解的不多，但是在企业市场下还是大有可为的。
另外还有其他有公司在支持的比如 MidoNet，和 Contrail 状况有些相近，目前很多私有云规模小，而规模大的往往要投入很多时间精力到架构设计、解决方案上，偏于项目而非产品（我指国内），所以像纯提供云网络管理这种比较难吃香，当然你可以在其他方面独树一帜，比如 DPI、可视化、性能等等。
这些都在模型上很迎合云计算的管理，也有一些不那么好直接集成的，比如 Calico，实际上 OpenDayLight、ONOS 也有类似问题，本身是独立项目，发展的也不错，没必要跟一个 CMS 死磕它发展出来那些“allowed_address_pair”、"address_scope"这些概念，这还是云网络管理，如果到了应用面，差异化就更多了，也因此 ACI 与 CMS 整合之路也往往不能一帆风顺。
ACI 本身个性极强，你也不能说有错，只能说两方个性都太鲜明可能不适合做夫妻，为什么会产生这样的现象我们认为与 API 设计也很有关系，如果 API 与资源模型是一个很优雅的 Restful 的资源模型，是很好看，但有些时候扩展起来确实不那么方便，由于要改数据库 Schema，导致用户用了你的集成之后升级、变更都与标准版有所差异。
ZStack 提供了另一种思路。其一是 API 以 消息形式优先，换句话说，我们不定义“标准”的资源模型，在代码中提供了一些供大家方便使用的模版，但你尽可以传你想要的消息。有人问如果我用标准的消息怎么办？数据库想加一些信息怎么办？ZStack 还提供了一个东西叫做系统标签，你可以把它理解为一个内置的 KV 数据库，集成的时候往往不是需要重新定义资源，而是扩展、改造，这是这样几乎无限灵活的标签带来了很大的可能性，既不影响升级和已有业务，还能在 API 中被传递使用。
ZStack 的网络模型是很鲜明的。大家查看文档都应该很快就能上手，但由于上面这些原因，我们在一些项目中为用户设计他该如何整合自有的系统或者心仪的 SDN 也极为方便，前段时间某大型互联网厂商尝试与 SDN 系统整合，整体并没有加多少代码，很快就能work起来。
所以 ZStack 非常欢迎各家厂商与 ZStack 提供整合，也不打算像 Neutron + OVS 实现一个非常复杂的 Driver，毕竟专业的事情还是要交给专业的人来做，在不久的将来 ZStack 将开始支持 VXLAN，我们比较了几家的 VXLAN 网络管理模型，觉得我们的还是蛮先进的。特别是通过 vxlan-pool 管理 vxlan（vxlan-pool 可以理解为 under-lay 网络），很多在其他厂商只能通过配置文件管理的事情，在 ZStack 都可以通过 API 管理，而且管理员可以轻易的批量管理、定义网络资源。
如果说产品能给用户带来好的体验，作为开发者的我们就感觉出力有所值了。ZStack 是一个开源系统，欢迎大家每个人去下载、尝试，欢迎网络厂商集成、支持，希望能和大家一起实现一个更好的 IaaS。
Q&A
Q：Hurricane应该是可以应用到控制器集群方面的吧？我觉得Squared高级抽象元语好厉害！
A：嗯，目前主要就是应用在控制器集群上，Squared元语主要是简化编程模型，它将底层复杂的通信和控制细节隐藏了，因此使用Squared 能够大大简化集群控制编写代码的复杂度和工作量。
Q：请问Hurricane可以保证消息不丢没，可以的话是怎么做到的?
A：Hurricane从架构层面保证了消息不丢失，每个节点收到消息的ack之前会暂时缓存消息，知道该消息被ack为止，如果后面的消息全部处理失败，Spout消息源也会重新从数据源获取原始数据并重新向集群推送数据，确保消息被最终处理。所以不会发生消息丢失。
Q：我想问一下，对于一些特殊的场景，而sdn对业务层本身没有感知能力，应该怎么解决:例如计算结果x，＞0分派给节点a计算，＜0分派给节点b计算，这种任务sdn又应该怎么样在转发阶段正确地转发呢？
A：这种情况可以使用字段分组解决，比如预先为目的节点定义标签，然后字段分组会根据字段的值将元组分发到具体的目的节点上。依赖于hurricane中心节点President实现具体的功能。
Q：比较过这个和RabbitMQ么？有什么优缺点？
A: RabbitMQ和hurricane 有本质上的区别，hurricane由hurricane framework 和 libmeshy 两个部分组成，其中libmeshy 提供了分布式消息队列的基础工具，而上层的hurricane framework 则实现了简单的消息队列，并在此基础上提供了强大的接口供开发人员使用，开发具体的计算功能和任务。
Q：我感觉这个还可以跟sfc结合，sfc组织的是vNetwork Function，而你这里组织的则是vFunction，更加广义化了，但是像sfc实现，在进入业务链的一刻就已经决定了流向，对于一些需要计算分支控制的流，显得就不是那么灵活了吧？
A：是的，这个结构中的Bolt可以用来做vFunction，作为广义化的vNetwork Function，实现Service Function。这里经过的业务节点都是在某个节点上计算得到的（通过分组条件），所以可以更为灵活。
Q：理解上那么消息到hurricane 后应该只是在内存里，消息是多个副本存储在不同节点吗，不然单个节点异常应该会丢消息的
A：是的，消息源缓存了最初的数据，而这些数据通过中央President节点缓存，President外接NoSQL做备份，所以会尽可能将数据保存下来，确保不丢失。另外，Hurricane原生支持Redis 和 Cassandra 编程接口，因此使用起来十分简单。
Q：怎么屏蔽底层设备的差异性怎么屏蔽，另外使用分布式实时处理系统hurricane做底层分发组件么？
A：嗯，考虑使用hurricane做底层分发组件。Hurricane 无法忽视底层硬件设备的差异，我们尽可能的将可以抽象的实体封装成了接口供上层使用，当然还有不足，也需要借助社区的力量逐渐增强。如果有兴趣的同学可以访问 https://github.com/samblg/hurricane 来加入我们的队伍。
由于hurricane framework 及其底层通信组件不依赖于任何第三方组件，因此在开发过程中尽可能隐藏硬件调用的细节，又因为是纯C++开发，从理论上讲在特定平台编译后都能够正常工作。（ARM 和 MIPS 等也在考量范围内）
Q：请问Hurricane+SDN有在做controller prototype实验，还是在理论概念阶段？
A：更多的是理论概念阶段。
Q：集群的管理者是一个节点还是集群，怎么做的高可用？
A：目前集群的管理者是一个节点，只不过可以使用热备模式在管理者出现问题的时候再选择一个新的管理者，因此通过这个机制，系统会较为快速的failover到另一台机器上，并让另一个节点作为管理器继续工作。
标签：实时处理,Hurricane,网络,任务,消息,SDN,ZStack 来源： https://blog.51cto.com/u_15127593/2745718