这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天
微服务框架
由于互联网的发展、硬件的发展，需求复杂性的多样化以及计算机理论技术的发展，系统架构不断演进。
微服务的核心要素包括：服务治理、可观测性、安全
原理及特征
服务：一组具有相同逻辑的运行实体。 实例：一个服务中，每个运行实体即为一个实例
实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例对应一个或多个进程
对于单体服务，不同模块通信只是简单的函数调用。而对于微服务，服务间通信意味着网络传输。
核心服务治理功能
服务发布，即指让一个服务升级运行新的代码的过程
蓝绿部署
蓝绿色部署是一种通过运行两个相同的称为 BLUE 和 GREEN 的生产环境来减少停机时间和降低风险的技术。
蓝绿部署，以颜色命名，简单的理解就是，线上有两套集群环境，在架构图中，一套标记成蓝色，称为蓝色集群BLUE；一套标记为绿色，称为绿色集群GREEN。通过将流量引入两个集群，完成系统升级切换。
步骤一：部署绿色集群，这个时候是初始状态，蓝色集群承担全部责任，接收全部流量，等待被替换。绿色集群刚刚部署，还没有投入使用，流量为0，等待验证和上线。
步骤二：蓝色集群流量不变，向绿色集群引入流量。这个过程可以分成几个阶段完成。第一个阶段，引入少量非实时流量，仅用于数据测试；第二个阶段，引入全部实时流量，用于做系统验证。
步骤三：切断向蓝色集群引入流量，将全部流量引入绿色集群。这个时候，绿色集群已经承担全部责任，接收全部流量。这个过程也可以分阶段操作。第一个阶段，平衡蓝色和绿色集群流量，也就是蓝色和绿色集群一同承担职责；第二个阶段，切断蓝色集群流量，流量全部写入绿色集群。是否采用分阶段操作，完全看升级的功能是否是破坏性的，是否可兼容。
步骤四：监控系统运行，这个过程是必要的。因为没有人能够保证测试时100%的覆盖的，所以新集群可能会出现这样那样、或大或小的问题，如果评估需要回滚，就需要将全部流量切换到蓝色集群。也完成了版本回滚。
金丝雀发布（灰度发布）
金丝雀发布，与蓝绿部署不同的是，它不是非黑即白的部署方式，所以又称为灰度发布。它能够缓慢的将修改推广到一小部分用户，验证没有问题后，再推广到全部用户，以降低生产环境引入新功能带来的风险。
步骤一：将流量从待部署节点移出，更新该节点服务到待发布状态，将该节点称为金丝雀节点；
步骤二：根据不同策略，将流量引入金丝雀节点。策略可以根据情况指定，比如随机样本策略（随机引入）、狗粮策略（就是内部用户或员工先尝鲜）、分区策略（不同区域用户使用不同版本）、用户特征策略（这种比较复杂，需要根据用户个人资料和特征进行分流，类似于千人千面）；
步骤三：金丝雀节点验证通过后，选取更多的节点称为金丝雀节点，重复步骤一和步骤二，直到所有节点全部更新
负载均衡
负载均衡负责分配请求在每个下游实例上的分布。
线上服务总是会出问题，包括如网络攻击、流量突增、网络故障等等。对于这些场景，微服务架构中典型的稳定性治理功能有限流、熔断、过载保护、降级这几种方案
流量控制，可以通过地区，集群，机器，请求等维度来进行流量控制，
负载均衡，一致性哈希，round，Robin等策略
稳定性治理：
- 限流 限制流量的输入，拒接部分流量，让服务能够稳定进行
- 熔断 服务处理不过来了，断掉连接，类比跳闸，
- 过载保护 通过动态过载组件来检测服务的CPU的使用程度，如果有过载迹象，则拒绝一些请求
- 降级 会给流量分等级，如果压力过大，拒绝等级低的请求，保持用户的正常体验。
重试
重试的意义： 降低错误率，降低长尾延迟，容忍暂时性的错误，避开下游故障实例。
重试的难点
不能给所有的请求都加上重试 post发起多次可能会造成数据错误 重试风暴（雪崩）
微服务有很深的调用链路，可能有几十层，链路加深，会对错误进行放大
解决方法
-
限制重试比例，如果大比率失败，则没有必要重试 防止链路重试，
-
最理想就只有最底层进行重试，避免放大
-
对于延迟高的请求，可以对它下游的实例再发起请求
-
确保幂等性
-
进行超时设置
