这是我参与「第五届青训营 」伴学笔记创作活动的第 10 天
重点内容概括
- 微服务架构原理
- 服务发布
- 流量治理
- 负载均衡
- 稳定性治理
详细知识
微服务架构原理
- 服务（Service）：一组具有相同逻辑（代码相同）的运行实体
- 实例（Instance）：服务中的一个运行实体
- 集群（Cluster）：服务内部根据逻辑对实例的划分
- 实例与进程没有绝对的对应关系，可能一个实例对应一个或多个进程
- 根据是否存储了可持久化的数据，将服务分为有状态服务和无状态服务
为了灵活控制各个服务，我们创建了一个“服务注册中心”，由服务注册中心完成服务与其实例地址（ IP地址和端口）的动态对应，实现负载均衡、服务探活等功能。
服务治理
服务发布
服务发布（Deployment）是指让一个服务升级并运行新代码的过程。服务发布的三个难点是服务不可用、服务抖动和服务回滚：
- 服务不可用：服务的所有实例同时更新，整个服务在一段时间内不可用
- 服务抖动：因某些实例正在更新，造成服务收到的部分请求丢失
- 服务回滚：发布后的代码出现 Bug 等问题，需要回滚至服务发布前的状态
为了解决以上问题，目前的常用策略有以下几种：
-
蓝绿部署：将服务分为两部分，将其中一部分依次下线并更新，待其重新上线后下线、更新、上线另一部分。
优点：简单、稳定
缺点：资源需求大，因此适合在流量较低使进行
-
灰度发布：又叫“金丝雀发布”，即先上线一个新版本的实力，若其稳定则下线一个老版本实例，依次进行，直至完成所有实例的更新。
优点：节省资源
缺点：实现复杂
流量治理
微服务架构下，可以基于地区、集群、实例、请求等维度对颠倒段流量的路径进行治理。
负载均衡
负载均衡（Load Balance）指分配请求在每个下游实例上的分布，常见的负载均衡策略有：
- Round Robin：每个实例绝对公平地获得请求
- Random：随机请求
- Ring Hash：保证同一个用户请求在同一个实例上
- Least Request
稳定性治理
在实际生产环境中，难免遇到一些与代码质量无关的问题，如网络攻击、机房断电等、光缆被盗、古筝计划等。对于这些问题，我们希望在软件层面提供一些保护，如限流、熔断、过载保护、降级等：
- 限流：服务限制自己的入口带宽，保证一段时间内的请求不会过多
- 熔断：当调用某服务多次超时时，停止调用该服务，一段时间后再重试
- 过载保护：与限流类似，但限制条件为服务内节点的资源压力（如 CPU 使用率）
- 降级：保证部分服务的正常运行，限制部分非重要服务的运行
本文若有不足之处,欢迎纠正(≧^.^≦)喵~
我的其他笔记，可在掘金或 Github( github.com/DoudiNCer/I… )阅读
