架构师面试（二十六）：系统拆分

问题

今天我们聊电商系统实际业务场景的问题，考查对业务系统问题的分析能力、解决问题的能力和对系统长期发展的整体规划能力。

一电商平台在早期阶段业务发展迅速，DAU在 10W+；整个电商系统按水平分层架构进行设计，包括【入口网关层】、【业务逻辑层】和【数据访问层】。为了进一步提升电商平台的DAU，几乎每周都会做几次运营活动，因此电商系统基本每天都会有新业务上线和服务重启，这导致电商系统的核心交易逻辑（下订单、支付等）极易受到影响。另外，电商系统的每个业务单元（如：风控系统、广告系统、营销系统等）也都处在不断地更新迭代中。

如果你是该电商系统的架构师，如何解决现有问题？对该电商系统的后续发展应该如何规划？

解析

该电商系统目前处于早期阶段，业务发展迅速，系统按水平分层架构在运行；这里多啰嗦几句，对【水平分层架构】进行简单描述。

水平分层架构一般是在“技术”扩展驱动之下，对单体架构进行水平拆分，通常可划分出【入口网关层】、【业务逻辑层】和【数据访问层】；入口网关层负责外部请求的路由、过滤和转换，业务逻辑层负责处理复杂的业务规则流程，数据访问层负责对持久化数据进行读写。

水平分层架构的每一层是整体系统的横向切面，没有拆分出独立的业务单元，也就是说：业务逻辑层是一个独立服务或进程在运行，这个独立的进程中既有运营活动逻辑也有核心的交易逻辑； 即在同一个工程中，运营活动程序很容易影响核心的交易逻辑程序，这是最根本的问题所在。然后业务逻辑层程序除了核心的交易逻辑和运营活动之外，还包括其他业务单元，比如：风控、广告、营销等；任何一个业务的升级迭代和重启，都会导致其他业务单元也需要重启，正所谓“城门失火殃及池鱼”！

那怎么解决现有问题呢？

目前最紧急的问题是“运营活动”影响“核心逻辑”，成本最低的解决方案是：对业务逻辑层拆分出一个附加的业务逻辑模块，假设目前的业务逻辑层程序叫做 Logic，那就从Logic中把运营活动逻辑单独拆分出来，不妨叫做 Extlogic；由 Logic 负责最核心的业务逻辑内容（比如下单、交易等），由 Extlogic 负责运营活动内容。

上述问题解决之后，就可以开始着手解决很重要但相对不紧急的问题，即很多业务单元（风控、广告、营销、下单、交易等）目前都还糅杂在 Logic 中，最彻底的解决方案是：对每一个业务单元进行服务化拆分；在当前的业务场景中，也叫做垂直化拆分。就是从 Logic 中分别拆分出 SpamLogic（风控逻辑服务）、AdLogic（广告逻辑服务）、MarketingLogic（营销逻辑服务）、OrderLogic（订单逻辑服务）、TradeLogic（交易逻辑服务）等。

这个问题解决之后，就可以坐等业务的发展了，如果业务发展良好，百花齐放，前端孵化出各种业务线时，就可以考虑中台化了，比如对交易业务、风控业务、广告业务等进行下沉形成可复用的业务中台。

简单总结一下：

1. 从 Logic 中拆分出 Extlogic，解决运营活动影响核心业务逻辑的问题；

2. 从 Logic 中拆分出 SpamLogic、AdLogic、MarketingLogic、OrderLogic、TradeLogic 等，解决业务单元之间互相影响的问题；

3. 业务单元中台化，解决业务复用问题，助力前端业务发展。