云原生架构的五个原则

我们经常把术语 Cloud-native“云原生/本地架构”作为您迁移或构建在Google Cloud平台（GCP）上的应用程序的预期最终目标。但是我们所说的云原生到底是什么意思呢？更重要的是，你如何着手设计这样一个系统？

在较高的层次上，云原生架构意味着要适应许多新的可能性，但与传统的本地基础设施相比，云提供的架构约束非常不同。考虑一下我们作为软件架构师所要考虑的高级元素：

• 系统的功能要求（它应该做什么，例如“处理此格式的订单…”）
• 非功能性需求（应如何执行，例如“每分钟至少处理200个订单”）
• 约束条件（超出范围的内容需要更改，例如“必须在现有的大型机系统上更新订单”）。

虽然功能方面没有太多变化，但云提供了（有时需要）非常不同的方式来满足非功能需求，并施加了非常不同的架构约束。如果架构师不能使他们的方法适应这些不同的约束，那么他们设计的系统通常是脆弱的、昂贵的，并且很难维护。另一方面，一个架构良好的云原生系统应该在很大程度上是自愈的、经济高效的，并且可以通过持续集成/持续交付（CI/CD）轻松地进行更新和维护。

好消息是，云是由服务器、磁盘和网络组成的，这与传统的基础设施是一样的。这意味着几乎所有优秀架构设计的原则仍然适用于云原生架构。然而，当您在云中时，关于该结构如何执行的一些基本假设会发生变化。例如，在传统环境中，配置替换服务器可能需要数周时间，而在云环境中，应用程序体系结构需要几秒钟就能考虑到这一点。

在这篇文章中，我们阐述了云原生架构的五个原则，这将有助于确保您的设计充分利用云，同时避免将旧方法引入新平台的陷阱。

云原生架构的原则

云架构（architecting for The cloud）的原则，也称为云原生架构（cloud native architecture），主要关注如何针对云的独特功能优化系统架构。传统的体系结构倾向于为固定的、高成本的基础设施进行优化，这需要大量的人工修改。因此，传统体系结构侧重于相对较少的固定数量的组件的弹性和性能。然而，在云计算中，这样一个固定的基础设施就没有什么意义了，因为云计算是根据使用情况收费的（这样当你可以减少你的占地面积时，你就可以省钱），而且它也更容易实现自动化（所以自动上下扩展就容易多了）。因此，云原生架构侧重于通过水平扩展、分布式处理和自动更换故障组件来实现恢复能力和可扩展性。我们来看看。

原则一：自动化设计

自动化一直是软件系统的最佳实践，但云使得自动化基础设施以及位于其上的组件比以往任何时候都更容易。尽管前期投资通常更高，但从中期来看，支持自动化解决方案几乎总是会有回报的，这不仅体现在工作量上，而且体现在系统的弹性和性能上。自动化流程可以比人们更快地修复、扩展和部署您的系统。正如我们后面所讨论的，云架构不是一蹴而就的，自动化也不例外，因为您找到了系统需要采取行动的新方法，所以您将找到新的东西来自动化。

自动化云原生系统的一些常见领域包括：

1. 基础设施：使用googlecloud Deployment Manager或Terraform等工具，自动化基础设施的创建和更新

2. 持续集成/持续交付：通过使用googlecloudbuild、Jenkins和Spinnaker等工具，自动构建、测试和部署组成系统的包。您不仅应该自动化部署，还应该努力实现金丝雀测试和回滚等过程的自动化。

3. 扩容和缩容：除非您的系统负载几乎从不改变，否则您应该根据负载的增加自动放大系统，并根据负载的持续下降自动缩小系统。通过扩大规模，您可以确保您的服务仍然可用，而通过缩小规模，您可以降低成本。这对于高规模的应用程序（如公共网站）很有意义，但对于负载不规则的小型应用程序也很有意义，例如内部应用程序在某些时段非常繁忙，但在其他时段几乎没有使用。对于有时几乎不接收任何通信量的应用程序，并且您可以容忍一些初始延迟，您甚至应该考虑将其扩展到零（删除所有正在运行的实例，并在下次需要时重新启动应用程序）。

4. 监视和自动恢复：您应该从一开始就将监视和日志记录到您的云原生系统中。日志记录和监视数据流自然可以用于监视系统的健康状况，但除此之外还有许多用途。例如，他们可以对系统使用情况和用户行为（有多少人在使用系统、他们在使用什么部件、他们的平均延迟是多少等）提供有价值的见解。第二，它们可以聚合使用，以度量整个系统的运行状况（例如，磁盘几乎又满了，但它是否比平常填充得更快？磁盘使用率和服务利用率之间的关系是什么？等等）。最后，它们是连接自动化的理想点。现在，当磁盘填满时，您也可以自动调整磁盘大小以允许系统继续工作，而不只是记录错误。

