华为 18 级大牛整理总结：微服务设计和分布式服务框架原理实践文档

AB test 就是一种灰度发布方式:让一部分用户继续用 A,一部分用户开始用 B;如果用户对 B 没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到 B 上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

第 12 章，参数传递

服务消费者和提供者之间进行通信时，除了接口定义的请求参数，往往还需要携带一些额外参数，例如消息提供者的 IP 地址、消息调用链的跟踪 ID 等;这些参数不能通过业务接口来进行传递，

需要底层的分布式服务框架支持这种参数传递方式。

第 13 章，服务多版本

服务上线之后，随着业务的发展需要对功能进行变更，或者修复线上的 BUG;服务升级之后，往往需要对服务采用多版本管理。

服务多版本管理是分布式服务框架的重要特性，它涉及服务的开发、部署、在线升级和服务治理。

第 14 章，流量控制

当资源成为瓶颈时，服务框架需要对消费者做限流，启动流控保护机制。流量控制有多种策略，比较常用的有:针对访问速率的静态流控、针对资源占用的动态流控、针对消费者并发连接数的连接控制和针对并行访问数的并发控制。

在实践中，各种流量控制策略需要综合使用才能起到较好的效果，本章针对分布式服务框架的流量控制设计原则和实践进行讲解。

第 15 章，服务降级

大促或者业务高峰时，为了保证核心服务的 SLA,往往需要停掉一些不太重要的业务，例如商品评论、论坛或者粉丝积分等。

另外一种场景就是某些服务因为某种原因不可用，但是流程不能直接失败，需要本地 Mock 服务端实现，做流程放通。以图书阅读为例，如果用户登录余额鉴权服务不能正常工作，需要做业务放通，记录消费话单，允许用户继续阅读，而不是返回失败。

上述两种场景，都使用到了分布式服务框架的一个重要服务治理功能:服务降级。服务降级主要包括容错降级和屏蔽降级两种模式，下面我们就两种服务降级的策略和设计进行讲解。

第 16 章，服务优先级调度

当系统当前资源非常有限时，为了保证高优先级的服务能够正常运行，保障服务 SLA，需要降低一些非核心服务的调度频次，释放部分资源占用，保障系统的整体运行平稳。

服务优先级的调度策略非常多，对于分布式服务框架而言，需要能够支持服务发布时设置优先级策略，并在资源成为瓶颈时，按照用户配置的优先级策略调度执行服务。

第 17 章，服务治理

随着业务的发展，服务越来越多，如何协调线上运行的各个服务，保障服务的 SLA，对服务架构和运维人员是一个很大的挑战。

随着业务规模的不断扩大，小服务资源浪费等问题逐渐显现，需要能够基于服务调用的性能 KPI 数据进行容量管理，合理分配各个服务的资源占用，提高机器的利用率。

线上业务发生故障时，需要对故障业务做服务降级、流量控制、流量迁移等，快速恢复业务。

随着开发团队的不断扩大，服务的上线越来越随意，甚至发生功能相同、服务名不同的服务同时上线。上线容易下线难，为了规范服务的上线和下线，在服务发布前，需要走服务预发布流程，由架构师或者项目经理对需要上线的服务做发布审核，审核通过的才能够上线。

为了满足服务线下管控、保障线上高效运行，需要有一个统一的服务治理框架对服务进行统一、有效管控，保障服务的高效、健康运行。

第 18 章，分布式消息跟踪

随着业务分布式架构的发展，系统间的系统调用日趋复杂，以电商的商品购买为例，前台界面的购买操作涉及到底层上百次服务调用，涉及到的中间件包括:

◎分布式服务框架

◎消息队列 .

◎分布式缓存

◎分布式数据访间中间件

◎分布式文件存储系统

◎分布式日志采集

◎其.....

如果无法有效清理后端的分布式调用和依赖关系，故障定界将会非常困难。利用分布式消息跟踪系统可以有效解决服务化之后系统面临的运维挑战，提高运维效率。

第 19 章，可靠性设计

相对于传统的本地 Java API 调用，跨进程的分布式服务调用面临的故障风险更高。

1)网络类故障:链路闪断、读写超时等。

2)序列化和反序列化失败。

3)畸形码流。

4)服务端流控和拥塞保护导致的服务调用失败。

5)其 他异常.....

