本文内容选自中国DevOps社区年会 · 2019年会，刘超老师分享的《大规模微服务场景下灰度发布与流量染色实践》实录。
大家好，我的题目叫《大规模微服务场景下的灰度发布与流量染色实践》。最近微服务很热，与微服务相关的架构、流程、DevOps都很热。
很多公司，包括传统企业，到互联网公司做交流的时候，会问道，你们互联网公司号称能够加速业务创新、快速迭代，那我们是否也可以引入类似这样的机制。
我们做微服务，主要分为两个方面，一个是业务方面，另一个是技术方面。最下面是运维部，不过现在我们的运维部已经拓展成云计算，DBA里的数据管理部门，已经发展成大数据，于是就有了技术中台和数据中台，另外还有共享用户中心的业务中台，总体构成了下层的中台部门，在上层业务一定要做微服务化。业务和技术互相合作，做到加速创新的效果。
有很多人说，我们也上了微服务，但是会发现上微服务以后，看起来很好的东西，为什么用起来一团乱麻。
我们拜访过很多业界同仁，发现实施微服务之后，有以下痛点：
服
务依赖管理：服务间直接调用，
依赖混乱
（
微服务
越来越多，自己理不清楚，不知道上线时会影响谁，上线后谁影响我，到底该什么时候上线，依赖混乱的时候，没办法解决这些问题。
）
服务调用统计：
调用记录
无迹可寻，调用统计与分析无从谈起
服务接口规范：环境与接口
规范缺失
，维护困难
服务安全管理：安全靠白名单各自为战
服务治理能力：大量
重复代码
实现路由，分流，熔断，降级
服务接口测试：拆分过程中接口
行为不一致
，隐藏Bug
服务灰度发布：上线功能实现灰度借助
大量if-else
服务压力测试：对于峰值压力
无历史数据
，靠运气
服务调用链分析：当服务请求缓慢，
难以定位
问题点
测试环境治理：测试
环境多，难管理
，不可能100个容器每组一套
我们发现大家对微服务有很多误解。比如，一般做微服务的时候，很多人都会问微服务怎么拆，告诉我一个拆的最佳的实践，但是其实，根据我们的实践来讲，微服务不仅仅是微服务拆分，微服务拆分只是十二个要点的其中之一。
十二个要点分别是：
-
微服务化的基石：持续集成
-
静态资源分离与接入层设计
-
应用层设计之无状态化与容器化
-
应用层设计之服务的拆分，发现与编排
-
性能优化之数据库设计与横向扩展
-
性能优化之缓存的设计与横向扩展
-
性能优化之消息队列与异步化设计
-
服务的熔断，降级，限流设计
-
配置中心的设计与实践
-
统一日志中心的设计与实践
-
全链路应用监控实践
-
服务的全链路压测实践
我们建议，先把前三个基础打好，再进行拆分，而不是什么技术、平台、工具都没有，直接把自己的传统应用拆得七零八落。
同时，值得再强调的是第一条，微服务化的基石：持续集成。微服务绝不是让大家关起门来用三个月的时间拆出来，就直接上线。而是应该不断地集成、迭代，是渐进式的模式。
另外，微服务也不仅仅是个技术问题，它还涉及到IT架构、应用架构、组织架构的改变。
接下来给大家讲一下网易微服务和DevOps的实践过程。
我们整个DevOps，也是经历了几个过程。第一个和大家都一样，当服务比较少的时候，开始手工化的方式，后来手工不行了就变成了脚本化的方式，再后来因为开源有很多的工具可以用，变成了工具，而后变成一个平台，最后变成一个统一的DevOps的平台。
首先，第一个阶段就是手工化。可能很多企业一开始都会存在这样的阶段，开发和运维之间的隔阂比较严重，老死不相往来。开发负责写代码，线上的运维、发布，以及SLA的保障，都是运维进行管理的。由于服务相对比较少，用物理机部署，基本上是一个单机应用加一个Oracle就可以搞定。
后来，随着业务的发展，服务越来越多。这个模式和原来还是没有变，开发和运维部的隔阂依旧存在。但是，运维发现接的需求越来越多，需要部署越来越多，需要一个环境隔离的方式，因此一般会上一个虚拟化系统，业内主流是用Vmware。这时候的部署方式一般是，Oracle部署在物理机上，其他业务系统都是部署在VMware上。部署东西多了，运维开始使用批量脚本试图解放人力，这属于第二个阶段-脚本化的阶段。虚拟化带来很多的优点，比如，粒度灵活，隔离性得到一定保证，不会在一台服务器上部署很多东西。
但是这个阶段也有非常多的问题。比如说发布脚本、逻辑相对复杂，时间长了以后，逻辑是难以掌握的。而且，如果你想把一个脚本交给另外一个人，也很难交代清楚。
另外，并且脚本多样，不成体系，难以维护。线上系统会有Bug，其实发布脚本也会有Bug。
虚拟机大量地依赖于人工的调度，需要运维人员非常清楚，要部署在什么地方。另外VMware还有一个问题，它使用共享存储，会限制整个集群的规模，因为此时的应用不多，这个程度的规模还可以接受。
线上的高可用性，业务层的开发人员不会做任何事情，他认为是线上一旦出事，应该由运维集中处理，迫使运维服务的发布人员依赖虚拟化机制，来提供高可用机制。我们都知道VMware有非常著名的简化运维的高可用机制，比如FT、HA、DR等类似的机制。如果我们是从IT层来做高可用，有一个缺点，作为基础设施层来讲，它看上层没有任何的区别，所以没有办法区分业务优先级。比如说FT的模式，跑CPU指令，它不知道这是最核心支付的指令、还是日志的指令
，再如数据中心之间的同步，存储层是无法区分交易数据和日志数据的。
另外网络、虚拟化、存储等基础设施，没有抽象化的概念，复杂度非常高，开发接不了这个工作，必须依赖运维，就要审批。由统一的一帮人来做，而且他们要考证书，比如，网络要有思科的证书，虚拟化要有VMware的证书，要特别专业才能做这件事情，因此会极大地降低迭代速度。业务方无论做什么事，都要走审批，运维部的人根本忙不过来，这是第二阶段的问题。
后来是怎么改变了这个问题？首先是业务层，业务层接的需求越来越复杂，迭代速度要求越来越快，这个时候单体应用跟不上了，需要进入服务化的架构，工程要拆分，要开始基本的注册发现，要实现自己的RPC。
应用层的改进会带来应用层的问题。比如，服务雪崩的问题。大量的请求堆积，一个进程慢了，把整个链路也都变慢了，所有人都在等着它缓过来。我们要进行熔断，快速尝试另外的服务。原来依赖很多内网负载均衡以及硬件负载均衡的维护代价比较大，一旦出现任何问题，就会引来抖动的问题。所以相应的要有快速恢复、快速熔断的机制，一旦发现错误以后，我们要能够尽快的重试。
以上就是应用层的问题，经过了一段时间的解决，又引入了新的问题。
我把它称为“云原生怪圈”，应用向云原生的（Cloud Native）。
它包含两个层次，第一个层次是应用层的服务数目会增多。第二个层次是资源层申请速度的灵活性会相对增加，这两个层次形成了一个圈。每家公司可能都存在这个圈，无论是从哪个起点开始，这个圈都可能会被激活。
一个起点是，很多公司的上面是单体应用，但下面先采购了容器，资源申请灵活性大幅度提高了。一旦灵活性提高了以后，会给应用层释放很多动力。原来申请一百个机器需要一个星期的审批流程，这时能不拆分就不拆分。而现在有了容器，他会认为我有了这么好的工具，我可以进行拆分了，反正不费劲，任何一个小部门创建一个小的环境都不费劲。
另外一个起点，先是应用层服务数目增多，给资源层越来越大的压力，然后会使得你原来七八点下班，现在变成十点多下班，然后十二点下班，压力越来越大，就会想办法增加资源层的灵活性。这个圈在整个DevOps的过程中会一直产生的。
微服务化了以后，我们会发现存在以下几个现象。
第一个是服务器的机型非常的碎片化，一开始采购机器的时候，有大规格、小规格的，硬盘比例各不一致，导致服务器非常难以管理，也无法进行批量化的安装。
第二是很多的进程，不管是虚拟化以后，还是不虚拟化，在不在一台机器上，QoS无法保证。
第三是测试环境的需求量大大增加，下层的基础设施根本忙不过来。
接下来进入到云计算的平台。有很多人不理解云计算和虚拟化都是运用了虚拟化的技术，两者之间到底有什么不同。其实云计算带来了非常大的不同，甚至是本质上的不同。如果你们内部上了一个云平台，或者上了公有云，但是你没有感受到资源申请的灵活性，那肯定是有些姿势用得不对。
这里，
我总结了一下云计算带来的改变，主要有三大方面，分别是统一接口、抽象概念，租户自助。
正是因为这三大方面，使开发和运维不像原来那样，有那么深的隔阂，而是开始逐渐互相靠近，开发部或者业务部开始进行一定的自助。
OpenStack实现接口统一，大部分部署工具支持其接口，可基于开源工具实现发布的工具化和平台化
Flavor抽象资源配比（4G 8G 计算优化型，网络优化型，存储优化型），统一硬件配置，提升利用率，硬件上线效率提升
自动调度代替人工调度，区域可用区抽象对机房机架交换机的感知
云提供租户概念，有账号子账号体系，有quota，可以让租户在管理员许可的范围内自助操作，加快环境部署速度
VPC屏蔽物理网络复杂性，冲突问题和安全问题，使得租户可自行配置网络
基于虚拟机分层镜像发布和回滚机制，构建发布平台，可实现大规模批量部署和弹性伸缩
基于虚拟机的PaaS托管中间件，简化租户创建，运维，调优中间件的难度
发布平台提供基于虚拟机镜像+PaaS中间件的统一编排
要求业务对于高可用性设计要在应用层完成
