我介绍一个方法,一定不是唯一的一个方法.
在我快10年的工作经历中,7年的架构工作.我待过创业公司,也在一线大厂工作过.
我们可以思考一个问题:
一个阿里的架构师,去了腾讯还是架构师吗?
答案是显而易见的,一定是.
但是我们可以想想这个问题背后意味着什么
如果一个架构师(可以是职位title),是和公司无关的,那么也一定是和我们处理的业务无关的(因为你换了公司,业务的细节肯定发生了变化).
这也一定意味着:架构是有通用的标准和一些通用的方法的,这些方法和标准,是我们业务研发共同的.
所以一个阿里的电商系统架构师,去了腾讯可能不会是一个中间件架构师,但是也一定是应用架构师
通用但不相同
通用但不一定有用
什么是方法论
就像我刚才的举例一样.其实我很讨厌"方法论"这个词,我更加喜欢"通用方法"这个描述.
因为"论"这个字,总感觉是空口无凭,没有落地的实践的感觉.
相反"用"这个字,就更加强调如何使用了.
其实什么是方法论很简单
本质就和我们用筷子一样,当我们学会用筷子了之后,可能是先学习夹土豆丝,但是这并不妨碍我们直接用这个使用方法去夹胡萝卜丝.
使用方法是通用的.
所以方法论,本质就是某些通用的内容.
这些通用的内容可能是总体的思路,设计的模式,设计的步骤,解决某一类问题的方案.
再具体一些,我们所有的技术框架,和一些技术方案,都可以认为是方法论.
比如,如何解决一个高并发QPS的问题?
我们往往选择前置缓存的方案.这就是分层访问控制,这种通用的方法.
那么这个方法,不管你是电商里面商品详情,还是微博里面的消息,都可以使用.
这种"通用"的部分,就是方法论.
前提
我一直是做互联网应用研发相关的工作.我相信绝大部分开发同学都是从事这样的工作:
针对公司的某些特定的业务,提供功能,完成互联网上面用户真正使用的一个产品.
比如电商业务,社交业务,支付业务等等.
应用研发相关领域,是明显有别于中间件,基础服务,高可用这些工作的.所以高可用架构师是否能使用我这个方法论呢?
我觉得是不行的,因为这部分内容很明显没有抽象到那么高的高度.
越通用,就越抽象
"明灯"
我的一个方法.我叫做明灯.具体内容是
高度抽象业务领域,然后具象化到某一具体的概念,形成隐喻
围绕这个概念设计我们的核心领域模型
基于核心领域模型驱动定义我们的平台服务
基于平台服务的组合,定义我们的平台产品
有别于DDD,我很多时候喜欢叫这个过程和方法是SDD(service design driven).其实没有什么特别的关系,就是为了装逼.
之所以叫明灯.是沿袭我之前的一个生活感悟
我要举起一盏灯
可能无法照亮一切
也不能给大家指引出明确的方向
甚至无法找到脚下的道路
但是黑暗中那一点微弱的光
终将成为我们前进的动力
隐喻
这个概念来源于XP:极限编程,里面专门提到的架构隐喻.
在XP里面重点强调,架构是演进的.所以书里介绍了很多帮助架构演进的一些方法.比如结对编程,第一子弹原则,TDD等等.我觉得这个概念和方法太好了.在工作中就直接使用了.沿袭至今.
隐喻就是用一种大家都非常有体感的概念和话语,直接的描述出来我们系统在干什么.
比如:
商品系统就是在货架上放一个东西
交易系统就是一手交钱,一手交货
当然,也有非常高度抽象和具备领域特征的.比如在支付宝,一些我的理解
统一支付:基于有价资产转移
结算:基于交易的支付后资金关系协调
收单:基于业务场景的,支付能力串联
交易:业务活动状态驱动的支付能力组合
隐喻,一定不是我们某个业务领域或者某个系统的架构定位,系统职责,核心领域模型.
隐喻就是隐喻
就是一个概念,就是一个简单介绍.
关键在于,当我们迷茫的时候,可以帮助我们指引方向.
核心领域概念
这部分内容和方法取自DDD.就是DDD里面的领域模型驱动的领域概念.
唯一有些不同的想法就是,我不喜欢DDD里面关于领域模型"驱动"的部分.我觉得太过形式了.
很多时候使用不好就变成了为了形式而形式,为了架构而架构.没有真正的解决问题.
此外,我想强调一下,领域模型不等于DB数据模型.
可能我们有5个核心领域模型,但是只有4个数据表.因为其中可能一些领域模型是需要基于我们数据进行计算的.不方便直接存储状态.
平台服务&平台产品
这里是抽象定义出来我们的核心原子服务的.
平台服务也可以使用枚举法来定义,比如枚举出来我们所有的业务场景,然后其中相似的业务功能,就是一个平台服务.
但是我更加建议使用领域驱动定义法.否则很多杂七杂八的validator都变成平台服务了.
定义平台服务一定注意抽象,如果把控不好粒度,那么也可以按照领域模型的方式来抽象定义.抽象的时候不要超过领域模型.
比如一个电商的交易系统,那么肯定会有一个"订单"领域模型.
我们的核心平台服务就可以定义成:
订单创建,订单状态变更,订单确认,订单支付.
这种都是合适的.
那么我们还是可以继续抽象的.比如支付,退款,改价等服务都涉及到金额或者资金驱动.
是不是我们可以抽象成,资金动作驱动这个服务?
我觉得是不可以的.因为按照我的理解,平台服务是基于领域模型的,你抽象到没有订单的概念了.就不合适.
基于平台服务的组合,满足某种特定业务场景里面的功能,就是平台产品.
这里其实是用的分层的概念来做的.因为一个原子服务一定无法独立对外使用的,肯定需要有一层来处理组合的问题.
需要大家注意的是,"平台产品"里面所有的概念,都是自内向外的.
就是典型的,我不要你认为,我要我认为.
大家可以体会体会.我后面可以单独开一个文章来讲述什么是平台产品,以及什么是平台型架构
业务场景
业务场景,我的建议是不要那么抽象.外面需要啥,我们就弄啥.
没了.简单直接.
怎么用? 架构方案结构
不要拿个锤子,看什么都是钉子
其实我想和大家强调一下,也是和一些所谓"大厂架构师"来说的.
且不论有些架构师有没有方法论(可能就是之前的架构经验,和一些以前的架构方案)
方法论,是一定无法直接使用的
我们仔细想想,如果方法论是通用的,那么他就一定不可能是特用的.
就好比盐在我们做饭的过程中是通用的.
那么我们可以直接吃盐吗.不行,一定要搭配某些菜肴来做.
方法论,一定要结合我们对于具体业务的理解,来结合使用
但是方法论,是具体指导我们做架构设计的.比如我们需要产出一个架构方案.就可以简单的按照我上面的内容来.
架构方案包含四个部分:隐喻,核心领域模型,平台服务&平台产品,业务场景.
但是往往不会直接这样做架构方案设计,因为这个是我们思考和设计过程中的结构,并不是我们落地成文档和架构宣讲的一个结构.
我直接给出我之前做的一个领域代际架构升级的方案目录结构,大家可以选择性的删减使用.
这个架构方案是非常完整的.包含了我们一个架构方案里面需要展示的内容和逻辑顺序.
写架构方案的时候直接按照这个目录来就行
后面我会详细解释每一部分
架构方案结构讲解
最好的结构,是思维结构
架构方案的产出顺序,往往不是架构方案的讲述顺序.
比如在工作中.我们可能划分好业务背景了之后.就设计业务架构部分了.
设计完毕业务架构,可能才能得出架构定位这个部分
这种通过业务枚举产出架构定位的方法,也叫做自底向上.
背景概述
我们对问题定义的高度,往往决定了我们的架构高度
背景描述其实很简单.就是说说你要干啥.
但是说清楚要干什么实在是一个很困难的事情.如果是在大厂里面干活.
往往给高层汇报,就只需要一个背景描述就够了.
在描述背景的时候,有很多的思维工具可以使用,我这里推荐5w2h方法.
当然也有很多其他的.比如业务项目使用的swot分析法.汇报的时候使用star方法等等.
重点是要描述清楚我们的现状与问题.
5w2h,我经常会分为
- what,why
这里是重点,描述为什么,一定要清晰的告诉别人为什么要做这个事情.做这个事情必须的原因.
在背景描述里面,what我会分成两个部分:现状与问题
现状就是我们当下的系统架构设计的情况.问题就是这种架构设计有什么问题.
- who when where
这里主要是描述我们需要的"资源部分".在架构方案里面
who往往是我们需要人的维度.比如需要哪些团队合作.我们做这个事情需要多少人
when主要解释我们当下做这个事情的判断以及紧迫程度.比如明年做这个行不行?
where主要解释我们在哪个业务领域做这个事情
- how,how much
具体方案部分.要包含我们的目标和我们需要的资源
业务发展趋势判断
代码好好的,就不要动
我往往说,架构,是面向未来的架构.
如果一个系统或者业务运行好好的,我们为什么一定要动它呢?一定是有什么问题.
在上面我们使用5w2h解释了很多背景的因素,也包含了问题.但是没有描述清楚未来.
而前瞻性如此的重要,所以我单独说说.
首先,我希望大家在做架构方案设计的时候,把问题定义成:
业务现状与未来的gap.
一定是未来要发生什么变化.我们的系统不支持了.所以我们要做一个措施.系统不支持了就是问题.
而架构前瞻性也是架构师的一个核心能力维度
核心架构定位
"隐喻"是面向未来的架构
解释与作用
我在架构设计里面最大的一个原则是:
能用就不要动
也就是说,我们在做架构方案的时候,一定是某种程度上目前的架构方案不能用了.
所以一定是背景发生了变化,这点在背景描述里面有所阐述.
那么我们的架构一定是面向未来的架构,因为我们是在解决未来的问题.
(除非是真0->1建设,但是也可以抽象成面向未来架构)
而采用隐喻得来的架构定位.就是一个非常好的未来架构和架构延续的方法.
因为,无论业务如何发展,某个领域的定位和概念往往是不会发生改变的.
我可以举个例子:
我19年进行结算领域系统代际架构升级,当时新建结算中心系统.架构定位是:
在收单交易业务中,围绕商家的资金关系协调.
详细的解释架构定位是架构职责.当时这样划分:
-
确定收单交易业务中的参与者(主体关系和账户关系)
-
确定这些参与者之间的资金往来关系(债务债权的清分清偿)
-
这些资金关系与结算领域定义的服务(结算,收费,分账)之前的关系协调
上面就是一个支付业务中结算领域的一个系统架构定位部分.可以看出来.这个架构定位还是非常抽象的.那么也可以看出来,在3-5年内,这个架构定位不会发生变化.
这种抽象,就是架构定位是面向未来架构的原因
这样说比较抽象.我们可以用一个更加简单的例子来说明:电商交易.
我们可以定义
电商交易是一个有价交换业务中的状态与流程驱动业务.
架构职责如下
-
定义有价模型,包括数量,单位,物品类型
-
定义主交易业务状态.并且定义交易状态流转,(下单,支付,确认,退款,关闭)
-
基于状态流转,定义业务流程,驱动业务流程.
可以看出来,这个架构定位足够的抽象,以至于可能未来发展出ai导购了.这个架构定位还是不会发生太大的变化.那么这个领域就十分的稳定.
这里先忽略到底这部分怎么用代码实现,比如是一个FSM还是ISM.这个是属于应用架构里面去描述的
也可以忽略每个状态是怎么定义的.比如是不是应该有物流状态?是不是有退款状态?什么是主状态,什么是子状态.这部分是属于业务架构里面描述的
内容与设计方法
就如我刚才的举例,一个架构定位主要包含两部分内容:
- 核心架构定位与概念
这里描述我们的系统和业务具体是做什么的,围绕哪些内容.主要定义我们做什么.
在后面的业务架构中,定义边界的时候就可以划分出来我们不做什么.
- 架构职责
需要详细的解释架构定位里面的概念,注意一般还是侧重我们要做什么.然后这些里面的概念具体是指什么,有哪些部分.重点在概念的解释上.
比如我们说"业务状态的流转".那么一定要解释什么是业务状态.比如一定是外部领域驱动,导致我们接下来流程发生变化的一个中间稳定状态.
注意,每个可能引起歧义的词语都要解释
比如这里要说明,什么是"流转".我们可以定义,一定是外部流程驱动的一个业务动作.
在领域驱动架构设计里面,领域用语是非常非常关键的.必须保证大家的理解一致.
我这里把这句话扩展到我们架构方案里面的所有内容,尽量不要做成名词架构师.要对每个名词有解释.
这里也可以看出来为什么大部分时候我很讨厌黑话
比如什么拉通,对齐,赋能.
这些话带来的歧义实在是太大了.往往没有特别的含义,就是浪费耳朵.但是反过来说,如果我们有明确的定义,那么使用"黑话"是可以极大的提高我们沟通效率的
比如"证账实一致性","最终一致性","高可用","资损防控","平台产品"
等等.这些我们定义清楚了之后.直接使用是可以节省我们很多的时间的.
业务架构
业务架构及其重要,甚至超过了技术架构
这里的"业务",不是广义层面的业务.在技术视角,业务是我们要完成的技术功能,处理的技术场景.
所以业务,就是直面我们的功能需求,描述要做的内容.
业务架构,就是解决我们的系统要做什么,提供什么功能,核心的业务职责是什么的问题.
业务架构还有一个非常核心的工作:领域建模.
但是这个实在是太重要了.以至于我需要单独写一个文章来介绍领域建模的方法和作用.
业务架构的作用
结构效率远大于运营效率
领域效率远大于技术效率
结构效率,分层效率
我举个非常简单的例子: 三层架构.
三层架构就是一个典型的按照功能类型划分系统设计的一个模式.dao层处理数据操作相关,service层处理业务逻辑,api层处理对外表达和接口适配.
如果我们把sql全写到service里面,或者把sql写到api层里面.可以想像.不管组件化设计的多么精美.我们的架构效率和研发效率都不会高.
把合适功能放到合适的地方.这个就是业务架构.
业务架构带来的结构效率.远超过我们使用任何的开发流程,开发框架,开发技术.
对于一个大公司的业务架构建设.就类似部门划分.
比如一个电商公司.里面可能有交易部门,汇金部门,支付部门,营销部门,供应链部门.等等.
业务架构就是解释,我们公司处理的所有电商业务,交易域应该负责哪些内容.
是不是觉得很简单?
那么,购物车,这个功能应该放到交易域,还是支付域?还是单独一个域?
抽象维度效率
比如我们在做业务场景划分的时候.可能会用三个维度来识别业务场景.
假如三个维度是: product,scene,type 这三个维度.
然后我们可能基于这三个维度使用了某个业务流程引擎,通过流程配置+原子功能的方式来定义我们的应用架构.
那么我们就能提高我们的架构效率吗?
其实不是.因为我们完全没定义product,scene,type是什么意思.这三个维度包含的内容可能完全不收敛.我们有100个业务场景.可能使用三维定义了之后.还是100种组合.
使用了流程引擎,最后还是100个流程,那能解决什么效率问题呢?
而定义我们应用架构中每个模块,组件,流程具体包含的内容.也是业务架构要解决的问题.
越是高层架构,越会放大业务架构的比例
怎么做
对于某个系统里面的业务架构部分.可以直接使用三层架构:
业务场景,平台产品,平台服务
写到这里，我发现一个问题，我主要围绕一个非常复杂的背景：平台架构，在描述我的方法。
也有可能有的同学没有处理过这样复杂的问题，或者没有这部分的经验。
首先，方法一定是相通的，能理解复杂的系统，没道理做不好trade off，没道理做不好简单系统的业务划分。
此外，这是不是说明，我们做更多的事情，也更好的帮助我们自己成长。所以这并不是PUA的一种。
- 业务场景
业务场景是描述整个业务身份，我们的系统要处理哪些”业务“。然后这些业务是按照什么维度进行划分的。业务场景定义最难的地方在于”垂直拆分“的问题。即：为什么业务A和业务B是两个业务。为什么不是一个业务。什么时候新增业务场景，如果一个业务A和业务B只有100行左右的代码不同，怎么办。等等这些问题。
- 平台产品
平台产品是描述”非业务相关，业务通用“的。某个特定的平台型功能聚合。提供标准的扩展和标准的解决方案。比如”担保交易“这是一个非常典型的平台产品，淘宝，天猫都是基于这个交易链路来做的。
平台产品最难解决的是”横向拆分“问题。比如某个功能是不是平台产品功能，还是只属于某几个业务的功能。
- 平台服务
平台服务能力是描述完全隔离的，独立提供功能的代码。注意一定是隔离的，并且独立的。这是平台服务的基本特性。比如一个资金转移服务，安全校验服务等等。
平台服务能力最难解决的也是垂直问题。就是什么是独立服务，什么是服务配套。
举例
这里可能讲的太干，太抽象了。我用一个最简单的例子来描述我们要做什么。
比如一个皮肤处理业务的架构方案设计（可以简单的理解成有一个图片模板，然后用户可以领取一个图片）
那么我们要做的核心事情就是：围绕图片的管理与发放，领取。
核心领域模型就是：图片模板，用户图片
核心服务就是：图片查询，图片发放，图片CRUD。
对外暴露的业务能力就是：发放，列表查询。（很简单的场景，就是按照业务功能就是业务场景即可）
架构图如下：
这里可以展开说很多内容，比如按照接口集成维度划分场景，然后我们围绕领域模型定义产品流程，这样可以跨接口场景复用。然后我们的流程是基于领域模型DDD的。
下游核心服务，就是我们的DB（这也是洋葱圈架构标准定义）。所以我们把DB的操作定义成原子服务。
这是一个非常简单场景。但是如果我们是这样思考和设计的。那么我相信这就是一个架构师的能力标准。
业务架构还包括一些核心内容，比如：核心领域模型，核心业务流程等内容。这些都是在具体实践中。我们进行一些关键设计。
应用架构
应用架构.解释起来很简单.就是我们怎么实现业务架构里面的内容.
换句话说就是我们怎么写代码.就是把文字转换成我们的代码实现.
在实践的过程中.往往包含两部分内容:应用分层&分模块,业务框架,系统流程设计
应用分层&分模块
最典型的三层架构:api,service,dao.就是一个应用分层的方法.在我们应用架构设计的过程中往往会直接按照我们业务架构里面设计的内容进行分层定义.
比如我们设计了平台产品,那么就应该有一层平台产品的分层定义
这里额外区分一下,业务架构可能描述了平台产品有:车票平台产品,机票平台产品
但是应用架构只有:平台产品
一个是业务维度的语义,一个是代码维度的抽象
上面就是我快速画的一个应用架构分层图
主要解释我们在业务架构设计里面,代码维度的抽象是怎么样的
业务框架
业务框架我后面会单独写一个文章.主要一些复杂的系统流程.可能我们需要很多的配置画的内容.
又或者需要很多的流程配置的功能.这些功能可能没有那么通用(通用的比如IOC,ORM框架)
这样大部分内容需要我们研发.这里是需要在应用架构里面说明的.
系统流程设计
注意,注意,系统流程不是业务流程.
系统流程,是系统在不同的系统交互(rpc,消息,异步化,定时调度)的流程.
是所有的业务通用的流程.我这里举个例子,比如交易
业务流程: 下单环节的流程是,用户状态校验,库存校验,生产用户订单,存储用户订单.
系统流程: 订单数据加载,用户模型初始化,服务产品映射,服务能力驱动,数据持久化.
在思考系统流程设计里面,也可以使用比较抽象的业务流程来划分.这也没什么事情.但是一定要注意通用.通用
技术架构
技术架构关注的是核心的技术细节问题.这些技术细节会很深的影响到我们的系统设计.
比如分布式ID生成,高可用部分,资损防控部分,DB模型设计部分.
我们常见的技术选型就是技术架构里面的内容.比如一些异地多活的方案.我们的db选型.一些框架的使用等等.
在技术架构里面还包括一些通用的技术方案设计.
比如我们系统的幂等是怎么处理的.系统里面的异步化是怎么处理的.这些内容.
在架构方案里面,希望大家摆脱的误区就是
不要把技术架构当成了架构本身
一些技术架构,结合我们的业务背景,往往有一个最优解(注意,不是完美解).
后面还会整理一些通用技术方案的文章分享给大家.
实施计划
就是架构里面怎么落地.包含:需要的资源,时间,里程碑,关键路径
这里列举出来就是让大家不要忽视就好了.
- 资源
在资源部分,我们往往关注需要投入多少人.并且可能还需要说明我们需要上下游和其他业务团队什么帮助.
此外,还可以列举出来我们评估的服务容量,db容量等内容
- 时间
给一个合理的项目实施时间,时间是和里程碑还有关键路径息息相关的
- 里程碑
里程碑的部分.也是我们对项目合理分期的一个部分.
往往架构项目是很庞大的.我们需要分期管理.这就需要我们合理的设定每期的部分.然后这每期就是我们的里程碑
- 关键路径
在关键路径选择上.如果是已有业务的架构升级项目,需要说明我们建设的业务场景和切流的过程
