微服务

业务之前采用了单体应用的架构 不同功能模块的代 码耦合在一起，编译打包部署也都在一起。
有的人忘记提交代码、有的人忘记打包、有的人忘记修改工程依赖到最新版本。一次上 线过程需要反复确认，耗费了大量精力，严重影响了整体的开发和部署效率。
最后选定了服务化的解决方案 对原有的单体应用架构进行改造，把功能相对独立的模块拆分出去，部署为微服务
当前移动互联网时代最先进的业务架 构解决方案，能更好地迎合移动互联网业务快速迭代的要求。

单体应用的痛(总结：部署 发布 协同 效率低 可用性差)

然而随着业务规模的不断扩大，团队开发人员的不断扩张，单体应用架构就会开始出现问 题。

部署效率低下

应用编译打包、部署测试一次，甚至需要 10 分钟以上

团队协作开发成本高

超过 5 人修改代码，然后一起打包部署，测试阶段只要有一块功能有问题，就得重 新编译打包部署，然后重新预览测试，所有相关的开发人员又都得参与其中，效率低下， 开发成本极高。

系统高可用性差

某段代码不断在内存中创建大对象，并且没 有回收，部署到线上运行一段时间后，就会造成 JVM 内存泄露，异常退出，那么部署在 同一个 JVM 进程中的所有服务都不可用，后果十分严重。

线上发布变慢

特别是对于 Java 应用来说，一旦代码膨胀，服务启动的时间就会变长， 有些甚至超过 10 分钟以上，如果机器规模超过 100 台以上，假设每次发布的步长为 10%，单次发布需要就需要 100 分钟之久。因此，急需一种方法能够将应用的不同模块 的解耦，降低开发和部署成本。

想要解决上面这些问题，服务化的思想也就应运而生。

什么是服务化？（总结：本地方法调用，改造成通过 RPC 接口产生的远程方法调用）

服务化就是把 传统的单机应用中通过 JAR 包依赖产生的本地方法调用，改造成通过 RPC 接口产生的远程方法调用

举个例子

以微博系统为例，微博既包含了内容模块，也包含 了消息模块和用户模块等。
其中消息模块依赖内容模块，消息模块和内容模块又都依赖用户 模块。
当这三个模块的代码耦合在一起，应用启动时，需要同时去加载每个模块的代码并连 接对应的资源。一旦任何模块的代码出现 bug，或者依赖的资源出现问题，整个单体应用 都会受到影响。

 首先可以把用户模块从单体应用中拆分出来，独立成一个服务部署，以 RPC 接口的 形式对外提供服务.

什么是微服务（服务拆封更细 独立部署 独立维护 有统一治理平台）

那么微服务相比于服务化又有什么不同呢？

服务拆分粒度更细。

微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依 赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务。

服务独立部署

每个微服务都严格遵循独立打包部署的准则，互不影响。比如一台物理机 上可以部署多个 Docker 实例，每个 Docker 实例可以部署一个微服务的代码。

服务独立维护。

每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维， 并对整个生命周期负责。

服务治理能力要求高

因为拆分为微服务之后，服务的数量变多，因此需要有统一的服务 治理平台，来对各个服务进行管理。

什么时候应该拆分单体应用？拆分单体应用有哪些标准可依呢(总结：互相影响就开始拆了 单体应用开发超过10人 根据功能是否独立 公共的也要分出去)

什么时候进行服务化拆分？

一个收费视频用户量访问过大导致内存泄露 因为免费视频和收费视频耦合在一起 最后导致免费视频无法观看

一旦单体应用同时进行开发的人员超过 10 人，就会遇到上面的问 题，这个时候就该考虑进行服务化拆分了。

服务化拆分的两种姿势

1是纵向拆分 ：是将不同的功能模块 服务化，独立 部署和运维

标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分 为一个微服务。

2是纵向拆分 ：是从公共且独立功能维度拆分。

标准是按照是否有公 共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合。

