云原生架构是一种在云环境中从头开始构建应用程序的设计模式。虽然云原生架构没有硬性规则，但大多数云原生应用程序都是由微服务组织而成。微服务主要用于将应用程序分解为可由小型团队维护的自治、松散耦合的单元，每个微服务通常部署为一个容器或一组容器。
此外，云原生应用通常遵循12因素应用框架的原则。它们围绕以下方面构建：
- 性能：应用程序在设计时考虑可扩展性，旨在在规模上表现良好。
- 弹性：应用程序由伸缩性良好的小型、可扩展的组件构建而成。
- 韧性：应用程序对故障具有很强的复原能力，可自动更换发生故障的组件且不会中断其他组件的运行。
- 安全性：在构建应用程序时考虑安全性，确保应用程序或其数据不被攻击者破坏。
原生架构原则
在构建云原生应用程序时，首先应构建一个可以在多个维度上不断移动的系统，以实现动态扩展，自动处理故障，并尽可能轻松的添加或删除组件。以下几个原则可以使构建的云原生架构更加强大、更加适应变化并且更容易维护。
1. 自动化设计
创建可以部署、修复和扩展系统的自动化流程，并且生成相关日志和事件。构建系统以自动处理：
- 提供的基础架构，如机器实例;
- CI/CD 管道中的生成、测试和部署阶段;
- 基于工作负载或其他应用程序要求的动态可扩展性;
- 备份、运行状况监视和故障恢复。
2. 尽可能保持无状态
虽然一些云原生纯粹主义者认为云原生应用程序应该是无状态的，但在现实世界中可能很难实现无状态应用程序的开发。然而也应尽可能使用无状态组件，因为跟踪分布式应用程序中的管理状态(如当前正在运行的实例数)是困难的。无状态组件使扩展(添加更多副本)、修复(删除并替换为新实例)、回滚和工作负载平衡(无需关心哪个实例正在处理哪些事务的复杂逻辑)变得更加容易。
3. 弹性设计
通过在设计中添加冗余将弹性构建到云原生应用程序中。云原生应用程序通过使用实例集群、数据复制以及多可用区或多区域云部署来避免单点故障。那些必须在本地运行的应用程序应使用混合架构利用公有云以实现高可用性和灾难恢复，至少对于其某些组件而言。
一些常见的弹性机制：
- 能够识别由连接丢失或服务超时等临时问题引起的暂时性故障，进行重试请求;
- 实现断路器模式，检查重试操作的次数，并在后续重试时返回错误而不激活服务;
- 允许服务在它们所依赖的其他服务出现故障时正常降级，并且仍提供合理的用户体验;
- 根据应用程序的使用速率限制和节流来识别和限制大容量用户;
- 使用补偿事务，将业务事务分解为一系列较小的事务，更容易在分布式系统中实现事务一致性。
4. 使用微边界构建每个组件
云原生应用不仅应该从一开始就设计安全性，还应该在假设没有可信任组件的情况下进行设计。因为应用程序与其用户之间，甚至内部组件之间可能没有专用网络，此时应该致力于强化所有组件、加密数据并在组件之间实现身份验证，使应用程序更具弹性，并能够在不受信任的环境中灵活地部署组件。
5. 构建多语言架构
云原生应用不需要高度集成的架构、使用相同语言编写的组件以及使用相同的技术和框架。由于REST
API可以公开每个组件的功能，允许异构组件相互通信和使用，因此可以在充分考虑团队能力之后，使用能够提供最大价值和最快上市时间的语言或技术编写每个组件。
6. 组件不可变
通过基础架构组件不可变以引入高级别的敏捷性和灵活性。这也就意味着不允许在部署后对配置服务器或虚拟机(VM)进行修改。
在部署不可变服务器后，就可以不再对其进行修改，相反，若没有部署不可变服务器，则应确保已部署的服务器保持原样且不进行任何修改，以便如果出现问题也可以快速轻松地更换服务器并保持应用程序运行。
以下是使用不可变基础架构的几个主要优点：
- 不可变组件有助于实现一致且可靠的基础架构，使测试变得更加简单明了。
- 部署不可变组件可以更简单、更可预测。
- 不可变组件的每次部署都是版本化和自动化，这使得环境回滚更加容易和简单。
- 配置飘逸、雪花服务器和错误得到缓解，甚至完全消除。
- 使用云服务时，自动伸缩也毫不费力。
可变服务器会增加成本和迭代时间，严重延迟上市时间，不可变的基础设施则促进了敏捷开发。不可变基础架构可提高已部署环境的可靠性、一致性和效率，开发人员可以在几分钟内重新创建环境。
云原生架构的优缺点
云原生架构有许多优点：
- 成本：云提供低成本选项，确保系统不间断运行，为客户提供服务，此外还可以利用各种云交付功能。若在企业内部提供这些功能，则既耗时又昂贵。
- 可靠性：云环境提供弹性和可靠性选项，例如可用性区域，可以确保系统永远不会出现故障，免受中断的影响，因此避免停机造成的不可挽回的损失。
- 敏捷性：敏捷开发需要不断的测试和优化，这在传统的整体架构中是很困难的，因为一个小小的改变可能会破坏整个系统。云原生系统在构建时考虑了持续变化，因此可以更轻松地更新和调整应用程序。
- 灵活性：云原生设计与平台无关，因此若当前系统不适合开发，可以切换到新环境，而不必从头开始重新编译。
云原生架构的缺点包括：
- 解决问题：在传统体系架构中可以遵循线性计划来识别问题。而云原生设计存在复杂网络中相互连接和交互的容器，并且特定组件集之间的路径可能不明确。如果问题的根源分散在多个容器中，则可能更难找出根本原因。
- 安全性：由于系统是由大量动态分布式组件构成，云原生架构通常更难以监控和保护。
- 知识差距：如果开发人员不熟悉云原生系统，则需要重新学习，就像使用新语言一样，重要的是需要能够很好地理解新概念，以避免造成严重损失的错误。
在考虑构建新的云原生架构时，企业组织需要仔细权衡各种优缺点，以便为业务、客户和利益相关者做出正确的决策。
