开发者学堂课程【微服务治理之全链路灰度：微服务治理之全链路灰度】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/973/detail/14894
微服务治理之全链路灰度
内容介绍
一、单体架构与微服务架构的区别
二、微服务架构带来的挑战
三、什么是全链路灰度
四、全链路灰度的解决方案
五、流量入口：网关
六、从0到1实践全链路灰度
在微服务体系架构中服务之间的依赖关系是非常复杂的。有时某个功能发板依赖多个服务同时升级上线。对这些服务的新版本同时进行一些小流量灰度验证，这就是微服务架构中特有的全链路灰度场景。
本次课程一方面加深对全链路灰度的认识。此外可以了解阿里云如何把阿里巴巴内部多年积累的恢复治理能力输出到云产品上面。
一、单体架构与微服务架构的区别
在早期的业务系统，单体架构是非常普遍的，单体架构的核心思想是把所有的服务一起打包进行部署。现如今一些初创的公司进行项目立项时，也会首选单体架构。因为单极架构部署结构简单便于理解。
如图所示单体架构的举例，蓝色部分是单体的应用，api是pass匹配的路由，user card and order对应用户服务、购物车服务、订单服务。应用前端的流量网关是四层代理，主要负责负载均衡。单体应用不是单脸部署的，为了高可用进行多实例部署，因此需要进行流量负载。
安全通信，需要在流量网关这进行统一的证书卸载。
安全防护，是为了保护后端服务不被一些非法流量入侵。
单体架构整体结构较为简单，部署非常方便，用维人员方便使用。但在较大的项目中随着一些开发软件的加入，代码也会随之膨胀，单体架构应用打包编译的速度很慢。因为单体架构服务是紧合在一起，随着业务增长会导致整个业务系统的复杂性加大。
除此之外，单体架构的扩展性跟灵活性较为薄弱，导致技术栈较为单一，sdk升级周期较长。为了解决就单体架构服务发布的敏捷性不够，灵活性较差的问题，开发者开始对原来应用进行服务拆分，拆分一般会按照功能维度和业务域进行服务拆分。而被拆分后的服务会独立部署。
如上图中，用户服务User、购物车服务Cart和订单服务Order都是通过网络互相通信的单独应用。微服务网关是七层网关，作用为暴露后端服务以及流量治理。例如限流或一些对内容进行修改，在认证健全方面可以对终端用户进行统一的健全。
流量监控作为一个流量入口，对流量的可观性要求较高。
总体来看微服务架构似乎是一个很好的一个模式，但是存在一个缺点，对于这么多的微服务，怎么进行有效的治理是一个很难的问题。
二、微服务架构带来的挑战
服务发现解决的是服务之间的可见性问题;
负载均衡，主要是消费者从服务提供者的连接池里，去有效的选择一个ip地址;
熔断限流是为了保护后端服务的安全的水位;
认证健全不仅是需要对终端用户进行健全，服务之间也需要进行健全的，并且保护敏感数据的服务;
监控告警，可以有效的发现每个微服务的一些运行状况;
服务发布是一个重点，关注服务发布主要是为了解决服务发布过程中怎么平滑无损。
三、什么是全链路灰度
1.业务场景——单体架构下的服务发布
举例：购物车服务需要灰度发布，它作为应用的一部分，单体架构中的服务发布上升成为一个应用发布，应用发布需要对整个应用进行编译，打包以及部署，按照一些发布策略进行升级。
一个服务接口需要发布升级，需要：
1. 整个应用编译、打包、部署
2. 按照发布策略进行升级
主要有蓝绿发布和灰度发布：
蓝绿发布
如下图所示： 
蓝绿发布需要对服务的新版本进行一个冗余部署。
一般新版本的机器规格和数量都与旧版本保持一致，相当于该服务有两套完全相同的部署环境。但此时只有旧版本在对外提供服务，而新版本则作为一个热备的身份存在。
当流量需要从旧版本升级到新版本时，只需要在流量网关进行一个流量切换就可以把流量从一个环境转移到另一个环境，是一个整体切换的操作。
此时旧版本就做为一个热备的存在，如果新版本出现问题就可以迅速在流量网关把流量切回去。
它的优点是服务发布周期比较短，流量切换操作比较简单。缺点是需要引入额外的机器成本，来搭建卫星版本，搭建一个隔离的环境。
灰度发布
灰度发布的思想不是将所有的流量从旧版本移到新版本上，而是以循序渐进的方式 。根据请求内容或请求流量的比例将线上的流量一小部分的转换至新版本。待灰度验证通过后逐步调大新版本的请求流量。
图中显示的有两种策略，一种是Traffic routing一种是Traffic shifting。Traffic routine是基于请求内容的，例如将请求中头部含有stage=gray的流量转发到应用v2上，是对请求内容比较清晰化控制的一种方法。traffic shifting比较类似于traffic Swiching,traffic Swiching主要是流量切换，但是traffic shifting是流量分流，它们的思想都是无差别的将流量进行转移，只是转移时只转移小部分。
灰度发布的优点是可以将一小部分流量进行验证，如果新版本出问题，故障面比较小，并且对机器成本的要求也比较小，因为可以在发布过程中对新版本进行扩容，同时对老版本进行缩容。缺点就是发布周期比较长。
2.业务场景——微服务架构下的服务发布
如图所示三个服务已经被拆分后独立部署。一次请求是经过微服务网关，然后经过用户服务，经过购物车，经过订单，最后到数据库。
如果想对cart服务进行一个灰度升级，只需要将cart服务单独部署一个灰度版本。
那么怎么能使请求流量在整个调用链上命中cart服务的灰度版本呢？有两种方案:第一种方案是配置cart的流量流入规则,user路由到cart的时候使用cart的流量流入规则。这是一种基于provider的治理规则。
方案二是配置user的流量流出规则。User路由到cart时使用user的流量流出规则。这是一种基于consumer的治理策略。这种方式可以解决微服务架构的服务发布问题，但是若我们希望对Order服务也进行灰度发布：则需要按照方案一方案二对Order配置流量治理规则。
图上为三个微服务，但是整个请求应用链路上可能有很多的微服务，若下面还有其他的服务也需要进行灰度发布，那么需要对每个服务去配置灰度规则。当微服务非常多时，治理规则就会呈指数级增长，就非常难维护。所以引出了全链路灰度发布的策略。
3.全链路灰度发布：端到端的灰度发布
该策略将流量控制视角从微服务转移到了整个请求链路上。我们希望在请求链上命中更多微服务，所以在使用全链路灰度时并不关心灰度环境中有多少微服务，只需要本次请求流量在路由的时候会优先路由到灰度流量。
专注于整个调用链，仅需要少量的治理规则即可构建出从网关到整个后端服务的多个流量隔离环境，可以有效保证多个亲密关系的服务顺利发布，以及服务多版本并行开发。
如左图是对于正常的流量，经过微服务网关，经过用户服务，经过cart然后经过order去正常进行。而如果是灰度流量，经过user服务时会被发现是一个灰度流量，然后根据流量治理规则，访问Cart服务。到达Cart服务,cart服务在访问order服务时会发觉本次流量是一个灰度流量，所以它会优先访问order服务。
在user服务进行拆分时是根据请求内容来进行分流的，而右图是根据请求比例的。
四、全链路灰度的解决方案
常见的解决方案有两种：一种是基于物理环境隔离，第二种是基于逻辑环境管理。
方案一：物理环境隔离
物理环境隔离，主要是采用堆机器的方式搭建真正意义上的流量隔离。需要为灰度服务搭建一套网络隔离资源独立的环境，然后在其中部署服务的灰度版本。
至于其他服务，因为整个调用链涉及到这三个服务，灰度环境1中的cart服务有v1版本，那么需要在这个灰度环境中部署user order的正式服务版本。
因为灰度环境跟正式环境是网络隔离的，所以需要在各自的环境中去部署非灰度版本。同时在搭建灰度环境时需要引入一个注册中心，因为两个环境是网络隔离的，所以在正式环境中user服务去访问Cart时，从注册中心获取的Cart服务的地址是正式环境的ip地址，然后在灰度环境中，user服务去访问注册中心，得到的是灰度环境中cartv1的节点，所以注册中心也需要在每个环境中额外部署。
基于物理环境隔离的方案比较适用于企业中的正式环境，预发环境测试环境搭建。不便于对线上流量进行一些服务新版本的验证的场景。当微服务规模比较小时可以采纳这种方案，但是微服务规模比较大时，机成本会远超收益。
方案二:逻辑环境隔离
基于逻辑环境隔离，比较贴合全链路灰度的概念。流量经过微网关，流经每一个服务和组件时，每一个服务都会在流量流出的时候动态地去判断访问的provider应该是哪个版本，会根据流量的一些特征进行动态路由。例如蓝色流量是正式环境的流量，可以看到它整个调用链的链路都在这个蓝色节点中。黄色是灰度环境v1，在从微服务网关访问服务A时发现服务A没有灰度环境的v1版本，那么就直接访问正式环境。但是服务A在访问服务B时，服务A再次对流量进行判断，发现服务B有灰度环境v1，这时候流量就会流入到灰度环境v1。
B访问C也执行类似判断，红色的流量是灰度环境v2的流量，也在流经整条链路上的各个组件时进行动态判断。
优点是不用大量的机器成本去搭建一个真正意义上的物理隔离，只需要部署需要灰度的服务即可。
真正的灰度流量的路由，只是由整个链路上的各个服务对流量进行判断去路由。那么需要实现基于逻辑环境隔离的权限的灰度，需要解决哪些问题呢？
第一个是链路上各个组件和服务，能够根据流量特征进行动态路由。
第二个是需要对服务下的所有节点进行分组，能够区分出版本。
第三个是需要对流量进行灰度标识，版本标识，还有流量染色。
第四个是链路上的每个组件怎么去识别出不同版本的灰度流量。
即：
1.标签路由（动态路由）
2.节点打标
3.流量染色（流量打标）
4.分布式链路追踪
