业务架构没那么容易

业务架构是一个存在二十多年的概念，很多工程师认为业务架构与技术架构相比，缺乏技术含量，对于工程师的能力增长没有多少帮助。但对于大型科技公司而言，业务架构却非常重要。它是连接企业战略和技术实现的桥梁，是连接业务人员与技术人员的桥梁。基础架构有很多可以复用的通用能力，但业务架构却是千变万化需要针对企业自身业务去设计、生长的。

业务架构的定义是什么？有哪些特点和难点？都有哪些发展阶段和挑战？业务架构师该怎么设计架构、做技术选型？它与中台、微服务的关系是什么？InfoQ 记者采访了ArchSummit全球架构师峰会（北京）“业务架构”专题出品人、58 同城高级总监江军平老师，向他请教了业务架构背后的那些事儿。

什么是业务架构？

2008 年从浙江大学毕业以后，江军平先后在微软、腾讯任职，研发过多款亿级别的产品，具有丰富的海量服务架构设计经验。2015 年加入 58 同城后，先后负责过基础架构部、云平台部，承担分布式存储、IM 即时通讯、微服务中间件、私有云等系统研发，支撑全集团每天几千亿次调用。2019 年开始负责 HBG 房产技术部（58+安居客），结合多年的技术积累，深入房产业务，推动服务升级。目前重点关注的技术方向是业务架构，以及基础架构的前沿进展。

在他看来，业务架构是实现业务目标的一整套技术方案，也可以是针对某个具体业务点的架构方案。在互联网行业，好的业务架构具有业务效果好、能快速落地、可持续迭代、不容易出错等特点。

举例而言，对于创业型小团队来说，初期技术团队解决的几乎所有问题都是业务架构的范畴。随着业务的发展和团队规模不断扩大，才会有一部分人专注地去做服务于其他开发人员的通用技术工作，最早被抽象出来的就是运维和基础架构（微服务框架、监控、云平台、前端组件等），上层业务只需关注业务本身的复杂性，而不用去重复制造基础设施的轮子。

基础架构相对而言更加通用，因此也是开源社区比较活跃的领域，有很多开源的成熟产品可以直接用，或者结合自身业务特点二次开发深度定制。业务架构和具体的业务领域相关，一般不能在不同业务中直接复用，但是解决问题的思路方法是通用的，因此业务架构非常适合分门别类介绍方法论。

从单体到微服务

业务架构的演进和业务的发展变化是息息相关的。

早期业务规模较小的时候，一台服务器就可以搞定所有业务，研发人数也较少，这个时候基本都会采用单体架构，比如流行的 LNMP 架构。随着业务发展壮大，一台机器搞不定，就要做分布式，多台机器同时提供服务。伴随组织规模的不断扩大，单体架构无法适应业务的发展，人越多越乱，迭代速度变慢、上线困难等问题接踵而至。这个时候微服务架构就派上用场了，将一个超大规模的单体应用拆分为多个微服务，每个微服务完成一个相对完备独立的功能，可以独立研发、上线、演进。组织也可以相应地划分为小团队，每个小团队都可以小步快跑，敏捷高效。

以 58 集团的业务架构发展为例。

1. 58 集团最早是基于 Windows .NET 的单体架构，很好地满足了业务早期发展的需求；

2. 随着业务发展壮大，2010 年整体升级到 Linux 平台，编程语言也改成Java，这个时期研发了 58 自己的RPC框架和 WEB 框架等中间件，业务架构由一个 Web 服务和后端多个 RPC 服务组成，底层存储使用的是MySQL；

3. 发展到 2015 年，并购安居客、合并赶集网之后，公司组织上推进 BG 化，业务分品类做深做透，技术上业务架构也跟着组织做相应调整，业务服务垂直拆分到各 BG，每条业务线可以独立迭代、上线。同时横向也进行架构拆分，成立公司级技术中台，负责通用技术能力的建设，例如运维、存储、中间件、搜索、数据平台、AI 平台、移动组件、安全、商业等。

业务架构最常遇到的一个痛点是，企业级的业务场景是多变的，如何让业务架构适应不同阶段的业务特性，是业务架构师们最头疼的问题。58 同城在 2015 年并购安居客、合并赶集网以后，亟待解决的问题是如何整合多平台的业务架构。

以房产业务为例，细分的品类有新房、二手房、租房、商业地产等，这些业务在 58 同城和安居客上都有，但是两个 App 的客户端和后端业务架构完全不同，需要两支团队分别开发，整个团队的资源和效率被严重稀释和消耗，急需提升研发效率。

为了解决这个问题，在保证现有线上业务正常运转的前提下，业务架构团队将 58 同城和安居客 App 的业务架构进行打通，首先将 App 底层的公共组件统一，此后基于统一的公共组件对业务代码进行重构，实现两个 App 的房产业务使用同一份代码，通过配置的方式实现差异化；同时整合了后端服务，将所有的底层系统打通，包括逻辑层和数据层服务，实现一个服务能够同时承载 58 和安居客的业务，并且做到新老服务线上平滑切换。架构整合完成以后，团队可以同时做 58 和安居客的业务开发工作，一次开发，两网同步上线，大幅提升了业务的迭代效率。

