微服务架构原理及治理
微服务
微服务是彻底的服务化，其带来了优秀的开发效率、独立的业务设计、自下而上的构建和优秀的故障隔离，但同时也增加了治理和运维的难度，并且给观测和安全性提出了挑战
核心要素
-
服务治理
服务注册、服务发现、负载均衡、扩缩容、流量治理、稳定性治理
-
可观测性
日志采集、日志分析、监控打点、监控大盘、异常报警、链路追踪
-
安全
身份验证、认证授权、访问令牌、审计、传输加密、黑产攻击
原理和特征
服务注册及发现
在代码层面，若要指定调用一个目标的服务，我们需要硬编码（hardcode）ip及端口，由于服务的动态性，维护的难度将会大大增加。
所以在微服务架构中增加了统一的服务注册中心，用于存储服务名到服务实例的映射（类似DNS）
服务上下线过程
下线：
- 从服务注册中心中删除需要下线的服务实例条目，切断该实例的流量
- 安全下线实例
上线：
- 直接上线实例，并进行健康检查，确保服务正常
- 在服务注册中心中添加条目
流量特征
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
核心服务及治理
服务发布
服务发布 (deployment), 即指让一个服务升级运行新的代码的过程。
其中存在一些难点：服务不可用、服务抖动、服务回滚
方案
-
蓝绿发布
将一个服务划分为两个逻辑的集群，当需要更新时，则两个集群依次更新，确保一直可用
优点是简单，稳定，缺点是需要两倍资源，可能需要错峰升级（用一半的资源承受全部的流量）
-
灰度（金丝雀）发布
新的代码可能有问题，逐步对每个实例进行更新，而不是一次更新完成
难点：精细化控制流量、精细化代码回滚
流量治理
精确操控端到端流量的路由，便于分流、测试等
负载均衡
负载均衡（ Load BaIance) 负责分配请求在每个下游实例上的分布。
一个服务中，通常每个实例的负载应当是大体均衡一致的
常见的 LB 策略
- Round Robin
- Random
- Ring Hash
- Least Request
稳定性治理
微服务架构中典型的稳定性治理功能包括：限流、熔断、过载保护以及降级