服务化拆分的前置条件（总结 ：服务接口协议定义要事先定义好, 发布订阅用的注册中心 监控方案，服务治理方案 比如熔断 故障定位）

单体应用迁移到微服务架构时必将面临也必须解决的。

服务如何定义

每个服务都运行在各自的进程之中，应该以何 种形式向外界传达自己的信息呢

答案就是接口，无论采用哪种通讯协议，是 HTTP 还 是 RPC，服务之间的调用都通过接口描述来约定，约定内容包括接口名、接口参数以及 接口返回值。

服务如何发布和订阅

拆分为微服务独立部署后，服务提供者该如何对外暴露自己的地址，服务调 用者该如何查询所需要调用的服务的地址呢

注册中心

服务如何监控

需要一种 通用的监控方案，能够覆盖业务埋点、数据收集、数据处理，最后到数据展示的全链路功 能。
来关注我们最关心的是 QPS（调用量）、AvgTime（平均 耗时）以及 P999（99.9% 的请求性能在多少毫秒以内）这些指标

服务如何治理

服务的数量变多了，依赖关系也变复杂 了。比如一个服务的性能有问题时，依赖的服务都势必会受到影响。可以设定一个调用性 能阈值，如果一段时间内一直超过这个值，那么依赖服务的调用可以直接返回，这就是熔 断，也是服务治理最常用的手段之一。

故障如何定位

需要有一种解决方案能够将一次用 户请求进行标记，并在多个依赖的服务系统中继续传递，以便串联所有路径，从而进行故 障定位。

起走进微服务架构，来看看 它的各个组成部分

1.向注册中心注册服务 告诉我能提供什么服务和那个服务的地址

2.来服务消费者 ，查询所需要调用服务的地址 拿到地址发请求 拿到结果解析

3.服务的请求耗时、调用量以及成功率都被记录下来用监控  而调用经过的链路信息会被记录下来，用于故障定位和问题追踪

4.如果期间调用失败 可以通过重试等服务治理手段来保证成功率

总结一下，微服务架构下，服务调用主要依赖下面几个基本组件：
服务描述
注册中心
服务框架
服务监控
服务追踪
服务治理

服务描述

首先要解决的问题就是服务如何对外描述。的服务名叫什么？调用这个服务需要提供哪些信息？调用这个服务返回的结果是什么 格式的？该如何解析？

这些都是服务描述组件解决的 一般包括 RESTful API、XML 配置以及 IDL 文件

RESTful API 方式通常用于 HTTP 协议的服务描述，并且常用 Wiki 或者Swagger来 进行管理

 

IDL 文件方式通常用作 Thrift 和 gRPC 这类跨语言服务调用框架中，比如 gRPC 就是通过 Protobuf 文件来定义服务的接口名、参数以及返回值的数据结构，示例如下

 注册中心

下一步要解决的问题就是服务的发布和订阅 

提供者一启用 就向注册中心注册自己服务（会根据 服务发布文件的发布信息）

消费者在启动时 就向注册中心订阅自己服务（消费者配置文件 中 配置的服务信息）　

再然后注册中心返回服务提供者地址列表给服务消费者
当服务提供者发生变化 ，注册中心将变更通知给服务消费者。

 

服务框架

在发起调用之前你还需要解决以下几个问题

服务通信采用什么协议？    TCP、UDP 协议，还是采用七层 HTTP 协议，还是采用其他协议？
数据传输采用什么方式？ 就是说服务提供者和服务消费者之间的数据传输采用哪种方式， 是同步还是异步，是在单连接上传输，还是多路复用。
数据压缩采用什么格式？比如常见的 JSON 序列化

服务监控

一旦服务消费者与服务提供者之间能够正常发起服务调用，你就需要对调用情况进行监控， 以了解服务是否正常。通常来讲，服务监控主要包括三个流程。
指标收集。就是要把每一次服务调用的请求耗时以及成功与否收集起来，并上传到集中的 数据处理中心。
数据处理。每次调用的请求耗时以及成功与否等信息，就可以计算每秒服务请求量、 平均耗时以及成功率等指标。
数据展示。数据收集起来，经过处理之后，还需要以友好的方式对外展示，才能发挥价 值。通常都是将数据展示在 Dashboard 面板上，并且每隔 10s 等间隔自动刷新，用作 业务监控和报警等。

