什么是微服务

维基百科定义：

微服务的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他们定义了微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通讯。同时，服务会使用最小规模的集中管理 （例如 Docker）技术，服务可以用不同的编程语言与数据库等。

微服务解决了哪些问题

事物的发展是逐步演进的，我们关注一下软件服务应用发展历程，可见其一斑

应用发展历程

单体架构

简单单体模式是最简单的架构风格，所有的代码全都在一个项目中。这样研发团队 的任何一个人都可以随时修 改任意的一段代码，或者增 加一些新的代码。

垂直架构

分层是一个典型的对复杂系 统(不仅仅是软件)进行结 构化思考和抽象聚合的通用性办法，也符合金字塔原理 。MVC是一个非常常见的3 层(3-Tier)结构架构模式。

SOA架构

面向服务架构(SOA)是 一种建设企业IT生态系统的 架构指导思想。SOA的关 注点是服务。服务最基本的 业务功能单元，由平台中立 性的接口契约来定义。

微服务架构

微服务架构风格，以实现一 组微服务的方式来开发一个 独立的应用系统的方法。其中每个小微服务都运行在自 己的进程中，一般采用 HTTP资源API这样轻量的机 制相互通信。

应用发展原因

单体架构到垂直架构，根据业务模块和代码职责被横切竖隔为，结构更加清晰，但存在一些弊端：

1. 部署效率低下：编译打包慢
2. 团队协作开发成本高：一块功能有问题，需要全部重新部署
3. 系统高可用性差：一段代码有问题，影响整个系统
4. 线上发布变慢：代码膨胀，服务启动变慢

SOA 是因为以前 ERP、CRM、OA 之类的信息系统都是一套套部署起来的，各个系统并不互通，企业有了应用集成和数据集成的需求，SOA 就出来了，各个系统对外提供粗粒度的服务供外部系统访问，所有的服务都集中在一个 ESB。但ESB对于互联网来说，从来都不是主流。

SOA和微服务区别：微服务算是SOA的子集，SOA 高度依赖服务总线（ESB），而微服务不需要。

分布式服务化就是把传统的单机应用中通过 JAR 包依赖产生的本地方法调用，改造成通过 RPC 接口产生的远程方法调用。微服务我理解，是服务化的演进。不同于服务化：

1. 服务拆分粒度更细：模块依赖资源与其他模块没关系，可以拆分为一个微服务
2. 服务独立维护：每个微服务由一个小团队甚至个人负责
3. 服务治理能力要求高：拆分后服务变多，需要统一的服务平台，对各个服务进行管理

不管是互联网，还是银行、证券、保险，业务越来越复杂，数据越来越多。系统对性能、稳定性，一致性，可用性，扩展性，可维护性，要求越来越高。原来的单体架构无法满足要求，我们需要部署更多的机器来满足业务需求，更多的机器会引来其他问题，我们要解决把这些问题，所以，就有了现在的架构。

微服务组件

服务描述

各种中心

实现各种中心核心二要素：

1. 需要有存取数据的能力，特别是临时数据
2. 需要有数据变化的实时通知机制，全量或增量
   各种中心异同：

• 相同点：都需要保存和读取数据/状态，变更通知
• 不同点：配置是全局非业务参数，注册中心是运行期临时状态，元数据是业务模型。

配置中心

管理系统需要的配置参数信息。可以解决如下问题：

1. 大规模集群下，如何管理配置信息，特别是批量更新问题
2. 大公司和金融行业，一般要求开发、测试、运维分离（物理隔离）
3. 运行期的一些开关控制，总不能不断重启

注册中心

管理系统的服务注册、提供发现和协调能力。实现方式：

1. 注册中心api：

服务注册接口
服务反注册接口即注销
心跳汇报接口
服务订阅接口
服务变更查询接口
服务查询接口（后管）
服务修改接口（后管）

2. 集群部署
   采用集群部署来保证高可用性，并通过分布式一致性协议来确保集群中不同节点之间的数据保持一致。
3. 目录存储
   注册中心存储服务信息一般采用层次化的目录结构。
4. 服务健康状态检测
   保证注册中心里保存的服务节点都是可用的。
5. 服务变更状态通知
   服务状态变更通知：注册中心探测到有服务提供者节点新加入或者被剔除，就必须立刻通知所有订阅该服务的服务消费者，刷新本地缓存的服务节点信息，确保服务调用不会请求不可用的服务提供者节点。
6. 白名单机制
   注册中心可以提供一个白名单机制，只有添加到注册中心白名单内的 RPC Server，才能够调用注册中心的注册接口，这样的话可以避免测试环境中的节点意外跑到线上环境中去。

元数据中心

管理各个节点使用的元数据信息。

服务治理

服务治理就是通过一系列的手段来保证在各种意外情况下，服务调用仍然能够正常进行。常见故障：

1. 单机故障：以通过一定的策略，自动摘除故障节点，不需要人为干预，就能保证单机故障不会影响业务。
2. 单IDC故障：通过自动切换故障 IDC 的流量到其他正常 IDC，可以避免因为单 IDC 故障引起的大批量业务受影响。
3. 依赖服务不可用：通过熔断，在依赖服务异常的情况下，一段时期内停止发起调用而直接返回。这样一方面保证了服务消费者能够不被拖垮，另一方面也给服务提供者减少压力，使其能够尽快恢复。

