2016年，网易杭州研究院（以下简称“杭研”）成立十周年之际，我们推出“十年•杭研大咖说”系列访谈文章，针对亲历杭研核心技术体系变迁的数位技术大牛发问，揭秘网易云背后的技术脉络、研发思想和技术人成长的故事。本期的受访嘉宾，是杭研云计算平台产品部首席架构师尧飘海。
尧飘海目前负责网易容器云平台 – 网易蜂巢的建设，致力于自动化平台的架构和实践，旨在提高产品开发效率。作为互联网产品开发和基础建设的老将，以及Pomelo项目（网易开源的基于Node.js的高性能、分布式游戏服务器框架）的主要开发者，尧飘海对分布式系统设计开发、性能调优，系统架构有独到的经验和理解。他认为，容器的编排服务才是真正考验和体现应用弹性、DevOps能力的关键所在。在本次采访中，他详解了网易蜂巢根据业务需求所做的关键优化工作，并对未来的技术架构做了分析。
网易杭州研究院云计算平台产品部首席架构师尧飘海
首席架构师的感悟
从您毕业加入网易至今已有7年，您（参与）开发了哪些系统？为什么选择云计算架构师作为现在的职业？
尧飘海：大家好，我从毕业时加入网易到现在参与过不同的业务平台的开发，包括互联网、游戏、IM等，再到云计算平台的设计与开发。通过多年来和不同的职责的同事和朋友交流沟通，我慢慢体会到不同职位的不同价值，特别是技术类的开发人员。可能大部分人会认为开发只是作为业务的执行者，但是其实每一个技术人都不同的技术情节，希望自己能写出来的代码能像爱艺术作品一样，有更长的生命力，有更好的价值，更多的服务于用户。当前，云计算行业的影响力已经是随处可见，每个用户或企业现在不再是讨论要不要上云，而是如何上云、上好云、上新一代云等。这也是云架构师本身的职责和价值所在。
在杭研的开发工作中，有哪些让您印象深刻的难题？您是如何解决的？
尧飘海：杭研的发展体系包括了技术和产品，技术开发在很多产品成长过程是非常重要的一环，也是必须的一环，和其他公司一样，我们也会遇到各种不同的问题。尽管每种问题表现出来的形式是不一样的，最后的结果是无非是成与不成二种，把这些难题分类出来，包括沟通、流程、技术、业务等风险。作为技术人员，我开始更多的是去思考如何通过不同的技术去解决不同的问题，在解决的过程中，有没有充分的沟通和信息透明，有没有更好的技术协作，解决后有没有及时的反馈和总结并在下次项目提前预防；后来，随着承担的职责不同，会越来越关注技术对用户的价值和影响，从上到下、从左到右地思考产品需求是否真的能够满足用户的发展。
网易蜂巢是技术、知识、经验的整体输出
网易蜂巢强调提高产品研发效率，分解出来也是当前的容器云都谈到的弹性扩展、DevOps能力，包括跨云部署，您如何理解网易蜂巢和其他容器云平台的主要区别？
尧飘海：在容器云平台中，容器只能保证环境的一致性，跨云部署是其基本的能力，这是所有的容器云平台都支持的，但我们更多的工作是如何保证很好地协调这些容器来满足业务的架构需求，也就是容器的编排服务，这些才是真正考验和体现应用弹性、DevOps能力的关键所在。除此之外，企业级的容器云需要IaaS、PaaS能力的支撑，而提供稳定的自建基础服务需要一个很长的积累过程，包括丰富稳定可靠的PaaS服务也是如此，网易蜂巢依靠网易10多年的技术积累和大规模的线上产品验证，为只专注于业务的用户提供容器云服务，帮助他们提高产品开发效率，改变软件生产过程，是整体的技术、知识、经验的输出。
网易蜂巢选择基于Kubernetes提供编排服务，主要是看重它的哪些优势？Kubernetes的二次开发主要在哪些方面？
尧飘海：Kubernetes也是Google和社区的技术、知识、经验的输出。首先，Kubernetes是由Google的Borg团队的主力开发人员主导开发和维护的，Borg在Google内部经过了10年左右的验证，每周支持20十亿的容器生命周期管理。其次，Kubernetes的整体的设计理念和微服务架构的趋势非常吻合，对各种容器技术的细节支持也较完善。最后，我们是在2015年初做的选择，当时整个容器管理的生态和各大开源对Kubernetes的支持，及其他的容器集群管理工具的不成熟，也是我们在思考的问题。目前Docker、Mesos的发展越来越快，确实是在参考Kubernetes融入不同的新特性，这也佐证了我们的选择。
目前网易蜂巢对Kubernetes的二次开发，除了完成支持单集群多租户的模式（很大的工作量）之外，还包括如下几个方面：
- 容器网络互连、网络多租户，平坦化的网络结构轻松解决容器互联和可视化问题；
- 有状态容器支持，包括故障恢复与迁移的能力，保证用户对有状态业务的数据持久化需求；
- 编排服务多租户支持，根据可用域调整调度算法，优化编排服务性能，满足大规模容器集群隔离调度；
- 应用不停服发布，支持原子更新及不可变服务交付，实现对业务平滑过度，不损失一丝用户体验。
谈到多租户，容器隔离、安全的解决与性能损耗是否存在矛盾？
尧飘海：根据业务场景模式的目标作为主要解决的问题的依据，其实就不再是矛盾了，只是从不同的特性里面排序选择，比如是公有云还是私有云，是互联网应用还是游戏或者大数据场景。根据给定的条件去选择，就相对容易多了，如果没有限定条件去思考问题，只会把问题对立起来。
安全是相对的，可能没有任何系统能保证绝对100%的安全，用户会接受相对安全的等级，如果能做到一定的安全等级的划分，就比较好处理了。网易蜂巢的目标用户是公有云的企业，所以我们目前租户之间天然隔离，同时租户内采用了虚机+容器组合的方式，可以比较好的解决这些矛盾；如果有企业用户更关注对性能的极致追求，网易蜂巢也提供了不同的解决方案。
冰山之下的IaaS经验
能否介绍SDN方面对Neutron的深度二次开发？采用Neutron是因为OpenStack的历史原因，还是说Kuryr、Flannel、Calico这样的技术在隔离、性能等方面确实都不如Neutron更符合网易的需求？
尧飘海：网易蜂巢根据云计算的业务需求去做不同方面的优化，主要包括易用、安全、性能等方面。易用方面，包括租户容器网络内网扁平化和外网的直接挂载等；安全方面，包括网络带宽QoS设计原则、L2/L3/L4分层次的网络过滤等；性能方面，包括基于VxLAN的网络小包过载优化、Intel DPDK的性能加速等。
由于网易私有云2012年就可以线上业务的使用，底层的网络架构非常的复杂，使用范围很广，无论在性能还是稳定性都方面都经过大规模的业务考验并在不断的优化，本身也有专业的网络开发团队在开发和维护，具有完全的技术把控和机房网络控制的能力，所以这个架构使用在容器云平台上是水到渠成的事情。当然，我们也同时对和Flannel、Calico等网络技术方案进行过相关的调研和验证，发现在一定的使用场景里面需要新的投入，同时要在短时间满足业务的需求，还是比较困难，特别是后续存在大量企业客户对网络的不同接入，需求会更复杂。
网易蜂巢采用了高规格的硬件设备，包括全SSD，但是为什么会选择则Ceph存储？对SSD的支持、I/O等方面的一些槽点，我们如何解决？
尧飘海：网易蜂巢后端本身是支持二种存储类型的，包括基于iSCSI协议的NBS和基于Ceph存储，分别满足企业用户在不同的场景的使用。用户默认是使用Ceph的存储，Ceph是采用分布式架构设计的存储系统，具有高扩展、高可靠和高性能特性，并且经过了大量的用户线上的验证。在一些特殊的场景下面，比如系统重启或者对快照深度的支持等方面，确实需要对Ceph进行优化改造才能很好地使用，我们减少重启过程对集群正常I/O性能影响，降低的程度到达10%~20%，同时有效地缩短了重启恢复所需时间，重启单个OSD从10分钟减少到40秒左右。
除此之外，网易蜂巢容器还提供支持本地盘和远程盘的特性，满足不同的企业用户在性能和可用性的选择需求，而不需要考虑额外的成本的追求。随着规模的不断发展，也将遇到更多的发挥性能极致的机会，用户对性能的追求也是网易蜂巢对外技术能力的输出的一部分。
容器架构前瞻
Docker似乎已经认为Serverless是微服务的方向，AWS、Bluemix也都已经在探索Serverless Computing，作为架构师，您如何看待这项技术对未来云计算的意义？
尧飘海：Serverless是当今软件架构领域最热的话题之一，用于描述依赖云端服务实现对逻辑和状态进行管理的应用。这个概念直到2016年上半年才由Martin Fowler老爷子比较系统化地阐述出来，之前可能存在各种不同的技术实践，AWS从2014年就开始在践行相关的理念和技术推广（Lambda）。Serverless代表一种技术架构的创新，也可能成为未来的技术趋势，然而目前在国外也鲜有大型成功案例，在中国的落地发展可能需要更长的时间。微信最新推出的应用程序是相关领域的部分应用和实现，同时阿里、网易也在对Serverless 架构进行探索。从我们和相关专业人士以及用户的交流来看，这种架构对云生态的系统建设的依赖较高，从跨云能力输入到输出，还是需要统一的标准和接口，才能比较好地流行起来。从技术的创新角度来说，引导大家更好地思考，对未来云计算具有非常重要的意义。
在容器之外，Unikernel也是当前的一个热门技术，Docker公司也收购了Unikernel Systems，您如何看待Unikernel的应用潜力？
尧飘海：Unikernel在2016年初被收购，以其不同与传统虚拟技术为出发点，通过使用libOS构建的具有专门用途的单地址空间机器镜像，整体技术堆栈的路径更短，因此尽管存在各方面的争议，Unikernel在对大小、速度、安全、兼容性等特定的需求有很好的使用场景，可以让容器运行在物联网设备或者一定的数据中心服务器的硬件之上，甚至未来也不排除移动端APP采用容器来运行的可能。不过从总体来说，由于Unikernel在调试和诊断等技术还有很长的一段路要走，比如怎样满足永远在线、有状态等业务，发展多年的操作系统的技术，以及传统使用技术债等，要改变还是需要努力的。杭研目前主要还是专注软件生产过程的DevOps，同时保持对这些新技术的关注。