用微服务收敛异地多活的改造复杂度

[[异地多活的五大挑战]]中”依赖服务部署问题”最棘手的地方在于：核心服务往往依赖大量中小服务，把每一个中小服务都单独做异地多活改造，成本高到不现实。微博在后续演进方向里给出的解法是”借助微服务解决中小服务依赖问题”：把对资源等的操作统一包装成微服务，把中小业务迁移到微服务架构之上——这样一来，只需要对少数几个核心微服务做异地多活改造，众多依赖这些微服务的中小业务就不再需要各自操心”怎么支持异地部署”这件事，从而能以低成本完成大批中小服务的异地多活改造。这条思路和另一个演进方向”升级跨机房消息同步组件为跨机房消息同步服务”是同一种模式的两种体现：跨机房消息同步服务面向业务隔离掉了同步机制本身的复杂性，业务只需要处理消息内容即可，消息的跨机房分发、一致性由这个专门的同步服务统一保障，扮演的角色类似”快递公司”——所有业务都能复用同一个通道，而不必各自实现一套同步逻辑。这两个方向共同揭示的架构原理是：当一类基础能力（跨机房同步、异地多活支持）需要被大量上层业务共同依赖、而这类能力本身实现复杂度又很高时，与其要求每个业务方都各自搞定这个能力，不如把它下沉、收敛进少数几个专门的中间件或微服务里，让复杂度只在这一个地方被真正解决一次，上层业务只需要”接入”而不需要”重新实现”——这正是分布式系统架构里”关注点下沉”的一个具体应用：把原本分散在几十上百个业务里各自面对的同一个难题，收敛成一个组件只需要被正确解决一次的问题。