前言

软件架构的概念最早出现于1968年的计算机文献中。上个世纪九十年代，软件架构的概念开始流行。软件架构概念的出现，是为了解决复杂的软件结构问题。早期的软件开发人员通过设计良好的数据结构和算法来应对这种复杂性，但随着软件的发展，人们不得不去寻找一些新的概念和思想来指导日益复杂的软件开发活动。

在过去的几十年中，软件架构的思想得到了极大的丰富。和软件架构相关的方法论、建模语言、建模工具、架构模式等，都已经非常成熟了。此外，关于软件架构的书籍也层出不穷。尽管如此，软件架构仿佛一直披着一层神秘的面纱。人们常常认为软件架构很复杂，既看不清它的全貌，也无法随心所欲地驾驭。出现这种现象是有一定道理的。相比于软件领域中其他的一些人工制品，例如，编程语言和算法，软件架构有其特殊性。

编程语言是一套编写程序的符号系统。所有的编程语言都有精确的语法规范，以及相应的语义。编程语言要解决的问题是，针对特定的计算任务，如何使人们更方便地让计算机完成计算指令。例如，针对统计工作，使用R语言是一个不错的选择。从精确度的角度来看，算法也是如此。算法是一种更古老的概念，甚至可以追溯到公元9世纪的数学文献。在软件领域，算法是实现从一些给定输入，通过一段程序逻辑，产生精确输出的计算方法。无论编程语言还是算法，所要解决的问题都非常单纯。

而在软件架构师眼中，世界却是另一番景象。例如，尽管R语言是完成统计工作的最佳选择之一，但你还必须考虑商务上的约束，项目的资源，现有软件资产的改造，替代方案的可行性，项目实施后的维护，采用一门新语言的学习曲线，用R语言实现的功能与软件系统其他组件的交互，软件系统的长期规划，你得权衡R语言给你带来的回报与使用它所带来的成本。对于算法，你或许还要考虑项目的硬件资源。在软件架构领域中，决策是软件架构师最重要的工作之一。

软件架构工作是一项系统工程，这不仅是由于设计软件架构涉及繁杂的输入项，还和软件架构师是否有足够的经验支撑来应对有关。很多软件架构设计的知识无法在课堂上完成，因为你无法枚举实际项目中的所有关键因素，并总是能做出适合特定场景的最佳方案。软件架构工作的这种不确定性，或许是让人们感到难以驾驭它的原因之一。

要尝试解决软件架构工作中的复杂性，对于领域的认识至关重要。人们的学习和认知能力是有限的，我们每一个人几乎不可能掌握软件领域的所有知识。例如，一个计算机安全领域的专家，不一定会是计算机游戏设计的高手。因此，领域的划分非常重要。专注于领域会使领域内的工作变得更加专业和有深度。

软件架构是软件行业中的一个领域。这个领域和其他领域有一些交集。当我们讨论软件架构的时候，不应该无限延伸到其他领域，例如，执着于算法的内部结构，或者极力探究规则引擎的内部机制。事实上，专注地在软件架构领域内进行工作有助于简化软件架构工作的复杂性。本书将基于这个思想致力于软件架构领域的深入探讨。

软件架构的重要性是显而易见的，与此同时，一个有趣的事实是，即便没有刻意设计或合理设计，软件架构也总是存在于软件系统中。虽然这种近乎自然形成的架构常常摇摇欲坠，后期维护代价高昂，但基于这种架构上的软件系统并非完全无法工作。这种现象给人们在理解软件架构重要性方面带来了极大的困扰。

正如前文提到的，软件架构概念的出现是为了解决软件结构的复杂性问题，归根到底，是为了降低软件开发的成本。当一个软件系统可以工作，并在市场上赢得客户时，人们很难下决心深入地审视架构的优劣并做出改变。

站在项目投资者的立场上看，或许可以部分理解这种现象。首先，软件架构对软件开发的影响是一个长期的过程，其次，这种影响难以量化，最后，人不能两次踏进同一条河流，没有参照，无所谓优劣。这些不确定性使人们不愿意贸然投入。面对这样的现实，很多软件架构师会有一种失落感。

为了化解这种困局，使软件架构改进成为常态，本书将尝试深入探讨软件架构对软件开发带来的具体影响。这种尝试可以帮助我们从一个全新的视角观察软件架构。对于项目投资者来说，也可以根据这种观察，做出最佳的商业决策。

本书由四个部分组成：

什么是软件架构。当我们进入一个领域时，首先必须了解这个领域内的术语和常识。这些术语和常识是在这个领域内进行工作的基础。它就像人们在日常生活中所使用的自然语言一样，表达意图，沟通想法，达成目标。软件架构领域也是如此。除了术语和常识，我们还需要了解该领域的工作包含了那些内容，有什么特点，以及基本的工作方法。此外，我们还会适度讨论一些与软件架构密切相关的概念，例如，什么是软件框架等。

软件架构的演化。软件架构从来没有停下它演化的步伐，客户端服务器架构（Client Server Architecture），多层架构（Multitier Architecture），面向服务架构（Service Oriented Architecture，SOA），微服务架构（Microservice Architecture），无服务架构（Serverless Architecture），每一种演化都是在解决软件领域特定问题的过程中产生，并以架构模式的形式保存了下来。而那些特定问题的出现，则是由于软件技术的发展和业务的需要而引起的。事实上，每一种架构模式都有其生存的土壤。我们将在这一部分的章节中对各种架构模式展开讨论，特别是微服务架构和无服务架构，分析它们产生的背景，适用的场景，解决的问题，以及面临的挑战。

软件架构的设计。设计软件架构是一项系统工程。当面对一个项目，该如何开始架构设计的第一步？如何对纷繁复杂的信息进行抽丝剥茧？如何井井有条缓急有序地进行设计和开发？如何合理地做出各种决策？如果你的心中对这些问题没有答案，应该仔细地阅读这部分的内容。我们将在这部分的章节中，全面深入地讨论架构设计工程，并引入一种新的设计方法。这种设计既非自上而下，也非自下而上，而是由浅入深，类似于雕刻艺术。

软件平台架构论。近年来，互联网应用发展迅猛，很多传统行业，例如金融保险行业的信息系统都开始逐渐推向互联网。众所周知，电子商务平台已经在互联网上取得了巨大的成功，而金融平台仍在努力尝试。从软件架构的角度看，金融平台存在一个新的挑战，即金融产品比普通电子商务产品要复杂得多，无论用户界面、规则、流程，还是计算，都难以找到普遍适用的规律。使用传统设计将导致平台膨胀的后果。软件平台是互联网时代出现的新事物，我们将在这一部分的章节中讨论平台架构设计中的新思路和新方法。

为什么写这本书

我已经经历了一段漫长的职业生涯，在过去的二十五年中，参与了很多软件项目，从基于单片机的汇编程序，到网络办公自动化软件，从图像处理的链接库，到大型的金融信息系统。时至今日，我仍然工作在软件开发的第一线。这么多年来，软件架构这个领域在我眼中从没有像今天这样变得如此清晰，这使我产生了对自己多年软件架构经验进行归纳总结的想法。

我读过软件架构领域的一些经典书籍，2013年，还有幸参与了JUST ENOUGH SOFTWARE ARCHITECTURE中译本的翻译工作。这些阅读和翻译活动，帮助我比较全面地了解了软件架构领域的知识。最近这几年，我又做了一些有趣的架构设计工作。更多的工程实践，总是会产生更多的经验和想法——前面的内容中提到了一些，而那些只是众多收获中的一部分。这也是我认为值得再写一本书的原因。