服务追踪

原理：

服务消费者发起调用前，会在本地按照一定的规则生成一个 requestid，发起调用时，将 requestid 当作请求参数的一部分，传递给服务提供者。
服务提供者接收到请求后，记录下这次请求的 requestid，然后处理请求。如果服务提供 者继续请求其他服务，会在本地再生成一个自己的 requestid，然后把这两个 requestid 都当作请求参数继续往下传递。

服务治理

服务监控能够发现问题，服务追踪能够定位问题所在，而解决问题就得靠服务治理了。服务 治理就是通过一系列的手段来保证在各种意外情况下，服务调用仍然能够正常进行

单 IDC 故障。你应该经常听说某某 App，因为施工挖断光缆导致大批量用户无法使用的 严重故障。而服务治理可以通过自动切换故障 IDC 的流量到其他正常 IDC，可以避免因为单 IDC 故障引起的大批量业务受影响。
依赖服务不可用。比如你的服务依赖依赖了另一个服务，当另一个服务出现问题时，会拖 慢甚至拖垮你的服务。而服务治理可以通过熔断，在依赖服务异常的情况下，一段时期内 停止发起调用而直接返回。这样一方面保证了服务消费者能够不被拖垮，另一方面也给服 务提供者减少压力，使其能够尽快恢复。

04 | 如何发布和引用服务？

想要构建微服务，首先要解决的问题是，服务提供者如何发布一个服务，服务消费者如何引用这个服务。

 

最常见的服务发布和引用的方式有三种：

RESTful API (无学习成本 跨语言 内外使用)

XML 配置

服务提供者定义接口，并实现接口。

服务提供者进程启动时，通过加载 server.xml 配置文件将接口暴露出去。

服务消费者进程启动时，通过加载 client.xml 配置文件来引入要调用的接口。

私有RPC框架才选择 适用于性能较高的业务 

IDL 文件

中立描述接口 不同语言直接可以相互调用 

常用的IDL 一个是  Facebook 开源的Thrift 协议，另一个是 Google 开源的gRPC 协议

根据服务者消费者 生成对应的语言代码

05 | 如何注册和发现服务？

注册中心原理和地图其实差不多，就是将部署服务的机器地址记录到注册中心，服务消费

者在有需求的时候，只需要查询注册中心，输入提供的服务名，就可以得到地址，从而发起

调用

注册中心原理

读取各自的xml配置文件 向注册中心注册自己的服务 

服务的发心跳信息 client向注册中心订阅 并于RPC 建立连接

节点别更时 会刷新本地换从去新的地址调用

注册中心实现方式 

涉及几个问题 1.需要提供哪些接口 2.如何部署 3.如何存储服务信息 4.如何监控服务提供者节点的存活5.节点变化如何通知消费者

注册中心 API

服务注册接口 调用这个接口完成注册

服务反注册接口 调用这个接口来完成服务注销。 

心跳汇报接口  调用心跳汇报接口完成节点存活状态

服务订阅接口：client 调用这个接口完成订阅，获取可用的接口

服务变更查询接口 client调用这个接口 获取最新的可用服务节点列表

 

后台管理的API

服务查询接口 查询注册中心当前有哪些服务信息

服务修改接口 修改某一个服务

 

集群部署

注册中心一般采用集群 为了高可用  并通过分布式一致性协议保证数据一致性 就比如注册中心开源项目 zookeeper

目录存储 

存储服务信息一般采用层次化的目录结构

服务健康状态检测

ZooKeeper服务健康状态检测
是基于 ZooKeeper 客户端和服务端的长连接和会话超时控制

机制，来实现服务健康状态检测的

