本文展开思维导图如下
一. 微服务相关概念
微服务的由来
单体应用（所有功能代码耦合在一起）存在诸多缺点，如部署效率低、团队开发成本高、系统高可用性差（某一功能代码有问题，整体不可用），为解决上述问题，微服务诞生。
2. 微服务概念及特点
微服务就是将系统拆分成各个小的功能模块，降低了各模块间的耦合。
1）服务拆分粒度细，模块依赖资源与其他模块都没关系，就可以拆分为一个微服务。
2）服务独立部署、维护，可以增加团队开发效率。
3）服务治理能力要求高，代码拆分后，服务数量变多，需要有统一服务管理平台，对各个服务进行管理。
二. 整体架构
流程梳理：
首先服务提供者按照一定格式服务描述，向注册中心注册服务，内容主要包含可以提供哪些服务，以及服务地址，完成服务发布。
服务消费者请求注册中心，查询要消费服务地址，然后用约定的通信协议向服务提供者发起请求，并按约定协议解析结果。
微服务架构下，服务调用主要依赖基本组件有：服务描述、注册中心、服务框架、服务监控、服务追踪、服务治理。
三. 基本组件
服务描述
1）作用
对服务进行描述，为服务调用起到桥梁作用，主要描述服务接口名、调用服务需要的参数、服务返回值等信息。
2）方式
a. RESTful API
主要被用作HTTP或者HTTPS协议的接口定义，较为适合跨业务平台之间场景。
b. XML配置
需要在服务提供者和消费者维持对等XML配置文件，耦合性强，发生化需要同时修改server.xml和client.xml。适用于公司内部联系紧密的业务。
c.IDL文件
主要用作跨语言平台服务间调用，常用的IDL有Thrift、gRPC。不适用接口返回值字段较多，并且经常变化情况。
服务描述方式 使用场景 缺点 RESTful API 跨语言平台，组织内外 使用HTTP通信，相比TCP性能差 XML配置 JAVA平台，组织内部 不支持跨语言 IDL文件 跨语言平台，组织内外 修改参数字段不能向前兼容
2. 注册中心
1）作用
解决服务调用过程中，寻找服务发布者地址的问题。
2） 原理
RPC Server（服务提供者）启动时根据服务发布文件server.xml中配置信 息，向注册中心注册自身服务，并向注册中心定期发送心跳汇报存活状态。
RPC Client调用服务，在启动时根据引用文件client.xml中配置的信息，向注册中心订阅服务，把返回的服务节点缓存到本地内存，并与RPC Server建立连接。
RPC Server节点变更，注册中心进行同步变更，RPC Client感知后在本地内存刷新缓存的服务节点列表。RPC Client从本地缓存服务器节点，基于负载均衡算法选择一台RPC Server调用。
注册中心采用分布式集群部署，保证高可用性，甚至采用多IDC部署，需要保证数据一致性。
3）其他功能
注册中心还具备对服务节点健康状态检测功能(zk基于客户端和服务端的长连接以及会话超时控制机制实现服务健康状态检测)、服务状态变更通知(注册中心检测到有服务提供者新加入或剔除，就必须立刻通知的所有订阅该服务的服务消费者刷新本地服务节点信息，确保服务调用不会请求不可用节点，zk基于Watcher机制)、白名单机制（将线上环境和线下环境分开）。
3. RPC远程服务调用
1）客户端和服务端建立网络连接方式
Http通信：基于TCP协议，三次握手、四次挥手
Socket通信：步骤，服务器监听、客户端请求、服务端确认连接、数据传输
2） 服务端处理请求方式
| 方式 | 特点 | 适用场景 |
| 同步阻塞BIO | 客户端每发一次请求，服务端就生成一个线程处理 | 连接数小 |
| 同步非阻塞NIO | 客户端每发一次请求，通过I/O多路复用技术处理 | 连接数多，请求消耗轻 |
| 异步非阻塞AIO | 客户端发起IO操作立即返回，IO操作完客户端会收到通知 | 连接数多、请求消耗重 |
客户端和服务器建立连接方式、服务器处理请求方式就是通信框架要解决的问题，现有开源方案有Netty、MINA。
3）数据传输使用的协议
客户端和服务端采用那种数据传输协议，有HTTP协议、Dubbo协议；协议相当于是一个锲约，服务消费者按照锲约对传输的数据进行编码，通过网络传输，服务提供者收到数据后，按照锲约对传输数据进行解码，然后处理。
4）数据序列化和反序列化方式
why?网络传输耗时由网络带宽和数据传输量决定，加快网络传输，可以提高带宽或者减少数据量。
常用序列化方式有文本类XML/JSON,二进制类PB/Thrift，采用那种方式主要考虑下面的因素：
支持数据结构的丰富度、跨语言支持、性能（序列化的压缩比，序列化的速度），eg:JSON序列化性能差一些，但可读性好。
4.服务监控
1）监控对象
用户端监控：指对用户提供的功能的监控；
接口监控：业务提供功能依赖PRC接口的监控；
资源监控：某个接口依赖的资源监控；
基础监控：服务器本身监控，如CPU利用率、内存使用量。
2）监控指标
请求量：实时请求量QPS，统计请求量PV(Page view)：一段时间内用户访问量；
响应时间：一段时间所用调用平均耗时，如TP99=500ms：百分之99请求需要的时间在500ms以内
错误率：一段时间内调用失败次数占总调用次数比率
3）监控维度
全局维度（对监控对象整体了解）、分机房维度、时间维度、核心维度（业务属于核心还是非核心）。
4）监控系统原理
主要包括数据采集、数据传输、数据处理、数据展示。
数据采集：服务主动上报（需要在业务代码加入数据收集代码）、代理采集（将服务调用信息写入本地日志，通过代理解析日志，然后上报）；需要考虑数据采样率，采样率高精确度高，但对系统有影响，可以根据系统负载情况来动态变化。
数据传输：UDP传输、Kafka传输；数据格式，二进制协议、文本协议。
数据处理：对收集来的原始数据进行聚合并储存，分接口维度聚合和机器维度聚合（调用节点维度）；数据储存，索引数据库（ES）、时序数据库（OpenTSDB）:以时序序列数据方式储存，可以按照时序如1min进行查询。
5 .服务追踪
跟踪记录一次用户请求发起的调用，记录每次调用涉及服务的详细信息，如果调用失败就可以通过日志快速定位哪个环节出现问题。
1）作用
优化系统瓶颈：如找出链路上耗时长的服务，并优化
优化链路调用：评估每个依赖是否合理，或者找出一个服务调用了异地的另一个服务，而没有调用处于同一个数据中心服务而造成时延较大的这种情况。
生成网络拓扑：生成一张网络调用拓扑图，展示出服务间调用关系
透明传输数据：把一些数据从调用开始一直向下传递，使系统中各个服务都能获取到这个信息，如ABtest开关逻辑一直向下传递。
2）原理
调用链：通过一个全局唯一ID将分布在各个服务节点上的同一次请求串联起来，还原原有调用关系。
traceId:标识某一次具体请求ID；spanId：标识一次RPC调用在分布式系统中的位置；annotation：业务自定义埋点数据，如一次请求的用户UID。
服务追踪该系统架构可分为数据埋点上报、数据收集采集、数据展示三部分。
数据埋点上报：服务通过SDK将信息发送至代理
数据收集计算：将代理传来的数据进行实时监控计算和储存
数据展示：前端查询展示性能数据、调用链数据
6.服务治理
主要解决微服务系统各环节出现问题的情况，如注册中心宕机，网路不通等。
服务治理手段：
1）节点管理
服务调用失败，对于节点来说可能有服务本身出现问题（服务器宕机），或网络问题。管理手段：
注册中心主动摘除机制：比较提供者汇报心跳时间，超出一定时间，将服务摘除，并将可用服务推送给消费者
服务消费者摘除机制：注册中心摘除可能出现一种情况，即注册中心和提供者网络出现问题，但此时消费者和服务者网络可能没问题，因此将存活探测机制用在消费者更为合理。
2）负载均衡
部署服务的机器性能存在差异，可以利用算法让性能高的机器流量大一些。
负载均衡算法：随机算法、轮询算法（可以给性能好的机器增加权重）、最少活跃算法（将服务器被调用的连接数进行到序排列，选择连接数小的）、一致性哈希算法（某节点故障，将原本请求平摊到其他节点，不引起剧烈变动）。
3） 服务路由
对于服务消费者，选择哪个提供者节点不仅由负载算法决定，还由路由规则确定。
指定路由规则原因：业务存在灰度发布需求（只希望服务被少数人访问）、多机房就近访问需求。
4）服务容错
对于服务调用失败场景，要有手段保证自动恢复，使调用成功。
| 手段 | 含义 | 特点 | 要求 |
| FailOver | 失败自动切换 | 调用失败从可用服务列表选取下一节点重新发起调用，可设置重试次数 | 服务调用操作幂等 |
| FailBack | 失败通知 | 服务调用失败不在重试，根据失败信息，执行策略 | |
| FailCache | 失败缓存 | 服务调用失败不立即重试，隔一段时间在重试 | |
| FailFast | 快速失败 | 一次调用失败，不在重试 | 用于非核心业务，调用失败记录失败日志并返回 |
对于幂等调用使用FailOver或者FailCache，非幂等使用FailBack或FailFast。
