什么是架构 - 7年大厂架构经验

“什么是架构”，这个问题伴随着我近10年的技术道路。可以说我不断的加深这个问题的理解，并且每个阶段都有不同的理解，尝试对这个问题的阶段性描述来总结我这10年的技术发展。

我会深入讲解每一部分我经历的过程，递进思考的过程，我的成长过程。以及对每种层次的理解。

“架构"这个词其实从建筑领域发展而来，软件技术仍然使用了架构这个词。所以我认为架构是伴随做技术路线一辈子的。

而不同的架构理解，其实就也代表了技术认知的不同。

总结

我目前对架构的理解，分为五个层次，也对应了我技术发展的五个阶段：

1 架构是框架

2 架构是分层与抽象

3 架构是定义与权衡

4 架构是共识与方向

5 架构就是解决问题的一种手段

架构是框架

我刚学软件的时候，当时还是SSH和SSM的天下（好像现在也是）。

因为是自学java并且是通过培训班来学习的，所以接触到的名次都是ssh架构和ssm架构。我掌握了之后也一度自信的认为。自己已经掌握了几套架构了。

我本科是物理，我一度认为理学院比工学院更加适合坐软件设计。毕竟物理里面的”抽象“都是非人的。

我很多次非常”自信“，而我成长过程就是发现当初自己的自信多么sb的一个过程

这个时候对架构的理解，就是一套套”框架“,比如shrio权限管理，spring，springMvc这样的框架。解决某个特定的问题，达到降低代码量，提高研发效率的事情。

当时所有的重点，其实都是围绕各种”技术“来学习的。比如学习缓存类的api：redis，学习全文查找：ES，权限管理，workflow（activity） 等等。

掌握了这些技术的时候，一度觉得自己无敌了。好像很多的问题我都有解决办法。

但是到了具体项目的时候，很快就发现了自己的SB。不过我也比较庆幸，没有沉迷在不同的技术中间件里面不能自拔。

总结

特征上：技术api学习，能力上：掌握不同的框架，发展上：处理复杂业务项目

架构就是框架，描述的是我理解架构的功能部分，是写一套可以帮助别人解决通用问题的代码。这部分代码没有业务语义，可以让不同的人复用。

比如spring，就是一个IOC框架。我们用的很多。就是我理解的架构。

这段成长的过程会很快，因为当我们处理具体的业务项目的时候，就会发现，代码量可能非常的多。我们要解决的问题不仅仅是通用的功能实现（比如查询db），而且要解决业务功能的实现（比如一个登录服务）。

并且业务功能的代码实在是太多了。我们需要对业务代码进行划分。这就到了三层架构部分。

架构就是分层与抽象

很简单。当时BS项目很火。所以学习过程中设计一个电商库存管理系统。遇到了典型的三层架构：

Controller,Service,Dao

这是最早接触到的”架构方面“。我记得很清楚，当时培训老师说，这是一种架构设计。

这是最初对代码进行划分的理解，对于页面处理放到Controller里面，对于业务逻辑的处理放到Service里面，对于数据的处理放到Dao里面。

我个人感觉，这里是架构的第一步，从这里需要意识到：

架构不仅仅是对代码功能的划分，也是需要对非功能，主要是代码负责的哪部分逻辑，进行划分和设计。而这种设计，不仅仅是思考如何实现代码，是需要分割代码。

这个就是我当时遇到三层架构之后的理解和认知。

个人感觉这点非常重要，是从”如何用代码把这个功能实现“到”如何设计代码“ 这个的转变。我们不仅仅需要关注代码能否run，还需要关注代码是否合适。

而我对三层架构的理解就是，这是一种代码划分的设计。用于满足典型BS架构下的不同代码职责范围。

比如最原始的

Controller：解决外部请求和响应模型的转换逻辑部分。三层架构的扩展，就是对”view“这个概念理解的扩展。比如json返回值也是视图的一种。

Service：解决核心业务功能的逻辑部分。所有业务功能，都可以包含在Service中。包含我们业务流程的识别，分支，核心产品功能的代码复用这些问题。

DAO：处理和DB交互的部分。扩展思考，一种是把所有的数据处理内容放到DAO层，比如缓存。另外延伸思考，db可以当成一个外围服务，这样就把所有下游业务系统交互部分都作为”DAO“层了。

