文章目录
关键要点
- 作为仓促采用微服务的一部分，架构稳定性差距和反模式可能会出现。
- 了解历史范式转变的警告和陷阱应该使我们能够从以前的错误中吸取教训，并使我们的组织在最新的技术浪潮中蓬勃发展。
- 了解不同架构风格（如单体应用程序、微服务和无服务器功能）的优缺点非常重要。
- 架构演进的重复循环：在新范式中不了解最佳实践的初始阶段，这加速了技术债务。随着行业开发新模式来解决差距，团队采用新的标准和模式。
- 将架构模式视为有利于快速技术发展同时保护业务应用程序免受波动影响的策略。
近年来，微服务、云计算和容器化等技术趋势发展迅速，以至于这些技术中的大多数现在已成为顶级 IT 工程师、架构师和领导者日常职责的一部分。
我们生活在一个支持云的世界。但是，支持云并不意味着云原生。事实上，在没有云原生的情况下启用云不仅是可能的，而且是危险的。
在我们研究这些趋势并讨论公司应该实施哪些架构和组织变革以充分利用云支持的世界之前，重要的是要了解我们曾经去过哪里、现在在哪里以及我们要去哪里。
了解历史性范式转变的警告和陷阱应该能让我们从以前的错误中吸取教训，并使我们的组织能够在这项技术的最新浪潮中蓬勃发展。
反模式
在我们简要介绍这一演变过程时，我们将探索反模式的概念，它是对反复出现的问题的常见反应，这些问题通常是无效的，并且有可能适得其反。
本系列文章将描述提到的反模式。
架构演进
在过去 50 年左右的时间里，软件架构和应用程序托管模型经历了从大型机到微服务和无服务器的重大转变。
图 1 显示了架构模型的这种演变以及它们所推动的范式。
图 1：从大型机到云和微服务的架构演变
集中
早在 70 年代和 80 年代，大型机就是计算方式。大型机基于集中式数据存储和计算模型，基本客户端用于数据输入和原始屏幕上的数据显示。
最初的大型计算机使用打孔卡，大部分计算发生在批处理过程中。没有在线处理，延迟为 100%，因为没有实时处理。
随着在线处理和用户界面终端的引入，大型机范式发生了一些演变。然而，包含在单个组织的四堵墙内的大型中央处理单元的总体范式仍然具有“一刀切”的方法，并且只能部分提供大多数业务应用程序所需的功能。
中心化 -> 去中心化
客户端/服务器架构将大部分逻辑放在服务器端，将一些处理放在客户端。客户端/服务器是分布式计算中首次尝试取代大型机作为业务应用程序的主要托管模型。
在这种架构的最初几年，开发社区仍在使用与大型机开发相同的过程、单层原则为客户端/服务器编写软件，这导致了意大利面条代码和blob等反模式。软件的这种有机增长也导致了其他反模式，比如Big ball of mud。业界必须想办法阻止团队遵循这些不良做法，因此必须研究编写健全的客户端/服务器代码所必需的内容。
这项研究工作制定了几种反模式和最佳实践设计和编码模式。它引入了一项称为面向对象编程 (OOP)的重大改进，它具有继承、多态性和封装特性，以及处理分散数据的范式（相对于具有一个事实版本的大型机）以及行业如何处理的指南可以应对新的挑战。
客户端/服务器模型基于由表示 (UI)、业务逻辑和数据层组成的三层架构。但是大多数应用程序是使用两层模型编写的，其中包含一个封装所有表示、业务和数据访问逻辑的厚客户端，直接访问数据库。尽管业界已经开始讨论将表示与业务与数据访问分开的必要性，但直到基于 Internet 的应用程序出现之前，这种做法才真正变得至关重要。
总的来说，这种模型是对大型机限制的改进，但该行业很快遇到了它的限制，例如需要在每个用户的计算机上安装客户端应用程序，并且无法在细粒度级别作为业务功能进行扩展。
去中心化 -> 连接/共享 (www)
在 90 年代中期，互联网革命发生了，一个全新的范式随之而来。Web 浏览器成为客户端软件，而 Web 和应用程序服务器托管所有处理和逻辑。万维网 (www) 范式促进了真正的三层架构，其中表示 (UI) 代码托管在 Web 服务器上，业务逻辑 (API) 托管在应用服务器上，数据存储在数据库服务器上。
开发社区开始从胖（桌面）客户端迁移到瘦（Web）客户端，主要受面向服务架构 (SOA)等理念的推动，这些理念强化了对三层架构的需求，并受到客户端技术改进的推动以及网络浏览器的快速发展。这一举措加快了上市时间，并且无需安装客户端软件。但是开发人员仍在将软件创建为紧密耦合的设计，从而导致混乱和其他反模式。
作为回应，业界提出了演变的三层架构和实践，例如领域驱动设计 (DDD)、企业集成模式 (EIP)、SOA 和松散耦合技术。
虚拟机托管 -> 云托管
21 世纪的第一个十年，当托管以云计算的形式作为服务提供时，应用托管发生了重大转变。与传统基础架构相比，需要分布式计算、网络、存储、计算等功能的应用程序用例变得更容易以合理的成本提供云托管。此外，消费者正在利用资源的弹性来根据需求扩大和缩小规模。他们只需要为他们使用的存储和计算资源付费。
IaaS 和 PaaS 中引入的弹性功能允许服务的单个实例根据需要进行扩展，为了可扩展性而消除实例的重复。但是，这些功能无法弥补出于其他目的而重复实例，例如拥有多个版本，或作为单体部署的副产品。
基于云的托管的吸引力在于，开发和运营团队不再需要担心服务器基础设施。它提供了三种不同的托管选项：
- 基础设施即服务(IaaS)：开发人员选择服务器规范来托管他们的应用程序，而云提供硬件、操作系统和网络。这是所有三种风格中最灵活的一种，但确实给必须指定服务器的开发团队带来了一些负担。
- 平台即服务 (PaaS)：开发人员只需要担心他们的应用程序和配置。云提供商负责所有服务器基础设施、网络和监控任务。
- 软件即服务(SaaS)：云提供商提供托管在云上的实际应用程序，因此客户组织可以将应用程序作为一个整体使用，而无需对应用程序代码负责。此选项提供开箱即用的软件服务，但如果客户需要在提供商提供的功能之外拥有任何自定义业务功能，则它不灵活。
PaaS 成为云选项中的最佳选择，因为它允许开发人员托管他们自己的自定义业务应用程序，而无需担心配置或维护底层基础设施。
尽管云托管鼓励模块化应用程序设计和部署，但许多组织发现将未设计为在弹性分布式架构上工作的遗留应用程序直接提升和转移到云端很诱人，从而产生了一种称为“单体应用”的现代反模式地狱”。
为了应对这些挑战，业界提出了新的架构模式，例如微服务和 12 要素应用程序。
迁移到云还给行业带来了管理应用程序对第三方库和技术的依赖关系的挑战。开发人员开始为太多的选项和选择第三方工具的标准不足而苦苦挣扎，我们开始看到一些依赖地狱。
依赖地狱可以发生在不同的层面：
- 库：对库（Java 世界中的 JAR 和 .NET 世界中的 DLL）的依赖关系管理不当可能会导致问题。例如，一个典型的 SpringBoot 应用程序包含 140 多个库 JAR 文件。确保在应用程序中没有打包不必要的库。
- 类：阐明应用程序内部对象的所有依赖关系。例如，Controller 类依赖于 Business Service 类，而 Service
类又依赖于 Repository 类。在代码审查期间花时间审查应用程序中的依赖关系，并确保没有不正确的依赖关系。 - 服务：如果您在系统中使用微服务，请确认不同服务之间没有直接依赖关系。
基于库的依赖地狱是一个封装挑战，后两个是设计挑战。本系列未来的一篇文章将更详细地研究这些依赖地狱场景，并提供设计模式来避免意外后果，以防止技术的任何扩散。
微服务：细粒度的可重用性
像DDD和EIP这样的软件设计实践从 2003 年左右就开始出现，当时一些团队一直在将应用程序开发为模块化服务，但是传统的基础设施，如用于 Java 应用程序的重量级 J2EE 应用程序服务器和用于 .NET 应用程序的 IIS 对模块化部署没有帮助.
随着云托管的出现，尤其是 Heroku 和 Cloud Foundry 等 PaaS 产品的出现，开发人员社区拥有了真正模块化部署和可扩展业务应用程序所需的一切。这引发了微服务的演变。微服务提供了细粒度、可重用的功能性和非功能性服务的可能性。
微服务在 2013-2014 年变得更加流行。它们功能强大，可以让较小的团队拥有特定业务和技术能力的全周期开发。开发人员可以随时部署或升级代码，而不会对系统的其他部分（客户端应用程序或其他服务）产生不利影响。这些服务还可以根据需求在单个服务级别上扩大或缩小。
需要使用特定业务功能的客户端应用程序调用适当的微服务，而无需开发人员从头开始编写解决方案或将解决方案打包为应用程序中的库。微服务方法鼓励服务提供者和服务消费者之间的契约驱动开发。这加快了整体开发时间并减少了团队之间的依赖。换句话说，微服务使团队更加松散耦合并加速了解决方案的开发，这对组织，尤其是业务初创公司至关重要。
微服务还有助于在业务流程和领域之间建立清晰的界限（例如，客户与订单与库存）。它们可以在组织中称为“有界上下文”的垂直模块化内独立开发。
这种演变还加速了DevOps等其他良好实践的演变，并在组织层面提供了敏捷性和更快的上市时间。每个开发团队将在其领域内拥有一个或多个微服务，并负责设计、编码、部署到生产以及后期支持和维护的整个过程。
然而，与之前的架构模型类似，微服务方法也遇到了自己的问题。
没有自下而上设计为微服务的遗留应用程序开始被蚕食，试图迫使它们进入微服务架构，导致称为单体地狱的反模式。其他尝试试图将单体应用程序人为地分解成多个微服务，即使这些微服务在功能方面没有隔离，并且仍然严重依赖于从同一个单体应用程序中分离出来的其他微服务。这就是称为microliths的反模式。
值得注意的是，单体和微服务是两种不同的模式，后者并不总是替代前者。如果我们不小心，我们最终可能会创建紧密耦合、混合的微服务。正确的选择取决于应用程序功能的业务和可扩展性要求。
微服务爆炸的另一个不良副作用是所谓的“死星”反模式。在服务交互和服务到服务安全（身份验证和授权）方面没有治理模型的微服务激增通常会导致任何服务都可以随意调用任何其他服务的情况。在没有适当协调这些服务调用的情况下，监控不同客户端应用程序正在使用多少服务也成为一项挑战。
图 2 显示了 Netflix 和 Twitter 等组织如何遇到这种噩梦般的场景，并且不得不想出新的模式来应对“死星”问题。
图 2：由于没有治理的微服务爆炸导致的死星架构
尽管图 2 中描述的示例可能看起来像只发生在巨头身上的极端情况，但不要低估云反模式的指数破坏力。该行业必须学习如何操作一种比世界上任何东西都大得多的武器。“强大的力量意味着巨大的责任，”富兰克林 D. 罗斯福说。
服务网格、边车、服务编排和容器等新兴架构模式可以成为有效的防御机制，以防止云世界中的不当行为。
组织应该了解这些模式并尽快推动采用。
快速浏览关键的云优先设计模式
服务网格
随着云平台的出现，尤其是 Kubernetes 等容器编排技术的出现，Service Mesh 越来越受到关注。服务网格是应用程序服务之间的桥梁，它增加了流量控制、服务发现、负载平衡、弹性、可观察性、安全性等附加功能。它允许应用程序从应用程序级库中卸载这些功能，并允许开发人员专注于业务逻辑。
一些服务网格技术（如Istio）还支持混沌注入等功能，以便开发人员可以测试其应用程序及其潜在的数十个相互依赖的微服务的弹性和健壮性。
服务网格非常适合平台即服务 (PaaS) 和容器即服务 (CaaS) 之上，并通过上述通用平台服务增强了云采用体验。
未来的文章将深入探讨基于服务网格的架构，并讨论特定用例以及使用和不使用服务网格的解决方案的比较。
无服务器架构
最近几年备受关注的另一个趋势是无服务器架构，也称为无服务器计算。无服务器比 PaaS 模型更进一步，因为它完全从应用程序开发人员那里抽象出服务器基础架构。
在无服务器中，我们将业务服务编写为函数并将这些函数部署到云基础架构中。无服务器技术的一些示例包括Amazon Lambda、Spring Cloud Function、Google Cloud Functions和Microsoft Azure Functions。
无服务器模型位于云托管范围内的 PaaS 和 SaaS 之间，如下图所示。
图 3：云计算、容器、服务网格和无服务器
与讨论单体服务与微服务的结论类似，并非所有解决方案都应实现为函数。此外，我们不应将所有微服务替换为无服务器功能，就像我们不应将所有单体应用程序替换或分解为微服务一样。只有细粒度的业务和技术功能，如用户身份验证或客户通知，才应设计为无服务器功能。
根据我们的应用程序功能和非功能性要求，例如性能和可扩展性以及事务边界，我们应该为每个特定用例选择合适的单体、微服务或无服务器模型。通常，我们可能需要在解决方案架构中使用所有这三种模式。
如果设计不当，无服务器解决方案最终可能会变成纳米石，其中每个功能都与其他功能或微服务紧密耦合，无法独立运行。
容器技术
容器技术等互补趋势大约与微服务同时出现，以帮助在微服务器环境中部署服务和应用程序，从而提供真正的业务服务隔离和单个服务的可扩展性。Docker、containerd、rkt和Kubernetes等容器技术可以很好地补充微服务开发。如今，我们不能在没有另一个的情况下提及一个 - 微服务或容器。
单体与微服务与无服务器
如前所述，了解三种架构风格的优缺点很重要：单体应用程序、微服务和无服务器功能。关于单体与微服务的书面案例研究详细描述了避免使用微服务的一个决定。
表 1 突出了这三个选项之间的高级差异。
表 1：服务架构模型以及何时使用或避免使用它们
稳定差距
对我们来说，密切关注随着时间的推移可能在我们的软件架构和代码中出现的反模式是很重要的。反模式不仅会导致技术债务，更重要的是，它们可能会将主题专家赶出组织。一个组织可能会发现自己只有那些不关心架构偏差或反模式的人。
在上面的简短历史之后，让我们关注作为仓促采用微服务的一部分可能出现的稳定性差距和反模式。
组织中的团队结构、业务领域和团队中的技能组合等特定因素决定了哪些应用程序应该作为微服务实现，哪些应该作为整体解决方案。但是我们可以看看选择将解决方案设计为微服务的一些一般注意事项。
Eric Evans 的《领域驱动设计 (DDD)》一书改变了我们开发软件的方式。Eric 提倡从领域的角度而不是从基于技术的角度看待业务需求的想法。
本书认为微服务是聚合模式的派生。但是许多软件开发团队正在将微服务设计理念发挥到极致，试图将所有现有的应用程序转换为微服务。这导致了诸如单体地狱、微石等反模式。
以下是架构和开发团队需要注意的一些反模式：
- monolithic hell
- microliths
- Jenga tower
- logo slide (also known as Frankenstein)
- square wheel
- Death Star
不断发展的架构模式
为了缩小在不同应用程序托管模型中发现的稳定性差距和反模式，业界提出了不断发展的架构模式和最佳实践来缩小差距。
下表总结了这些架构模型、稳定性差距和模式。
表 2：应用程序托管模型、反模式和模式
图 4 显示了所有这些架构模型、反模式形式的稳定性差距以及演变的设计模式和最佳实践。
图 4：架构演变和应用程序托管模型
历史告诉我们什么
图 5 列出了架构演进的步骤，包括在新范式中不了解最佳实践的初始阶段，这加速了技术债务。随着行业开发新的设计模式以解决稳定性差距，团队在其架构中采用新的标准和模式。
图 5：架构模型和新模式的采用
商业和技术
IT 领导者必须保护他们的投资免受技术不断增长的快速转型，同时提供在不断发展和优化的技术基础上运行的一系列稳定的业务应用程序。全球的 IT 主管越来越频繁地处理这个问题。
他们和我们应该拥抱技术的发展，但不能以支持业务的应用程序不断不稳定为代价。
纪律严明的系统架构应该能够做到这一点。将本系列文章中讨论的模式视为支持快速技术发展同时保护业务应用程序免受波动影响的策略。让我们在下一篇文章中探讨如何做到这一点。
结论
从大型机到最近的云原生架构，各种托管模型影响着我们开发、部署和维护业务应用程序的方式。每次业界发现新的托管模型时，团队都面临着获取架构全部优势的挑战。这导致了意想不到的后果，例如架构偏差和反模式，从而导致了重大的技术债务。随着时间的推移，新的设计模式不断发展，以解决新托管模型带来的稳定性差距。
技术债务管理在整个系统以及团队的健康中起着至关重要的作用。不及时处理技术债务的 IT 领导者可能会造成与软件相关的损害和组织损害。技术债务可以自食其力并产生更多债务，同时导致不良做法制度化并排斥顶尖人才。
当这些迹象出现时，立即停止并评估。然后采取坚定的行动。
确保您授权您的团队解决各种形式的技术债务。
本系列的后续文章将研究我的组织在采用微服务架构期间开发的通用服务平台。我们还将讨论该公司如何利用不同的云原生架构组件，如容器、PaaS 和服务网格。
下一篇文章将深入探讨团队应该注意的反模式以及他们应该在架构中采用的云原生设计模式。我们将讨论采用企业云原生服务网格策略的细节，这将有助于实现很多这些功能。最后，我们将分享一些针对架构和组织的建议。
参考