写点什么

业务架构没那么容易

  • 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:275783
用户头像
小智 让所有人认同的文字称不上表达

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

关注

评论 2 条评论

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

图片压缩格式自适应,真的很省流量!

七牛云

流量 带宽 音视频技术 图片压缩

数业智能心大陆:职场倦怠的新解法

心大陆多智能体

智能体 AI大模型 心理健康 数字心理

从“群聊”到“一单到底”,天润融通工单系统助力品牌服务升级

天润融通

AutoCAD 2020(cad设计绘图软件) Win&Mac 版下载

你的猪会飞吗

AutoCAD 2024 Mac版 cad 2022安装教程

比克方形锂电池:聚焦多元场景,赋能应用升级

科技热闻

创始人模式:硅谷领导力的实践方法

无崖子Z

实现NAS远程下载,Docker部署qBittorrent、Transmission、贝锐花生壳

贝锐

NAS Docker 镜像

Deep Dive | 应对不固定业务流量场景,Zilliz Cloud Serverless 正式推出

Zilliz

zilliz cloud

ubuntu修改用户名和用户密码

百度搜索:蓝易云

创建git分支命名原则

百度搜索:蓝易云

京东技术专家的修炼之道|“六边形战士”周默分享

京东零售技术

天润融通创新功能,将无效会话转化为企业新商机

天润融通

如何帮助我们改造升级原有架构——基于TDengine 平台

梦笔生花

时序数据库 TDengine征文 架构升级

CZ 即将回归,这四个月币安疯狂上币用意何在?

区块链软件开发推广运营

交易所开发 dapp开发 链游开发 NFT开发 公链开发

连接泄漏终结者设计方案:HikariCP中间件的先进检测策略(架构设计篇)

肖哥弹架构

Java 连接池 泄漏

天润融通助力连锁品牌,用知识库应对门店咨询挑战

天润融通

天猫店铺商品列表API:深度解析商品视频与图文详情的获取

代码忍者

API 测试 pinduoduo API

抖音、视频号足球直播授权为何难以获得?背后原因揭秘!

软件开发-梦幻运营部

WebViz可视化工具的应用

梦笔生花

基于ubuntu构建jdk镜像

百度搜索:蓝易云

数据驱动,实时监控显威力 —— 淘宝商品详情API助力商家精准营销

技术冰糖葫芦

API Gateway API 接口 API 测试 pinduoduo API

2024-09-21:用go语言,给定一个字符串 s,字符串中的每个字符要么是小写字母,要么是问号‘?‘。对于一个仅包含小写字母的字符串t,我们定义cost(i)为在t的前i个字符中与t[i]相同的字

福大大架构师每日一题

福大大架构师每日一题

金九银十,字节的第一面来咯

王中阳Go

面经 字节跳动面经 面试问题 golang 面试

mac万能音视频转换器:Permute 3 for mac 中文版

你的猪会飞吗

Permute 3 for mac Permute 3 Permute 3破解版

Apache Flink 流批融合技术介绍

Apache Flink

flink 实时计算 流批一体 流批融合 大数据计算

【功能详解】IoTDB 与 ThingsBoard 成功集成!

Apache IoTDB

MySQL四种备份表的方式

百度搜索:蓝易云

Ubuntu 22.04编译DPDK 19.11 igb_uio和kni报错解决办法

百度搜索:蓝易云

天猫店铺商品列表API返回值中的商品视频与图文详情

技术冰糖葫芦

API Gateway API 接口 API 测试 pinduoduo API

美联储降息50个基点是“核弹”?比特币涨到100万是可能的!

区块链软件开发推广运营

交易所开发 dapp开发 链游开发 NFT开发 代币开发

ONES 与华为云深度合作,共同打造企业智能研发管理平台

万事ONES

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