摘要：构建云原生应用
总的来说，本指南的重要结论如下:
云原生是关于设计新式应用程序的，这些应用在新式动态环境（如公有云、私有云和混合云）中支持快速更改、大规模操作和复原能力。
云原生计算基金会 (CNCF) 是一个有影响力的开源联盟，300 多家大型公司都是它的成员。 它负责推动跨技术和云堆栈采用云原生计算。
CNCF 准则建议，云原生应用程序采用 6 个重要支柱，如图 11-1 所示：
图 11-1。 云原生基础支柱
这些云原生支柱包括：
- 云及其基础服务模型
- 现代设计原则
- 微服务
- 容器化和容器业务流程
- 基于云的后备服务，例如数据库和消息代理
- 自动化，包括基础结构即代码和代码部署
Kubernetes 是大多数云原生应用程序的托管环境。 较小的简单服务有时托管在无服务器平台中，例如 Azure Functions。 在许多关键自动化功能中，这两个环境都提供自动缩放来处理波动的工作负载量。
构造云原生应用程序时，服务通信是一项重大设计决策。 应用程序通常会公开 API 网关来管理前端客户端通信。 随后，如果可能，后端微服务会尽量相互通信，来实现异步通信模式。
gRPC 是一种新式的高性能框架，它发展了由来已久的远程过程调用 (RPC) 协议。 云原生应用程序通常采用 gRPC 来简化后端服务之间的消息传递。 gRPC 对其传输协议使用 HTTP/2。 其处理速度可以比 JSON 序列化快 8 倍，消息小 60-80%。 gRPC 是开源的，由云原生计算基金会 (CNCF) 进行管理。
分布式数据是通常由云原生应用程序实现的模型。 应用程序将业务功能分隔到独立的小型微服务中。 每个微服务封装其自己的依赖项、数据和状态。 经典共享数据库模型演变成许多较小的数据库之一，每个数据库与微服务保持一致。 当一切明了时，我们得到了一个设计，它公开了一个
database-per-microservice模型。No-SQL 数据库是指高性能的非关系数据存储。 它们具有出色的易用性、可伸缩性、复原能力和可用性。 需要亚秒级响应时间的高容量服务倾向于使用 NoSQL 数据存储。 NoSQL 技术对于分布式云原生系统的普及怎么强调都不为过。
NewSQL 是一种新兴的数据库技术，它将 NoSQL 的分布式可伸缩性与关系数据库的 ACID 保证相结合。 NewSQL 数据库面向这样的业务系统，它们必须跨分布式环境处理大量数据，并且具有完全事务/ACID 合规性。 云原生计算基金会 (CNCF) 具有多个 NewSQL 数据库项目。
复原能力是系统对故障做出反应并仍然保持正常运行的能力。 云原生系统采用分布式体系结构，其中故障是不可避免的。 必须构造应用程序，来正常响应故障并快速恢复到完全正常运行的状态。
服务网格是一个可配置的基础结构层，其中内置了用于处理服务通信和其他横切挑战的功能。 它们将横切职责与业务代码分开。 这些责任转移到服务代理中。 代理被称为
Sidecar pattern，它部署到一个单独的进程中，来提供与业务代码的隔离。可观测性是云原生应用程序的关键设计注意事项。 服务跨节点群集分布，因此集中日志记录、监视和警报是必需的。 Azure Monitor 是一系列基于云的系统，旨在提供系统状态可见性。
基础结构即代码是一种被广泛接受的用于自动预配平台的做法。 基础结构和部署是自动执行的，具有一致性和可重复性。 借助 Azure 资源管理器、Terraform 和 Azure CLI 等工具，你能够以声明方式对所需的云基础结构编写脚本。
代码自动化是云原生应用程序的要求。 新式 CI/CD 系统有助于实现此原则。 它们提供单独的生成和部署步骤，可帮助确保一致且高质量的代码。 生成阶段将代码转换为二进制项目。 发布阶段选取二进制项目、应用外部环境配置，并将其部署到指定的环境。 Azure DevOps 和 GitHub 是功能齐全的 DevOps 环境。
