业务架构没那么容易

阅读数:3766 2019 年 11 月 5 日 16:27

业务架构没那么容易

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

业务架构的定义是什么?有哪些特点和难点?都有哪些发展阶段和挑战?业务架构师该怎么设计架构、做技术选型?它与中台、微服务的关系是什么?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. 调研各大云厂商,如果有成熟的方案选择,综合成本能接受的话,可以选择直接用。
    如果需要自建,也先调研下业界的成熟方案,借鉴其中的优秀经验和思路,避免走弯路。

业务架构、微服务与中台

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

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

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

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

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

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


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

评论

发布
用户头像
学习了,谢谢分享。
2019 年 11 月 07 日 08:09
回复
没有更多了