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