业务架构，没有想象中那么容易

基础架构和业务架构是一对双生子，后者通常会受到更多的误解。

一般来说，基础架构是通用的技术基础设施，比如各家云服务厂商在云上提供的产品基本都是基础架构相关：弹性计算、数据库、存储、中间件、监控等。业务架构则建立在基础架构之上，基础架构提供轮子，业务架构师将这些轮子又快又好地组装成用户想要的产品。

外界对业务架构的误解通常是其相对基础架构而言，缺乏“技术含量”，实则不然。业务架构师不仅要懂业务，更要能很好地理解基础架构中每个轮子的特性和原理，只有理解够深刻，才能用的更好，技术选型才能做对。

对于业务架构师来说，除了要有扎实的技术功底，还得有优秀的沟通和业务理解能力，能够把复杂的业务场景抽象、分层、简化，拆分给多个人协同开发，对其中的关键技术难点要有很好的识别和把控能力，比如数据规模、访问量、策略效果等，做到快速开发快速上线，且对上线后的业务效果也要有预判能力。因此要成为一个好的业务架构师，很不容易。

对于业务架构师来说，设计业务架构，首先要做业务建模抽象，把架构拆解为表现层、逻辑层、数据层，对于每一层的关键技术重点识别和把控，搞清楚上下游系统的特性，对整体架构方案要做到心中有数，一切尽在掌控。

1. 规划业务中台，把业务中共性的部分抽象出来，避免重复造轮子。比如房产业务的房源库、楼盘字典、开放平台，都是房产各品类可以复用的，因此应该放在业务中台，而不是每条线都自己搞一个。

2. 关注数据规模、访问量，这两个业务参数是每次做架构的设计的时候都应该重点考量的指标，对方案设计影响重大。

3. 考虑业务发展，预判业务未来可能的变化，在架构设计上提前做好规划，避免业务需求一变整个方案推倒重来。

技术选型上，可以考虑如下因素：

1. 如果是在大公司，基础架构一般都比较成熟，优先选择公司内部有支持的技术，且能够更加方便的和公司内部其他系统联动。

2. 如果没有现成的技术可用，优先考虑成熟的开源方案，选择自己熟悉的，能 hold 住的技术，做好未来二次开发的准备。

3. 调研各大云厂商，如果有成熟的方案选择，综合成本能接受的话，可以选择直接用。

4. 如果需要自建，也先调研下业界的成熟方案，借鉴其中的优秀经验和思路，避免走弯路。

业务架构、微服务与中台

如前文所言，业务架构存在的时间已经超过 20 多年，背后是一个不断发展、与时俱进的过程。在当前的云时代下，业务架构变得更加纯粹专注、聚焦在业务上。云时代以前，业务架构要大包大揽，什么都自己做，但在云时代下很多基础的事情可以交给云来做。这里的云，包括私有云和公有云。

除了云时代给业务架构带来的改变，中台概念的出现也对业务架构的设计产生了很大影响。一般来说多个业务能够复用的技术能力，应该放在中台来建设，业务架构直接复用就行，不用重复造轮子。

58 同城内部有公司层面的技术中台，负责通用技术能力的建设，例如运维、存储、中间件、云平台、搜索、数据平台、AI 平台、移动组件、即时通讯、安全、商业等。在房产业务线，也会建设业务中台，比如房源库、楼盘字典、房产开放平台、经纪人服务等，都是统一建设，新房、二手房、租房、商业地产等业务线可直接复用。

微服务是连接中台和业务架构的一个桥梁，很多人认为中台不过是微服务的集散地，这种观点其实有失偏颇。首先，从纯技术的角度来看，中台能力除了通过微服务的形式提供，还有很多是前后端结合的，比如即时通讯平台，大多数时候需要对接 JS 或 App 的 SDK。其次，中台也不是一个纯技术的概念，中台需要组织的保障，中台能力是可以随着前台业务发展不断迭代演进，只有组织才能保障中台的迭代能够和业务的发展节奏同步。

随着云架构、中台、Serverless等架构新趋势的涌现，业务架构也需要持续迭代、进化生长。互联网企业的业务规模增长迅猛，业务场景特性一天一变，对于业务架构的设计、实现乃至重构都提出了更多的要求，业务架构工程师同样需要持续学习、迭代自己的知识结构，以满足变化多端的业务架构。

业务架构不是银弹，没有放之四海皆准的选型方案，适合的，才是最好的。

活动推荐：在 12 月 6 日北京 ArchSummit 全球架构师峰会上，江老师出品“业务架构”专题，邀请了美团服务命名、钉钉存储、京东订单履约、美菜网交易中台的话题，透彻解读业务架构的技术和难点。点击官网查看会议日程。感兴趣来参会的可以联系票务经理 灰灰 15600537884