对于应用而言，分布式服务框架需要具备足够的健壮性，在平台底层能够拦截并向上屏蔽故障，业务只需要配置容错策略，即可实现高可靠性。


第 20 章，微服务架构

过去十年，SOA ( Service-Oriented Architecture)架构得到了广泛的应用，现在，随着云计算、移动互联网、Docker 容器等技术的快速发展和应用，“微服务”架构(Micro Service Architecture) 这一全新的架构风格越来越受到大家的关注，也有越来越多的企业和平台服务提供商在实践中尝试并使用它来解决具体业务问题,微服务架构的流行已经成为未来技术发展趋势之一。

第 21 章，服务化最佳实践

在服务化之前，业务通常都是本地 API 调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗，业务调用的时延将增大，同时由于网络闪断等原因，分布式调用失败的风险也增大。如果服务框架没有足够的容错能力，业务失败率将会大幅提升。

除了性能、可靠性等问题，跨节点的事务一致性问题、分布式调用带来的故障定界困难、海量微服务运维成本增加等也是分布式服务框架必须要解决的难题。本章节我们将对服务化之后面临的挑战进行分析，并给出解决方案和业务最佳实践。

其次，给大家介绍第二块儿内容是——微服务设计

======================

1.目录

2.主要内容

第 1 章微服务

随着领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小型自治团队、大型集群系统这些实践的流行，微服务也应运而生。它并不是被发明出来的，而是从现实世界中总结出来的一种趋势或模式。但是没有前面提及的这些概念，微服务也很难出现。在本书接下来的内容中，我会尝试把这些概念整合起来，从而给出一个涉及如何构建、管理和演化微服务的全景图。

很多组织发现细粒度的微服务架构可以帮助他们更快地交付软件，并且有更多机会尝试新技术。微服务在技术决策上给了我们极大的自由度，使我们能够更快地响应不可避免的变化。

第 2 章演化式架构师

目前为止可以看到，微服务给我们提供了很多选择，因此也需要我们做很多决定。比如应该使用多少种不同的技术，不同的团队是否应使用不同的编程规范，是应该合并多个服务还是把一-个服务拆成多个。我们应该如何做决定呢?这些架构支持在频繁变换的环境下以更快的节奏进行变化，因此架构师这个角色也需要做相应的改变。本章关于架构师职责的观点是我的个人见解，希望能对象牙塔中的定义发起最后的攻击。

第 3 章如何建模服务

现在你已经知道什么是微服务了，希望你对它的主要优点也有所理解。你可能已经迫不及待地想要实现它了，对吗?但是从何做起呢?在本章中，我们会讨论如何确定服务之间的边界，以期最大化微服务的好处，避开它的劣势。但是，首先我们需要有一个产品作为讨论的载体。

第 4 章集成

在我看来，集成是微服务相关技术中最重要的一-个。做得好的话，你的微服务可以保持自治性，你也可以独立地修改和发布它们:但做得不好的话会带来灾难。希望本章能够帮助你在微服务之旅中，避免曾经在 S 《一线大厂 Java 面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》开源 OA 中遇到的那些问题。

第 5 章分解单块系统

前面几章讨论了什么是好的服务以及为什么小服务能达到更好的效果，还讨论了系统具有可演化性的重要性。但事实上，可能我们手中已经有了很多代码库，而它们无一例外都没有遵循上述的模式。如何才能循序渐进地把-一个单块系统分解开来呢?

单块系统的形成非一日之功。开发人员每天都对系统添加新功能和新代码。一段时间之后，它变成了组织中一个恐怖而巨大的存在，没人想去修改它。但别担心，它并不是无可救药。只要使用了正确的工具，我们就可以手刃这个怪兽。

第 6 章部署

部署一个单块系统的流程非常简单。然而在众多相互依赖的微服务中，部署却是完全不同的情况。如果部署的方法不合适，那么其带来的复杂程度会让你很痛苦。本章会讲解一些技巧和技术，从而帮助我们]在细粒度的架构中更好地部署微服务。

我会从持续集成和持续交付说起。这些概念与我们下面要讨论的主题并不相同，但又有所关联，了 解它们可以帮助我们在考虑构建什么、如何构建以及如何部署时，做出更好的决定。

最后

手绘了下图所示的 kafka 知识大纲流程图（xmind 文件不能上传，导出图片展现），但都可提供源文件给每位爱学习的朋友