前言
随着互联网对各个行业的深度渗透，它对行业的改变除了使行业有了新的业务形式，还有对业务更新节奏的提速。近两年在与处于各种不同行业的朋友的交流中，感受最深的一点就是“这世界变化太快了”。如果前两年这种“快”的影响还只在互联网领域，那么现在几乎所有的行业都已经被裹挟到这个浪潮中来了。而“微服务”便是在这样的大势之下应运而生，由前两年互联网公司的“玩具”转变为被更多企业级IT系统所接受和尝试东西。
从计算机的发展历史来看，微服务是一一个新生产物，但它不是从石头缝里突然蹦出来的，它的设计思想其实是分布式系统与SOA的延续，同时又汲取了DevOps、持续集成、持续交付等工程实践，并借着云计算和容器化的春风开始了它的驰骋之旅。因此，要做好微服务架构，既需要在业务和技术方面钻研得够深，又需要具有涵盖整个生命周期的广博知识，但两者很难兼得，但本书的内容恰恰在这两方面都得到了很好的体现。我想，这一方面得益于本书已是第2版，在前一版全面介绍微服务架构的基础之上，是一次体 系化的精进，内容臻于成熟。华为亲身经历的众多大型项目，收获了大量实践微服务架构的经验。
与时俱进，从Martin Fowler提出“微服务”概念至今，不过三、四年时间，这其中已经诞生了许多能“呼风唤雨”的平台和框架。在软件设计领域，实现技术瞬息万变，唯有设计思想方能历久弥新。
下面我们就进入微服务架构之美吧
微服务架构与实践
目录
第一部分、基础篇
第1部分为基础篇，介绍应用架构的演进历程以及微服务诞生的背景，并通过对微服务概念、特征的探讨，帮助读者深刻理解微服务的本质。同时，本部分的内容也客观地阐述了实施微服务时所面临的挑战。
- 软件架构发展回顾以及微服务诞生的背景。
- 微服务架构的本质及落地时面临的挑战。
- 微服务与SOA、Serverless 的关系。
- 下一代微服务Service Mesh.
微服务架构综述
单体架构( Monolithic Architecture )
计算机科学领域自成立以来就遇到了与复杂性有关的问题。开发人员通过选择正确的数据结构，开发算法以及应用关注点分离的概念来解决早期的复杂问题。当时的企业组织结构多为功能型组织，同时服务只能部署在性能、可靠性强大但价格不菲的大型机上。在这样的条件下，应用的呈现、逻辑处理和数据存储等功能，都集中部署和运行在同一台服务器上，通常称为单体架构。
分层架构( Layered Architecture )
随着服务器开始在Web世界中承担更多的职责，如服务UI、事务处理、数据存储等，由于受到面向过程的思维及设计方式的影响，所有的逻辑代码并没有明显的区分，因此代码之间的调用相互交错，错综复杂。
微服务架构的特征
从业界的讨论来看，微服务架构的特征通常包括以下六个部分:
- 服务作为组件
- 围绕业务组织团队
- 关注产品而非项目
- 技术多样性
- 业务数据独立
- 基础设施自动化
Serverless的应用场景
第二部分、策略篇
从概念的维度看，微服务架构是一种架构模式，但从实现的维度看，微服务的落地过程绝不能仅关注微服务架构本身。实际上，微服务的落地过程通常会涉及IT领域过去多年的“最佳实践集”，包括但不限于持续集成、敏捷实践、运维自动化、测试自动化、DevOps 以及全功能团队等。对于落地微服务的团队而言，如何系统化地、有效地应用这些实践呢?优先考虑哪些实践，哪些实践依赖于其他实践呢?
针对上述这些问题，本书的第2部分将重点讲述微服务落地的思路和实现方式，其主要内容包括:
- 如何系统化地理解微服务全景图一微服务 生态系统。
- 什么是微服务实施参考模型，以及如何通过参考模型循序渐进地制定微服务演进路线。
- 在微服务演进过程中，涉及哪些重要的实践，如自动化测试、部署管理、运维等。
- 对遗留系统进行改造的方式，如绞杀者模式，以及改造案例。
微服务生态系统
基于笔者过去的经验，在帮助企业实施微服务的过程中，如果只是从架构解耦的角度入手，很难产生效果。从架构上看，微服务架构虽然是一种架构模式，但从实现上看，已经不能仅仅关注架构本身，需要从分布式、流程、工具、组织、文化、DevOps以及端到端的整体交付等考虑，这其实就是笔者所理解的微服务生态系统。构建好微服务生态系统，微服务的落地才能事半功倍，才能更高效地为业务创造价值。
微服务生态系统的核心内容
微服务生态系统主要包括两部分，即核心内容和工程实践，如图2-2所示。其中，核心内容是微服务演进过程中的重要部分，包括注册发现、配置管理、监控告警、日志聚合、调用链等内容。工程实践是微服务演进中的重要保障，包括交付流水线、开发框架，以及工程实践(全功能团队的落地实践)。
微服务关键技术
然而在微服务的实施过程中仍将面临许多挑战，例如如何设计出合理的微服务架构，以便高效地实现业务需求。同时，随着服务数量的增多，如何有效地实现大规模微服务的治理和运维，也会成为新的挑战。
服务划分
基于非功能性因素
CQRS的实现方案
三阶段提交
针对两阶段提交的问题，主要是协调者失败引发的问题，三阶段提交进一 步将准备阶段又划分为两个阶段，并引入了超时策略来缓解阻塞的问题。所以三阶段提交就变成了:确认能否进行事务操作、预提交和提交。
TCC模式
在微服务的分布式场景下，业务运行流程可能较长，采用传统ACID的事务方式会造成运行等待时间过长。除了前面提到的2PC/3PC的事务处理方式，还可以采用事务补偿的方式，即先执行正常的业务逻辑，当出现问题时，如流程中某些环节出错，再执行补偿的动作，即取消或者重试。
微服务参考模型
微服务参考模型梳理了产品在微服务实施过程中的适用性评估、成熟度参考、度量体系以及能力提升计划，旨在帮助团队尽早识别微服务实施过程中的风险，并有效地推进微服务相关实践的落地。
过程类度量指标
过程类度量指标又称辅助类度量指标，是团队实施微服务过程中的“放大镜”，能有效观察局部改进的效果，衡量的是团队在某个方面的能力提升和水平高低。对于交付过程中各个局部环节，笔者推荐的过程类度量指标如下表所示，笔者可以根据具体场景，采取部分或者全部指标进行度量。
基于参考模型的实践
有了充实的理论基础、丰富的工具以及明确的目标，如何在这些基础上，以多、快、好、省的方式，落实理论，选择合适的工具，就变成了实际的问题。本章将从微服务团队、核心敏捷实践、服务设计与实现、运维管理、测试管理、交付流水线、部署管理等维度出发，介绍笔者过去对不同项目实施微服务的实践，这些实践曾经帮助笔者在多个团队中顺利完成架构、组织的演进和工程能力的提升，希望这些内容能对读者有所启发和帮助，提高微服务实施的投入产出比。
工作任务可视化
架构即代码
监控机制
通过数据流水线统监控方式
对微服务测试的系统化思考
与测试活动相关的角色划分与协作
构建服务静态依赖图
由于内容细节过多就不一一展示了
遗留系统的微服务改造
随着时间的推移，遗留系统的维护和管理的成本越来越大。在向微服务架构全面转型的过程中，这些遗留系统就像一只只“拦路虎”，阻挡微服务转型之路。如何在不影响业务的同时，以更安全、更高效、更低成本的方式将这些遗留系统进行微服务改造，使之顺利融入微服务架构，并充分利用到微服务架构的优势呢?本章将详细介绍如何解决遗留系统的微服务改造问题。
绞杀者模式
遗留系统改造场景
第三部分、实战篇
在本书的第1部分基础篇中，阐述了微服务架构的理论基础以及其本质，理解这部分是落地微服务化的前提:在第2部分策略篇中，探讨了微服务生态系统、微服务参考模型以及相应的工程实践，帮助读者有效地落地微服务:在第3部分实践篇中，将以开源项目SockShop 为背景，探讨如何使用ServiceComb作为开发框架，ServiceStage作为基础设施，构建SockShop系统。本部分的主要内容包括:
- ServiceComb与Service Stage综述。
- SockShop系统的分析、设计以及服务实现。
- SockShop系统的部署、编排以及服务治理。
微服务开发框架ServiceComb
微服务云应用平台ServiceStage
AOS编排服务
SockShop系统分析与设计
建立统一语言
架构设计
实现SockShop系统的第一个服务
本章将介绍SockWorks团队，如何实现SocksShop系统的第一. 个服务，并完成端到端的自动化测试、打包、部署及发布过程。
商品服务自动化测试
实现SockShop系统的其他服务
运行SockShop系统
部署SockShop系统
运维SockShop系统
ServiceStage相关概念
集群:一个集群指容器运行所需要的云资源组合，关联了若干云服务器节点、负载均衡等云资源。
节点:每一个节点对应-台虚拟机， 容器应用运行在节点 上。节点上运行着代理程序( kubelet),用于管理节点上运行的容器实例。节点规格最小是CPU为lcore,内存为2048MB;最大是CPU为32core,内存为128GB。
容器:一个通过Docker镜像创建的运行实例，一一个节点可运行多个容器。
Docker镜像:Docker镜像是容器应用打包的标准格式，在部署容器化应用时可以指定镜像，镜像可以来用于ServiceStage 公有仓库，或者用户的私有镜像。
Pod: 以组容器(一个或者更多)，共享网络和存储，并且包含容器如何运行的规范。
编排:编排模板包含了一组容器服务的定义和其相互关联，可以用于多容器应用和虚机应用的部署和管理。
设计包:运维人员对应用的拓扑、生命周期管理计划进行设计，并输出堆栈模板(也可称为应用设计包)。
设计器:图形化设计器工具，用户可通过拖拽方式完成复杂应用的编排及拓扑设计，可以保存成堆栈模板，使用堆栈模板创建堆栈，简化应用部署难度，提升效率。
堆栈模板:堆栈模板是对堆栈的描述，包括基于应用模型的堆栈拓扑定义、堆栈生命周期描述、运行时资源描述、软件组件描述等。堆栈模板通过设计包创建而来，本质与设计包相同。
堆栈:由应用、服务、资源等元素组成的一个部署实例，平台将相关编排元素通过“堆栈”进行集中管理。
容器应用:一个容器应用可通过单个镜像或一个编排模板创建，每个容器应用可包含1个或多个容器，和Kubenetes Pod的概念等同。
仓库:仓库包括镜像仓库和软件仓库，镜像用于容器类应用，软件包用于虚拟机或物理机应用。用户在创建应用前，需要将应用所需的镜像或软件包上传到仓库中。
各个模块的关联和关系:
- 一个集群由多个节点组成。
- 一个节点上可以部署多个应用。
- 一个应用由一个或多个容器部署而成。
- 堆栈是由应用、服务、资源等元素组成的一个部署实例。
AK(AccessKeyID):访问密钥ID。与私有访问密钥关联的唯一标识符:访问密钥ID和私有访问密钥一起使用，对请求进行加密签名。
SK (Secret Access Key): 与访问密钥ID结合使用的密钥，对请求进行加密签名，可标识发送方，并防止请求被修改。
密钥(Key Pair): SSH 密钥对，用于ECS主机初始化时使用，方便用户通过SSH免密登录。
总结
随着数字化转型的推进，越来越多的企业开始尝试基于微服务框架构建和重构自己的系统，微服务实施不仅仅是微服务框架的技术选型和服务拆分，它涉及到方方面面，是一个系统化的体系工程。本书从架构演进、微服务拆分、接口契约测试，流水线构建到微服务实战，涵盖了微服务实施过程中的重要环节，是一本难得的系统化、全面介绍微服务的书籍，值得大家认真研读。
这份【微服务架构与实践2】笔记文档共为515页，需要完整版的朋友，可以点赞此文关注小编，【见下图】即可获取！！
