AI 年度盘点与2025发展趋势展望,50+案例解析亮相AICon 了解详情
写点什么

业务架构没那么容易

  • 2019-11-05
  • 本文字数:3682 字

    阅读完需:约 12 分钟

业务架构没那么容易

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


业务架构的定义是什么?有哪些特点和难点?都有哪些发展阶段和挑战?业务架构师该怎么设计架构、做技术选型?它与中台、微服务的关系是什么?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


2019-11-05 16:275794
用户头像
小智 让所有人认同的文字称不上表达

发布了 408 篇内容, 共 390.3 次阅读, 收获喜欢 1982 次。

关注

评论 2 条评论

发布
用户头像
你是在说业务架构还是系统架构,没看明白。业务架构有谁来定义?领域专家?一线业务?一线业务的leader?CTO或者BU技术老大?子团队架构师?一线研发?还是这里面的高层次人聚到一起来定义?如果你认为是其中一种,你们真的这么多的吗?
2021-01-24 17:41
回复
用户头像
学习了,谢谢分享。
2019-11-07 08:09
回复
没有更多了
发现更多内容

程序员提效的 10 个方法,建议收藏

秃头小帅oi

从人员外包到测试工具、测试平台,提供全方位的测试解决方案~

霍格沃兹测试开发学社

通义灵码知识库问答增强:知识库构建与管理指南

阿里云云效

阿里云 云原生 通义灵码

新技术如何解决体育直播平台开发中的五大难题?

软件开发-梦幻运营部

曹操出行借助 ApsaraMQ for Kafka Serverless 提升效率,成本节省超 20%

阿里巴巴云原生

阿里云 云原生

AI 原生时代,更要上云:百度智能云云原生创新实践

百度Geek说

spring-关于组件的注入及获取流程

快乐非自愿限量之名

Java Spring Boot 后端

通义灵码知识库问答增强:知识库构建与管理指南

阿里巴巴云原生

阿里云 云原生 通义灵码

软件测试学习笔记丨Flask框架-接口使用

测试人

flask 软件测试

LeetCode题解:2648. 生成斐波那契数列,迭代+递归,超详细解析

Lee Chen

如何成为一名优秀的程序员,进来看看

伤感汤姆布利柏

实时特征框架的生产实践|得物技术

得物技术

flink 性能优化 数据平台 特征框架

薅羊毛了!百万度算力免费申领活动狂欢继续!

九章云极DataCanvas

电子签软件是什么?概念以及主流产品分析

爱吃小舅的鱼

软件

天润融通邀您参加AI破局·聚力增长行业论坛

天润融通

用户增长 AI大模型 用户运营 天润融通

如果您干不动跨境外贸独立站,可以来看看反向海淘代购模式

tbapi

反向海淘 反向海淘代购系统 逆向海淘代购系统

解锁低成本数据库归档方案,Databend 受邀参加 TiDB 杭州地区交流会精彩回顾

Databend

全新HUAWEI MatePad 11.5发布:搭载华为教育中心,做更好的学习神器

最新动态

软件测试学习笔记丨Flask框架-请求与响应

测试人

flask 软件测试

除了邮件钓鱼外,你还知道哪些常见的钓鱼攻击方式?

国科云

知识管理系统是什么?

ServiceDesk_Plus

知识管理系统 知识管理软件

使用docker搭建ELK分布式日志同步方案

EquatorCoco

Docker 容器

推特账号被冻结怎么办?检查IP是否正常

Ogcloud

云手机 海外云手机 海外原生IP 海外IP

云原生开源开发者沙龙丨AI 应用工程化专场杭州站邀您参会

阿里巴巴云原生

阿里云 云原生

指标预警归因分析,及时发现业务问题,快速定位问题根因

Aloudata

数据分析 指标平台 指标开发

鸿蒙开发案例:打地鼠

zhongcx

数据结构 - 散列表,三探之代码实现

不在线第一只蜗牛

数据结构

如何解决SD-WAN安全问题?

Ogcloud

SD-WAN 企业组网 SD-WAN组网 SD-WAN服务商 SDWAN

什么是无代码?无代码开发平台又是什么?

积木链小链

无代码 无代码平台

如何通过指标驱动研发体系建设

思码逸研发效能

DevOps 研发效能 效能度量 研发效能管理 思码逸

立足云南,面向“两亚”,翻开普惠算力新篇章

九章云极DataCanvas

业务架构没那么容易_ArchSummit_小智_InfoQ精选文章