鲍里斯·肖勒是Azure计算团队的产品架构师，专注于分布式系统平台和应用程序模型。他自2011年起致力于Azure开发工具和平台，2018年重返Azure团队领导微服务平台开发。特伦特·斯旺森是云和边缘技术专家，帮助客户迁移和构建云应用。彼得·加索维奇拥有十多年软件开发经验，专注于云原生解决方案开发。

本书一开始先讲基础知识，让读者了解一些分布式系统的基本原理及其与云原生应用的关系。然后再进一步介绍容器和函数等相关技术。接着，本书介绍服务间的通信模式、服务的弹性和数据模式，并讨论在什么情况下应该使用这些技术。最后，会总结一些经验性的东西，例如如何结合DevOps方法、如何兼顾可移植性，以及一些最佳实践。这些最佳实践对于打造一个成功的云原生应用是非常有帮助的。这本书不会手把手教你如何实现一个满足特定业务需求的云原生应用。但是在读完这本书之后，你应该会知道如何去设计、构建和运维一个成功的云原生应用。在你去实现一些业务需求的时候，操作指南固然很有用，然而系统地理解云原生应用的基本原理和构建方法，才能使你的团队掌握打造成功的云原生应用的能力。

鲍里斯·肖勒（Boris Scholl），是Azure计算团队的产品架构师，专注于下一代分布式系统平台和应用程序模型的研究。自2011年以来，他一直从事Azure开发工具和平台方面的工作，担任不同的产品研发角色。在离开微软18个月之后，Boris于2018年重新加入Azure计算团队，领导一个研发团队开发基于Kubernetes和服务网格的微服务平台。
特伦特·斯旺森（Trent Swanson），是专注于云和边缘技术的软件架构师。作为Full Scale 180的联合创始人和顾问，他与微软的一些大客户合作，帮助他们将应用迁移上云，或在云中构建应用。他一直致力于利用Docker、无服务器技术和微服务架构来设计、构建和运行大型应用程序。
彼得·加索维奇（Peter Jausovec），是一位软件工程师，在软件开发和技术领域拥有十多年的经验。在他的职业生涯中，他曾担任过各种角色。近年来，他一直致力于开发分布式系统上的云原生解决方案。

O'Reilly Media，Inc.，这是一家致力于分享创新知识、改变世界的公司。自40多年前成立以来，它向企业和个人提供成功所需的技能和思想，鼓励他们创新并做得更好。公司核心是专家和创新者网络，通过在线学习平台提供直播培训、图书和视频，帮助客户获取专业知识。O'Reilly的图书和会议被视为技术领域的权威资料，其客户渴望通过创新推动世界进步。业界对O'Reilly的评价极高，认为它是思想领袖聚集的典范，其出版物和会议具有深远的影响力。



O’Reilly Media，Inc.介绍

云计算的兴起和公司“上云”的趋势，尤其是云原生应用的发展。阐述了云原生应用的特点和潜力，以及其在企业业务和运营中的优势。同时，指出了云原生并非万能，而是需要结合云计算、容器、函数计算等技术。最后，强调了本书作为参考手册的作用，帮助读者理解云原生的发展历程、应用场景和最佳实践。



译者序

容器技术已经成为现代应用程序的核心。Docker作为这一领域的代表，通过简化与内核的交互，推动了容器的普及。容器以其轻量级、快速启动和共享数据的优势，显著提升了部署密度。同时，Kubernetes等容器编排工具能动态管理容器生命周期，增强了应用的可靠性和可伸缩性。但在需要更高隔离性的场景，如多租户环境，就需要更高级的虚拟化技术，如Hyper-V容器和沙盒容器。

无服务器架构和函数计算为开发者提供了便捷的应用部署方式，但也带来了供应商锁定等问题。随着技术的发展，虚拟机正逐步向云原生应用转变，这带来了更高的效率和可扩展性。

云原生应用的概念和优势凸显了其相较于传统应用的灵活性、可扩展性和快速迭代能力。其核心是微服务架构，它将应用拆分成小而独立的微服务，便于快速开发和部署。容器技术为微服务提供了轻量级的运行环境，而函数计算则进一步简化了应用开发。

微服务架构的优势包括提高开发效率、降低部署风险、实现快速迭代等。然而，它也带来了一些挑战，如复杂性、数据一致性、性能问题等。书中还介绍了云原生应用的部署和运维工具，如Kubernetes和服务网格，以帮助读者更好地理解和实践云原生应用。

第2章 云原生基础