客户端和服务端建立连接后  就建立会话 生成sessionid
在一定时间内会不断发心跳信息  SESSION_TIMEOUT  没再收到ping的消息 则任务结束会话  
ZooKeeper 就会认为这个服务节点已经不可用，将会从注册中心中删除其
信息

服务状态变更通知 

白名单机制 

例如 错误的把测试环境下的节点注册到线上注册中心集群，这样的话线上流量调用到测试机的RPC 所以后果可能很严重

所以提供一个白名单 只有添加到注册中心白名单的RPC 才能去注册接口

06 | 如何实现RPC远程服务调用？

想要完成RPC调用，你需要解决四个问题：

客户端和服务端如何建立网络连接？

服务端如何处理请求？

数据传输采用什么协议？

数据该如何序列化和反序列化？

客户端和服务端如何建立网络连接？

通信框架。它主要解决客户端和服务端如何建立连接、管理连接以及服务端如何处理请求

的问题。

通信协议。它主要解决客户端和服务端采用哪种数据传输协议的问题。

序列化和反序列化。它主要解决客户端和服务端采用哪种数据编解码的问题。

根据我的实践经验，客户端和服务端之间基于 TCP 协议建立网络连接最常用的途径有两

种。

1. HTTP 通信  

建立完三次握手  通信  通过4次挥手断开

2. Socket 通信

见我之前的博客 python是如何完成TCP 通信的

 

当客户端和服务端建立网络连接后，就可以发起请求了。但网络不一定总是可靠的，经常会

遇到网络闪断、连接超时、服务端宕机等各种异常，通常的处理手段有两种。

断开处理

断开处理1.链路存活检测 （总结 客户端不断发心跳 当客户端发现次数和时间达到一定程度后没有回复 那么就要和服务器重新建立链接了）

客户端需要定时地发送心跳检测消息（一般是通过 ping 请求）给服务

端，如果服务端连续 n 次心跳检测或者超过规定的时间都没有回复消息，则认为此时链

路已经失效，这个时候客户端就需要重新与服务端建立连接。

断连重试2.（总结 要过一会儿再连 不然还没等到计算机回收连接 就又有连接进来 导致资源瞬间被占满）

服务端如何处理请求？

服务端如何处理请求1-同步阻塞方式（BIO-适用于连接数比较小的业务场景）

一个线程处理一个请求 线程池满的时候 其他请求无法进来

服务端如何处理请求2-同步非阻塞方式 (NIO-适用于连接数比较多并且请求消耗比较轻的业务场景)

通过 I/O 多路复用技术进行处理  从而使系统在单线程的情况下可以同时处理多个客户端请求

服务端如何处理请求3-异步非阻塞方式（AIO-连接数比较多而且请求消耗比较重的

）

发起调用会立马收到结果 完成后收到I/O结果 不需要实际IO读写操作    真正IO 在内存处理了

建议最为稳妥的方式：Netty、MINA

一次正常地

RPC 调用还需要解决两个问题 传输协议 和 如何序列化

数据传输采用什么协议

最常用的有 HTTP 协议  

定制的私有协议  Dubbo 协议

通常协议契约包括两个部分：消息头和消息体。其中消息头存放的是协议的公共字段以及用

户扩展字段，消息体存放的是传输数据的具体内容。

数据该如何序列化和反序列化？

为什么要对数据进行序列化和反序列化呢？ 减少数据传输效率 对数据进行压缩  来减少传输时间

常用的序列化方式分为两类：文本类如 XML/JSON 等，二进制类如 PB/Thrift 等，而具体

采用哪种序列化方式，主要取决于三个方面的因素。

1.性能

PB 性能和压缩比较高  josn可读性强 跨平台

2.是否跨语言

3.支持数据结构类型的丰富度  

通信框架   通信协议   序列化和反序列化  就组成了一个完整的 RPC 调用框架

 

07 | 如何监控微服务调用?

先你要搞清楚三个问题:监控的对象是什么?具体监控哪 些指标?从哪些维度进行监控?  再讲述如何监控微服务调用

 监控对象

监控对象分4层 从上往下  用户端监控 借口监控 资源监控 基础监控

