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

在了解了前面介绍的企业级后端架构的介绍后，我们应分析实际使用搭建这些架构应该注意的一些问题。

关键问题：

• 紧急回滚能力：企业提供的云端框架需要依赖很多不同的微服务，这时候万一其中一个出现了问题就会导致整个依赖链上都出现问题，因此框架必须具备回滚能力。
• 大规模
• 极端场景

方案一：自适应静态权重

通过不同宿主机的物理信息（如cpu型号等）根据这些信息来调整容器注册的权重，从而在容器A请求相同的的容器B的时候，注册中心会根据得到的主机能力来分配谁来提供服务。

优势：

• 复杂度低，仅需要增加一个注册中心记录不同宿主机的物理信息和权重。
• 完全分布式，可用性高。
• 微服务中间件无适配成本，对业务进程是无感知的。

缺点：

• 无紧急回滚能力
• 缺乏运行时自适应能力，当运行时宿主机情况发生变化时不能及时调整权重。

方案二：自适应动态权重 Alpha

增加一个动态权重决策中心，由纯分布式配置改为由决策中心来拉取权重。之前文章中提到的资源探针等方法来采集运行时的资源情况，也依赖服务网格得服务发现和流量调度能力。

改进方向：

• 增加了紧急回滚能力，记录了动态权重和静态权重，当动态权重分配出现错误的时候可以紧急回滚使用静态权重。
• 运行时权重自适应，它通过在运行时探知资源来动态调整权重。

缺点： 流量过度倾斜可能会出现一些异常。（例如动态调整到一台宿主机的权重到达100，万一出现问题就会出现大麻烦。

方案三：自适应动态权重 Beta

我们可以添加一些其他的指标来计算权重防止出现流量严重倾斜的情况。可以让服务网格上报RPC的一些指标，如图中的延迟P50、延迟P90.

改进方向： 能够处理极端情况了。

缺点：

• 时序数据库压力大，由于需要动态计算存储权重信息，需要每间隔一段时间就记录数据，系统大起来后数据库压力就会很大。
• 动态权重决策中心的职责过多。

方案四：最终方案 自适应动态权重Release

其他的不动，动态权重决策中心进行优化。

演化方向:

• 微服务化
• 引入消息队列进行削峰、解耦
• 离在线链路分离
• 梳理强弱依赖