避免不完全的云原生（三）：架构和设计角度.docxVIP

避开不完全的云原生（三）：架构和设计角度 2021-01-13 我们争辩了迁移到云原生方法可能会对人员组织和流程简化产生怎样的影响。在这篇文章中，我们将深化探讨它与架构和设计准绳之间的关系。 云原生要素：架构与设计 架构方法赐予技术生命。我们可以将传统的、竖井式的、无形态的粗粒度应用程序组件部署到现代的基于容器的云基础设备上。对一些人来说，这是一种让他们可以涉足云的方法，但这应当只是一个开头。假如这样做，你几乎体验不到云原生的任何优势。在这一部分中，我们将考虑如何设计一个应用程序，使其有机会充分利用底层云基础设备。明显，使用不行变部署滚动发布解耦良好的组件与接受灵敏方法和流程同样重要。下图呈现了云原生架构的组成部分： 云原生架构的组件 01 细粒度组件 不久之前，为了有效地使用硬件和软件资源，我们还是以大块的代码构建和运转软件。最近的技术进展（如容器），让我们可以将应用程序分解成更小的块并单独运转。我们所说的细粒度涉及几个不同的方面： · 功能驱动的粒度——每个组件执行一个定义良好的任务； · 自包含组件——在可能的情况下，该组件包括其全部依靠项； · 独立的生命周期、可伸缩性和弹性——组件从单个代码库构建，通过公用管道，并且在运转时独立托管。 通常，这种构建应用程序的方式被称为微服务，不过应当留意，真正的“微服务方法所涉及的面”比细粒度组件要广泛得多，而且的确与这里描述的云原生概念有很大的堆叠。 更细粒度组件的次要有如下好处： · 更强的机警性：它们足够小，可以完全理解并单独更改； · 弹性伸缩：每个组件都可以单独伸缩，从而可以最大限度地提高云原生基础设备的效率； · 离散弹性（Discrete resilience）：通过适当的解耦，一个微服务运转不稳定不会影响其他服务。 虽然在适当的环境中，上面的方法可以带来显著的好处，但是设计高度分布式的系统并不是一件简约的事情，管理它们更不简约。确定微服务组件的大小本身就是一个需要深化争辩的话题，然后还要进行进一步的设计决策，确定它们应当如何解耦，以及如何管理剩下的紧耦合部分的版本。发觉必要的内聚性与引入适当的解耦同样重要，经常会有由于粒度过细而不得不中止的项目。简而言之，只要设计良好、方法及流程成熟时，微服务应用程序才能具备机警性和可伸缩性。 留意：人们经常会对微服务架构和面对服务的体系结构（SOA）进行不恰当的比较，由于它们有相同的词汇，并且好像处于相同的概念空间中。然而，它们涉及不同的范围。微服务与应用程序架构有关，SOA 与企业架构有关。这个区分格外关键，文章“微服务与SOA：如何辨别”对此进行了进一步探讨。 02 适当的解耦 假如细粒度组件之间不能相互解耦，那么它们的很多优点（灵敏性、可伸缩性和弹性）就会丢失。这些细粒度的组件需要满足以下条件： · 清楚的全部者边界 · 方式化的接口（API和大事/消息） · 单独的长久化存储 编写模块化软件并不是什么新颖事。全部的设计方法，从功能分解到面对对象的编程，再到面对服务的体系结构，都旨在将大问题分解成更小的、更易于管理的部分。云原生领域的机遇在于，利用容器等技术，我们可以将每个容器作为真正独立的组件运转。每个组件都有本人的 CPU、内存、文件存储和网络连接，就像一个完整的操作系统一样。因而，只能通过网络访问它，这本身就在组件之间创建了一个格外清楚的强制性分别。不过，底层平台供应的解耦只是其中的一个方面。 从组织的角度来看，全部权要清楚。每个组件都需要由一个能够完全把握其实现的团队拥有。这并不是说团队不应当接受变更恳求，即来自其他团队的 pull 恳求，但是他们可以把握合并什么以及何时合并。这是灵敏的关键，只需是遵照与其他团队商定的接口，他们就可以修改组件，并且满怀决心地部署变更。当然，即便这样，团队也应当在组织全体设置的架构边界内工作，但是在这些边界内，他们应当有相当大的自在。 组件应当显式地声明接口，并且锁定全部其他的访问方式。它们应当只使用成熟的标准协议。同步通信最简约，HTTP 的普遍性使其成为首选项。更具体地说，我们通常会看到 RESTful API 使用 JSON，不过，其他协议（如 gRPC）也可以用于特定的需求。 区分相同全部权边界（例如应用程序边界）内跨组件的调用和对另一个全部权边界内的组件的调用，这很重要，但超出了本文的范围。更多信息请阅读这篇文章。 然而，HTTP API 的同步特性将调用者与下游组件的可用性和功能绑定在了一起。通过大事和消息进行异步通信，借助“存储转发”或“发布/订阅”模式，可以更彻底地将它们与其他组件解耦。 一种常见的异步模式是，数据的全部者发布有关数据更改的大事（创建、更新和删除）。其他需要该数据的组件监听大事流并构建本人的本地数据存储，这样，当它们需要该数据时，就有一份副