这里Service是我们自己系统内部的核心逻辑，DAO负责和”外围“系统交互。

这种角度去思考三层架构，就特别像简化的”洋葱圈“架构。

其实三层架构可以分别进行扩展

比如controller。深入有mvc模式。核心技术难点有tr接口设计，幂等处理，业务包装，业务身份定义等。

比如service。深入有DDD设计。核心难点有服务能力划分设计，平台流程，平台产品定义等。

比如dao。涉及到很多下游交互。类似洋葱圈。

总结

特征上：分层设计，能力上：抽象和总结，发展上：接手平台架构

三层架构，就是按照主要代码的功能职责不同，划分成Controller，Service，DAO的架构。

更深一步理解，其实是一种对软件代码按照横向功能职责划分的架构思路。

这里需要强调一下横向，并且我希望大家把三层架构，深化成为一种“分层架构“的设计思路

重点就是：横向功能职责划分

我经历了具体项目的操练，就会发现代码是需要划分的。而这个过程需要持续且不断的自我抽象和自我总结。在这个阶段我一直是一个创业公司的研发。

并且运气非常好的遇到了互联网蓬勃发展的时候，那个时候非常多的0->1的业务建设工作。我可以完整的设计一个完整app或者网站的服务端设计。在这个过程中不断的抽象和总结。然后觉得架构就是分层。

我在创业公司一直待了三年，当时觉得自己很NB（继续打脸）。觉得自己已经知道了什么是架构。自己也从0开始做了很多的架构。然后直到我加入了支付宝，才发现自己多么SB。

因为这个遇到了一个非常棘手的困难：一个系统支撑上千个业务。

一个平台系统，需要支持上千个业务，这个时候不是分几层的问题了。需要思考怎么”纵向“划分。而这，也是加深对架构的理解，并且能力随之发展的一个契机。

事实上可能很多人都停留在这个阶段，其实不同的分层定义是所有架构都要解决的问题。所以不能说分层架构就不是架构了。而是我们在面临不同的问题的时候，需要能够用不同的方法来解决。

从这里开始，每个架构理解，都是多了一种手段。是补充关系，不是替代关系了。

另外，即使是支付宝内部，仍然有很多P7同学，认为架构”只是分层“。所以如果看到一个架构方案，就是分了7层出来，不要意外（笑）

架构是定义与权衡

涉及到多个业务的划分就遇到了业务”垂直“的问题

加入支付宝了之后，我负责商家结算业务的研发。这期间处理了很多的业务项目。

我一直非常非常庆幸，当时的结算业务足够复杂，系统也足够”不同“。

比如结算对于业务的定义，是一个个的xml来定义的。然后计算出不同的Item。有一个叫资金插件和执行引擎的部分，负责执行Item。就完成了结算业务。

这种架构设计非常有DDD的影子。并且也足够”平台化“。恰恰是通过这期间的学习乃至我后面做的结算V3架构升级，都是基于我对这种架构形式的理解，抽象，然后落地实施的。我叫SDD（仅仅是为了装逼，区别于DDD）。

这个时候，面临的问题也很直接：让你搞一个负责上千个业务场景的系统的架构升级。你光用分层手段，你分个500层可能才真的能解决问题。这个时候不仅仅需要横向看问题，也要纵向看问题。然后横竖结合。

比如上图，我们要处理的业务场景太多了，而架构设计就是能抽象定义出来，场景无关的核心平台产品能力，用于解决场景通用能力定义。然后进行分层驱动。

这里深入解释一下，看起来好像这个阶段的架构方法，就是在分层架构上，多了一个场景识别模块。场景识别模块是分开的。和分层架构组合在一起，就是平台架构了。

如果读者这么理解，那我一定说你对。因为我理解的架构层次或者说阶段，就是在上一层的基础上进行发展和演进的。一定不是脱离的。

不过还是有很多的不同，因为”平台产品“这一层，是高度抽象的，有机会我可以展开说明一下，这里可以举个例子来说明这种抽象：

对于支付宝结算域来说，可能提供给抖音电商的平台产品，和高速公路场景用的平台产品是一个。

这个时候的架构工作是非常复杂，也有很多难点。但是按照这种模式，基本上能解决一个类似平台型架构面临的问题。而这个时候架构要做的工作就是