用户端监控：业务直接对用户提供的功能的监控  比如微信发送消息

接口监控: 对rpc接口的监控 比如 比如好友列表功能的监控

资源监控:接口依赖的资源监控 比如资源再redis 对redis的监控

接口监控：服务器本身的监控 cpu 内存等等

监控指标

请求量 qps就是一个指标 

响应时间 一个区间  

0~10ms、10ms~50ms、50ms~100ms、100ms~ 500ms、500ms 以上

除此之外，还可以从 P90、 P95、P99、P999 角度来监控请求的响应时间，比如 P99 = 500ms，意思是 99% 的请 求响应时间在 500ms 以内，它代表了请求的服务质量，即 SLA。

错误率 比如503的比率

 监控维度

全局 从整体角度监控对象的请求量 平均耗时 错误率 全局唯独的监控一般是为了让你有个大概的了解

分机房维度 一个机房一个机房的监控

单机 

时间 一周前 一月前 三月前

核心 把核心的与非核心的分开监控

对于一个微服务来说，你必须明确要监控哪些对象、哪些指标，并且 还要从不同的维度进行监控，才能掌握微服务的调用情况。

那 么该如何搭建一个监控系统，来完成上面这些监控功能呢?

监控系统原理（总结四大环节）

显然，我们要对服务调用进行监控，首先要能收集到每一次调用的详细信息，包括调用的响 应时间、调用是否成功、调用的发起者和接收者分别是谁，这个过程叫作数据采集。采集到 数据之后，要把数据通过一定的方式传输给数据处理中心进行处理，这个过程叫作数据传输。数据传输过来后，数据处理中心再按照服务的维度进行聚合，计算出不同服务的请求 量、响应时间以及错误率等信息并存储起来，这个过程叫作数据处理。最后再通过接口或者 Dashboard 的形式对外展示服务的调用情况，这个过程叫作数据展示。

数据收集

通常有两种数据收集方式:

服务主动上报 在业务代码里把收集后的数据主动上报

代理收集：把调用信息加入到日志文件中 分析系统进行分析

数据传输

udp 和 kafka（发送指定topic 让数据处理单元订阅对应的topic）

数据处理

对收集来的原始数据进行聚合并村粗

接口维度聚合  这个维度是把所有实时收集来的数据接口名维度聚合在一起 可以统计每个接口的实时请求量 平均耗时

机器维度聚合  把调用节点维度聚合在一起  （可以判断每个节点的实时请求量和平均耗时 ）

存储 两种

一种是索引数据库 比如es 查询按索引

一种是实讯数据库 比如openTSDB 查询按时讯 1min，5min来进行查询

 数据展示

1.曲线图 （监控变化趋势的 按时间推测变化趋势 ）

2.饼状图  (监控占比)

3.格子图  (细粒度的监控)

比如格子图代表了不同的机器的接口调用请 求量和耗时情况，展示结果一目了然。

如果没有强大的监控能力 改造微服务就不能掌握各个服务的情况 如果不能快速定位 是一场灾难

搭建一个服务监控系统，涉及数据采集、数据传输、数据处理、数据展示等多个环节，每个 环节都需要根据自己的业务特点选择合适的解决方案，关于监控技术方案的选型我会在专栏 后面进行详解。

08 | 如何追踪微服务调用?

在微服务里 有各个的服务 一次请求设计到多个服务  由于一次请求设计到 异地 语言不同 机器不同 ，那么请求失败查看具体原因是件多么复杂的事 

下面这张图描述了用户访问微博首页，一次请求所涉及的服务(这张图仅作为示意，实际上 可能远远比这张图还要复杂)，你可以想象如果这次请求失败了，要想查清楚到底是哪个应 用导致，会是多么复杂的一件事情。

 那么有这么一套服务追踪系统 可以跟踪发起了哪些调用 经过了哪些服务 并且记录了每一次调用所设计到的详情信息 如果调用失败了 你就可以通过这个服务追踪系统　　你就可以快速定位在哪个环节出现了问题

