作业帮多活架构

​

前面分享了唯品会机房级别故障又见机房级别故障，机房级别故障虽然不常见，但一旦出现基本上是影响巨大的。

因为如果系统架构没有做很好的设计和预案建设，可能出现问题后只能干等，而缺少主动应急预案，以至于故障影响不可控。

今天分享下作业帮的多活架构，整体方案还是比较简单的，对于大家理解多活架构的设计和多活架构带来的价值应该是有帮助的。

首先看业务模式，作业帮的业务分成两块：

• 作业帮APP：面向K12的学习辅助平台；
• 作业帮直播课：产业互联网产品，涵盖了教育的整个链条；

作业帮技术现状

作业帮从创立之初就是base在云上的，充分享受了云计算的红利，但随着业务的发展，遇到了单云架构的瓶颈，集中体现在稳定性和成本两方面。

在技术实现角度来说，方案设计有如下几种。

多云架构

主备模式，用户流量通过DNS调度，到达云机房的网络接入层，再路由到对应的服务。经过微服务的调用，最终落到数据存储上。

主备模式是很多企业选择多云最初的方式，当原有云机房出现不可恢复故障后，企业不至于血本无归，数据是可以恢复的。

弹性模式

企业更进一步，不光是数据存储在另外一家云上，也开始把一些核心服务部署在另外一家云上。

这种模式下，通过DNS流量调度，可以实现流量的路由。

企业过去的资源成本，一直是在为峰值买单。

如果云厂商可以以比较合适的价格承担部分弹性的流量，比如峰值30%的容量，这样原有机房只需要70%的容量，整体利用率会有极大的提升，同时可以承担一部分预期之外的流量，为业务保驾护航。

业务切分模式

业务切分模式，业务按照业务特点，选择不同策略的技术架构，通过DNS将流量路由到不同的云机房，实现流量分发。

这种模式下，不同云上的不同服务和数据是不一样的。

数据主权模式

对于出海业务，会受到当地政府数据合规监管的要求，必须将数据放在本地，这样数据就出现了分区，形成了数据主权的多云。

云上的服务和数据表都一样，只是数据不同。

多活模式

多活模式，是通过DNS的流量分配，将不同比例的流量分配到不同的云机房，在云机房里面，实现了所有服务的流量闭环。

当某个云出现故障时，通过DNS切换，将用户流量调走。

多活模式是最理想的方案。

但单云服务等量的部署以及服务闭环还是很难实现的事情。

多云架构全貌

最底层是资源层，包含计算、存储、网络。以Docker+K8s为代表的容器技术，通过容器镜像作业编排，作业调度，资源管理，实现底层资源对上层应用的透明。

上层应用层可以分为基础组件和业务应用，基础组件包括各种数据存储、网关、消息队列、大数据、安全等组件。

上层的业务应用想要跑的更快，还需要一层服务治理体系，整体的服务治理体系以服务的注册和发现为基础，包括服务通信，服务观察，服务流量管控。

网络是多云互联的基础，作业帮早期走了一些弯路，最终选择了多云组网的方案。

链路层方面有冗余，在两条链路上，通过BGP+ECMP实现了链路的负载均衡，以及单条链路出现故障时，可以实现秒级自动切换。

存储层，比如mysql、es、redis，应用不是直接去访问数据存储的cluster节点，而是通过数据存储的proxy中间件进行访问。

通过proxy访问的好处是，可以对下游屏蔽底层细节，提升了易用性、扩展性、稳定性。

在数据存储层的中间件有较为丰富的路由策略，对于写流量，都是路由到主库。对于读请求，根据从节点的负载情况，主从延迟情况，进行流量分发。

当主从延迟超过一定程度的时候，会把这个从节点从proxy中摘除。

还有一个HA方案，可以主动监测主节点，实现故障时的自动切换。

对于交易型链路，对一致性要求比较高，很多读请求不能接受延迟，所以业务上强制读主，保障一致性和可用性。

大多数业务都追求可用性，所以如果主库出现了故障，或者主从出现了延迟，在一个小时的情况下，从库完全不需要摘除，照样可以给业务提供稳定的服务。

虽然系统故障时，推荐采用自动兜底降级的方案，但仍然排除不了需要通过人工介入缩短故障影响时间的情况，以保障对大部分用户提供正常服务。

单元化架构是读写都是闭环的，不会跨单元请求。

也就是说单元内只有自己的数据，通过DTS把其他单元的等差数据同步过来，这样每个单元就具备了全量的数据。

多数公司在做单元化的时候，会选择passport这样的业务：

1. 首先，所有用户产品的业务基础，想要对其他业务单元化，passport一定需要做；
2. 其次，Passport天然是可以按用户id进行切分；
3. 同时，Passport提交并发量较低，不管是用户登录还是信息修改都不是高频操作；

作业帮单元化的业务是直播课堂，因为直播课堂是天然按照业务进行切分的，在单个课堂内，师生之间需要强互动，但不同课堂之间不需要在线实时交互，只需要离线的大数据统一汇总分析即可。

通过单元化提升整体稳定性，当单云出现故障时，通过DNS或者自研的Doh进行流量调度。

东西流量治理，这块是比较复杂的。多数公司的技术选型也是在这里出现差异的。

作业帮将云上应用分为两部分，一部分是互通区域，一部分是受限区域。

互通区域的应用可以做跨云通信，受限区域服务不可用，只能通过互通区域中转。

跨云治理是一个漫长的工作，需要完备的平台支撑，避免一次性的任务，需要开发对应的平台，面向研发。

持续运营

最后就是这套架构的持续运营了，对于短时间无法改造完成的，持续跟进进度，逐步将其从跨云白名单剔除。

定期演练

多云架构不能停留在方法论或者方案上，为了确保多云架构真正在出现问题时可用，务实的做法是需要进行定期断网演练。

比如半年进行一次，用于发现架构的隐患问题以及预案的执行流程流畅性。

故障模拟要尽量真实，演练中能达标，面对真正故障时才能更有底气。

以上就是作业帮的多活架构设计，整体设计方案还是非常简单的，对于想做的多活架构的业务来说，上手还是比较简单的。