1.4　会有第五代架构吗

架构发展历程，不同专家的观点并不相同，我比较认可的是相对粗放的四代架构论。每一代架构虽然和所处年代的计算资源及能力、编程语言及开发框架有关，但是定义各代架构，其核心视角在于理念和风格，或者说是实现复杂软件的方法论调。

1.4.1　前四代架构的精髓

第一代是单体（Monoliths）架构，也称作巨石型应用系统，水平分层；容易上手、部署和测试；缺点是耦合性高、技术选型单一、开发效率低下，主要生存年代是2010年之前。

第二代是面向服务架构（SOA），垂直分层；系统之间通过Service API和中心化管理的企业服务总线（ESB）进行交互，已有服务化整合和治理理念，但每个服务从本质上还是单体服务，对ESB严重依赖，主要活跃期约在2010—2020年。

第三代是微服务（MicroService）架构，水平分层与垂直分层结合；将单应用程序作为一套小型服务，分布式技术，轻量级通信机制；有服务注册、熔断、容错、自检测、自动发布等能力；可快速迭代及持续交付。微服务架构与分布式开发框架相辅相成，体现了小团队自治和快速迭代产品发展，至今仍然被广泛认知和使用，处于成熟期、活跃期。

微服务实际上是面向服务架构的一个更好的替代，即去中心化的分布式服务架构（DSA），将服务寻址和服务调用完全分开，不再依赖于ESB。

微服务架构下，产生了一些新的词汇，例如“微服务节点”，对原来传统的系统概念造成了一定的冲击。一个微服务，究其概念来说，颗粒度比应用系统小，与原来我们所谓的“子系统”较为类似，但是作为一个独立部署、独立运行的独立进程，一个微服务本身就是一个系统。学科上定位，系统即是一个操作系统的进程，从这个角度看，一个微服务应用与一个应用系统是一个概念，理解这点也可以帮助读者更加畅快地阅读本书。至于“节点”二字，一般用于部署这类语境的上下文，是系统进程在部署视角的落地形态，例如，8个节点的意思是这个应用系统上线时水平部署了8个，目的一是负载均衡，二是冗余机制。

第四代是云原生（Cloud Native）架构，基于微服务思想，以容器为载体，提供一种产品研发运营的全新模式。在业务角度提倡基于云的中台战略(8)，在开发和运维方面包括：基于云的能力，资源动态管理；Docker容器技术；Service Mesh服务网格；Serverless无服务器架构；API服务化；轻量服务无状态化；Restful风格化；自助管理资源；持续集成（CI）持续交付（CD）；DevOps开发运维一体化、自动化。从云平台推广至今，仍然被广泛认知和使用，仍处于发展期。

1.4.2　深谙架构职业特性

到底什么是软件架构，核心是模式与工具，还是理念和思想？模式是风格吗？微服务到底是架构模式，还是架构风格？架构模式与设计模式，在实际工作任务中，它们真地有界限吗？防腐层到底算是哪个级别的模式？消息推拉呢？反射呢？系统重构工作所用的绞杀者模式，模式二字，重在说明设计技术，还是思维方法？事件驱动架构（EDA）算是架构模式吗？API网关也算是来源于某个架构模式吧。那么前后端分离算是一种架构的结果体现吗？AOP和IOC，也属于架构模式吧？连接器，算是一个模式，还是一类模式？说架构，难免提起著名的领域驱动设计（Domain Driven Design，本书中统一使用简称DDD），究其根本内容而言，DDD是一种架构模式吗？某些书中讲述的几大架构模式，其中还有开源贡献者模式，这算吗？

这些专业词汇，就范畴、属性、归类而言，有一致的官方定义吗？并没有。软件架构领域书籍众多，但你仔细寻找上述话题的答案，会发现对于这些内容，不同专家在维度和量纲上的回答是五花八门的，很多术语本身具有模糊性、主观性特征。不同资料对架构和设计模式的分类，没有严格的可循之迹，看的资料越多，得到的答案越多，或者说是越得不到答案。

