qq_29434541的博客

治理是指让系统能够符合预期地稳定运行，并能够持续保持在一定的质量水平上​​。治理的核心是确保系统的正确执行和持续保持。治理分为静态治理和动态治理两部分。静态治理：确保系统能够按照预期正常运行。这需要在系统设计和实现阶段采取措施，保证系统的结构和行为符合设计规范和业务需求。动态治理：确保系统能够在运行过程中持续保持一定的质量水平。这需要在系统运行阶段采取措施，监控系统的状态，发现并解决问题，保证系统的稳定性和可靠性。微服务架构的治理涉及系统设计、实现和运行的各个阶段。

微服务的粒度设计是微服务架构中的一个关键问题。合理的微服务粒度应该满足独立、内聚和完备的要求，同时应考虑团队规模和研发周期的实际情况。通过领域驱动设计的方法论，架构师可以更好地识别和划分微服务边界，确保系统的灵活性、可维护性和高效性。

微服务架构的实施不仅需要技术上的准备，更需要组织结构、团队文化和管理模式的调整。通过满足上述前提条件，企业可以更好地规划和实施微服务架构，从而提升系统的灵活性、可维护性和整体性能。成功的微服务转型需要清晰的组织结构、高效的沟通机制、强大的技术基础、成熟的团队、完善的自动化与监控体系以及合理的复杂性管理策略​​。

微服务架构的九个核心特征为系统的灵活性、独立性和可扩展性提供了强有力的支持。通过围绕业务能力构建、独立部署、去中心化治理和数据管理、自动化基础设施、容错性设计和演进式设计，微服务架构能够有效应对复杂分布式系统的挑战，提升系统的整体性能和维护效率​​。

微服务架构的驱动力主要来自于其灵活性、独立部署、技术异构性、团队效率和系统弹性等方面的优势。通过理解这些驱动力，企业可以更好地规划和实施微服务架构，从而提升系统的整体性能和维护效率​​。

服务网格作为一种新兴的分布式系统通信解决方案，通过引入数据平面和控制平面，提供了统一的流量管理、安全、监控和可观测性功能。尽管服务网格带来了许多优势，如提高可观测性、安全性和灵活性，但也伴随着一定的复杂性和性能开销。因此，在引入服务网格之前，开发团队需要充分评估其带来的收益和挑战，选择最适合自身业务需求的实现方案。通过遵循最佳实践，逐步迁移、合理划分服务、优化性能、加强安全性和完善监控，开发团队可以充分利用服务网格的优势，提高系统的稳定性和可靠性。

服务网格（Service Mesh）是一种基础设施层，专门用于处理服务间的通信。它通过在服务间引入一个轻量级的代理层，来统一管理服务之间的网络流量、认证和授权、安全、监控等功能。服务网格的核心组件包括数据平面和控制平面。服务网格作为一种新兴的分布式系统通信解决方案，通过引入数据平面和控制平面，提供了统一的流量管理、安全、监控和可观测性功能。尽管服务网格带来了许多优势，如提高可观测性、安全性和灵活性，但也伴随着一定的复杂性和性能开销。

第十四章详细介绍了Kubernetes的资源模型、服务质量与优先级、驱逐机制和默认调度器。这些机制共同构成了Kubernetes高效、灵活的资源调度体系，确保了集群的稳定性和性能。通过对物理资源的精细管理和调度算法的优化，Kubernetes能够在大规模集群中高效运行，满足各种复杂应用的需求。

持久化存储是容器化应用的重要组成部分。Kubernetes通过静态和动态存储分配机制、丰富的存储插件生态系统，提供了强大的持久化存储支持。无论是块存储、文件存储还是对象存储，Kubernetes都能通过灵活的存储架构和扩展机制，满足不同应用场景的需求，确保数据的可靠性和持久性。Kubernetes的存储设计不仅提升了存储管理的效率和灵活性，还为云原生应用的发展提供了坚实的基础。

通过Linux网络虚拟化技术和容器网络插件，现代分布式系统实现了高效、灵活的网络通信。无论是通过虚拟网卡和虚拟交换机实现的本地通信，还是通过VXLAN和CNI插件实现的跨主机通信，容器网络为云原生应用提供了强有力的支持。通过Flannel、Calico、Weave等CNI插件，用户可以根据实际需求选择合适的网络解决方案，构建高效可靠的容器网络生态系统。

