在容器云市场竞争愈发激烈的今天，网易云基础服务(网易蜂巢)的负责人陈谔确实是一个大忙人。不过，在陈谔的脸上，我们很少能够看到一丝急躁，似乎十年的磨炼足以让他面对任何挑战都能做到有条不紊。
在陈谔看来，技术架构的剧变发生在 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秒左右完成一个容器的建立(除去镜像传输的时间)。在云计算这个复杂系统里面，做到这一点其实是很不容易的。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
