在容器云市场竞争愈发激烈的今天，网易云基础服务(网易蜂巢)的负责人陈谔确实是一个大忙人。不过，在陈谔的脸上，我们很少能够看到一丝急躁，似乎十年的磨炼足以让他面对任何挑战都能做到有条不紊。
在陈谔看来，技术架构的剧变发生在 Web 2.0爆发之时，之后至今只是平缓期的不断优化，而网易杭州研究院(下称杭研)经历了那个时刻。
他分享了此后杭研网易私有云、网易云基础服务(网易蜂巢)的研发思路、技术优化路线以及研发管理心得。他表示，云计算的研发是一定要能够提升业务研发效率的，SDN、容器、编排管理等技术框架的选择及应用，都是要回归于业务架构。意外的是，他还提出编程语言的选择对云计算研发的影响会越来越重。
(网易杭州研究院云计算平台产品部总监陈谔)
一、杭研十年印象
Q：请先介绍您在杭研的早期工作经历，参与过哪些系统的设计和开发?
陈谔：我负责过网易博客、网易监控平台、网易消息推送平台以及易信公众号系统，从 2012年起就一直做云计算，从网易私有云、网络虚拟化架构设计，再到现在的网易云基础服务(网易蜂巢)。
早期的网易博客个人首页，是我开发的，博客的认证授权框架，包括一些和数据库对接的中间件，运维方面的类似持续发布、持续集成的东西，也是我的工作。
Q：作为杭研的***批员工，您心目中这十年来杭研***的技术成果是什么?
陈谔：***个，我们几乎是最早做分布式关系数据库的，而且是把分布式关系数据库直接用于 Web 2.0的产品上，这对于杭研是一个很大的成就。
另一个，云计算平台的应用，对整个网易公司的互联网业务带来很明显的推动作用，因为当时我们对服务器的管理、业务的增长都已经到了一个瓶颈，必须有这样一朵云，才能实现新的突破。我个人认为这两个方面是杭研很重要的成果。
(网易私有云架构(2014年))
Q：回顾十年，在做私有云和网易云基础服务(网易蜂巢)之前，您参与过多个网易系统的研发，其中哪些是您至今仍然印象非常深刻的经历?
陈谔：早期从头开始做的东西让我记忆犹新。我刚进入网易的时候，正值 Web 2.0概念爆发，整个技术挑战、技术方向突然和以前完全不一样，关注点变成水平扩展、高并发、大吞吐量等。我是网易***个做 Web 2.0业务的(网易博客)，不仅做博客本身的属性，同时还做博客的运维，包括版本控制等等。从那个时间点到现在，整个技术体系的发展相对平缓，就那个时间突然跳跃了一下，需要不同的运维手段，做互联网的似乎变成了做运维的，所以我的印象是比较深刻的。
回头来看，那个时候杭研大约有20号人，还分为前台(负责中间件和产品)和后台(负责数据库)，效率还是很高的。
Q：这些经验对后来网易云基础服务(网易蜂巢)的研发有什么影响?
陈谔：其实包括网易云基础服务(网易蜂巢)、网易私有云的研发，都不是从纯粹的运维工程师或者系统工程师的角度来做，因为我们以前都是做中间件、做业务的架构师，设计云平台的时候，我们都会思考如果自己在上面开发业务系统，能否实现很高的研发效率。
网易云基础服务(网易蜂巢)的研发初衷，就是因为我们觉得只是把 IaaS系统做好，对提升研发效率的作用还是很有限的。网易云基础服务(网易蜂巢)的技术路线，包括一些细节的决策，包括网络的设计，包括 Docker容器、 Kubenetes编排技术的选择，都是从业务架构去考虑的，是来自于前期研发工作积累的经验。如果我们原来只是运维或者系统工程师，现在的网易云的形态可能是有很大的不同的，哪怕是 Docker的使用方法，都不一定是现在这样的。
二、云计算系统设计法则
Q：从业务架构的角度考虑，设计云系统或者分布式系统有没有一些通用的黄金准则?
陈谔：我们做云计算、分布式关系数据库，都是分布式系统，我认为最核心的是要懂得可以取舍哪些东西，也就是要非常清楚地掌握它的非功能需求是什么。
因为分布式系统架构的方式、实现的技术，这十几二十年没有太大的突破，该有的理论很早就存在，后面的 CAP原理(一致性、可用性、分区容错性)也只是归纳性的东西。所以，最重要的还是要知道取舍，比如 CAP的取舍，还有系统的复杂性与可运维性的取舍，功能很强大但是运维很麻烦也是不行的。
还有一点，从我个人的偏好出发，采用合适的编程语言做分布式系统也是一件很重要的事情。我们采用 OpenStack有很多坑，其实就是 Python语言带来的——不是说 Python不好，但是它很多的机制，在公有云的发展方向上会带来一些性能、并发的瓶颈。Go语言出现之后，一大批的公有云产品都是基于 Golang开发的，Golang比以前的语言在并发、性能、安全性等方面做得更好，如果是用 Java来写这些系统，要达到一样的性能效果，需要的研发周期会长很多。所以，从长期的发展来看，编程语言对云计算研发决策的影响会越来越重。
Q：能否介绍您对编程语言、编程模型有什么特别的偏好?您还在编写代码?
陈谔：我个人不会执着于“PHP是世界上***的语言”之类的想法。比较流行的语言，包括 Erlang、Ruby、Java、JavaScript 等，甚至像 Rust这样一些偏门的语言，我都会去了解，因为它们擅长于解决某些方面的问题。
你可以发现我刚才没提 Go，因为我先接触 Erlang，后来又接触 Rust，从我的角度，Go要解决的一部分问题，我可以直接用 Erlang来写，而如果是系统编程，对 GC很敏感的，我会倾向于用 Rust来写，如果让我用 Go来写，我好像没有什么动力。包括之前给网易博客做运维需要的脚本语言，我希望用起来简单，有成熟的库可以依赖，选择了 Java技术栈，虽然 Ruby语法特性更好，但是 Java生态可以依赖那些很好的库。所以，能产生直接的效果、擅长解决某些问题，这就是我选择编程语言的偏好。
至于编程语言的特性，个人更倾向于往 Functional的方向发展，包括一些解决异步方面的问题，个人觉得 Reactive这种模型，更加偏向于 Functional，会更让人喜欢。因为它其实是描述解决问题的方法，而不是密密麻麻地写一堆指令去描述解决问题的过程。这是我接触各种不同的语言之后逐渐养成的习惯。
落实到我们整个团队的开发工作，语言的选择其实是很实际的：OpenStack就只能选择 Python;网络、内核相关的东西，就只能选择 C;Docker、Kubernetes的选择必然是 Go。当我们设计一些适配容器的东西，比如写一个Kubernetes的Controller，虽然有些工程师之前擅长 Java，但是我会告诉他去学习 Go，用 Go来写。所以这和我们的技术选型是相关的。其实 Google也选择这种组合，这是很有道理的。
我个人目前也会写代码，但是不适合和团队协作，因为团队在等待我提交某个模块或者修复某个 Bug的时候，我往往正在进行一些无法离开的沟通工作，这会影响项目进度。所以，我现在只能写一些 Demo，写一些东西去体验我们自己的网易云，尝试我们的接口。
三、厚积薄发网易云
Q：网易云承载网易95%的业务，您如何看待网易云基础服务(网易蜂巢)所扮演的角色，以及能够做到95%的关键因素?
陈谔：首先，网易云能够承载网易95%业务的背景，是网易的互联网技术栈是很统一的，因为所有的中间件、公共技术解决方案都出自我们杭研，这使得我们开发一个云平台把一些服务封装提供给大家变得很容易。同时杭研掌握了网易运维体系，运维是必须和云计算配合的，这是***的基础。
其次，网易的互联网业务都不小，虽然业务的数量不是太多，但是每个大业务对吞吐能力、性能要求都是很极端的，基于网易 19年的互联网技术积累，我们花费大量的精力进行云化，在 IaaS、网络方面的投入是很大的，而网络和存储就是云计算平台研发最难解决的问题。
以网络为例，从***个版本上线开始，三年之内对于整个网络的架构、网络的优化，我们投入的力量是***的。最开始只有三层，后来完成二层的格局，然后把网络性能从只能跑千兆网络，做到一直到接近万兆，这就经历了一个很长的优化过程。网络问题解决之后，上面的业务就好集成，因为计算虚拟化是相对比较成熟的，但各方对网络实现优化的差异其实是很大的，有些方案连千兆都做不到，尤其是做SDN之后。
再说网易云基础服务(网易蜂巢)。我刚才提到过一个逻辑，在做完传统 IaaS私有云、网易业务迁移进来后，我们监控大家使用云的情况，和业务线的技术部门访谈，发现 IaaS对业务部门开发效率的提升是非常有限的，有时候甚至起到了反作用。为了解决这个问题，我们才做的网易云基础服务(网易蜂巢)。
网易云基础服务(网易蜂巢)的原型，是一套内部的 OMAD系统，为了解决业务的 CI/CD流程而开发，因为当时容器技术还不成熟，做完这个系统之后，我们发现它对 Runtime的管理存在一些问题，比如各方需要不同的 Runtime，需要 update的时候，或者做集成的时候，就会碰到很多环境的问题。后来我们发现了 Docker容器，就用 Docker改造系统，把它做成网易云基础服务(网易蜂巢)，***做成现在的形态。以 PaaS融合 IaaS，业务部门无需特别考虑资源，也无需对应用做太大的改变，即可实现应用弹性、DevOps。
同时，我们也开始选择了开源的技术栈，因为我们发现，很多东西如果能够用社区的力量，我们也能掌控这个东西，或者能够贡献到上游，这个东西的生命力会更长久;反而自己折腾的一些东西，过几年被废弃的可能性会很大，投资回报是很低的。
Q：这些经验对后来网易云基础服务(网易蜂巢)的研发有什么影响?
陈谔：在用 Neutron之前，Nova是一个平坦的大而全的网络，分割成很多的 VLAN，要搞很多路由，要设很多的 IP规则做隔离，二层的扩展能力就存在问题;而且安全组的规则、一致性、网络的调试，已经变得非常复杂，有个地方是不通的，没有人知道是怎么回事，这个问题愈演愈烈，所以我们开始尝试 Neutron，并且用 SDN的方案。
我们胆子还是比较大的，有些实践会同时保留经典网络和 SDN，默认提供经典网络，我们直接默认提供 SDN的私有网络，这个性能要求非常高，我们就要拼命优化这个东西。现在，从我们业务的角度，一个二层就够了，很多个二层可能还不相通，还会增加复杂性。一个二层里面，能支持数千个虚拟机节点;从容器的角度，一个租户下，一张网络支持数万个容器应该是没有问题的，当然一般也不会支撑这么多。这是我们目前的网络状态，当然以后要适应新的 IT架构，有可能会支持大二层网络，二层网络之间有路由，这是以后的规划了。
四、做好产品研发的关键
Q：您提到了很多好技术，但是要把它们整合成为一个云计算平台产品，达到“网易出品，必属精品”的境界，有哪些关键因素需要注意?
陈谔：把技术交付给用户的时候，一定要考虑用户的真正场景和他的使用方式，了解有哪一些性能是用户特别关注的，这是很重要的一点。比如刚才说，不应该由用户处理复杂性，否则，很容易做成一个看似很高大上的实现，某项功能很复杂，结果用户不是这样使用，或者他根本不愿意去应对这个复杂性。
有一个很简单的例子，以前有些虚拟网络是通过 NAT去提供的，有一些浮动 IP，我们设计的时候，就要避免这种 NAT出去一个浮动 IP的情况，因为这可能会造成用户做长连接业务时，以前能用的写心跳的程序，突然就不能用了，或者用户程序依赖本地 IP，但是本地看不到 IP，他的业务上来就发现不行了，还得改业务。
我们强调，有时候，你感觉你的设计是高大上的，性能也很好，但是用户真的上来的时候，他的感受不一定是这样的。所以，一定是考虑用户怎么会使用这个技术去解决他的问题。
Q：所以还是需要一些非技术***的折中?
陈谔：对。包括 Docker也是这样，比如网易云基础服务(网易蜂巢)如果直接用 Docker的理念，那是很极端的，它觉得根本不应该存在有状态的、不能随时掐掉的业务，但实际上我们看到用户还是需要有状态的、可以保证硬件故障或者宕机时能够恢复的有状态容器——他可能开一个数据库，不可能从这里宕机，再从另一个地方起来，至少短期之内还做不到这样的事情。所以你必须先让他把业务架构搬到云上面，先能用上 Docker的一些镜像、部署的好处，再逐步帮他做解决方案，让他用上你提供的更多好处，否则他搬都搬不上来。
Q：那么从网易云基础服务(网易蜂巢)的角度，目前优化的主要方向都有哪些?
陈谔：首先，作为云计算基础服务，永远要提升性能指标，包括吞吐能力，而且性能指标必须平稳，不能有太大的波动，所以我们在块存储、虚拟网络性能方面不断优化，希望也能满足那些极端的情况。我们认为，只要做基础设施，就要不停提升网络 IO性能，就会有很大的效果，这是直接影响客户业务体验的。
还有重要的一块是容器的编排管理，不仅要考虑用户业务在线上怎么做编排管理，还要从研发、测试的角度来考虑怎么利用编排管理的服务来支撑研发的过程。同时 Kubernetes也在不停地发展，包括对两地三中心的支持，我们会保持容器编排管理的持续跟进、优化，使得用户的业务能够在尽可能短的时间内获得到容器云技术***进展的支持。
Q：您会如何带领研发团队去实现您的目标?
陈谔：我目前带领最多的就是研发工程师。我认为很重要的一点，就是要给大家学习、表现的机会。我们根据研发路线的需求提供一些可以学习的方向，通过学习，还能够筛选出一些能力基础很好、有发展潜力的工程师委以重任。所以技术团队的学习、交流的机会很重要。同时，技术团队的学习和实践有了积淀之后，要推动这些人去分享，不管是技术文章，还是技术课堂，优秀的工程师，无论对内对外都要有表现的机会，让他的价值得到肯定。
另外就是标准化的管理、目标的设定。从技术的角度，我更倾向于设定目标的管理，而不是 KPI的管理。我会告诉大家我们都能认同的目标，比如网络模块应该做到哪些目标，网络抖动可以下降到多少，网络吞吐量可以到多少，让他自己在理解项目整体目标的基础上，再把自己的量化目标定出来。
分享我们做过的一件很有意思的事情：
网易云基础服务(网易蜂巢)最初的版本，从申请资源开始监测，到虚拟机、容器全部启动，大概需要两分半钟。我认为这个速度太慢，当时就提出要求，希望20秒就能把容器启动搞定。大家觉得这个事情太困难，几乎是不可能完成的。但是接下来分解目标，我们不是制定哪个组几秒钟的 KPI，而是分一些阶段性的目标，先优化到1分钟，再到40秒，再到20秒，让大家看自己的环节，还有哪些潜力可以挖掘，怎么可以一步步地进步，设定一些业界有挑战的、有价值的目标(不是拍脑袋，而是根据业界先进水平或者理论来决定)，不断迭代，朝着目标前进。***，我们确实实现了在20秒左右完成一个容器的建立(除去镜像传输的时间)。在云计算这个复杂系统里面，做到这一点其实是很不容易的。
