在 Google Cloud，我们经常将“云原生架构”这个术语作为您在Google Cloud Platform (GCP) 上迁移或构建的应用程序的理想最终目标。但是，我们所说的云原生到底是什么意思？更重要的是，您如何设计这样的系统？
在高层次上，云原生架构意味着适应云提供的许多新可能性——但架构约束集非常不同——与传统的本地基础设施相比。考虑一下我们作为软件架构师受过培训要考虑的高级元素：
- 系统的功能要求（它应该做什么，例如’以这种格式处理订单…’）
- 非功能性需求（它应该如何执行，例如“每分钟处理至少 200 个订单”）
- 约束（超出范围的更改，例如“必须在我们现有的大型机系统上更新订单”）。
虽然功能方面没有太大变化，但云提供了，有时需要非常不同的方式来满足非功能性需求，并施加了非常不同的架构约束。如果架构师未能使他们的方法适应这些不同的约束条件，他们所构建的系统通常会变得脆弱、昂贵且难以维护。另一方面，架构良好的云原生系统应该在很大程度上是自我修复的、具有成本效益的，并且可以通过持续集成/持续交付 (CI/CD) 轻松更新和维护。
好消息是，云是由构成传统基础设施的相同结构的服务器、磁盘和网络组成的。这意味着几乎所有优秀架构设计的原则仍然适用于云原生架构。但是，当您在云中时，有关该结构如何执行的一些基本假设会发生变化。例如，在传统环境中配置替换服务器可能需要数周时间，而在云中则需要几秒钟——您的应用程序架构需要考虑到这一点。
在这篇文章中，我们列出了云原生架构的五项原则，这将有助于确保您的设计充分利用云，同时避免将旧方法套入新平台的陷阱。
云原生架构的原则
云架构的原则，又称云原生架构，侧重于如何针对云的独特功能优化系统架构。传统架构倾向于针对固定的、高成本的基础架构进行优化，这需要大量的人工修改。因此，传统架构侧重于相对较少的固定数量的组件的弹性和性能。然而，在云中，这样一个固定的基础设施意义不大，因为云是根据使用量收费的（所以当你可以减少你的足迹时你可以省钱）而且它也更容易自动化（所以自动扩展和缩减更容易）。因此，云原生架构侧重于通过水平扩展、分布式处理、并自动更换故障组件。让我们来看看。
原则 1：自动化设计
自动化一直是软件系统的最佳实践，但云使基础架构以及位于其之上的组件的自动化比以往任何时候都更加容易。尽管前期投资通常更高，但从中期来看，偏爱自动化解决方案几乎总能在工作量以及系统的弹性和性能方面获得回报。自动化流程可以比人们更快地修复、扩展和部署您的系统。正如我们稍后讨论的那样，云中的架构不是一次性的交易，自动化也不例外——因为您会找到系统需要采取行动的新方法，因此您会发现新的东西需要自动化。
自动化云原生系统的一些常见领域是：
- 基础架构：使用Google Cloud Deployment Manager或Terraform等工具自动创建基础架构及其更新
- 持续集成/持续交付：使用Google Cloud Build、Jenkins和Spinnaker等工具自动构建、测试和部署构成系统的包。您不仅应该自动化部署，还应该努力实现金丝雀测试和回滚等流程的自动化。
- 放大和缩小：除非您的系统负载几乎从不改变，否则您应该自动扩大系统以响应负载的增加，并缩小以响应负载的持续下降。通过扩大规模，您可以确保您的服务保持可用，通过缩小规模，您可以降低成本。这对于大型应用程序（如公共网站）以及负载不规则的小型应用程序（例如在某些时间段非常繁忙但在其他时间段几乎不使用的内部应用程序）来说显然是有意义的。对于有时几乎没有流量的应用程序，并且您可以容忍一些初始延迟，您甚至应该考虑将其缩放到零（删除所有正在运行的实例，并在下次需要时重新启动应用程序）。
- 监控和自动恢复：您应该从一开始就将监控和登录到您的云原生系统。记录和监控数据流自然可以用于监控系统的健康状况，但除此之外还有很多用途。例如，他们可以对系统使用和用户行为（有多少人在使用系统，他们正在使用哪些部件，他们的平均延迟是多少等）提供有价值的见解。其次，它们可以综合使用来衡量整个系统的健康状况（例如，磁盘几乎再次满了，但它是否比平时更快地填充？磁盘使用和服务吸收之间的关系是什么？等等）。最后，它们是连接自动化的理想点.现在，当该磁盘填满时，您不仅可以记录错误，还可以自动调整磁盘大小以允许系统继续运行。
原则 2：聪明地对待状态
存储“状态”，是用户数据（例如，用户购物车中的商品，或他们的员工编号）或系统状态（例如，正在运行的作业实例数量，生产中运行的代码版本） ，是构建分布式云原生架构最困难的方面。因此，您应该在构建系统时有意识地考虑何时以及如何存储状态，并尽可能将组件设计为无状态。
无状态组件很容易：
- 规模：要扩大规模，只需添加更多副本。要缩小规模，请指示实例在完成当前任务后终止。
- 修复：要“修复”组件的失败实例，只需尽可能优雅地终止它并启动替换。
- 回滚：如果部署不好，无状态组件更容易回滚，因为您可以终止它们并启动旧版本的实例。
- 跨负载平衡：当组件是无状态的时，负载平衡要简单得多，因为任何实例都可以处理任何请求。有状态组件之间的负载平衡要困难得多，因为用户会话的状态通常驻留在实例上，迫使该实例处理来自给定用户的所有请求。
原则 3：支持托管服务
云不仅仅是基础设施。大多数云提供商都提供一组丰富的托管服务，提供各种功能，让您摆脱管理后端软件或基础设施的麻烦。但是，许多组织对利用这些服务持谨慎态度，因为他们担心被“锁定”给特定的提供商。这是一个值得关注的问题，但托管服务通常可以极大地节省组织的时间和运营开销。
从广义上讲，是否采用托管服务的决定归结为可移植性与运营开销，无论是在资金方面，还是在技能方面。粗略地说，您今天可能考虑的托管服务分为三大类：
托管开源或开源兼容服务：托管开源（例如 Cloud SQL）或提供开源兼容接口（例如 Cloud Bigtable）的服务。这应该是一个简单的选择，因为使用托管服务有很多好处，而且风险很小。
可节省大量运营成本的托管服务：一些服务不能立即与开源兼容，或者没有直接的开源替代方案，但比替代方案更容易使用，因此值得冒险。例如，BigQuery经常被组织采用，因为它非常易于操作。
其他一切：还有一些困难的情况，即没有简单的服务迁移路径，并且它提供了不太明显的运营优势。您需要逐个检查这些，考虑诸如服务的战略意义、自己运行它的运营开销以及迁移所需的工作量等。
然而，实践经验表明，大多数云原生架构偏爱托管服务；必须迁移出它们的潜在风险很少超过让云提供商代表您大规模管理服务所节省的大量时间、精力和运营风险。
原则4：深度练习防守
传统架构非常信任外围安全，粗略地说是一个强化的网络外围，里面有“受信任的东西”，外面有“不可信的东西”。不幸的是，这种方法一直很容易受到内部攻击，以及鱼叉式网络钓鱼等外部威胁。此外，提供灵活和移动工作的压力越来越大，进一步削弱了网络边界。
云原生架构起源于面向互联网的服务，因此一直需要应对外部攻击。因此，他们通过在每个组件之间应用身份验证，并通过最小化这些组件之间的信任（即使它们是“内部的”）来采用深度防御方法。结果，没有 ‘inside’ 和 ‘outside’。
云原生架构应该将这个想法扩展到身份验证之外，包括速率限制和脚本注入等内容。设计中的每个组件都应设法保护自己免受其他组件的影响。这不仅使架构非常有弹性，而且还使生成的服务更容易部署在云环境中，在云环境中，服务与其用户之间可能没有受信任的网络。
原则 5：始终是架构师
云原生系统的核心特征之一是它始终在发展，架构同样如此。作为云原生架构师，随着组织需求的变化、IT 系统环境的变化以及云提供商自身能力的变化，您应该始终寻求改进、简化和改进系统架构。虽然这无疑需要不断的投资，但过去的教训是显而易见的：为了发展、成长和响应，IT 系统需要生存、呼吸和改变。死气沉沉、僵化的 IT 系统迅速使组织陷入停顿，无法应对新的威胁和机遇。
唯一不变的就是变化
在动物王国中，生存偏爱那些适应环境的个体。这不是从“坏”到“最好”或从“原始”到“进化”的线性旅程，而是一切都在不断变化。随着环境的变化，物种面临进化和适应的压力。同样，云原生架构并没有取代传统架构，而是更好地适应了非常不同的云环境。云越来越成为我们大多数人发现自己工作的环境，正如许多物种可以证明的那样，未能进化和适应并不是一个长期的选择。
上述原则并不是创建云原生架构的神奇公式，但希望为如何充分利用云提供强有力的指导。作为一个额外的好处，移动和调整云架构让您有机会以其他方式改进和调整它们，并使它们能够更好地适应下一次环境转变。改变可能很难，但正如数十亿年的进化所表明的那样，你不必成为最好的生存者——你只需要能够适应。
如果您想了解有关本文中主题的更多信息，请查看以下资源：
要详细了解 Google 如何在生产环境中运行系统，请查看站点可靠性工程页面上的资源
详细了解容器以及持续集成和持续部署，它们是在云上构建的核心技术
几乎所有云架构都基于微服务架构，请查看将单体应用程序迁移到 Google Kubernetes Engine上的微服务，以获得对微服务的全面了解，以及有关迁移现有应用程序的实用建议
任何组织都很难改变，在谷歌 re:work 网站上改变谷歌的改变规则对谷歌如何处理改变有一些有趣的见解