本文讲解虚拟化容器技术的发展及其在现代计算架构中的应用。内容分为三个主要部分：容器的崛起、以容器构建系统、以应用为中心的封装。以下是对每个知识点的详细描述。通过容器技术的不断发展和创新，现代计算架构在灵活性、可扩展性和可靠性方面取得了显著进步。从chroot到cgroups和namespaces，再到Docker和Kubernetes，容器技术为构建高效的分布式系统提供了坚实的基础。

除了常见的应用级和系统级指标，还可以根据具体需求定义和收集自定义的指标数据。例如，在电商系统中，可以收集每分钟的订单数、每秒的支付成功率等业务指标。

事件日志是分布式系统可观测性的重要组成部分。通过科学合理的日志输出、收集、缓冲、加工、聚合和存储查询，可以实现对系统运行状态的实时监控和问题排查。上述方法和技术，不仅适用于大规模分布式系统，也可以为中小型系统提供有效的解决方案。通过实际案例的分析，可以看到这些技术在提升系统可观测性方面的显著效果，为系统的稳定运行保驾护航。

链路追踪是分布式系统可观测性的重要组成部分。通过科学合理的追踪和数据收集，可以实现对系统请求流转过程的实时监控和分析。

我们已经了解了与具体架构形式无关的业界主流安全概念和技术标准（如TLS、JWT、OAuth 2等概念），在上一章节探讨了与微服务运作特点相适应的零信任安全模型。在本节中，我们将从实践和编码的角度出发，介绍在微服务时代（以Spring Cloud为例）和云原生时代（以Istio over Kubernetes为例）分别如何实现安全传输、认证和授权。通过这两者的对比，我们将探讨在微服务架构下如何将业界的安全技术标准引入并实际落地，实现零信任网络下安全的服务访问。

任何一个系统的运算、存储、网络资源都不是无限的，当系统资源不足以支撑外部超过预期的突发流量时，便应该有所取舍，建立面 对超额流量自我保护的机制，这个机制就是微服务中常说的“限 流”。最大处理能力为80TPS的系统遇到100 TPS的请求时，应该能完成其中的80TPS，也即有20 TPS的请求失败或被拒绝才对，这是最理想的情况，也是我们追求的目标。

容错性设计（Design for Failure）是微服务的另一个核心原 则，也是笔者书中反复强调的开发观念转变。不过，即使已经有一定 的心理准备，大多数首次将微服务架构引入实际生产系统的开发者， 在服务发现、网关路由等支持下，踏出了服务化的第一步以后，很可 能仍会经历一段阵痛期，随着拆分出的服务越来越多，随之而来会面 临以下两个问题的困扰。本章我们将围绕以上两个问题，提出服务容错、流量控制等一系列解决方案。

客户端负载均衡（Client-Side Load Balancing）是指将负载均衡的逻辑从服务器端转移到客户端，使得客户端在发送请求之前决定将请求发送到哪个服务实例。这种模式相较于传统的服务器端负载均衡有许多优点，例如减少网络开销、避免单点故障等。在传统的服务器端负载均衡模式下，所有的请求都先发送到一个负载均衡器，由它来决定将请求转发到哪个服务实例。这种方法的缺点是负载均衡器本身可能成为单点故障，且在高并发场景下容易成为系统瓶颈。

网关路由在分布式系统和微服务架构中扮演着至关重要的角色。它不仅作为不同服务之间的通信桥梁，还承担着流量管理、安全控制和其他重要职能。路由：将外部请求路由到内部服务。网关根据预定义的规则或策略，决定如何处理和转发客户端请求。安全性：提供身份验证和授权控制。通过集成OAuth、JWT等机制，确保只有经过认证和授权的用户才能访问服务。流量管理：实现负载均衡、限流等功能。通过智能路由和流量分配，优化系统资源使用，防止单点过载。监控：记录和分析请求和响应数据。通过日志和监控系统，提供系统健康状态和性能指标。

