微服务Agent治理学习探索_agent 服务治理

1、微服务发展

• 微服务技术的发展

服务框架就像铁路的铁轨⼀样，是互通的基础，只有解决了服务框架的互通，才有可能完成更

⾼层的业务互通，所以⽤相同的标准统⼀，合⼆为⼀并共建新⼀代的服务框架是必然趋势。

• 微服务优技术势

1、开发和部署相对简单：单个微服务的功能可以更快地更改，因为可以独⽴部署，影响范围更

⼩，启动和调试单个微服务的时间成本相⽐于单体应⽤也⼤⼤减少。

 2、横向扩展简单：根据业务的⾼峰低⾕周期快速的横向扩展⾮常简单，因为单个微服务通常很

⼩，可以随着系统整体负载的变化更快地启动和停⽌。

 3、架构升级灵活：单个微服务的内部架构可以迅速升级，因为微服务之间松散耦合的，只⾯向

定义好的通讯接⼝进⾏编程。这使开发团队能够基于⾃身的技术背景和偏好灵活选择，⽽不

会直接影响其他应⽤程序、服务或团队。

 4、更好的容错性：微服务之间可以实现更好的故障隔离，单个服务内的内存泄露等故障不容易

影响其他服务，相⽐单体应⽤⼀个组件故障会拖垮整个系统。

• 微服务隐藏问题

1、服务之间使⽤远程调⽤进⾏通讯，这⽐进程内的直接调⽤复杂很多。由于通讯链路的复杂性，

可能会出现很多不确定的问题，会出现远程调⽤不可⽤或者延迟较⾼的情况，开发⼈员需要

能够处理这些偶发问题，避免影响业务。

 2、随着业务的发展，微服务之间的拓扑图开始变得复杂，排查问题变得困难，搭建完整的开发

测试环境成本也越来越⼤。

 3、当功能涉及到多个微服务模块时，迭代时需要谨慎地协调多个开发团队的迭代排期，才能保

证迭代能够按时交付，达到敏捷开发的效果。

2、微服务治理

• 应对方案

1、因为代码本身逻辑出错导致业务异常：这时可以通过 SLS 查询⽇志，结合 ARMS 分析错误

堆栈找到根因，修改完代码后，重新发布来修复问题。

2、遇到性能瓶颈：则直接扩容操作，⽐如⽔平扩容应⽤，或者升级数据库。

3、发布新版本影响到⽤户：因为⽤户数和请求数都不算多，很容易就可以找到业务低峰期，在业

务低峰期进⾏发布。

4、如何确保新版本的正确性，因为业务场景不复杂，内部测试就能覆盖所有的场景，测试通过就

可以直接上线。

• 开发测试提效

a.【开发环境隔离】传统的多套开发环境，需要使⽤多套的物理环境，才能实现多套环境各⾃

独⽴互不⼲扰，但是多套物理环境的隔离的机器成本是很⾼的，基本上不⼤能接受。但通过全

链路灰度这种逻辑隔离的⽅式实现开发环境隔离，可以在不增加成本的情况下增加多套开发测

试环境，助你实现敏捷开发。

b.【⾃动化回归测试】⾃动化回归测试功能，可以将多个测试⽤例串联成测试⽤例集，将上⼀

条测试的返回值作为下⼀跳测试⼊参，串联成具体的业务场景并沉淀到⾃动化回归测试中，在

每⼀次的发版之前都跑⼀次⾃动化回归来验证功能的正确性，这样就可以⼤⼤节省测试的⼈⼒

成本。更进⼀步，还可以通过流量录制回放功能，将线上的真实流量录制下来，并沉淀成⾃动

化回归⽤例集，在测试环境进⾏流量回放，更进⼀步地提升测试 case 的覆盖率。

c.【服务契约】功能越来越多，迭代越来越快，API 越来越复杂，团队之间沟通的效率越来越低，

API ⽂档严重过期。如果能⾃动⽣成服务契约，可以有效地避免⽂档腐化造成的开发效率低下

的问题。

• 安全发布

a.【⽆损下线】⽆损下线问题的根本原因是开源的微服务体系没有确保应⽤提供者节点在停⽌

服务前确保已经通知到所有消费者不再调⽤⾃⼰，也⽆法确保在处理完所有请求之后再停⽌应

⽤。所以新发版的应⽤，即使业务代码没有任何问题，也可能在发布过程影响⽤户的体验。

b.【⽆损上线】⽆损上线问题出现的原因是因为在某些场景下服务提供者，需要经过⼀段时间

才能正常地接收⼤流量的请求并成功返回。同时在 K8s 场景下，还需要和 K8s 中的 readine

ss 、滚动发布等⽣命周期紧密结合，才能确保应⽤发布过程中能不出现业务报错。

c.【全链路灰度】新功能上线之后，可以通过灰度规则控制哪些⽤户可以使⽤。这样可以先选择

让内部⽤户使⽤，测试新功能的正确性。当内部⽤户验证通过后，再渐渐地扩⼤灰度范围，确

保每个功能都经过充分验证后再全量开放给客户，屏蔽掉发布新功能的⻛险。⽽且当出现问题

时，可以通过修改灰度规则来实现快速回滚，做到新版本发版时⼏乎⽆⻛险。

• 屏蔽偶发异常导致的⻛险

a.【离群实例摘除】对于这些偶发的异常问题，离群摘除功能可以智能判断应⽤中的服务提供

者某个出现了问题，智能地在⼀段时间内屏蔽掉这个服务提供者，保证业务的正常，等这个服