同城双活和异地多活架构

首先这些架构，都是为了保证服务的高可用；

“活” 指的是可以提供服务，与之对应的是 “备” ，备份是冷数据，不能对外提供服务，仅仅是会同步数据，当活的机器都不可提供服务时，需要启动备份服务来先提供服务，备份的缺点是，启动备份后需要验证后才能使用，有延时性，不能保证服务每时每刻都可用；

同城双活，指的是同一个城市内，部署两个机房，如果一个机房不可用，另一个机房都能够单独对外提供完整的服务；

• 网关（NG）、注册中心、微服务每个机房都部署一套，尽量避免跨机房调用（就近调用降低延时）；
• Mysql、Redis 使用的是同一套“活”集群，同时有另一套备份的 Mysql 、Redis 会做数据同步（可使用主从架构保证）；
• 当某一个机房不可用时，可在最外层的网关关闭路由，判断数据库所在机房是否是不可用的机房，是的话则需要切换数据库配置到备份集群，不是的话则不需要切换；
• 拓展，测试环境搭建一般只有一套环境，那么如何模拟生产？服务通过 meta 标记子环境 subEnv 注册到注册中心，拓展注册中心 loadbalance 接口，对路由的子环境进行过滤，在进行负载均衡路由到对应机器；

两地三中心，指的是同城双活的基础上，增加一个冷备份的机房，当双活都不可用时，启动备份机房提供服务；

前面两种架构，仍然不能保证极端情况下，如地震，某个城市的基础设施都不可用了，那么同城双活都不能对外提供服务；如果需要保证极端情况下的高可用，可以使用异地多活的架构；

异地多活，每个城市的的机房，都拥有完整的一套对外提供服务的能力，包括数据库、Redis 都是机房单独部署（异地链路太长，数据同步延时会很长，假设某个机房挂掉的情况下，数据同步不及时还是会存在数据不一致的问题，所以还不如直接数据库单独机房使用），且不可跨机房调用（异地链路太长影响 tps）；

那么怎么实现路由呢？

• 对于网联专线的方案，直接通过参数 idc 指定机房，但不方便的是客户需要自己上送；
• 另一个可行方案类似，通过商户订单号，取余路由到特定的机房；这样同样的订单就能路由到同一个机房进行获取；
• 但是如果有些接口没有商户订单号怎么办呢？又要找另一个字段来路由吗？使用商户的 id 来路由是否可行？因为商户进件必须有商户 id，商户的数据也肯定与商户 id 有关联；但其实是不可行的，因为会存在数据倾斜的情况，某个大商户的订单量大就会导致数据量都积压到同一个机房；
• 所以目前看来，还是让客户自己上送 idc 参数指定机房是较好的方案；