这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天
本节课介绍了微服务架构的原理和实现
微服务架构中核心服务治理主要分为服务发布、流量治理、负载均衡、稳定性治理
服务发布
指让一个服务升级运行新代码的过程
服务发布有几大难点：
1.服务不可用：指在升级发布过程中，原有的服务对用户不可用的问题
2.服务抖动：对于服务中某些实例，在升级发布过程中短暂不可用的问题
3.服务回滚：对于已经升级完成的服务，在使用过程中出现bug，需要将提供的服务代码回滚到上一个无bug的版本
对于服务发布的难点，企业实践有：
蓝绿部署：
对于要升级的服务，将其中的实例复制一个副本，当要进行升级时，将服务流量切至不需要升级的集群，同时对另一集群进行升级，升级完成后流量切入，这样解决了服务不可用问题，同时两份副本也可以实现服务回滚，
蓝绿部署稳定，实现简单，但需要两倍空间
灰度发布：
对于可能有问题的新代码，不让其一次性全部上线，对于服务内的实例，先下线并更新单个实例，更新完成上线后观察在服务中是否出现问题，由此迭代最终更新全部实例
灰度发布节省空间，但是在更新过程中需要不断修改注册表，而且在服务需要回滚的情况下（若此时大部分实例已经升级完成则情况更糟）实现回滚有较大难度
流量治理
对于不同的服务以及实例，其所需要的流量不同，在微服务架构下，可以基于地区、集群、实例、请求等维度，对端到端的路由路径进行精确控制
对于地区：可以根据地区服务器数量和负载控制流量分配
对于服务集群：可以根据集群实例数量、集群类型进行流量分配
对于服务实例：可以根据服务运行的机器质量进行分配，对于质量差的机器为其分配较少流量
对于请求：可以根据请求类型判断流量需求，进行流量分配
负载均衡
负载均衡负责分配请求在每个下游实例上的分布
对于服务的诸多实例，我们希望对于每个实例分配到的负载是均衡的，防止某些实例负载过高，由此需要上游的负载分配方案
常见的负载均衡策略有：
轮询法（round robin）：
轮询法是将请求按顺序轮流地分配到服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。对于服务分配的服务器，从头遍历进行调度，遍历完成后继续从第一个开始
可以根据服务器特性进行加权调度
随机法（random）：
将请求随机分配到各个节点。由概率统计理论得知，随着客户端调用服务端的次数增多，其实际效果越来越接近于平均分配，也就是轮询的结果
源地址哈希法（ring hash）：
源地址哈希的思想是根据客户端的IP地址，通过哈希函数计算得到一个数值，用该数值对服务器节点数进行取模，得到的结果便是要访问节点序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会落到到同一台服务器进行访问。
最小连接数法（least request）：
根据每个节点当前的连接状况动态的选取其中当前积压请求最少的一个节点处理请求，尽可能提高后端服务的利用效率，将请求合理分流到每一台服务器
稳定性治理
实际运行中线上服务会出现各种难以预料的问题，与程序正确性无关
如：网络攻击、流量突增、机房断电、机器故障等等
对于微服务的稳定性治理，大致分为限流、熔断、过载保护、降级
限流： 对于服务流量过大的情况下，为防止其服务出现不可用，限制其实际处理的服务量
熔断： 对于服务调用连接失败时，停止向服务不断发送连接请求，停止调用
过载保护： 当服务实例压力过大时（可通过CPU使用判断），拒绝新的服务分配
降级： 当实例压力过大时，保证重要的服务能够被分配，同时拒绝不重要的服务