1. 定义什么是平台产品

2. 定义什么是业务场景

3. 权衡架构要解决的问题

在这个阶段，我坚定了一个原则：架构是无法解决所有的业务问题的。而定义怎么解决，权衡要解决多少。就是这个阶段架构师要做的工作。

我们需要定义出来，什么才叫”平台产品“，注意这个一定是没有业务场景语义的，一定是围绕我们一个系统核心要处理的内容来做的。

我们也需要权衡，什么是独立的业务，比如坐公交车和坐地铁，是一个业务还是两个业务？可能这就看这些业务的差异，是否足够让我们划分不同的概念处理。

我在这个时候的架构工作，有特别多的同学，拿着某个业务的特殊if来挑战平台产品。这其实有点舍本逐末，我们需要看到整个业务的全貌，用一些”技术手段“处理细枝末节的部分。

同时也要基于我们对某个业务领域的深入理解。坚定不移的推动自己的架构方案。

在这个阶段，大家也发现我在描述的时候，增加了很多”软“的方面的问题。这个时候就不是我们背一个Spring的事务隔离级别这种有标准答案了。

而是基于我们自己的思维和方法，去推动我们的方案落地。而这时，需要我们和其他开发同学进行协作，需要获得大家的认可。这也是这个架构阶段的特征。我们需要同一个业务领域内部的人，广泛的认可我们的想法。一起落地。

总结

特征：横纵定义与取舍，能力上：平台架构方法论，发展上：涉及跨域架构

这一阶段的架构，就是当我们面临一个系统承载非常非常多的业务场景的时候，需要进行平台产品定义，权衡不同业务场景的一种架构模式。

关于什么是平台架构，怎么进行平台架构设计，一些常见的业务平台架构系统怎么做的。我后面有机会可以展开讲讲。

当时我做完了支付宝结算系统的V3架构升级，又又又觉得自己天下无敌了。这么复杂的一个系统领域架构我都解决了。还有什么是我解决不了的呢？

然后我就接受了结算领域重定义项目，一度怀疑人生，痛苦不堪（我的纹身也是这个去做的）

而从这一阶段发展下去，就是涉及到架构域的边界划分。你需要和别的业务团队同学进行协作，定义整体的架构方案。

架构是共识与方向

在一个大公司工作，如果业务发展的非常快。大家都会遇到一个问题：抢地盘。技术团队也是划分了不同的业务线的，不同的业务线的职责不同。而抢地盘就是，把别人负责的内容”抢过来“，这样自己的”盘子“也就更大了。就会有很多的收益。

我这么说好像特别赤裸，但是事实的表现就是这样的。而如何”虎口夺食“，就是我们所谓领域架构师要做的工作了。

当然了。我们对外表述一定是：站在全域或者公司的视角下，为了业务更好的发展，重新进行架构设计。

当时，结算其实特别"弱小”，分给我们的业务就是一些别人不要的业务功能。但是随着支付宝外部商户的发展，除淘宝意外的电商发展的越来越好，比如抖音电商。这些商户对于资金的处理需求也是特别多的。这个时候往往一个项目需要上下游十多个系统一起修改。其实还是不合适的。

这个时候，我们的工作就是，设计一个新系统，重新定义我们自己业务领域的架构职责，核心定位，领域模型，平台产品，和上下游的其他业务领域，划分职责边界。

而通过这一阶段的工作，我明白了，架构其实是和其他人一起达成的共识，是架构师基于业务理解，为业务未来发展指明的一个方向。

这个阶段，架构主要是

1. 共识：跨部门甚至跨业务公司进行协作，取得大家对你负责业务领域的共识。取得团队内的共识，设定业务领域核心架构定位，平台产品，业务能力

架构定位（隐喻） -> 平台产品 -> 平台服务能力

这个小思路和流程，也是进行一个大的领域架构的思考过程，我非常推荐这种方法。后面我会写一个新文章详细解释。

1. 方向：架构是面向未来的架构，指引着我们对未来业务发展的判断。而这点是通过我们设定的核心领域模型和我们业务“前瞻性”判断得来的。

其实我有个判断：如何是一个好的架构？有个特点就是3-5年不会再进行“架构升级”了。这就要求我们对架构的发展判断要非常正确，并且能正确的抽象出来业务职责。

