“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

业务架构没那么容易

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

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

关注

评论 2 条评论

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

mysqldump备份技巧分享

Simon

MySQL 逻辑备份

解读 AppStore 新功能:自定义产品页面和 A/B Test 工具

37手游iOS技术运营团队

ios apple AB testing实战 appstore 马甲包

基于 WebRTC 的1 对 1 通话实战(二)信令服务器实现

IT酷盖

音视频 WebRTC 信令服务器

频繁创建基于Etcd实现的分布式锁会有什么问题?

BUG侦探

分布式锁 etcd 内存泄漏

物联网通信技术,那些你不知道的事

华为云开发者联盟

物联网 网络 通信 有线 无线

【LeetCode】最高频元素的频数Java题解

Albert

算法 LeetCode 7月日更

有图有真相!平衡二叉树AVL实现

Ayue、

数据结构

详解Spring中Bean的作用域与生命周期

华为云开发者联盟

spring 容器 ioc bean Bean对象

策略+IOC 消灭ifelse,拿来吧你

skow

Java 设计模式 代码设计

对标Shopify的千亿市值,有赞还要走多久?

ToB行业头条

SaaS 电商SaaS

我们为什么要选择 Rust 而不是 Golang 或 C/C++ 来开发 TiKV ?

恒生LIGHT云社区

编程 rust 语言 & 开发

ICML 2021顶会来袭,百度飞桨AI硬实力集中展现

百度大脑

人工智能 机器学习 百度

Triton推理服务器在阿里云机器学习PAI-EAS公测啦!!!

阿里云大数据AI技术

服务限流限流算法、限流策略以及该在哪里限流

Jokay

高可用 分布式限流 限流算法 限流 单机限流

【CRUD工程师的末路?程序员开发福音?】AI编程工具——GitHub Copilot推介

恒生LIGHT云社区

人工智能 GitHub 编程

DAPP系统源码模式开发定制

获客I3O6O643Z97

DAPP智能合约交易系统开发 DAPP系统开发

图解URL、URI和URN 区别

devpoint

API url 7月日更

如何优雅地关闭SpringBoot应用程序?听我给你讲

麦洛

Spring Boot

【大牛系列教学】2021年Android程序员职业规划

欢喜学安卓

android 程序员 面试 移动开发

《2021 年中国视频云场景应用洞察白皮书》联合首发!

阿里云视频云

阿里云 计算机视觉 音视频 直播架构 视频云

从源码分析Hystrix工作机制

vivo互联网技术

Java 源码分析 分布式 Hystrix

星火矿池APP源码开发

获客I3O6O643Z97

区块链+

和12岁小同志搞创客开发:遥控舵机

不脱发的程序猿

DIY 创客开发 控制舵机

Flutter Android 工程结构及应用层编译源码深入分析

工匠若水

flutter android dart Gradle 工匠若水

穿越六年艰难转型,明道云终于再获主流投资

明道云

互联网

【大牛疯狂教学】熬夜整理2021最新Android高级笔试题

欢喜学安卓

android 程序员 面试 移动开发

从零开始学习3D可视化之2D界面

ThingJS数字孪生引擎

大前端 可视化 3D可视化 数字孪生

一招教你数据仓库如何高效批量导入与更新数据

华为云开发者联盟

数据库 数据仓库 GaussDB(DWS) MERGE INTO

超好玩:使用 Erda 构建部署应用是什么体验?

尔达Erda

开源 DevOps 云原生 PaaS Go 语言

权威认可!腾讯云数据安全中台入选2021先锋实践案例

腾讯安全云鼎实验室

#腾讯云 数据安全中台

白林学院校友会小程序前端和后台管理系统设计方案

CC同学

校友录小程序 校友会小程序 同学录小程序

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