异地多活方案选型的六个决策维度

就像没有完美的通用架构一样，异地多活的最佳方案也要因业务情形而定——如果业务请求量比较小，根本没必要做异地多活，数据库冷备就够了；不管选哪种方案，异地多活的资源成本和开发成本相比单机房部署都会大幅增加。做选型时值得考虑以下六个维度。能否整业务迁移：如果机器资源不足，优先把体系独立的服务整体迁移出去，为核心服务腾出机架资源，实在腾不出再考虑异地多活。服务关联是否复杂：如果服务关联简单，可以用单元化或跨机房消息同步的方案（不管哪种方式，关联服务都要一起做异地多活部署，确保各机房对关联业务的请求都落在本机房内，不产生跨机房调用）。是否方便对用户分区：游戏类、邮箱类服务因为用户之间关系相对独立，很适合[[单元化方案与跨机房同步方案的对比]]中提到的单元化路线；而SNS类产品因为用户关系（好友、转发等）天然跨用户耦合，不太适合单元化。谨慎挑选第二机房：尽量选离主机房较近（网络延时10ms以内）、专线质量好的机房，这样能简化掉大多数小服务的依赖问题、把精力集中在核心业务的异地双活上，同时专线成本占比也小——以北京为例，建议优先考虑天津、内蒙古、山西这类近距离机房。控制部署规模：在数据层自身还不支持跨机房服务之前，不建议部署超过两个机房——两个异地机房已经能达成容灾目的，服务器规模也足够大、配套设施相对健全、运维成本可控；一旦扩展到三个点，新机房基础设施磨合、运维决策成本都会大幅增加。消息同步服务化：建议把消息同步能力从具体业务里抽出来，做成中间件或服务层直接支持的跨机房同步能力，并把消息体大小控制在10K以下——机房间的数据一致性只靠这套消息同步服务解决，机房内部另行处理缓存等与消息的一致性问题，核心要求是消息绝对不能丢，微博采用MCQ的”本地写、远程读”方式来实现高效稳定的跨机房消息同步。