O2O平台服务治理-异地多活架构设计

Posted 2021-04-25 架构师的历练

       2019年来临的时候，自己也开始了一段新的旅程，伴随而来也有新的领域和挑战。在一周的时间里，通过对原有业务流程、架构的了解，结合异地多活的目标及部门的思路，输出O2O业务的异地多活架构设计方案，分享出来，抛砖引玉。

        一、DB系统如何适应业务的发展

        在业务的蛮荒年代，多数业务的DB系统往往采用一主多从的架构。

        但这种架构很难满足业务增长的需要，因为写的需求会越来越大，无论是“一主几从”都无法解决当前问题了，这时，往往需要而临数据库的拆分，常见的思路是：把热点业务单独拆出来，把一套数据库拆成多套，即数据的垂直拆分。

      垂直拆分的最大优点是贴合微服务理念，对业务的改动量较小，见效快。常见的拆分原则是根据业务的QPS（TPS），以半年或一年的周期计算增长情况，然后再反推所需要的数据集群数量。

       垂直拆分虽然能解决一部分问题，但热点业务增长所带来的数据压力隐患依然存在，随时可能成为瓶颈。

       这时候，水平拆分就成为常见技术方案。

       水平拆分常见方案就是把原来在一张表中的数据在底层拆分成1000张小表，放在不同的集群上。这样，即使业务量增涨，也可以通过不断扩容机器来将压力拆分到更大的集群上，从而将热点的压力分散。

        为了保证水平拆分时，业务逻辑不作太大的变化，一般会引入DAL中间件来对底层数据进行透明化的管理和访问。比如常见的cobra，mycat，以及能力更强的TiDB。

        这些DAL中间件主要作用是封装了底层数据路由及分表查询的数据聚合，使得上层业务在操作数据时就象操作单库单表。

        一般业务发展到分库分表之后，业务维度的数据热点压力就基本上解决了。

        二、同城容灾和异地多活

        虽然垂直拆分和水平拆分之后，业务的热点压力基本上解决了，但机房又会成为另一种瓶颈。

        一般来说，一个租凭供应商的机房、场地是有限的，虽然技术上可以通过水平扩展数据集群来分散压力，但机器、场地、网络等物理条件会成为容量瓶颈。

        另一方面，天灾（地震、洪水、挖掘机等）和管控（限电等）也会严重影响业务的正常运转。

        所以，为了解决物理的限制，一般企业会引入两种方案：一是同城容灾，二是异地多活。

        （一）同城容灾

        顾名思义，就是在同一个城市的两个不同机房（一般距离会间隔30km以上，跨区），部署同一套集群。

        由一个主机房负责承载业务，数据只作单向流动，分机房只部署主链路服务及全量数据。正常情况下，主机房处理业务，备用机房作backup，一旦主机房出现问题，把流量调度到备用机房。

        但这样的架构一方面实际的资源利用率不高，另一方面，可靠性也存在比较明显的问题：

        1、WAF作为业务请求的防火墙，同时也承担跨机房流量调度的职责。但它不像互联网架构那样，通过cdn来进行流量调度，WAF本身会成为流量和系统稳定性的瓶颈。

        因此，基本互联网架构的异地多活是更加优秀的方案。

        （二）异地多活

        为简单起见，主机房称为中心，从机房称为单元。

        1、目标

        1）中心流量切换：中心断电断网场景下，流量调度到单元；

        2）单元流量切换：单元断电断网场景下，流量调度到中心；

        3）主链路同城切换：流量划拔到同城IDC，灰度及容灾切换；

        4）主链路异地切换：流量划拔到异地IDC，灰度及容灾切换；

       5）30秒完成流量切换；5分钟完成数据切换；1分钟完成其它切换；

        2、主链路业务选择

        异地多活的整体架构基本延续了分布式的基础设施，将服务与数据在不同的地域部署。方案本质上是通过数据的冗余，实现中心级的服务容灾。数据同步是异地多活方案的核心。

       数据同步关键点是两个，一个是实时性，另一个是冲突的处理，可能会涉及业务规则的变更，方案相对成本比较高，因此，对于实现异地多活的业务考量，主要考虑覆盖核心业务场景

        o2o业务中，以线下门店为例，核心业务行为发生在订单生成和结算付款环节，因此，优先保证核心链路的异地多活。       

        

        

        3、实时一致性的保证

        物理上的限制

      拿广州到北京的距离举例，理想时延为5毫秒左右，再加上传输环节中各种设备的处理时延，正加上网络抖动，正常情况RTT为50ms左右，如果遇上网络波动，有时会飙升到500ms甚至1s，如果发生丢包，延迟可能会有几秒几十秒了

        

      考虑对策

       2）减少数据同步：只同步重要数据，减少不重要数据及同步后没用的数据的同步。比如会员的cookie或session信息，丢失后重新鉴权即可。甚至极端情况下，待支付的商品，丢失后重新查询生成支付列表即可。

      3）保证最终一致性：在业务逻辑中，尽量减少对数据同步实时性的依赖，只要数据能最终一致即可。比如当某件商品新增了折扣，查询的时候，业务不必要求50ms以内同步到所有机房，只需要保证最终扣款和打印发票时时折扣已被计算入内。需要同时考虑二次读取的问题，比如yh机房的商品折扣信息发生了变更，还没有同步到qd机房，这时qd机房发生支付行为时，需要根据路由规则到yh机房请求数据。（这块能力需要建设）

        

        4、数据层可用性保证

        1）同步方案

        mysql自带的Replication和Semi Replication，都满足不了数据一致性下的高可用和高性能，特别是跨机房时的稳定性很难保证。一般可以考虑DRC同步组件。

      数据同步组件 DRC，实现的功能是在一边机房接受变更日志，并把变更日志传递到其他的机房去，其他机房再能把这个变更应用上。

        2、但只是数据库同步也是不能完全满足要求，可以考虑其它的配套策略：

       1）消息队列：在业务层通过MQ进行同步。

       2）二次读取：一次读本地，失败后根据路由规则，二次读对端。这是比较常用的解决异常情况下同步延迟的方案。

     3）回源读取：对于信息量比较大的数据，比如会员或门店的cookie，可以不同步数据，根据hash规则，直接访问门店或会员所在的数据中心读取。

       4）降级：切换期间开启业务降级，禁写。在diff gap apply之后，进行冲突检测，若有冲突则手工对帐订正数据。

       5）重新生成数据：比如一些非重要数据，宕机了就重新生成。

       5、服务路由规则

        

        服务路由切分

        1）方案是根据门店编码进行mod，保存在cookie中，当无MA时流量随机分配。门店的路由划分方案有二种：

     考虑支持会员ID的划分方式，因为单元化之后，不能保证依赖的公共数据在单元中是全量部署的。

       数据路由划分

       1）数据路由规则与服务路由规则保持一致，如果流量按照门店编码来切分，那数据切分也是同理。

       2）在开启数据路由的情况来，单元的数据可以不是全量。但一期建设，预计不会上线数据过滤，因此首期建设时，单元的数据也可以是全量。

        6、业务模型

业务模型与服务的特点相关：

1）业务服务：封闭在一个Cell内的服务•

     独占型服务：不与其它Cell交互的服务，如易购会员、订单、购物车

     共享型服务：所有Cell共享的数据，如商品、价格等

     竞争型服务：各个Cell竞争的数据，一般在中心进行控制管理

2）控制服务：对所有IDC提供服务，在物理上一般部署在中心

     竞争服务：所有Cell操作同一份数据，一般在中心进行控制，如Inventory、优惠劵、定量抢购等。

    维度服务：对无维度数据提供维度服务，如临时购物车

3）索引服务：提供映射和路由的服务，如CDN、RSF、MQ等

4）管理服务：用于推送共享数据和业务数据到各个Cell

     后台服务：推送共享数据给各个Cell

     变更服务：向各个Cell通知业务变更信息

     7、异地多活系统架构