节点管理

1. 注册中心主动摘除机制：要求服务提供者定时的主动向注册中心汇报心跳
2. 服务消费者摘除机制：如果服务消费者调用服务提供者节点失败，就将这个节点从内存中保存的可用服务提供者节点列表中移除。

负载均衡

1. 随机
2. 轮训
3. 最少活跃调用
4. 一致性hash

服务路由

对于服务消费者而言，在内存中的可用服务节点列表中选择哪个节点不仅由负载均衡算法决定，还由路由规则确定。因为：

1. 业务存在灰度发布需求
2. 多机房就近访问需求

服务容错

1. FailOver：失败自动切换。

就是服务消费者发现调用失败或者超时后，自动从可用的服务节点列表总选择下一个节点重新发起调用，也可以设置重试的次数。这种策略要求服务调用的操作必须是幂等的，也就是说无论调用多少次，只要是同一个调用，返回的结果都是相同的，一般适合服务调用是读请求的场景。

2. FailBack：失败通知。

就是服务消费者调用失败或者超时后，不再重试，而是根据失败的详细信息，来决定后续的执行策略。比如对于非幂等的调用场景，如果调用失败后，不能简单地重试，而是应该查询服务端的状态，看调用到底是否实际生效，如果已经生效了就不能再重试了；如果没有生效可以再发起一次调用。

3. FailCache：失败缓存。

就是服务消费者调用失败或者超时后，不立即发起重试，而是隔一段时间后再次尝试发起调用。比如后端服务可能一段时间内都有问题，如果立即发起重试，可能会加剧问题，反而不利于后端服务的恢复。如果隔一段时间待后端节点恢复后，再次发起调用效果会更好。

4. FailFast：快速失败。

就是服务消费者调用一次失败后，不再重试。实际在业务执行时，一般非核心业务的调用，会采用快速失败策略，调用失败后一般就记录下失败日志就返回了。

服务流控

系统的容量有限，保持部分服务能力是最佳选择，然后在问题解决后恢复正常状态。

1. 限流
   内部线程数，外部调用数或数据量。
2. 服务降级
   去掉不必要的业务逻辑，只保留核心逻辑。
3. 过载保护
   系统短时间不提供新的业务处理服务，积压处理完后再恢复输入请求。

服务监控

监控对象

1. 用户端监控：指业务直接对用户提供的功能的监控。
2. 接口监控：指业务提供的功能所依赖的具体接口的监控。
3. 资源监控：指某个接口依赖的资源的监控。
4. 基础监控：指对服务器本身的健康状况的监控。主要包括 CPU 利用率、内存使用量、I/O 读写量、网卡带宽等。

监控指标

1. 请求量：实时请求量 QPS，反映了服务调用的实时变化情况；统计请求量 PV（Page View），即一段时间内用户的访问量来衡量
2. 响应时间：更关心慢请求的数量。

为此需要把响应时间划分为多个区间，比如 0～10ms、10ms～50ms、50ms～100ms、100ms～500ms、500ms 以上这五个区间，其中 500ms 以上这个区间内的请求数就代表了慢请求量，正常情况下，这个区间内的请求数应该接近于 0；在出现问题时，这个区间内的请求数会大幅增加，可能平均耗时并不能反映出这一变化。除此之外，还可以从 P90、P95、P99、P999 角度来监控请求的响应时间，比如 P99 = 500ms，意思是 99% 的请求响应时间在 500ms 以内，它代表了请求的服务质量，即 SLA。

3. 错误率

监控维度

1. 全局维度：从整体角度监控对象的的请求量、平均耗时以及错误率，全局维度的监控一般是为了让你对监控对象的调用情况有个整体了解。
2. 分机房维度
3. 单机维度
4. 核心维度：业务上一般会依据重要性程度对监控对象进行分级，最简单的是分成核心业务和非核心业务。核心业务和非核心业务在部署上必须隔离，分开监控，这样才能对核心业务做重点保障。

服务追踪

记录服务调用经过的每一层链路，以便进行问题追踪和故障定位。

作用

1. 优化系统瓶颈：从全局视角上去观察，找出整个系统的瓶颈点所在，然后做出针对性的优化。
2. 优化链路调用。一般业务都会在多个数据中心都部署服务，以实现异地容灾，这个时候经常会出现一种状况就是服务 A 调用了另外一个数据中心的服务 B，而没有调用同处于一个数据中心的服务 B。
3. 生成网络拓扑：可以生成一张系统的网络调用拓扑图，它可以反映系统都依赖了哪些服务，以及服务之间的调用关系是什么样的。
4. 透明传输数据：除了服务追踪，业务上经常有一种需求，期望能把一些用户数据，从调用的开始一直往下传递，以便系统中的各个服务都能获取到这个信息。

原理

核心理念就是调用链：通过一个全局唯一的 ID 将分布在各个服务节点上的同一次请求串联起来，从而还原原有的调用关系，可以追踪系统问题、分析调用数据并统计各种系统指标。

1. traceId
2. spanId
3. annotation

实现

1. 数据采集层
2. 数据处理层：实时数据处理；离线数据处理
3. 数据展示层：调用链路图；调用拓扑图