微服务架构的一个重要设计原则是“通过服务来实现独立自治的 组件”（Componentization via Service），强调应采用“服务” （Service）而不是“类库”（Library）来构建组件化的程序，这两 者的差别在于类库是在编译期静态链接到程序中的，通过调用本地方 法来使用其中的功能，而服务是进程外组件，通过调用远程方法来使 用其中的功能。

在正式探讨分布式环境中面临的各种技术问题和解决方案前，我 们先把目光从工业界转到学术界，学习几种具有代表性的分布式共识 算法，为后续在分布式环境中操作共享数据准备好理论基础。下面笔 者从一个最浅显的场景开始，引出本章的主题：如果你有一份很重要的数据，要确保它长期存储在电脑上不会丢 失，你会怎么做？这不是什么脑筋急转弯的古怪问题，答案就是去买几块硬盘，在 不同硬盘上多备份几个副本。

我们从JWT令牌的一小段“题外话”来引出现代密码学算法的三种 主要用途：摘要、加密与签名。JWT令牌携带信息的可信度源自于它是 被签过名的信息，是令牌签发者真实意图的体现，因此是不可篡改 的。然而，你是否了解签名具体做了什么？为什么有签名就能够让负 载中的信息变得不可篡改和不可抵赖呢？要解释数字签名（Digital Signature），必须先从密码学算法的另外两种基础应用“摘要”和 “加密”说起。摘要也称为数字摘要（Digital Digest）或数字指纹（Digital Fingerprint）。

为系统引入缓存之前，第一件事情是确认系统是否真的需要缓 存。从开发角度来说，引入缓存会提 高系统复杂度，因为你要考虑缓存的失效、更新、一致性等问题；从运维角度来说，缓存会掩盖一些缺 陷，让问题在更久的时间以后，出现在距离发生现场更远的位置上；从安全角度来说，缓存可能会泄漏某些保密数据，也是容易受到攻击 的薄弱点。冒着上述种种风险，仍能说服你引入缓存的理由，总结起 来无外乎以下两种。

在互联网时代的早期，网站流量还相对较小，业务也相对简单， 单台服务器便可满足访问需要，但时至今日，互联网应用也好，企业 级应用也好，一般实际用于生产的系统，几乎都离不开集群部署。信 息系统不论是单体架构多副本还是微服务架构，不论是为了实现高可 用还是为了获得高性能，都需要利用多台机器来扩展服务能力，希望 用户的请求不管连接到哪台机器上，都能得到相同的处理。

客户端缓存机制通过减少重复数据传输，提高了网络性能。强制缓存通过时间有效性假设，协商缓存通过变化检测机制，二者互补，共同实现了HTTP协议下高效的缓存管理。这些缓存机制是透明多级分流系统的一部分，提升了分布式系统的性能和可靠性。

事务处理几乎在每一个信息系统中都会涉及，它存在的意义是为 了保证系统中所有的数据都是符合期望的，且相互关联的数据之间不 会产生矛盾，即数据状态的一致性（Consistency）。按照数据库的经 典理论，要达成这个目标，需要三方面共同努力来保障。以上四种属性即事务的“ACID”特性，但笔者对这种说法其实不 太认同，因为这四种特性并不正交，A、I、D是手段，C是目的，前者 是因，后者是果，弄到一块去完全是为了拼凑个单词缩写。事务的概念虽然最初起源于数据库系统，但今天已经有所延伸， 不再局限于数据库本身了。

远程服务将计算机程序的工作范围从单机扩展至网络，从本地延 伸至远程，是构建分布式系统的首要基础。而远程服务又不仅仅是为 分布式系统服务的，在网络时代，浏览器、移动设备、桌面应用和服 务端的程序，普遍都有与其他设备交互的需求，所以今天已经很难找 到没有开发和使用过远程服务的程序员了，但是没有正确理解远程服 务的程序员却不少。

所谓的“后微服务时代”指的是在微服务架构广泛应用并成熟之后，行业开始探索更进一步的架构模式和技术，以解决微服务在实际应用中遇到的一些挑战，如服务管理的复杂性、数据一致性问题、服务间通信的开销等。在后微服务时代，人们探讨和采纳了一些新的概念和技术，以优化和超越传统微服务架构的限制。