这是我参与「第五届青训营 」伴学笔记创作活动的第 九 天

• 微服务架构
• 微服务架构原理及特征
• 核心服务治理功能
• 服务治理实践

微服务架构

架构演变：

• 单体架构
• 垂直应用架构
• 分布式架构
• SOA架构
• 微服务架构

为什么需要演进？

• 互联网的爆炸式发展
• 硬件设施的快速发展
• 需求复杂性的多样化

微服务架构的核心要素

服务治理	可观测性	安全
服务发现	日志采集	身份认证
负载均衡	日志分析	认证授权
扩容缩容	监控打点	访问令牌
流量治理	监控大盘	审计
稳定性治理	异常报警	加密传输

微服务架构原理及特征

基本概念：

• 服务：一组具有相同逻辑的运行实体
• 实例：一个服务中的每个运行实体
• 实例与进程的关系：没有必然对应关系，一般一对一或者一对多
• 常见过的实例承载形式：进程、VM、k8s pod...

服务间通信：

• HTTP 协议
• RPC 协议

服务注册及发现：

服务调用如何指定下游实例地址？

使用IP地址或者DNS？

指定IP：port	DNS
没有动态能力	本地DNS存在缓存，导致延迟
无法指定多个实例IP	DNS没有负载均衡
	不支持服务探活检查
	DNS不能指定端口

服务注册发现： 统一服务注册中心，存储服务名到服务实例之间的映射关系

• 旧服务实例下线前，从注册中心删除映射，下线流量
• 新服务实例上线后，再注册中心添加映射，上线流量

微服务流量特征：

• 统一网关入口
• 外网通信多数采用HTTP，内网通信多数采用PRC（thrift/gRPC）

核心服务治理功能

服务发布：

• 难点：

  • 服务不可用
  • 服务抖动
  • 服务回滚

• 策略：

  • 蓝绿部署
  • 灰度发布

流量治理：

在微服务架构中，可以从各个维度对端到端的流量在链路上进行精确控制

维度：

地区	集群	实例	请求

负载均衡：

Round Robin	Random	Ring Hash	Least Request

稳定性治理：

• 限流：限制服务最大处理 QPS
• 熔断：中断请求路径
• 过载保护：高负载实例主动拒绝一部分请求
• 降级：服务处理能力不足时，拒绝级别低的请求，只响应优先级高的请求

服务治理实践

重试的意义：

• 降低错误率
• 降低长尾延时
• 容忍暂时性错误
• 避开下游故障实例

tips：本地函数没有重试的意义

远程函数调用：避免偶发性的错误（网络抖动、下游负载高、下游机器宕机）

重试难点：

• 幂等性：请求重复被消费
• 重试风暴：随着调用链路的增加，重试次数呈指数上升
• 超时设置：如何确定超时时间

重试策略：

• 限制重试比例
• 防止链路重试：返回特殊的status code，表示“请求失败，但别重试”
• Hedged Requests：对于可能超时（或延时高）的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应

课后

结合 CAP 等原理，思考微服务架构有哪些缺陷？

无法保证服务的 高可用（A）、强一致（C）、分区容忍（P） 同时实现，只能同时满足CP或者AP或者CA。

微服务是否拆分得越“微”越好？为什么？

不是。服务越微小意味着调用链路加长，服务部署依赖越加繁琐。服务的拆分应该把控粒度。

Service Mesh 这一架构是为了解决微服务架构的什么问题？

服务网格解决微服务架构服务间通信和治理问题。

有没有可能有这样一种架构，从开发上线运维体验上是微服务，但实际运行又类似单体服务？

完全有可能，复杂频繁相互调用的服务使用IPC进行通信，即将这些服务部署在同一个物理机器，再部署多个一样的服务到其他物理机上。