前言
大多数企业的软件体系结构都是从单一体系结构开始的，而不是从微服务体系结构开始的。由于单一体系结构足够简单且易于使用，因此可以快速开发应用程序，而无需复杂的过程。但是，随着企业的成长，单一架构的风险将逐渐凸显。当需求激增时，整个应用程序将受到限制，因为一部分或一个流程会遇到瓶颈。此外，由于单一架构的紧密耦合设计，应用程序也面临可用性挑战。面对日益复杂的错误处理，它们很难继续扩展，并且在构建、部署和测试过程中变得非常困难。
然而对企业来说影响更大的一点是，单体架构严重阻碍了创新发展。
因此，企业会在发展过程中逐渐转向微服务架构，将应用程序拆分成多个“微”小的服务运行。这些微服务都是面向业务功能或者某个子领域进行构建的，每个微服务实现一个单独的功能。微服务的理念也提倡每个服务分别由小型的、独立的团队进行开发并负责管理，所以说这不仅是技术管理上的更新，更是企业组织管理上的变革。
但是谈论微服务是一回事，能够真正地落地实施则是另一回事。本文旨在提供关于这方面的参考，全面地介绍了如何进行微服务的开发，并尽可能地从各个维度对其进行描述。从微服务的架构设计、构建、配置、测试、监控、安全，到持续集成/持续交付(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页，有需要的朋友，可以点赞收藏查看主页来获取！