云原生应用以五大支柱为基础，包括精益运营、安全性、可靠性与可用性、可扩展性与成本。精益运营涉及自动化、监控、文档、增量更改和故障设计；安全性强调纵深防御策略；可靠性与可用性关注应用从故障中恢复的能力；可扩展性与成本关注经济扩容。与传统架构相比，云原生应用的无状态性、事件驱动通信和故障处理方式有所不同。

API版本控制对于资源更新至关重要，允许在不影响其他资源的情况下更新特定资源。基于MIME的版本控制方法通过HTTP头部进行，使API接口更清晰但使用更复杂。实现版本控制需要管理代码以支持多个版本资源，并确保API向后兼容，避免为每个客户维护单独的API版本。同时，消息格式和API文档也应进行版本控制。

在选择通信协议时，应考虑HTTP、WebSockets、HTTP/2和gRPC等，根据性能和需求选择合适的协议。消息协议如MQTT和AMQP在消息传递中也扮演重要角色。序列化选择和幂等性设计对于确保系统稳定性和性能至关重要。请求/响应和发布者/订阅者模式以及同步和异步通信方式的选择也应考虑。

在微服务架构中，API网关用于解决客户端定位服务接入点和应对服务部署及扩展的问题。网关路由请求到后端服务，执行SSL终结、鉴权等任务，并具备聚合请求、卸载后端服务负载等功能。实现网关的技术多样，包括NGINX、HAProxy等，云服务也提供了相应的网关服务。出口网关用于控制内网流量，确保服务安全访问外部资源。

云原生应用架构构建与设计中，服务网格处理微服务通信和提供通用功能至关重要。将通用功能抽象到服务网格中，提升开发效率并实现业务功能与通用功能的分离。文章详细描述了服务网格核心模块——代理的工作原理，包括边车模式和主机模式的优缺点。服务网格还具备流量管理、故障处理、安全性和追踪监控等功能。使用YAML文件定义规则和通过控制层管理数据层也是重要方面。最后，通过智能家居设备管理服务的架构示例，展示了云原生架构在实际应用中的运用。

第3章 云原生应用的设计

随着技术的不断发展，数据存储系统的重要性日益凸显，其多样性也日益增加。在构建应用程序时，选择合适的数据存储产品变得复杂，因为不同的存储系统适用于不同的任务。文章详细介绍了各种数据存储类型，包括对象存储、文件存储、磁盘存储、数据库（如键值数据库、文档数据库、关系型数据库、图数据库等）、流和队列以及区块链。在选择数据存储产品时，需要考虑功能性需求和非功能性需求，如数据格式、读和写操作、数据大小、伸缩性、数据间的关系、一致性模型等。

数据在多个存储系统中分布时，保持数据一致性是一大挑战。我们可以利用数据迁移、事件流等技术来确保跨存储数据的一致性。同时，通过捕获数据更改（CDC）可以有效地进行数据通知、缓存失效、审计、搜索等操作。使用监管服务确保事务成功完成或回退，以及利用事务回滚处理操作失败，是保证数据完整性的重要手段。在数据迁移方面，ETL平台可以将数据从不同系统迁移至便于分析的地方。微服务架构中，数据湖成为了一种常用的数据汇总方式，通过将数据迁移到数据湖，可以满足数据分析的需求。

客户端访问数据时，通常需要通过服务进行授权、审核和转换，以确保数据安全。使用GraphQL数据服务，可以提供灵活的数据访问方式。保证数据可伸缩性方面，数据分片和数据缓存是两种有效的方法。

缓存数据与源数据同步面临挑战，数据更新频繁时，缓存失效和更新变得尤为重要。文章提到了多种缓存失效和更新的方法，包括设置TTL值、使用CDC、实现业务逻辑更新、缓存透传层管理、后端服务定期更新、数据库复制和缓存层自动更新等。内容分发网络（CDN）的概念和作用，以及CDN在减少网页加载时间、提高应用程序性能、加速文件上传等方面的应用，也得到了介绍。

数据分析的发展趋势包括数据流、批处理、对象存储上的数据湖、数据湖和数据仓库、分布式查询引擎等。云服务在数据存储和分析领域的重要性也得到了强调。

第4章 数据处理

DevOps，这是一个涉及软件开发人员与IT专业人员协作和沟通的广泛概念。其核心目标是提升开发与运维团队间的协作，从而优化整个软件开发流程。这包括提升部署频率、缩短产品上市时间、降低故障率等。CALMS模型是评估DevOps团队成熟度的工具，包括协作、自动化、精益、度量和分享五个方面。协作强调关注人员健康和拥抱失败，自动化则强调通过代码管理基础设施，精益原则和流程注重消除流程浪费，度量用于快速发现问题，分享则鼓励积极交流经验。此外，SRE（网站可靠性工程）是DevOps的子集，旨在构建研发团队与运维团队之间的桥梁。



