业务架构设计迭代演进思路

业务架构大家都在做，到底什么是业务架构，业务架构有什么用，如果要做业务架构需要注意些什么？

在 2021 年 5 月 28-30 日举办的 QCon 全球软件开发大会（北京站）“业务架构演进”专题上，到家集团技术委员会主席、快狗打车 CTO 沈剑老师将分享《百万司机在线打车平台架构演进》，在会前 InfoQ 带着一系列的问题对沈老师进行了采访。希望帮大家理清楚“到底什么是业务架构？业务架构有什么用？如果要做业务架构需要注意些什么？”等问题。

以下内容根据采访内容整理。

为什么需要做业务架构

在讲业务架构之前，我们先看下什么是“架构”，理解架构之后，业务架构就更好理解了。“架构”一词的英文单词是“architecture”，而这个单词来源于建筑词汇，可以理解是房屋的整体结构、框架。再看下“基础架构”，它其实就是偏底层通用基础建设相关的架构，如 K8s 集群建设、Service Mesh 等。现在再回过头来看“业务架构”是不是已经又一个比较直观的答案了呢？基于业务场景去设计架构，就是业务架构了。

为什么要做业务架构？这个问题沈剑老师是这么说的，“系统本身是服务于业务的，脱离业务谈系统，没有意义；系统架构本身也是解决业务问题的，脱离业务问题和业务阶段谈系统架构也同样没有意义。在做系统设计，在做系统架构的过程中，一定要先了解业务的特点，针对业务做系统；也一定要了解业务的痛点，通过系统架构设计去解决业务的痛点。”

因为我们置身于业务场景中，脱离业务去设计架构其实是有问题的。那么，在业务发展的不同阶段，架构的设计会不会是一样呢？我们以快狗在线打车平台来看。

不同阶段，如何做业务架构

快狗打车，是中国头部同城即时货运平台，其业务核心流程是：从用户下单，系统推送，到司机抢单，中单，完单。当同时在线司机数，从万，到十万，到百万的过程中，在量级不同的阶段应该使用什么样的系统架构来应对，不同的阶段的架构设计是不是一样呢？

沈老师说，“其实在快狗打车业务发展之初，业务形态并不稳定，业务对系统的要求是快速实现、快速响应、快速迭代。但随着业务形态逐步稳定，用户、司机、订单越来越多，业务对系统的要求是稳定，要具备一定的扩展性。”

然后沈老师举了三个具体的场景案例来说，“相同的场景下，在早期和现在对系统架构的要求截然不同。”

第一个场景，订单系统。早期快狗打车多个业务（2C、2B、直营城市、下沉城市等），每个业务更适合有自己独立的订单库，方便快速试错。而现在则需要统一订单中心，提升稳定性、保证扩展性，并维持较低水平的维护成本。

第二个场景，经纬度检索。司机的经纬度上报与检索，是快狗打车的业务核心之一。早期我们直接使用数据库来存储与检索经纬度，快速实现、快速迭代。如果现在还用数据库，肯定性能扛不住，所以现在则抽离了单独的服务来实现。

第三个场景，消息中心。早期 GPS 上报，快速实现了一套消息通道；订单推送，快速实现了一套；用户与司机聊天，快速实现了一套。现在，我们则把共性的需求抽象除了消息中心，以满足不同场景，在扩充业务场景的适合，能够复用系统。

通过沈老师对快狗不同的业务场景的系统要求分析，我们可以知道，在量级不同的阶段因为对系统的需求不同，所以对应的系统架构也不会相同。在快狗发展的这几个阶段中，他们在业务架构设计方面还是走了一些弯路的；我们来看下，他们是怎么解决的。

业务架构设计迭代踩过的坑及解决思路

沈老师说，“因为业务的不同阶段对架构的要求不同，在架构迭代或者重构的过程会比较痛苦，一方面要完成架构升级与转型，另一方面又不能影响业务需求的开发与迭代。”

在架构迭代和重构过程中，既要保证架构升级迭代，又不能影响现有业务正常进行；其实是有一定难度的。沈老师通过一个“订单库从分开，到订单中心合并”的例子来说，他们当时遇到快速支持业务迭代的同时并行架构改造时是如何做的？

还是举订单库从分开，到订单中心合并的例子，整个过程实际是比较痛苦的：

(1) 第一个业务（优配业务），闭环了自己的订单库；

(2) 第二个业务（货旳业务），为了快速迭代，也闭环了自己的订单库；

(3) 第三、第四个业务（车队业务、合伙人业务），发现情况不对，尝试统一订单库，尝试建立订单中心，但并不彻底；

(4) 当有订单统一展现的需求时，要访问多个订单库，开始抓狂了，抱怨早期为何不统一，下决定要统一；

(5) 然后开始数据收口，服务写收口，服务读收口，最终花了 1 年的时间，才完成订单中心的统一；

随着业务的发展，对架构的需求不一样，架构升级过渡期会比较痛苦，但又必须协同各个业务研发团队，往正确的方向走，做到架构的阶段性合理。

中台是下一步尝试

当我问到，快狗在下一步的计划时，沈老师说，其实他们目前在业务中台方面做尝试。

“首先业务中台是结合业务的，其次业务中台是多业务通用的。例如，快狗打车的用户、交易、订单、结算、营销等，不管是 2B、2C，自营业务还是下沉业务，都是通用的，就适合抽象成业务中台，统一来建设。”

来自快狗打车的又一金句“任何脱离业务的中台都是蹭热度”。

总结

我们熟悉了业务架构的概念，从快狗的业务场景出发，看到了不同阶段对业务架构设计的目标其实是不一样的，如果你正好也要做业务设计，沈老师是建议：

(1) 贴近自己的业务场景，深入的了解业务逻辑，针对该业务阶段设计适合自身的框架；

(2) 系统架构设计中必须要考虑的可用性、高性能、扩展性、一致性等常见要素；

(3) 还需要考虑业务特性、业务痛点、业务需求，密切贴合业务做系统架构。

针对不同的业务场景，不同的业务架构设计总是给我们带来惊喜。比如 2020 特殊情况下，在线教育的崛起，学而思等在线教育又是怎么针对自己的业务特性去做架构设计呢？除了在线教育的业务架构，在线票务、短视频在业务架构演进的过程中，又会有怎样的故事呢？

嘉宾介绍

老熟人了，哇咔咔。大家好，我是沈剑，现在是快狗打车的 CTO，负责产品研发，同时是架构师之路公众号的作者，偶尔深夜写写文章。比较喜欢分享自己的一些技术，产品，管理的一些经验，不管在公号上，还是在 QCon 大会上，期待和大家的沟通交流，期待面基。