题图：Afterquake by Angelo Giordano@pixabay
编辑：冷锋
文章转自网易云（微信公众号Netease_cloud）
刘超
网易云首席解决方案架构师，代码级略懂OpenStack、Hadoop、Docker、Lucene、Mesos等开源软件，10多年的云计 算架构与开发经历，积累了丰富的企业级应用的微服务化，容器化实战经验，曾出版《Lucene应用开发揭秘》，个 人博客可搜索popsuper1982。
刘超在分享了题为“网易蜂巢基于容器和微服务加快迭代速度实践”的演讲， 主要讲述了网易蜂巢根据具体的业务场景和架构，进行逐步微服务化，容器化的实践。
坊间一直有“网易出品，必属精品”的言论流传，网易云音乐、考拉海购、有道云笔记、网易云课堂等都是深受大家喜爱的应用，而这些应用的背后，都少不了网易蜂巢的支撑。目前网易95%以上的应用都已经部署在了网易蜂巢上，基于蜂巢，考拉扛过了6·18、双11，每天更新达700余次，网易云音乐用户也已经达到2亿，成为最受欢迎的音乐播放器之一。
从私有到公有，从虚拟机到容器
网易蜂巢是网易云推出的云计算基础服务，用丁爸爸的话就是为“解放全中国的程序员”而生的。网易蜂巢的发展也经历了从基于虚拟机的私有云平台，向基于容器的公有云平台的转变历程。平台层从虚拟机向容器的转变，给整个迭代过程和环境的管理带来了极大的便捷性，而容器的使用也让应用层不得不进行调整，架构上要向微服务迁移，流程上则要DevOps转变。
上图是网易蜂巢整个平台的架构，从下向上依次是硬件层、IaaS层和PaaS层。
硬件上，网易云全部都是五星级的机房，多线BGP网络接入，万兆网络互联，全SSD存储。
其次是网易云是基于OpenStack的自研IaaS：
-
计算：定制KVM系统镜像，实现云主机IP静态化，优化OpenStack创建云主机流程；
-
网络：二层至四层网络过滤防止MAC/IP欺骗，基于Linux TC修改OVS实现网络QoS；
-
存储：云硬盘架构基于iscsi和Ceph实现，优化Ceph核心模块OSD；
最上层是高可用、高性能的PaaS，蜂巢在这个方面的积累非常深厚：
-
数据库：网易定制的MySQL内核分支，主从切换数据零丢失，提供健康检查和SQL优化工具；
-
缓存服务：主从热备、跨可用域部署，自动容灾，高性能单笔延时毫秒级；
-
对象存储：高可用性为99.99%，高可靠性三备份8个9，基于自研分布式非结构化存储系统。
对于开发者来说，之前基于虚拟机的部署，操作上是比较简单的。只要调用IaaS层的API，把虚拟机创建出来；数据库、对象存储等中间件放到PaaS平台就可以了。如果应用比较少，直接手工部署就行，但是如果应用量比较大，或者分的服务比较多，就需要用到一些自动化部署的工具，比如Puppet、Chef和Ansible。之所以要用到这些工具是因为,仅仅资源层面的弹性，并不能满足互联网快速迭代的需求。比如电商大促期间，原来10台机器，要扩展到20台，另外的10台虚拟机还要靠手工一台台去部署，整个扩展的速度还是达不到要求，就要靠脚本做一些事情。
电商系统的架构发展
上图就是一个电商系统的雏形，对于一个互联网+的应用，为了系统快速上线，进行观念的验证，多数都会采取集约化的单体架构，主要包括用户管理、商户管理、订单管理、商品管理、支付管理这么几块。这样做的好处是易开发、易测试、易部署、易运维。
但是随着业务的飞速发展，整个应用的架构会变得很复杂，网络流量、用户请求、日活都会大幅度增长，功能也会越来越完善，比如用户的个性化推荐、积分系统，商户的供应商管理、物流管理。这时单体架构的好处几乎都会消失，服务器的重复部署和数据库的查询都会成为瓶颈，整个系统的迭代速度也会慢下来，一个功能的修改可能要牵扯到很多模块。
电商系统的微服务化
为了解决这个问题，要进行应用架构的改造，比如加上负载均衡器和缓存服务器，数据库进行读写分离，使用中间件把大服务拆成小服务，服务之间通过消息组件进行交互，这样应用首先可以水平扩容了，比如下订单特别的忙，3个节点不够就可以扩成9个节点，结合脚本还能实现弹性的伸缩。
这样的改造后也会出现新的隐忧，比如随着系统模块的增多，每个模块又有自己的开发环境、测试环境和生产环境，应用的管理成本会变得很高；另外，虚拟机的部署效率是很差的，因为每创建一个虚机都是有内核的；产品发布慢，业务上线慢；依赖组件搭建麻烦（服务发现、分流）；监控，日志管理复杂。
容器+微服务相得益彰
容器的诞生恰好弥补了虚拟机的这些不足：
-
首先，容器非常轻量级，如果你要跑一个2G的程序，创建一个2G内存就够了，因为内核是共享的；
-
另外的好处是易迁移和环境的一致性，容器的镜像将所有的应用、环境、配置、依赖都打包在内了，镜像无论在哪里启动都能保持一致，而且整个镜像非常小；
-
最后，镜像是有版本的，这个版本和环境的一致性结合起来，就可以保证我们能很放心地进行版本的回滚，进行版本控制。
当然容器在追求这些优势的同时，也牺牲了一些特性，比如内核共享使得容器间的隔离不足，在公有云中会存在安全隐患；应用的迁移也是应用逻辑的迁移，数据是迁移不了的，这就要求应用是无状态的；此外，容器的网络、存储、日志和配置功能都不够完善，需要做很多优化。
网易蜂巢的进一步优化
网易蜂巢在采用容器作为部署单元的同时，进行了很多优化工作，去解决这些问题：
蜂巢在编排方面的优化：
-
支持多租户: 默认kubernates的namespace只隔离replication controller，pod 等资源，网易实现节点，存储、网络的租户隔离；
-
调度性能优化：kubernetes调度优化，任务串行队列改为多个优先级队列；
-
集群扩展性：根据Pod/Node/Replication Controller等资源到拆分不同的etcd集群；
蜂巢在容器方面的优化：
-
虚拟化扁平二层网络，基于VXLAN实现租户隔离，外网网卡直接挂载到容器内部；
-
有状态容器挂载云盘，可实现跨主机迁移；
-
提供统一的日志收集，分析，搜索服务，利于分布式架构问题定位；
-
引入服务端 APM 解决细粒度性能分析，迅速发掘性能瓶颈；
总之，蜂巢就是用IaaS层和容器层紧密结合的方式来解决了以上提到的各种问题，比如：
-
使用虚拟机解决内核隔离问题
-
使用IaaS层能力解决网络和存储问题
-
使用Kubernetes解决编排和配置问题
-
使用统一日志和监控解决容器日志监控问题
-
有状态容器暂时解决状态保持问题
其中有状态的容器只是暂时的方案，还是建议进行应用的无状态化改造，主要就是把内存中的数据保存到缓存中，把用户数据保存到数据库中，把文件保存到分布式存储中。这样应用中只包含商务逻辑，无论怎么扩展都只是商务逻辑的扩展，下面的存储也都有自己的集群，不需要应用层做过多的考虑。
基于Kubernetes的编排
蜂巢容器层的编排是Kubernetes开源技术，Kubernetes的编排方式，能让应用拆成微服务后，以一种非常优雅的方式进行部署、编排、自发现、自修复和实现CI/CD。比如一个应用拆成了A、B、C、D四个服务，如果中间那台机器挂了，Kubernetes会把B服务和C服务移到另外2台没有挂的机器上。
容器还有一个特性就是启动后IP地址会变，而Kubernetes的服务间引用是通过服务名实现的，这就让容器的自修复成为了可能。Kubernetes的机制还让容器的动态扩展变得非常容易。
另外，Kubernetes还能让整个开发的流程变得很优雅，一方面容器的镜像可以使业务的代码、系统库、权限完全一致，所有的配置通过容器的编排也会保持一致，这样从Dev到Ops的各种环境维护的都是一套东西，开发人员一旦提交了代码，代码可以通过hook的方式触发到容器平台，容器平台会自动把当前的代码打包成镜像，一分钟之内测试环境就会更新，去进行自动化测试，测试完成后Ops就可以一键部署到生产环境，形成一套非常顺畅的DevOps流程。
聚焦应用，拥抱开源
上面就是经过蜂巢微服务化后的一个比较理想的电商系统的简版架构。
整个网易蜂巢的特色在于聚焦应用，解放开发者。对于互联网+公司和创业公司来说，无论是IaaS平台还是PaaS平台，无论是数据库、分布式存储还是缓存，想要做好调优还是非常花时间和精力的，就算是用Kubernetes，想要用好，做好二层网络的打通，和统一的存储，也是很有难度的。我们希望蜂巢的用户都能聚焦于自己的业务和产品，把基础设施的部分交给云平台来做。
另外，蜂巢是一个全开源的平台，包括MySQL、Redis、Kubernetes和OpenStack都是当下最流行的开源技术，以便让平台的应用接口和行为习惯符合大多数开发者的习惯。蜂巢会作为一个知识输出的平台，服务于企业的微服务化改造。
提问环节
您刚才提到容器的隔离度不够，所以蜂巢是在IaaS层的虚拟机上再做容器的，请问是如何对性能、开销和启动时间进行调优的呢？
Q
刘超：这个调优首先要找到慢的原因，比如容器启动比较慢，我们发现IaaS层OpenStack的很多操作对于容器平台并不是必要的，我们就把KVM弄得很简单，把IP做成静态化的配置，使得整个启动过程从分钟级降到了秒级，在启动第一个容器的时候会多几秒的时间，后续的容器如果虚拟机的资源足够就完全没有损耗了。
来源：中生代技术