如果我也给出一个观点，那就是“欲言架构，必言模式”，在内容表述上不论是偏技术形态，还是偏思维理念，本质是能够用于特定问题的可复用解决方案，这就是模式。模式无处不在，好的设计方法实际就是模式，没有实际边界，也没有锚定的层级关系，按照经验而言，一般有颗粒度大小之分，适合于不同层面的设计工作。如果非要说现在到底有多少种模式，那么所有已知的这些都算是模式，做一个并集。

学习软件架构知识，最好能自然而然，广泛地吸收，灵活地理解，不要为大杂烩所扰，可以把这些当作多多益善即可，重点是在实际设计工作中，合理分析并有效使用架构能力，用结果说话。

究其根本，软件架构的基因，具有天生的“模糊性”，现在大学有软件架构专业吗？我上学时没有。相比于建筑行业已经存在了几千年，软件行业还很稚嫩。软件架构设计更像是一门手艺，不需要持证上岗，主要门槛是个人实力。难以将软件架构进行绝对化、学科式的考量，更不乏自学成才者，在此方面，难以将其与律师、医生、会计师等行业相提并论。

另外，需要注意到架构设计工作具有的“双向性”特点，干得不好，不是零分，而是负分。相比于正向学习，对“反模式(9)”的领悟会令你脑洞大开，例如，掌握“蘑菇管理(10)”“委员会设计(11)”……可以避免许多容易忽略的问题。

1.4.3　预测五代无意义

四代架构的发展历程，体现的是核心理念、风格和模式在几十年间的实践，并非是银弹技术。和前三代具象的描述方式不同，第四代架构的定义已经模糊化，是广义的能力包，更多的是对应云技术的广泛应用。而云生态，就量纲而言，与AI、大数据、区块链，往往被水平排列，已经没有影响力上谁大于谁之分。

很多人想预测下一代的架构理念，但是，当今软件技术是多极化发展趋势，分工的细化注定没有什么“天下通识”，如前四代架构代次的定义方式，未来无法覆盖全部主流。算法开发人员的职业规划，估计没能从云原生架构中获益，Hadoop大数据开发者，对微服务架构也不甚关心，这些是可想而知的。未来可能没有任何一个词能独自站出来，承担起对第五代架构的缩写定义，取而代之的是各个领域的分支发展。

不论有无第五代架构，其实际意义已然消散。而且，不应认为后代比前代好，好坏之说过于绝对，只能说后代是面向行业发展的新产物，软件本身不是目的，只有是否适合目标之分，如果要做一个很简单的小Demo，仍然可以用单体理念，找一个最原始的技术栈来实现。各行业各领域中，老旧遗留系统的更新换代，可能没有热衷于微服务人士想象得那么快，有很多大型机构的重要业务系统还是JSP+Oracle这样的技术架构，我还见过某些老牌传统企业中，很多项目是由数据库存储过程来实现业务逻辑，而且依然使用FTP方式进行跨企业间的业务数据传递。架构升级与系统平台重构作为企业数字化转型众多任务之一，仍旧任重而道远。

不断涌现的架构代次之说，是为表达发展趋势下的主流潮流，以及新理念、新技术落地的模式方法，时间轴只是各代架构的一个附属体现而已，并非判断的核心因素，DDD已经有超过20年的历史，仍旧处于高度活跃状态。

立此话题，首要目的是引起读者的思考，虽无答案，但是这种思考对布道成长是有意义的。至于为何我主观地给出有些消极的观点，可能还在于：勿让架构“统治”了我们，架构优劣与否，并非是全部问题的答案，不应认为架构是“银弹”，而将过多精力置于考量架构模式的话题上。大量的设计方法更广泛存在于程序语言中，编写整洁的代码和使用自动化测试，对于系统的成败更为重要，这仍是现代化软件研发工作的核心。