原则二：精明处事

存储“状态”，即用户数据（例如，用户购物车中的项目，或其员工编号）或系统状态（例如，一个作业有多少个实例正在运行，生产中运行的代码版本），是构建分布式云原生体系结构的最困难方面。因此，您应该设计您的系统，以便有意考虑何时以及如何存储状态，并尽可能将组件设计为无状态。

无状态组件易于：

1. 缩放：要放大，只需添加更多副本。若要缩小，请指示实例在完成当前任务后终止。

2. 修复：要“修复”一个失败的组件实例，只需尽可能优雅地终止它并启动一个替换。

3. 回滚：如果部署不好，无状态组件更容易回滚，因为您可以终止它们并启动旧版本的实例。

4. 负载平衡：当组件是无状态的时，负载平衡要简单得多，因为任何实例都可以处理任何请求。跨有状态组件的负载平衡要困难得多，因为用户会话的状态通常驻留在实例上，从而强制该实例处理来自给定用户的所有请求。

原则三：支持托管服务

云不仅仅是基础设施。大多数云提供商都提供了一组丰富的托管服务，提供了各种各样的功能，可以减轻您管理后端软件或基础设施的麻烦。然而，许多组织对利用这些服务持谨慎态度，因为它们担心被“锁定”到给定的提供者。这是一个值得关注的问题，但是托管服务通常可以极大地节省组织的时间和操作开销。

从广义上讲，是否采用托管服务的决定归结为可移植性和操作开销，这不仅涉及资金，也涉及技能。粗略地说，您今天可能会考虑的托管服务分为三大类：

• 托管开放源代码或开放源代码兼容服务：托管开放源代码（例如Cloud SQL）或提供开放源代码兼容接口（例如Cloud Bigtable）的服务。这应该是一个简单的选择，因为使用托管服务有很多好处，而且风险很小。
• 具有高运营节省的托管服务：有些服务不能立即与开放源代码兼容，或者没有直接的开放源代码替代方案，但是比替代方案更容易使用，因此值得冒这个风险。例如，BigQuery经常被组织采用，因为它很容易操作。
• 其他方面：还有一些困难的情况，在这些情况下，不存在离开服务的简单迁移路径，并且它提供了不太明显的操作好处。您需要逐个检查这些问题，考虑到服务的战略意义、自己运行服务的操作开销以及迁移所需的工作。

然而，实践经验表明，大多数云原生架构都支持托管服务；必须从托管服务迁移出去的潜在风险很少超过让云提供商代表您大规模管理服务所节省的时间、精力和操作风险。

原则四：深度防御

传统的架构非常信任外围安全，粗略地说是一个加固的网络外围，内部有“可信的东西”，外部有“不可信的东西”。不幸的是，这种方法总是容易受到内部攻击，以及外部威胁，如鱼叉式网络钓鱼。此外，提供灵活和流动工作的压力越来越大，进一步削弱了网络的边界。

云原生架构起源于面向互联网的服务，因此总是需要处理外部攻击。因此，他们采用了一种深度防御的方法，在每个组件之间应用身份验证，并最小化这些组件之间的信任（即使它们是“内部的”）。因此，没有“内”和“外”。

云原生架构应该将这个概念扩展到认证之外，包括诸如速率限制和脚本注入之类的内容。设计中的每个组件都应该设法保护自己不受其他组件的影响。这不仅使体系结构具有很强的弹性，还使生成的服务更易于在云环境中部署，因为云环境中服务与其用户之间可能没有可信的网络。

原则五：永远是架构

云原生系统的一个核心特征是它总是在不断发展，架构也是如此。作为一个云原生架构师，随着组织的需求变化、IT系统的环境变化以及云提供商自身的能力变化，您应该始终寻求优化、简化和改进系统的体系结构。尽管这无疑需要不断的投资，但过去的教训是明确的：要发展、成长和应对，IT系统需要生存、呼吸和改变。死气沉沉、僵化的IT系统迅速使组织陷入停滞，无法应对新的威胁和机遇。

唯一不变的就是变化

在动物王国，生存有利于那些适应环境的个体。这不是一个从“坏”到“最好”或从“原始”到“进化”的线性过程，而是一切都在不断变化。随着环境的变化，压力被施加到物种的进化和适应上。类似地，云原生架构不会取代传统架构，但它们可以更好地适应非常不同的云环境。云越来越成为我们大多数人工作的环境，许多物种可以证明，不能进化和适应不是一个长期的选择。

上面描述的原则并不是创建云原生架构的神奇公式，但希望能为如何最大限度地利用云提供强有力的指导。作为一个额外的好处，移动和调整云架构为您提供了以其他方式改进和调整它们的机会，并使它们能够更好地适应下一个环境变化。改变可能很难，但正如数十亿年来进化所显示的那样，你不一定要成为最好的生存者，你只需要能够适应。