终于学完了阿里 P8 架构师 7 年心血整理总结的微服务实战文档
在过去 5 年中，微服务架构风格(通过一系列细粒度的、松耦合的、可以独立部署的服务来组织应用)变得越来越流行。且不论公司规模多大，单就工程团队来说，微服务也变得越来越可行。
本文主要介绍与微服务应用开发和部署相关的内容，并辅以实际示例来引导读者体验从设计到部署微服务的全过程。
通过学习本文的内容，读者将了解如何进行微服务应用的开发和部署、如何通过微服务来实现有效的持续交付，以及如何用 Kubernetes、Docker 和 Google Container Engine 开发实例。
本文适合了解企业级应用架构和云平台(如 AWS 和 GCP)的中级开发人员和架构师阅读,也适合对微服务感兴趣的读者参考。
本文内容的目录
主要内容
本文总共有 13 章的内容，带领大家彻底解读微服务实战，因为内容过多，只能把部分知识点拿出来给大家介绍，希望大家能够理解和喜欢！！
第 1 章 微服务的设计与运行；
(1)微服务既是一-种架构风格，也是一系列文化习惯的集合。它以五大核心原则为支撑，它们分别是自治性、可恢复性、透明性、自动化和一-致性。
(2)微服务减少了开发冲突，实现了自治性、技术灵活性以及松耦合。
(3)微服务的设计过程是非常有挑战性的，因为它不仅需要丰富的业务领域知识，还需要开发者在团队之间平衡优先级。
(4)服务向其他服务暴露契约。设计良好的契约是简洁的、完整的和可预测的。
(5)在长期运行的软件系统中，复杂性是不可避免的，但是开发者可以通过-一些决策来减少冲突和风险，进而持续地在这些系统中交付价值。
(6)自动化和可验证的发布操作能够让部署过程更加可靠和“没有事故发生”，进而降低微服务的风险。
(7)容器技术将运行环境中的服务之间的差异进行抽象化，简化了对类型各异的微服务进行大规模管理的方式。
(8)故障是不可避免的:对团队来说，微服务需要是透明的、易观测的，这样团队才能够主动地管理、了解和真正拥有服务运维;反之亦然。
(9)采用微服务的团队需要在运维方面比较成熟，并且关注于服务的整个生命周期，而不只是关注设计和开发阶段。
第 2 章 SimpleBank 公司的微服务；
(1)微服务非常适合于有多维复杂性的系统，比如产品的供应范围、全球部署和监管压力。
(2)在设计微服务时，了解产品业务领域是至关重要的。
(3)服务交互可以是编配型的，也可以是编排型的。后者会增加系统复杂度，但是能够降低系统中服务之间的耦合度。
(4) API 网关是一-种常 见的模式，它将微服务架构的复杂性进行了封装和抽象，所以前端或者外部消费者不需要考虑这部分复杂度。
(5 )如果开发者充分信任自己的服务能够处理生产环境上的流量压力，就可以说这个服务是生产就绪的。
(6)如果开发者可以可靠地部署和监控某个服务，就可以对这个服务更有信心。
(7)服务监控应该包括日志聚合以及服务层次的健康检查。
(8)微服务会因硬件、通信以及依赖项等原因而出现故障,并不是只有代码中的缺陷才会导致故障发生。
(9)收集业务指标、日志以及服务间的链路跟踪记录对于了解微服务应用当前和过去的运行表现是至关重要的。
(10)随着微服务以及支持团队的数量的不断增加，技术分歧以及孤立会日渐成为技术团队的挑战。
(11)避免技术分歧和孤立需要在不同团队间采用相似的标准和最佳实践，不管采用何种技术基础。
第 3 章微服务应用的架构；
(1)单独来讲，微服务的内部和单体应用是相似的。
(2)微服务应用就像一个街区:它最终的样子不是指定好的，而是由一系列的准则和高层的概要模型来指导实现的。
(3)指导微服务架构的准则会反映出组织的目标并对团队的实践产生影响。
(4)架构规划应该促进良性发展，而不是强行指定整个应用的方案。
(5)微服务应用是由四层组成的:平台层、服务层、边界层和客户端层。
(6)平台层提供了一系列的工具和基础设施来支持开发面向生产的服务。
(7)在微服务应用中，同步通信通常是第一 选择,并且它非常适合命令型的交互，但是也存在缺点一会增 加耦合性和不稳定性。
(8)异步通信更加灵活，能够适应快速的系统演化，付出的代价是复杂度增加。
(9)常见的异步通信模式包括队列和发布-订阅。
( 10)边界层就是微服务应用的一个门面，对于外部消费者来说，这是非常适合的。
(11)常见的边界层模式有 API 网关和消费者驱动的网关(如 GraphQL)。
(12)客户端应用，比如网站和移动端应用，通过边界层与移动后端进行交互。
(13)客户端有越来越臃肿庞大的风险，但是现在也开始出现--些将微服务原则应用于前端应用的技术。
第 4 章新功能设计；
(1)了解业务问题一识别实体 和用例一划分服务 责任，我们可以通过这一流程来划定服务范围。
(2 )可以采用不同的方式来对服务进行划分:按业务功能划分、按用例划分和按易变性划分。读者可以综合运用这些方法。
(3)好的划分决策能够让服务满足微服务的三大关键特性:只负责单-职责、 可替换和可独立部署。
(4)限界上下文通常是与服务边界相对应的，在思考服务的未来发展时,这是一一种很有效的方法。
(5)通过对易变领域的深入思考，开发者可以将那些会- -起变化的领域封装起来，以提高应对未来变化的适应能力。
(6)如果服务划分不好，后期修正的代价是特别大的，因为到那时，开发者需要重构多个代码库，由此产生的工作量会变得特别大。
(7)我们也可以将技术功能封装成一个服务 ,这么做既能够简化业务能力，又可以对业务功能提供支撑，并能最大限度地提高服务的可用性。
(8)如果服务边界还不够明确，我们宁可选择粗粒度的服务，但是要主动在服务内部采用模块化的方案来为未来的拆分做准备。
(9)服务下线是一件特别有挑战性的工作，但是随着微服务应用的不断发展,我们未来终有一天会需要这么做。
( 10)在大型组织机构中，将所有权拆分到多个团队中是很有必要的，但是这又会引入新的问题:控制变弱、设计受限、开发速度不一致。
(11)代码开放化、接口明确化、沟通持续化以及放宽对 DRY 原则的要求都可以缓解团队之间的紧张关系。
第 5 章微服务的事务与查询；
(1)在跨服务的交互中实现 ACID 特性是很困难的，微服务需要采用不同的方式来实现一致性。
(2)类似两阶段提交这样的协调方案会引入加锁操作，扩展性不好。
(3)基于事件的架构可以解除各个独立组件之间的耦合,并为微服务应用的业务逻辑和查询的可扩展性打下基础。
(4)倾向于高可用，而非-一 -致性，这会使得架构的可扩展性更强。
(5) Saga 是由- -组消息驱动的、独立的本地事务组成的全局操作。它们通过补偿操作来回滚错误的状态，以实现- -致性。
(6)在构建反映现实世界环境的微服务时，预见失败场景并做好准备是非常重要的一部分内容，操作的隔离性反而没那么至关重要。
(7)我们通常通过组合多个 API 的结果来实现跨多个微服务的查询功能。
(8)高效的复合型查询应该采用 CQRS 模式来实现一套独立的读数据模型，特别是在那些查询模式需要采用另-一种数据存储系统时。
第 6 章 设计高可靠服务；
(1)在复杂的分布式系统中，故障是不可避免的一 在设计这些系统时，开发者必须考虑容错能力。
(2)每个服务的可用性都会对整个应用的可用性的产生影响。
(3)对每个应用制定合适的策略来减轻故障的风险，这需要仔细考虑故障的频次、影响以及减少这些罕见的故障事件所增加的成本。
(4)大部分故障发生在 4 个领域:硬件、通信、依赖项和内部。
(5)正反馈导致的连锁故障是微服务应用中一种很常见的故障形式。通常，大部分是连锁故障由服务过载所导致的。
(6)可以使用重试和超时时间的策略来减轻服务交互中出现的故障的影响。在采用重试方法时，开发者要加倍谨慎，以免加重其他服务的故障。
(7)可以使用缓存、候选服务和默认值等后备方案( fllback )来返回成功的结果，即使服务依赖不可用。
(8)应该在服务交互中将超时时间传播到下游服务，这样不仅能够确保在整个系统内超时时间是一致的，还可以少做无用功。
(9)当错误量达到一定阈值时，服务之间的断路器会通过快速失败来避免连锁故障。
(10)服务可以使用限流策略来保护其免于受到突发的超过服务容量承载能力的负载请求高峰的影响。
(11)每个服务应该为负载均衡器和监控系统开放健康检查接口供其使用。
( 12)可以通过压力测试和混沌测试来有效地验证系统可恢复性。
(13)可以采用一些标准一 不管是通过框架还是代理一 来帮助工程师快速(“flall into thepit of sccess”"“) 开发出默认具有容错性的服务。
第 7 章 构建可复用的微服务框架；
(1)微服务底座能够加快新服务的启动速度，扩大试验领域和降低风险。
(2)使用服务底座能够让开发者将与某些基础设施相关的代码实现抽取出来。
(3)服务发现、可观测性以及不同的通信协议都是服务底座所关注的内容，服务底座需要提供这些功能。
(4)如果有适合的工具存在，我们可以为下单出售股票这样的复杂功能快速开发出原型。
(5)虽然微服务架构经常和使用任意语言开发系统的可能性联系起来，但是在生产环境中,这些系统需要保证并提供机制来让运行和维护都是可管理的。
(6)微服务底座能够实现上述这些保证，同时能够让开发者快速启动和开发以验证想法的正确性，如果验证通过，就可以部署到生产环境。
第 8 章微服务部署；
(1)部署新的应用和变更必须标准化和简单明确，以免在微服务开发过程中出现摩擦。
(2)微服务可以运行在任何地方，但是理想的部署平台需要支持一系列功能， 包括安全、配置管理、服务发现以及冗余。
(3)开发者将一个典型服务部署为一组完全相同的实例，并与一-个负载 均衡器连接。
(4)实例组、负载均衡器以及健康检查能够让所部署的服务实现自愈和自动扩容。
(5)服务工件必须是不可变的和可预测的，以将风险控制到最小，降低认知难度，简化部署抽象。
(6)开发者可以将服务打包为特定于语言的包、操作系统软件包、虚拟机模板或者容器镜像。
(7)添加/删除微服务的单个实例是基本的初级操作，可供开发者组合成更高级别的部署。
(8)开发者可以使用金丝雀部署或蓝绿部署来降低意外缺陷对可用性的影响。
第 9 章 基于容器和调度器的部署；
(1)将微服务打包为不可变的、可执行的工件能够让开发者通过基本操作(增加或移除容器)来对部署过程进行编排。
(2)为了方便服务开发和部署，调度器和容器会将底层的机器管理概念抽离出去。
(3)调度器的工作是设法将应用的资源需求与集群机器的资源使用情况匹配起来，同时对运行中的服务进行健康检查以确保它们正确运行。
(4) Kubernetes 具备了微服务部署平台的理想特性，包括密码凭据管理、服务发现和水平扩容。
(5) Kubernetes 用户定义了所期望的集群服务状态(或者规格),而 Kubermetes 会不停地执行“观测-比较执行”这-循环操作来计算如何达到所期望的状态。
(6) Kubernetes 的逻辑应用单元是 pod:一个容器或者在一起执行的多个容器。
(7)复制集管理 pod 组的生命周期。如果现有的 pod 出现故障，复制集会启动新的 pod。
(8) Kubernetes 中的部署对象被设计用来通过对复制集中的 pod 执行滚动更新来保持服务可用性的。
(9)开发者可以使用服务对象来对底层的 pod 进行分组并供集群内外的其他应用访问。
第 10 章构建微服务交付流水线；
(1)微服务部署过程应该满足两大目标:节奏安全和- -致性。
(2)部署新服务所花费的时间通常是微服务应用中的一大阻碍。
(3)对微服务而言，持续交付是理想的部署实践方式，它通过快速交付小版本的经过验证的变更集来降低风险。
(4)良好的持续交付流水线能够确保部署过程的可见性、部署结果的正确性，并能够向工程师团队反馈丰富的信息。
(5) Jenkins 是非常流行的自动化构建工具，它使用脚本语言将不同的工具联系到一.起并组合成交付流水线。
(6)预发布环境是非常有价值的，但是当面对大量的独立变更时,维护好预发布环境也面临着巨大的挑战。
(7)读者可以在各个服务上复用声明式流水线步骤;积极推动标准化能够提高不同团队间部署过程的可预测性。
(8)为了对发布和回滚提供细粒度的控制，读者应该将部署这一技术活动与功能发布的业务活动分开管理。
第 11 章构建监控系统；
(1)可靠的微服务监控系统包括度量指标、链路追踪和日志。
(2)从微服务中收集丰富的数据有助于开发者发现故障.调查问题,并理解整个应用的表现。
(3)在收集度量指标时，开发者应该重点关注四大黄金标志:时延、错误量、通信量(吞吐率)和饱和度。
(4) Prometheus 和 StatsD 是两种常见的和具体语言无关的从微服务中收集度量指标的工具。
(5)开发者可以使用 Grafana 将度量指标数据以图表的形式展示出来，创建人类可读的仪表盘和触发告警。
(6)如果基于度量指标的告警体现的是系统不正常的症状而非原因的话，那么这些告警更具有持久性和可维护性。
(7)定义良好的告警应该有明确的优先级，能够逐层升级到对应的人员，具有可操作性并且包含简洁而有价值的信息。
(8)从多个服务中收集和聚合的数据能够让开发者将完全不同的度量指标关联起来并进行比较，从而对系统有进一-步全面的了解。
第 12 章使用日志和链路追踪了解系统行为；
(1)读者可以使用 Elasticsearch、 Kibana 和 Fluentd 一起搭建一套日志基础设施,并使用 Jaeger 搭建一套分布式链路追踪系统。
(2)日志基础设施可以生成、转发和存储索引的日志数据以方便检索和关联不同请求。
(3)分布式链路追踪能够让开发者跟踪不同微服务之间的请求的执行过程。
(4)除了度量指标集合，链路追踪能够让开发者更好地了解系统的运行方式，发现潜在问题并随时对系统进行审查。
第 13 章微服务团队建设；
(1)构建优秀的软件不仅和选择什么方案实现有关，还与有效的沟通、协调和协作有关。
(2)应用架构和团队结构有着共生的关系。可以使用后者来改变前者。
(3)如果想让团队变得高效，就应该将他们组织起来,最大化地实现自治、所有权以及端到端职责。
(4)在微服务交付方面，跨职能团队比传统的职能团队速度更快、更有效率。
(5)较大型的工程组织应该建立一套具有 基础设施、平台和产品团队的分层模型。较低层次的团队为较高层次的团队提供服务以保证其能够更有效地工作。
(6)社区实践(比如协会和分会),可以分享职能知识。
(7)微服务应用很难全部装进人的大脑，这给全局决策和值班的工程师带来了挑战。
(8)架构师应该指导和影响应用的演进，而不是支配应用的方向和结果。
(9)内部开源模型能改善跨团队协作，削弱占有欲，降低巴士因子的风险。
( 10 )设计评审能提高微服务的质量、可访问性和一致性。
(11)微服务文档应该包括概述、 操作手册、元数据和服务契约。
这份【微服务实战】文档共有 331 页，需要完整版的小伙伴，可以转发此文关注小编，，**点击这里，获得文档领取方式**
还未添加个人签名 2020.09.25 加入
还未添加个人简介
评论