谢谢大家！我是来自于大河云联的翁建毅，今天主题是SDN实践之路。我们是一家基于SDN的初创公司，成立一年多，跟大家分享一下这一年多我们在SDN实践上碰到的问题，以及背后的思考。
我之前的工作经历主要在互联网基础架构和云计算方向，所以今天的分享会更多的站在程序员的角度、程序开发的角度去讲。公司创立一年多，主要专注在SDN广域网这个方向，我们主要提供云和数据中心、数据中心和数据中心广域互联的解决方案。目前CanalON率先在国内正式商用，大河云联总部位于杭州，提供杭州、北京、成都、广州的大量研发工作机会。简历投递：zhaopin@fabric4cloud.com
什么是SDN？老调重弹下。传统的网络像是我们创造了一些小人，这些小人精通几种语言，我们把小人连接在一起，他们通过一定的协商会话，手拉手组成了这个网络。SDN是我们把这些小人弱化了，变成一个一个木头人，类似棋子。紧接着我们造了一个机器人去挪动这些棋子，下这盘棋。这幅图左侧的那个人跟我们每次做版本发布的时候，我内心的写照是一样的，我们做了一个机器人，当它开始下棋了，我不知道它会发生什么事情，内心是很忐忑的。SDN的核心是为了造一个会下棋的机器人吗？不完全是。SDN的核心是开放，开放管理接口、开放数据、开放网络管理智能。只有开放才能让我们用更创新的方式去玩这个网。我们几年前开始讲SDN的时候，谈的更多的是Openflow和控制器，今年大家都在讲的是场景、业务编排，那是因为开始应用了。随着应用的推广和深入，也许明年大家就会开始谈到SDN的运维（SDN ops）、数据，再下一步会谈SDN智能。这是发展的必然趋势。
我们在初创的时候，感觉这条路是这样的，我们定了一个目标，做了一个计划，路是直的。一年发展下来，回头去看这条路，很不好走。有很多问题、很多坑。我们的方案应用的主要场景是全球骨干网，解决SDN全球骨干网的管理和调度等问题。当时生态蓬勃发展，控制器也有很多开源项目，能拿到的方案，都是上面是一个Controller，下面直接管理几台SDN交换机。但把这种架构直接应用到一张全球网络的管理，有点怪，很不合适。我们面临的最大问题是延时变大了、稳定性变低了。当时提出了一些设计思想，包括三条铁律，分享其中一条是：控制转发分离，限制控制平面异常时候对转发平面的管理能力，提供一个业务的保护，就像机器人三定律的不可以伤害人。一个中心思想是中央控制、分区自治，这是什么意思，在广域上如果所有事件，都汇报到中央控制器处理，那故障收敛等等都无法得到保障。我们进行了局部自治权的下放。
第一次提出的架构是，我们设计了一个中央的控制器叫CanalCore，边缘控制器当时采用了开源项目O。我们在实际使用这套开源控制器的时候碰到了很多问题，比如Barrier Timeout机制不成效，Node连接不稳定时候产生的UP/Down的事件乱序，统计线程异常停止，DataStore的数据不一致等。紧接着在第二版架构中，我们实现了自己的边缘控制器CanalEdge。同时增加了业务编排层SmartControl，编排层对外提供了一层完整的API，CanalAPI。我们基于这套API实现了一个Portal管理界面，也跟一些云做了集成对接的尝试。
完成了第二版架构的实现后，就像你造了一艘船，只有真正放到海上才知道会碰到什么问题。就像这张图一样，本来风平浪静的航行，也许突然就会碰到一个深渊。列举几个问题：
第一，网络设备跟控制器的连接断开了，它是脱网还是宕机了？如果只是脱网了，控制器不应该去干扰它的，因为数据的正常转发还在走。但如果宕机了就马上要干预。
第二，带内还是带外管理？一张广域的SDN网的节点我们怎么样去管理它？如果是做带外网，相当于又要建一张IP网。
还有一个是控制层和转发层的流表一致性。如果控制转发发生了不匹配，肯定是要会出致命问题的。怎样保证控制层转发层的流表一致性，包括控制信令可达、时序等等一系列的问题。
我们踩过的坑很多，这里面有很多很麻烦的问题。
接下来我讲一下部署。SDN的方案，我们去网上搜一下，你会看到SDN的架构都是非常复杂的，有各种层次，很丰富的组成。但是怎么部署，它是一个软件还是一套平台？这个东西不知道大家有没有概念，当这样的东西出现在你面前的时候，你怎么样去落地它？这里面我们也碰到了很多很有趣的事情。一开始的时候，是以一个平台化的视角要去做这个东西的，觉得它是一个网络即服务的平台，就应该按平台的思路去设计。做着做着，客户说，给你一台服务器，你把你的东西装上去，这就很尴尬了，我们做的集群化的东西至少是三台起，客户说我给你一台服务器，你自己玩吧。我们又改，改成了类似软件交付的模式，就像今天很多商业化的控制器卖软件的形式一样。紧接着他给了两台服务器就问你能不能做高可用？今天我们在高可用上也做了很多努力，包括做了选举的改善、防脑裂、脏数据保护等功能。为什么一开始就给了一两台服务器？因为他可能只有三台交换机啊。
那什么时候会出现集群？这个平台不可避免最终要提供给大众去使用，它是需要平台化的。什么时候去做平台化。我们现在的策略是在边缘的这一侧会软硬件一体化的提供控制器，在中央控制器、编排以及往上业务可以提供平台化的解决方案。这也符合现在客户的实际情况，体量都是由小到大，我们可以很灵活的适配和部署。面向两种不同的场景，在南向的管理上，我们使用软硬件一体的控制器，北向面向于广大受众，他是一个平台，会以集群化、互联网化的方式去解决。如果两个乱搭，会很奇怪。比如今天你买了一个控制器的软件装在一台服务器上，然后宣称我要开放给整个互联网的用户去使用，这是不现实的。
接下来讲Ops，为什么叫SDN Ops？网络运维的代名词是CLI和流量图，软件运维的代名词是什么？大家看看这张图，他是由一整套工具链组成的，这是两个完全不同的领域。研发内部，会讲持续集成，那么最近大热的Devops，是平台化软件从研发往运维延伸，是在讲持续交付。那么SDN可能还要再往前一步，服务交付。从持续交付到服务交付，这其实是有很多挑战性的工作的。你提供给最终用户的是他可以点点鼠标就可以购买的服务。所以SDN Ops会包含这么一整个链条，最难的地方是在于人、在于团队，怎么样在一个有限的团队里，进行跨界体系的融合，是比较难的一个地方。
最后讲一下数据，我们做了很多很切实的工作，从左到右是数据从产生、搜集、处理、存储到最终的消费，这是我们的整个DataFlow。这里面会包含流量、流速、日志、事件、拓扑快照等等数据。我们在存储层设计了一层统一数据源，只要是在SDN网产生的数据都可以被拿来消费。在应用消费侧，可以借助我们提供的CanalData框架，简化数据的应用。我们在上面开展了很多数据的分析、统计工作。除了这些数据图表。最右侧那个图里是一段代码，我们在线玩数据的一个小平台，我们的数据工程师可以在这样一个平台上写一些简单的代码，验证他的想法，去做一些数据分析。一旦比较成形之后，我们就会把它迭代到现在的产品中去。
最终我们形成了这样一套结构，由SDN业务、运维支撑和数据组成，初步完成了三大组件的布局。当然，还有很长的路要走。运维支撑、数据，是SDN核心业务外，需要大家一起去努力的。
随着SDN应用的深入，网络将变得不可思议的复杂，人终有一天将管理不过来，这一时刻即将来临。人工的网络控制会被机器决策取代，由数据驱动。打个比方比如速记员这份工作，最终打败他的不是更快的速记员，而是机器，是机器学习，像最近开的一些会，它的速记是由机器直译出来的，准确率已经超过人了。所有这些前提是网络的开放，开放管理、开放数据、开放智能，我们才有这么大的想象空间。
最后，感谢SDN生态，因为开放给了我们这次创新的机会，也感谢风雨同舟的伙伴们，让我们一起为梦想坚持。谢谢大家！