5.1 什么是DevOps

代码在部署到生产环境之前，必须进行全面的测试，特别是在云原生解决方案中，由于高频部署，手动测试难以实现。自动化测试是关键，它能够确保代码质量，满足高频发布的需求。CD（持续交付）是实现自动化的手段之一，测试任务也是CD流程的一部分。对于云原生解决方案，测试准备工作因函数服务而异，需要根据其触发机制和返回值来设计测试策略。测试替身，如模拟、伪造和桩，在自动化测试中发挥着重要作用。自动化测试金字塔包括单元测试、服务测试和UI测试，其中单元测试是最基础的。此外，还有Jepsen测试、性能测试、负载测试、安全和渗透测试等多种测试类型。根据CI/CD阶段，应运行不同类型的测试，确保代码质量和系统稳定性。在生产环境中进行测试也是可行的，但需要投入和风险评估。



5.2 测试

开发环境和工具的演变，从传统本地环境到如今的微服务架构和无服务器计算。随着新工具的出现，云端开发环境逐渐变得便利，并支持协作和测试环境的一致性。团队需要结合本地和云端环境，例如在本地编写代码，然后推送到云端环境进行测试。介绍了各种开发工具，如MiniKube、Docker、Docker Compose等，它们能帮助在本地运行Kubernetes集群。同时，Skaffold、Draft、KSync等工具能简化代码改动推送到远程环境的过程。Telepresence工具则可以将本地服务与远程Kubernetes集群无缝连接。云端开发环境提供了集成开发环境，如Eclipse Che，使开发人员可以连接到云中运行的开发机，方便创建新的开发环境。



5.3 开发环境和工具

持续集成/持续交付（CI/CD）这一软件开发流程，强调了其在自动化构建、测试和集成代码中的重要性。CI/CD流程包括持续集成、持续交付和持续部署三个阶段，旨在确保代码质量，提高开发效率。其中，持续集成阶段通过自动化构建和测试，确保代码合并到主分支前通过所有测试；持续交付阶段则进一步测试代码，确保其随时可以发布到生产环境；而持续部署阶段则专注于自动化部署，减少人工介入。此外，文章还探讨了源代码管理、构建、测试、部署和发布等环节，并强调了容器镜像构建、服务监控等因素在CI/CD流程中的重要性。



5.4 持续集成/持续交付

”
在持续集成/持续部署（CI/CD）流程中，监控扮演着至关重要的角色，尤其是在发布阶段。文中深入讨论了故障率、请求速率、延迟和利用率等关键性能指标。当这些指标出现异常时，应立即暂停发布并执行回滚操作。Prometheus作为一种开源监控工具，能有效地抓取应用程序的指标数据。它能够通过简单的配置自动抓取部署在Kubernetes平台上的应用数据。

文章详细介绍了使用Prometheus抓取数据的方法，包括配置Prometheus服务、创建ConfigMap资源、部署Prometheus服务以及创建Kubernetes服务以访问Prometheus实例。此外，Prometheus的告警功能也被提及，包括如何定义告警规则，以便在服务出现问题时能够及时通知相关人员处理问题。

Prometheus的核心功能在于其数据抓取能力。它能够通过客户端库和推送网关等方式收集指标数据，并将其展示出来。例如，配置Prometheus服务时，需要指定数据源，如Kubernetes集群中的Pods或Services。创建ConfigMap资源是为了存储Prometheus的配置文件，而部署Prometheus服务则是在Kubernetes集群中运行Prometheus实例。

告警功能是Prometheus的另一大亮点。通过定义告警规则，系统可以自动检测到关键指标异常，并触发告警。告警规则通常基于阈值和匹配条件，当指标值超过设定阈值或满足特定条件时，系统将发送告警通知。

分布式链路追踪技术，如Jaeger，在监控分布式系统中的服务调用链方面也发挥着重要作用。通过Jaeger等工具，可以追踪请求从源头到目标服务器的整个流程，分析性能瓶颈和故障点。

总之，Prometheus在CI/CD流程中的监控作用不可忽视。它不仅能够帮助开发者及时发现问题，还能提高系统稳定性和可用性。通过合理配置和使用Prometheus，可以确保应用程序在Kubernetes等容器化环境中高效运行。

5.5 监控

配置管理的重要性，强调了服务或函数配置的全面性，包括连接字符串、凭据、超时等。为了适应不同环境，代码和配置应严格分离。文章提到使用环境变量或配置文件组织环境变量，并推荐了Kubernetes中的ConfigMap资源来保存配置。此外，还介绍了如何使用ConfigMap、环境文件和环境变量在Pod中使用配置，以及如何使用Secret资源来存储敏感信息。最后，讨论了使用Helm进行部署配置管理，并提及了云原生应用捆绑包（CNAB）的作用。