总结

特征：架构定位与协同，能力上：跨域协作和业务趋势判断，发展上：为业务负责

这个阶段的架构，已经是比较高级别的架构了。因为设计到一个领域的设计，一个领域可能保护10个左右的系统，需要你同时进行外围交互和定义。这个时候需要基于业务高度抽象，定义我们的核心架构概念。推动架构落地。

其实我感觉，我也只有这个一半的阶段。我负责了支付宝一个二级域的架构升级。同时也有失败的经历。对于如果负责一个公司的全站基础架构工作，其实是没有经验的。比如全公司统一应用服务技术栈（全用springboot）这些问题。

这个阶段度过到下个阶段我也不能保证一定是唯一的方向，因为阿里内部新增了P8->P9职级的架构线路。而度过这个阶段，我的发展路径是：从一个架构师，变成为业务负责

架构就是解决问题的一种手段

大概在20年之后，我从支付宝支付链路的架构师，转到资金领域，做个人资金的技术负责人。

我的OKR也有了非常大的变化，之前50%是架构部分，架构的工作。目前50%在业务结果达成上，比如取得**的DAU，业务增长***%这样的形式。

作为技术是使用技术手段，去解决业务增长的问题。

这个时候有很多维度

1. 定义问题。之前可能是定义架构，定义架构问题。我们可能需要定义业务问题。

很多的时候，我们可能写了10万行代码，然后业务直接下线了。这其实非常挫败。我们面临的问题可能根本不是代码如何实现的问题。可能是业务发展方向的问题。

我经常举一个例子：我们业务的一个场景也出过资损问题，就是给商户的钱多了。损失很大。我们怎么判断这个问题，是不是某行代码写错了？我们可能需要多问几个，比如为什么是A场景出问题，B场景没出问题。这段代码为什么不是相通的。为什么会A场景一个金额代码，B场景一个金额代码。可能不是一个代码问题，是一个核心设计的问题。

1. 解决问题。

这里我经常举的一个例子是12306。12306一开始崩溃问题非常多，后面产品交互链路直接变了，新增了一个排队等待中间页面（其实背后就是一个等待队列）。然后整体“高可用”就上来了。这其实就是典型的产品交互方向去解决问题。

另外，比如很多的框架有“无锁设计”，比起硬凹某部分代码，可能从设计层面上就可以解决问题。比如我在面试的时候被问到了。订单库存用的缓存，如何高效解决一致性问题。我给的答案是：不用缓存。这看起来非常无厘头。其实缓存和DB一致性有很多方案，关键在于涉及到购买行为，金额行为，真的要用缓存吗？我们要解决的是高并发问题，还是“争抢”问题。是不是应该用架构设计去解决硬凹技术的问题？

1. 为团队负责，为业务负责

这个时候往往感觉力不从心，因为不可能一个人负责所有的架构工作。我很喜欢一句话是无为而治。如果我的团队同学都能成长成为“我”，那团队的战斗力可能更加强大（也说明我可以被裁了）

另外，我一直强调的一点，就是“目标感”。就是真正回到本质。我们写一行代码是为什么，我们设计的架构是解决了什么问题。不断的围绕这个问题。才能最终的发挥我们技术的价值。

架构方法论上面，我也形成了从隐喻->领域建模->业务架构->应用架构的一套模式。在方法论层面目前也没有取得更深层次的理解，也有可能，一套高度抽象的方法，已经能解决所有的问题，而我们需要丰富的就是，越来越大的问题，越来越多的手段。

总结

没想好，随便说点吧。

对于架构的认识，主要是总结和回顾我自己的工作经历。可能我2年后推翻了我自己的所有想法，觉得自己很sb。

我就是在不断的认为自己是sb的过程中成长的。相反我觉得更快的觉得自己之前有多无知更加有益。

我从之前学了ex，Lucene这些框架之后，感觉天下无敌自己啥问题都能解决了。到现在大聊特聊方法论。是一种转变，也是不断的发现自己不足和视野短浅的过程

不过我感觉自己还是不断发展的。至少工资和认知体现了这点。所以我以技术人都面临的一个架构问题作为切入。描述我自己成长的道路，也希望能让部分人发现自己成长的道路。