服务追踪的作用

除了快速 定位 我在这里列出了4点 可以帮你在微服务改造过程解决不少问题

第一 优化系统瓶颈

通过记录调用经过的每一条链路上的耗时 我们能快速定位系统瓶颈点所在 是网络慢呢 还是网关系统异常 

可以从全局视角去观察 对某个瓶颈点作出优化

第二，优化链路调用

判断服务经过的链路是否合理 比如一个服务下游依赖了多少个服务 经过这个链路分析 可以判断每个依赖是否合理是否都是必要的 是否可以通过业务来优化

比如跨中心服务调用了 比如一个服务a调用了 另外一个服务中心的服务b 而没有调用自身的服务中心b 那么通过链路调用   

第三，网络拓扑

通过服务追踪系统中记录的链路信息，可以生成一张系统的网络调用拓扑图，它可以反映系 统都依赖了哪些服务，以及服务之间的调用关系是什么样的，可以一目了然。除此之外，在 网络拓扑图上还可以把服务调用的详细信息也标出来，也能起到服务监控的作用。

第四，透明传输数据

除了服务追踪，业务上经常有一种需求，期望能把一些用户数据，从调用的开始一直往下传 递，以便系统中的各个服务都能获取到这个信息。比如业务想做一些 A/B 测试，这时候就 想通过服务追踪系统，把 A/B 测试的开关逻辑一直往下传递，经过的每一层服务都能获取 到这个开关值，就能够统一进行 A/B 测试。

服务追踪系统原理

它的核心理念就是调用链:通过一个全局唯一的 ID 将分布在各个服务

节点上的同一次请求串联起来，从而还原原有的调用关系，可以追踪系统问题、分析调用数据并统计各种系统指标。

traceid 用于标记用户请求的唯一ID  在第一层生成 随着rpc调用不断往后传递 这样就可以把调用路径串联起来

spanid   用于标识一次 RPC 调用在分布式请求中的位置

 

annotation，用于业务自定义埋点数据，可以是业务感兴趣的想上传到后端的数据，比 如一次请求的用户 UID。

服务追踪系统实现

　　

数据采集层

作用是在各个模块之间进行埋点 上报给数据处理层进行处理

CS(Client Send)阶段 : 客户端发起请求，并生成调用的上下文。 SR(Server Recieve)阶段 : 服务端接收请求，并生成上下文。

SS(Server Send)阶段 : 服务端返回请求，这个阶段会将服务端上下文数据上报，下面 这张图可以说明上报的数据有:traceId=123456，spanId=0.1，appKey=B， method=B.method，start=103，duration=38。

CR(Client Recieve)阶段 : 客户端接收返回结果，这个阶段会将客户端上下文数据上 报，上报的数据有:traceid=123456，spanId=0.1，appKey=A， method=B.method，start=103，duration=38。

 2数据处理

实时数据处理

针对实时数据处理，一般采用 Storm 或者 Spark Streaming 来对链路数据进行实时聚合加 工，存储一般使用 OLTP 数据仓库，比如 HBase，使用 traceId 作为 RowKey，能天然地 把一整条调用链聚合在一起，提高查询效率。

离线数据处理

针对离线数据处理，一般通过运行 MapReduce 或者 Spark 批处理程序来对链路数据进行 离线计算，存储一般使用 Hive。

3. 数据展示层

两种图形展示，一种是调用链路图，一种是调用拓扑 图。

 

 

下面以一张 Zipkin 的调用链路图为例，通过这张图可以看出下面几个信息。

服务整体情况:服务总耗时、服务调用的网络深度、每一层经过的系统，以及多少次调用。 下图展示的一次调用，总共耗时 209.323ms，经过了 5 个不同的系统模块，调用深度为 7 层，共发生了 24 次系统调用。

 每一层发生了几次调用，以及每一层调用的耗时。

调用拓扑图 

下面是一张 Pinpoint 的调用拓扑图，通过这张图可以看出系统内都包含哪些应用，它们之 间是什么关系，以及依赖调用的 QPS、平均耗时情况。 

 

