前言

绝大多数企业的软件架构都是从一个单体架构开始的，而不是微服务架构。因为单体架构足够简单、容易上手，不需要复杂的流程就可以快速开发应用程序。但是伴随着企业的成长，单体架构的风险就会逐渐凸显出来。在需求量激增的情况下，整个应用程序会因为某一部分或者某一进程遇到瓶颈而受到限制。此外，因为单体架构的紧耦合设计，应用程序也面临着可用性上的挑战，面对日益复杂的失误处理几乎无法持续扩展，并且在构建、部署和测试等流程上都变得非常困难。

然而对企业来说影响更大的一点是，单体架构严重阻碍了创新发展。

因此，企业会在发展过程中逐渐转向微服务架构，将应用程序拆分成多个“微”小的服务运行。这些微服务都是面向业务功能或者某个子领域进行构建的，每个微服务实现一个单独的功能。微服务的理念也提倡每个服务分别由小型的、独立的团队进行开发并负责管理，所以说这不仅是技术管理上的更新，更是企业组织管理上的变革。

但是谈论微服务是一回事，能够真正地落地实施则是另一回事。本文旨在提供关于这方面的参考，全面地介绍了如何进行微服务的开发，并尽可能地从各个维度对其进行描述。从微服务的架构设计、构建、配置、测试、监控、安全，到持续集成/持续交付(CICD)流水线，本文都进行了积极的探索，并提供了详细的 Go 示例代码进行说明。

另一方面，所有上述内容的实现都是结合 Kubernetes 完成的。众所周知，Kubernetes 是目前最流行的开源平台之一，主要用于在集群中自动化应用程序容器的编排，包括部署、扩展和维护等。Kubernetes 提供了一个以容器为中心的基础设施框架，如今你很难找到一项没有(或者没有打算)和 Kubernetes 进行集成的新技术。除此之外，本文也涉及无服务器计算和服务网格这些热门话题，探讨了它们是如何发挥各自的优势为基于微服务的系统提供帮助的，并分别通过开源项目 Nuclio 和 Istio 进行了具体的说明。

希望读完本文后，你可以获得基于 Kubernetes 与微服务的云原生系统的设计、开发及管理的知识和经验。

目录

主要内容

第 1 章面向开发人员的 Kubernetes 简介；在本章中，我们带你进行了一番 Kubernetes 旋风之旅，并了解了它与微服务的融合。Kubernetes 的可扩展架构使得大型企业组织、初创公司和开源组织社区能够一起协作，围绕 Kubernetes 创建一个生态体系，从而扩大收益并确保可持续发展。Kubernetes 内置的概念和抽象非常适合基于微服务的系统，它们支持软件开发生命周期的每个阶段——从开发、测试、部署，一直到监控和故障排除。

Minikube 项目让每个开发人员都能够在本地运行 Kubernetes 集群，这非常适合了解 Kubernetes 自身的功能和特性，并且可以在与生产环境非常相似的环境中进行本地测试。

Helm 项目是 Kubernetes 的绝佳补充，作为软件包管理解决方案为用户提供了巨大价值。在下一章中，我们将深入研究微服务领域，并了解为什么微服务是在云中开发复杂、快速迭代的分布式系统的最佳方法。

第 2 章微服务入门；本章我们讨论了很多问题。首先是微服务的基本原理——少即是多，以及如何将系统分解为许多小型的、自包含的微服务来帮助其扩展。我们还讨论了使用微服务架构的开发人员所面临的挑战。我们提供了大量关于构建基于微服务的系统的概念、选项、最佳实践和实用建议。在这一点上，你应该理解微服务提供的灵活性，但也需要你谨慎选择使用它们的多种方式。

第 3 章示例应用程序——Delinkcious；

• 3.1 技术需求

• 3.2 为什么选择 Go

• 3.3 认识 Go kit

• 3.4 Delinkcious 目录结构

• 3.5 Delinkcious 微服务

• 3.6 数据存储

• 3.7 小结

• 3.8 扩展阅读

第 4 章构建 CI/CD 流水线；

• 4.1 技术需求

• 4.2 理解 CI/CD 流水线

• 4.3 选择 CI/CD 流水线工具

• 4.4.1 Jenkins x

• 4.4.2 Spinnaker

• 4.4.3 Travis Cl 和 CircleCl

• 4.4.4 Tekton

• 4.4.5Argo CD

• 4.4.6 自研工具

• 4.4 GitOps

• 4.5 使用 CircleCI 构建镜像

• 4.6 为 Delinkcious 设置持续交付

• 4.7 小结

• 4.8 扩展阅读

