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

微服务架构介绍

单体式应用程序

与微服务相对的另一个概念是传统的单体式应用程序( Monolithic application )，单体式应用内部包含了所有需要的服务。而且各个服务功能模块有很强的耦合性，也就是相互依赖彼此，很难拆分和扩容。

说在做的各位都写过单体程序，大家都没意见吧？给大家举个栗子，刚开始写代码你写的helloworld程序就是单体程序，一个程序包含所有功能，虽然 helloworld 功能很简单。

单体应用程序的优点

• 开发简洁，功能都在单个程序内部，便于软件设计和开发规划。

• 容易部署，程序单一不存在分布式集群的复杂部署环境，降低了部署难度。

• 容易测试，没有各种复杂的服务调用关系，都是内部调用方便测试。

单体应用程序的缺点

单体程序的缺点一开始不是特别明显，项目刚开始需求少，业务逻辑简单，写代码一时爽，一直爽。噩梦从业务迭代更新，系统日益庞大开始，前期的爽没有了，取而代之的是软件维护和迭代更新的无尽痛苦。

由于单体式应用程序就像一个大型容器一样，里面放置了许多服务，且他们都是密不可分的，这导致应用程序在扩展时必须以「应用程序」为单位。

当里面有个业务模块负载过高时，并不能够单独扩展该服务，必须扩展整个应用程序（就是这么霸道），这可能导致额外的资源浪费。

此外，单体式应用程序由于服务之间的紧密度、相依性过高，这将导致测试、升级有所困难，且开发曲线有可能会在后期大幅度地上升，令开发不易。相较之下「微服务架构」能够解决这个问题。

微服务架构核心要素

服务治理

可观测性

安全

微服务架构原理和特征

基本概念

服务：一组具有相同逻辑的运行实体 实例：一个服务中的每个运行实体 实例与进程的关系：一般一对一或者一对多 常见的实例承载形式：进程，K8s pod 服务间通信：微服务之间通过网络进行通信，常见的通信协议包括 HTTP、RPC

服务注册与发现

微服务之间相互调用完成整体业务功能，如何在众多微服务中找到正确的目标服务地址，这就是所谓「服务发现」功能。

常用的做法是服务提供方启动的时候把自己的地址上报给「服务注册中心」，这就是「服务注册」。服务调用方「订阅」服务变更「通知」，动态的接收服务注册中心推送的服务地址列表，以后想找哪个服务直接发给他就可以。

流量特征

   统一网关入口
   外网通信多数采用 HTTP，内网通信多数采用 RPC（Thrift, gRPC）
   网状调用链路

核心服务治理功能

服务发布

服务发布难点

• 不可用
• 抖动
• 回滚

蓝绿发布

• 将服务分成两个部分，分别先后发布
• 简单、稳定
• 但需要两倍资源

灰度发布

• 先发布少部分实例，接着逐步增加发布比例
• 不需要增加资源
• 回滚难度大，基础设施要求高

流量治理

在微服务架构中，可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制

稳定性治理

   限流：限制服务处理的最大 QPS，拒绝过多请求
   熔断：中断请求路径，增加冷却时间从而让故障实例尝试恢复
   过载保护：在负载高的实例中，主动拒绝一部分请求，防止实例被打挂
   降级：服务处理能力不足时，拒绝低级别的请求，只响应线上高优请求

3.字节跳动服务治理实践

重试的意义

重试策略

   限制重试比例：设定一个重试比例阈值（例如 1%），重试次数占所有请求比例不超过该阈值
   防止链路重试：返回特殊的 status code，表示“请求失败，但别重试”
   Hedged Requests：对于可能超时（或者高延时）的请求，重新向另一个下游实例发送一个相同的请求，
   并等待先到达的相应