调用拓扑图是一种全局视野图，在实际项目中，主要用作全局监控，用于发现系统中异常的
点，从而快速做出决策。比如，某一个服务突然出现异常，那么在调用链路拓扑图中可以看
出对这个服务的调用耗时都变高了，可以用红色的图样标出来，用作监控报警。

09 | 微服务治理的手段有哪些? 

可见，一次服务调用，服务提供者、注册中心、网络这三者都可能会有问题，此时服务消费
者应该如何处理才能确保调用成功呢?这就是服务治理要解决的问题。

节点管理 

服务消费者出现问题 或者网络不通  

无论哪种都有节点管理的两种管理手段

1.注册中心主动摘除

服务提供者主动回报心跳 如果超时 那么就把这个节点给摘除了 并把最近的可用节点推送给服务消费者

2.服务消费者摘除机制

虽然1方案可以解决服务提供者节点异常，那么要是服务注册中心网络到提供者网络不通呢 就会把接所有服务提供者全部摘除

所以存活探测机制在服务消费者这段更加合理 如果发现到服务提供者节点失败那么就在内存中删除

负载均衡

由于采购机子批次不同 新采购的机子性能要好于旧的批次 对于服务消费者而言 在从服务列表中选择可用节点 希望让配置高一些的机器承担多一点流量那么就需要用到负载均衡的算法

1.随机算法

每个节点得到调用量是差不多的

2.轮询算法

就是按照固定权重 对可用节点轮询 可以对某些好的配置节点调高他的权重 那么请求量就会多一些

3.最少活跃调用算法

在服务消费者那一端维护一个连接数 选择连接数较少的的节点发起调用 

4.一致性hash算法

指相同参数的请求总是发到同一服务节点。当某一个服务节点出现故障时，原本发往该节点
的请求，基于虚拟节点机制，平摊到其他节点上，不会引起剧烈变动。

 配置差不多 选择1和2 算法最合适  配置明显差异选择3最合适

服务路由 

选择哪个节点发起调用不仅是负载均衡算法决定 还是有服务路由规则确定 为什么要有这个规则

1.原因是因为业务存在灰度发布的需求

2.多机房就近访问原则

如何配置路由规则呢

静态配置（放在消费端 要想更换调用配置 需要修改 并重新上线）

和

动态配置  （这种方式下 路由规则是存在注册中心的 定期去请求服务器来保持同步 修改注册中心即可 下一次请求 会请求注册中心来更新配置 从而实现动态变更）

服务容错

对于服务调用失败的情况，需要有手段自动恢复，来保证调用成功。

 

通常的调用手段主要一下几种

failouver

失败自动切换  这种策略要求服务调 用的操作必须是幂等的  一般适用于读请求的场景

FailBack 

失败通知 调用失败后不再重试 而是返回的结果来决定后续的操作 比如像上面幂等 调用失败了不只是执行重试 而是查询服务端的状态 看调用是否生效 已经生效不再重试

FailCahce 

失败缓存 调用失败不立即发起调用 而是过一段时间后重启发起调用

Failfast

快速失败  调用失败不重试 采用于非核心的调用 记录失败日志后就返回了

你可以看出它们的使用场景是不同的，一般情况下对于 幂等的调用，可以选择 FailOver 或者 FailCache，

非幂等的调用可以选择 FailBack

或者 FailFast。 

上面我讲的服务治理的手段是最常用的手段，它们从不同角度来确保服务调用的成功率。节
点管理是从服务节点健康状态角度来考虑，负载均衡和服务路由是从服务节点访问优先级角
度来考虑，而服务容错是从调用的健康状态角度来考虑，可谓是殊途同归。

在实际的微服务架构实践中，上面这些服务治理手段一般都会在服务框架中默认集成了，比 如阿里开源的服务框架 Dubbo、微博开源的服务框架 Motan 等，不需要业务代码去实 现。如果想自己实现服务治理的手段，可以参考这些开源服务框架的实现。