第 5 章使用 Kubernetes 配置微服务；在本章中，我们讨论了与配置有关的所有内容(不包括密钥管理)。首先是传统配置方法，然后研究了动态配置,重点是远程配置存储和远程配置服务。

接下来，我们讨论了 Kubernetes 特有的一些选项，重点介绍了 ConfigMap。我们介绍了创建和管理 ConfigMap 的方法，还有 Pod 如何将 ConfigMap 用作环境变量(静态配置)或者作为文件挂载卷，当运维工程师修改相应的 ConfigMap 时，它们会自动更新。最后，我们研究了一些更强大的选项如自定义资源，并讨论了服务发现这个特殊但非常重要的功能。到目前为止，你应该基本理解了配置，并且可以使用传统的方式或以 Kubernetes 特有的方式配置微服务。

第 6 章 Kubernetes 与微服务安全；在本章中，我们认真研究了一个严肃的主题:安全性。基于微服务的架构和 Kubernetes 对于支持关键任务目标并经常管理敏感信息的大型企业分布式系统来说非常有意义。除了开发和发展此类复杂系统所面临的挑战之外，我们还必须意识到，此类系统为攻击者提供了非常诱人的目标。

我们必须使用严格的流程和最佳实践来保护系统、用户和数据。首先，我们介绍了安全性原则和最佳实践，并且还看到了它们如何相互支持，以及 Kubernetes 如何致力于应用它们来支持我们安全地开发和维护系统。

我们还讨论了作为 Kubernetes 上微服务安全性基础的支柱:认证/授权/准入、集群内部和外部的安全通信、强大的密钥管理(存储加密和传输加密）以及分层安全策略。

此时，你应该对安全机制有了清晰的了解，并有足够的信息来决定如何将它们集成到系统中。安全性是个持续的话题，但是利用最佳实践将使你在每个时间点都能在安全性与系统其他要求之间找到适当的平衡。

第 7 章 API 与负载均衡器；

• 7.1 技术需求

• 7.2 熟悉 Kubernetes 服务

• 7.3 东西流量与南北流量

• 7.4 理解 ingress 和负载均衡器

• 7.5 提供和使用公有 REST API

• 7.6 提供和使用内部 gRPC API

• 7.7 通过消息队列发送和接收事件

• 7.8 服务网格

• 7.9 小结

• 7.10 扩展阅读

第 8 章有状态服务；

• 8.1 技术需求

• 8.2 抽象存储

• 8.3 在 Kubernetes 集群外存储数据

• 8.4 使用 Statefulset 在 Kubernetes 集群内存储数据

• 8.5 通过本地存储实现高性能

• 8.6 在 Kubernetes 中使用关系型数据库

• 8.7 在 Kubernetes 中使用非关系型数据存储

• 8.8 小结

• 8.9 扩展阅读

第 9 章在 Kubernetes 上运行 Serverless 任务；在本章中，我们介绍并实现了 Delinkcious 的链接检查。首先，我们讨论了 Serverless 场景，包括它的两种常见含义，即不处理实例、节点或服务器，使用云函数服务。然后，我们在 Delinkcious 中实现了一个松耦合的解决方案以进行链接检查，该解决方案利用了我们的 NATS 消息系统在检查链接时分发事件。然后，我们介绍了 Nuclio，并用它来完成 ServerIss 函数的管理，让 LinkManager 在 Serverless 函数上启动链接检查，并在以后收到通知时可以更新链接状态。

最后，我们研究了 Kubernetes 上许多其他 Serverless 函数解决方案和框架。此时，你应该对 Serverless 计算和 Serverless 函数的内容有了深入的了解。你应该能够就你的系统和项目是否可以从 Serverless 函数中受益，以及采用哪种解决方案最合适做出明智的决定。显然，Serverless 计算的好处是实实在在的，并且这不是一种昙花一现的时尚。我预计 Kubernetes 中的 Serverless 解决方案最终将会合并到一起(可能围绕 KNative)，并且将成为大多数 Kubernetes 部署的基石，即使它们不是核心 Kubernetes 的一部分。

第 10 章微服务测试；在本章中，我们讨论了测试的主题及其各种风格:单元测试、集成测试和各种端到端测试，我们还深入研究了测试是如何构建的。我们演示了链接管理器单元测试，添加了一个新的冒烟测试，并引入了 Telepresence，以便在本地修改代码的同时，针对实际的 Kubernetes 集群加速编辑–测试–调试生命周期。

然而，测试也是有成本的，一味盲目地添加越来越多的测试并不能使你的系统变得更好或者具有更高的质量。在测试的数量和质量之间有许多重要的权衡，例如开发和维护测试所需的时间、运行测试所需的时间和资源，以及测试早期发现的问题的数量和复杂性。你应该有足够的环境来为你的系统做出这些艰难的决定，并选择最适合你的测试策略。

同样重要的是要记住测试会随着系统的发展而变化，当风险越来越高时，即使对于同一组织，测试水平也必须要提高。如果你是一个业余开发人员，拥有一个测试版产品并且只有几个非正式的测试用户，你可能不需要那么严格的测试（除非它能节省你的开发时间)。但是，随着公司的发展，用户逐渐聚集，更多的人使用你的产品进行关键任务应用程序，代码中出现问题产生的影响会促使系统需要更严格的测试。