5.6 配置管理

基于提供的上下文，以下是对持续集成/持续交付（CI/CD）流程的步骤和描述的总结：

1. **代码完成**：代码编写完成。
2. **推送至Git**：将代码提交并推送到代码仓库。
3. **获取代码**：构建系统获取最新代码。
4. **源代码分析**：执行静态代码分析。
5. **构建容器**：编译源代码并打包到容器中。
6. **单元和服务测试**：运行测试，失败则流程终止。
7. **推送到私有注册服务器**：将构建好的镜像推送到私有注册服务器。
8. **镜像安全扫描**：对镜像进行安全扫描。
9. **测试配置**：运行配置测试，失败则流程终止。

如果部署到预发布环境：
1. **部署到k8s**：将容器部署到Kubernetes。
2. **集成测试**：执行集成测试。
3. **回滚**：失败则回滚，流程终止。
4. **发布**：通过则发布到预发布环境。
5. **发布到生产环境**：渐进式发布到生产环境。

如果部署到生产环境：
1. **部署到k8s**：将容器部署到Kubernetes。
2. **持续金丝雀测试**：持续运行测试以发现潜在问题。
3. **渐进式发布**：缓慢增加流量到新版本。
4. **遥测**：持续监控指标，确保流程正常。
5. **发布**：流量完全导向新版本。

这个过程展示了CI/CD流程的典型步骤，包括代码的提交、测试、部署和监控等。每个步骤都至关重要，以确保应用的稳定性和可靠性。



5.7 持续集成/持续交付流程示例

DevOps基础知识及其价值，并分享了评估组织成熟度的实例。深入探讨了云原生环境下的测试意义，列举了不同测试类型及其执行时机。本章还介绍了在生产环境中进行测试的重要性，以及相应的工具和CI/CD工作流程，旨在帮助读者搭建开发环境，实施监控和追踪措施，并完成服务和部署的配置。



5.8 本章小结

第5章 DevOps

迁移传统应用至云原生应用的过程，需首先评估应用的重构需求。这涉及对代码库规模、组件扩展需求和技术更新的考量。随后，建议逐步解耦简单服务，以小规模运维模式进行，并采用防损层模式解决新旧服务兼容问题。

在迁移过程中，要关注数据迁移策略、代码重构、技术选型及淘汰老代码。同时，确保应用具备弹性、安全性和数据处理最佳实践，如利用托管数据库、缓存技术、分区和复制等。

此外，引入函数计算时，应遵循最佳实践，如编写单一用途函数，避免函数串联。在开发云原生应用时，需关注函数设计原则，如保持轻量、简单、无状态，并通过消息队列实现函数间通信。

运维方面，要区分部署和发布，实施小规模化部署内容，配置CI/CD组件层级。在日志、监控和告警方面，推荐使用统一日志系统、关联ID和结构化日志格式。同时，针对服务通信和容器使用，提出一系列最佳实践。

第6章 最佳实践

软件的可移植性在当今时代变得至关重要，它源于应用需要在多种不同环境中部署，以及追求最小化延迟和跨云端运行的需求。然而，追求这一特性并非没有代价，它涉及到运营成本、基础设施成本和工程成本等多个方面。

在实现软件可移植性的过程中，标准化接口、容器技术、共用服务和功能、抽象和分层等策略是不可或缺的。第三方服务商提供的托管服务，如Auth0和MongoDB Atlas，能有效降低运营成本，并提高可移植性。

云原生应用的可移植性成为了一个关键特性。然而，使用第三方托管服务可能面临计费集成问题，并可能无法与云服务商的其他服务完全集成。为解决这些问题，开发者可以利用Serverless Framework等可移植性工具，它们提供了抽象层，使得应用能够在不同云服务商之间轻松迁移。同时，使用Terraform等基础设施管理工具，可以帮助开发者创建和管理多个云平台上的基础设施。Kubernetes作为可移植性层，可以在云服务商的基础架构上搭建一层抽象层，使得应用程序能够以相同的方式部署和管理。

尽管这些方法简化了资源管理任务，但也带来了一些额外的负担，如性能影响和特定功能限制。在追求可移植性的同时，开发者需要权衡这些因素，以确保应用能够满足业务需求。

总结来说，软件的可移植性是现代软件开发中不可忽视的一环。通过采用合适的策略和工具，开发者可以降低成本、提高效率，同时应对日益复杂的多云环境。然而，在这一过程中，开发者需要仔细权衡各方面因素，以确保最终的应用能够满足需求。