第 11 章微服务部署；

• 11.1 技术需求

• 11.2 Kubernetes 部署

• 11.3 多环境部署

• 11.4 理解部署策略

• 11.5 回滚部署

• 11.6 管理版本和依赖

• 11.7 本地开发部署

• 11.8 小结

• 11.9 扩展阅读

第 12 章监控、日志和指标；

• 12.1 技术需求

• 12.2 Kubernetes 的自愈能力

• 12.3 Kubernetes 集群自动伸缩

• 12.4 使用 Kubernetes 供应资源

• 12.5 正确地优化性能

• 12.6 日志

• 12.7 在 Kubernetes 上收集指标 12.8 警报

• 12.9 分布式跟踪

• 12.10 小结

• 12.11 扩展阅读

第 13 章服务网格与 lstio；在本章中，我们讨论了服务网格，并重点介绍了 Istio。Istio 是一个复杂的项目，它构建在 Kubernetes 之上，并使用代理创建了一个影子集群。Istio 具有出色的功能，它可以在非常细粒度的级别进行流量整形，还能提供复杂的认证和授权、实施高级策略、收集大量信息并帮助集群扩展。

我们介绍了 Istio 架构及其强大的功能，并探讨了 Delinkcious 如何从这些功能中获益。然而，想用好 Istio 一点也不简单。它创建了大量的自定义资源，并以复杂的方式扩展了现有的 Kubernetes 资源(与 Kubernetes 服务对应的虚拟服务)。

我们还介绍了 Istio 的替代方案，包括 Linkerd 2.0、Envoy、AWS App Mesh 和 Consul。此时，你应该对服务网格的好处以及 Istio 能给你的项目带来什么帮助有了一个很好的了解。至于是否应该立即将 Istio 集成到你的系统中，还是考虑替代方案之一，或者再观望一段时间，你可能还需要一些额外的阅读和实验，以便做出更明智的决策。

我相信服务网格尤其是 Istio 将会变得非常重要，并将成为大型 Kubernetes 集群的标准最佳实践。

第 14 章微服务和 Kubernetes 的未来；在本章中，我们讨论了微服务和 Kubernetes 接下来的发展方向。种种迹象表明，微服务和 Kubernetes 将继续成为设计、构建、发展和运行云原生、大规模、分布式系统的主要因素。这是个好消息。小型程序、脚本和移动应用程序并不会消失，但后端系统将变得庞大，能够处理更多的数据，并将覆盖我们生活中的方方面面。虚拟现实、传感器和人工智能等技术将需要处理和存储越来越多的数据。

在微服务领域的短期发展中,gRPC 将成为一种流行的服务间通信传输工具和公共接口。Web 客户端将能够通过用于 Web 的 gRPC 技术使用 gRPC。与 REST API 相比，GraphQL 是另一项重大改进。业界仍然需要一些时间来理解如何设计和构建基于微服务的架构，构建单个微服务非常简单，但建立一个协调的微服务系统是另一回事。容器和 Kubernetes 解决了基于微服务的架构存在的一些难题。服务网格等新技术将很快获得关注，无服务器计算帮助开发人员更快地部署和更新应用程序。容器和虚拟化的合并将带来更安全的系统。Operator 将把更大、更有用的构建块管理变成现实。集群联邦将成为可扩展系统的新领域。

此时，你应该对这些技术未来的发展有了自己的认识。这些知识将使你能够提前计划，并就当前要投资的技术以及哪些技术需要进一步成熟做出自己的评估。

简而言之，我们正处于一个激动人心的新时代的开端，我们将学习如何构建前所未有的规模的可靠系统。希望你能够继续努力，掌握这些惊人的技术，构建自己的系统，并为社区做出自己的贡献。

这份【Kubernetes 微服务实战】文档共有 377 页，需要完整版的小伙伴，可以转发此文关注小编，**点击这里，获得文档领取方式**