微服务设计原理与架构¶
微服务架构特点:
1. 服务组件化
2. 按业务能力组织服务
3. 去中心化
4. 基础设施自动化
微服务具备业务独立、进程隔离、团队自主、技术无关轻量级通信和交付独立性等“微”特性。
微服务架构设计切入点:
一. 首要的切入点在于服务建模，尽可能明确领域的边界。
我们可以充分利用领域驱动设计(DDD)方法，通过:
1. 识别领域/子域中的模块和服 务、
2. 判断这些模块和服务是否独立、
3. 考虑提升某些模块和服务的层次并建立充血领域模型，
从而明确各个界限上下文( Boundary Context )之间的边界。
二. 第二个切入点就是服务之间的集成方式
即需要保证集成方式的技术无关性，不要选择对服务具体实现有技术性限制的集成技术。
三. 第三个切入点在于服务的部署
独立部署单个服务而不需要修改其他服务
微服务架构的优势:
1. 技术优势
a. 组件化方案
高内聚、低搞合的组件化方案
组件所能带来的独立性与健壮性，微服务都可以具备，
但微服务的组件化特征更多表现在对业务的提炼和对边界的思考
使用微服务架构迫使我们使用诸如领域驱动设计的思想去进行策略设计和技术设计，
从而为更好地划分业务功能、提取界限上下文和开展系统集成工作提供依据。
而这些方法和依据的背后恰恰是我们在架构设计过程中经常会碰到的问题
b. 技术自由度
各个微服务之间使用的是轻量级的通信机制。
所谓轻量级，就是指这些通信机制跟具体实现技术无关，不受限与某一个特定协议或交互媒介。
每个微服务高度独立
c. 可扩展性
与生俱来的可扩展性
单个服务在保持通信方式不变的前提下，对其内部功能和技术的改变不会对外部依赖它的服务产生任何影响
d. 可伸缩性
高扩展性往往能够带来高可伸缩性，因为可以伸缩的前提是对系统有合理的拆分
对是瓶颈的业务功能构建成独立的微服务，使用服务集群等手段有效加强服务运行时的环境和状态
e. 有效应对遗留系统
遗留系统( Legacy System )
一方面该系统的技术体系可能府在设计上的较大缺陷
另一方面则是因为代码量巨大且不容易修改
在代码层次与遗留系统进行直接集成是痛苦且具有挑战性的工作
而把遗留系统看成是提供接口的一个服务，微服务架构就能与之进行通信并完成功能整合
f. 支持持续交付
微服务作为独立的可部署单元，非常适合使用持续交付
因为每一个服务都可以在不依赖于其他服务的条件下完成发布和部署
持续交付管道可以运行得更快，从而加速问题反馈，这是持续交付的主要目标之一。
而持续交付的另一个目标是降低系统风险，微服务小而独立，一旦出现问题很容易进行回滚操作
2. 业务与组织优势
康威定律( Conway’s Law)
你想要什么样的 系统，就搭建什么样的团队
a. 消除过程浪费
开发周期的缩短同样意味着开发成本的降低，建立高效的研发过程体系可以提高开发效率
微服务架构的技术特征决定了开发各自微服务的团队之间只需要进行较少的协调工作，
这为降低研发过程浪费提供了基础
从组织管理的角度出发，自治性团队较之集中式管理模式下的团队在团队建立和发展上能够得到更好的可扩展性
另一方面 ，软件团队中时常会出现所谓的“扯皮现象” 原因在于不清晰的边界
微服务架构的一大特征就是根据业务来组建团队，
某个特定业务局限于某个微服务中并由独立团队负责所有相关事宜。
明确的边界有助于减少团队之间的扯皮现象，从而提升开发效率。
b. 快速产品开发
微服务架构从技术角度给出了缩短产品开发周期的方法，主要表现在并行的开发模式上
将业务拆分成各个微服务能够让不同的业务功能处于一种并行开发的状态，
因为每个团队所负责的业务需求只影响到团队自身的微服务，所以各个团队能够独立开发，
整个系统也很容易分 布到各个团队中
微服务架构的挑战:
将一个系统分散到多个微服务中使得系统整体结构变得更加复杂
由于各个微服务都需要独立部署，我们就会有更多的服务需要单独进行发布和运行管理，运维基础设施也会面临比单块系统更大的困难
微服务架构在很大程度上改变了系统的研发过程 ， 从团队协作到需求管理等方面，都需要通过引人变化进 行调整和完善 。
1. 技术架构挑战
a. 去中心化与平衡
去中心化的设计思想意味着微服务之间不需要共享技术，然而缺少通用的技术体系同样也会加剧系统的复杂度
去中心化是微服务架构的基本特征之一，所以支持「技术异构」(从而增加技术复杂性)
但从统一发布和运维等角度去看待整个系统时，这种技术复杂性就可能会是一个问题
b. 服务版本控制
如果某一个服务与另一个服务具有版本关联性，
即这两个服务要么都不发布、要么一起发布，那么事情就变得有点复杂。
如果这些具有版本关联性的服务很多且版本的更新频率很高，
如何正确地管理服务版本就是一项具有挑战性的工作。
2. 研发过程挑战
a. 需求的边界
对于整个系统而言，需求的边界并不会那么容易划分
如何确定业务功能的粒度、
如何把非功能性需求分解到各个微服务中、
如何从系统整体上把握需求的优先级
b. 引入变化
使用微服务架构就是一个引入变化的过程。
最大的误解: 认为新想法一旦引入就意味着已经成功
当微服务架构被引入时，我们还要做很多事情，
因为前面所提到的各种技术、架构和过程的挑战都需要我们进行跟踪和协调
微服务架构实施前提:
1. 当出现下图这个拐点时对系统进行微服务化的拆分才是合适的方案，服务的合理拆分是实施微服务架构的一大前提。
2. 微服务架构实施的另外一个前提是基础设施的自动化
一个应用部署到一台主机或在主机集群上，部署复杂度是 o(n)
而当把单块系统拆分成多个微服务之后，其部署复杂度就上升到 o(n^2)
从开发之后的构建、测试、部署都需要高度自动化的环境来支撑才能有效降低边际成本
生产率和复杂度关系图——马丁·福勒(Martin Fowler)。在复杂度较小时，采用单块系统的生产率更高，微服务架构反而可能降低生产率。当复杂度到了一定规模时，无论采用单块系统还是微服务架构，都会降低系统的生产率。但是单块系统的生产率开始急剧下降，而微服务架构则能缓解这种生产率下降的程度。本图展示了复杂度和生产率拐点的存在，但并没有量化复杂度的拐点到底是多少。也就是说，系统或代码库的规模达到 具体多大才适合开捕挂行微服务化的拆分，需要各个团队因地制宜。¶
微服务建模¶
一. 服务分类¶
定义:
从技术实现角度和业务角度分别切入，梳理微服务架构中的代表性服务类型和表现层次
一方面可以从技术实现角度进行归类;
另一方面，服务也具备层次性，需要把服务与业务结合起来梳理服务层次。
服务的基本类别¶
技术平台在构成过程中可以采用大量成熟的技术理念和工具，基本思路就是实现服务化。
三种主要的表现类型:
1. 工具服务
2. 实体服务
3. 任务服务
1. 工具服务( Utility Service )¶
定义:
代表: 可重用服务，区别业务模型。
作为: 应用程序与技术基础设施之间的交叉点
特点: 业务领域无关
本质: 面向技术、具备高可重用性的低层处理服务，因此能够遵循独立开发和管理生命周期
工具服务的四个常见维度:
1. Java 标准的 API 的封装
JCE(Java Cryptography Extension, Java 密码扩展)
提供用于加密、密钥生成和协商以及消息认证码 ( Message Authentication Code , MAC )算法的框架和实现
JMS(Java Messaing Service, Java 消息服务)
提供面向消息中间件( Message Oriented Middleware, MOM )的 API 规范
JAX-RS (Java API for RESTful Web Services)
支持按照 REST 风格创建 Web 服务
JDBC,
2. 公共功能区域的提炼
安全性、
消息传递系统、
HTTP 数据传输
持久性
3. 非功能性需求的抽取
性能、
可扩展性、
可用性、
安全性
4. 常见开源框架的应用
Zookeeper: 实现分布式协调和分布式锁机制
Dubbo: 实现通用的 RPC 功能和服务治理
Redis: 实现海量数据存储
Mongodb
注: 以 Java 为例
工具服务根据其用途细分为以下表现形式:
1. 公共工具服务
面向多种应用程序，如安全性、记录和审核，
该类工具服务通常设计成基于 Web的服务，并开放通用、松散类型接口。
2. 资源工具服务
封装物理系统资源，如数据存储/消息资源
这类服务处于底层，使用服务门面暴露入口
3. 微工具服务
细粒度、高度特性化，如XML加密服务。
这类服务通常本地调用，需要考虑性能、无状态性和线程安全，可以作为 JAR 包进行直接引用
4. 包装器工具服务
面向遗留系统，建立标准化服务契约
显然这类服务需要明确所支持的数据和消息模型
实体服务( Entity Service )¶
建立一种一致的方法访问和处理业务数据，对应基于业务的 功能上下文，侧重于以数据为中心。
实体服务中包括两种实体:
领域实体( Domain Entity)
消息实体( Message Entity)
任务服务( Task Service )¶
关注实现业务相关逻辑，很大程度上由组合逻辑组成，通常需 要维护状态
备注
工具服务不涉及业务。实体服务关注于数据，任务服务关注于业务组合，都需要根据业 务本身抽象化 。
服务与业务¶
业务服务的层次分类:
1. 基础服务
基础服务处于业务体系的最低层，这些服务一般对用户并不可见，
但却被其他各种服务所依赖，或者说为其他服务提供运行时支撑
如: 消息服务、路由服务
这些服务是业务体系中与技术结合比较密切的一组服务，
有时候也很难区分基础服务中业务和技术之间的隔离点
2. 通用服务
通用服务与基础服务的区别就在于它们是完全面向业务的服务，
这些服务通用性非常高，也可以像基础服务一样提供低层的业务支撑
如: 账号服务、登录服务、通知服务
「基础服务」与「通用服务」的区分可参考以下判断标准:
如果一个服务被依赖的层次和数量非常多，
那么可能会更加偏向于基础服务，反之则可以归为通用服务。
3. 定制服务
在一个系统中，定制服务相对而言不应该太多，
在日常开发过程中，定制服务主要是「面向外部」、「面向系统集成类」
如: 各种插件( Plug-in )类服务、外部账号和接口管理类服务
一方面需要对第三方服务进行适配，通常都需要进行一定程度的定制化开发
另一方面，为了系统的灵活性和扩展性，需单独把这部分从核心业务中剥离出来单独管理
4. 其他服务
这些服务因行业和业务体系而异
示例——移动医疗行业场景¶
二. 服务模型¶
备注
架构师使用模型来表达系统架构
服务的概念模型¶
定义:
提供服务的概念模型，并给出服务的统一表现形式
服务的概念模型来自于两个维度:
一个是服务标准，即什么样的服务才是一个好的服务
另一个是服务级别，即不同的服务应该具备不同的重要性
服务的概念模型:
两个维度:
一个是服务标准: 什么样的服务才是一个好的服务
一个是服务级别: 不同的服务应该具备不同的重要性
服务标准: 以下设计原理是服务标准最好的描述:
1. 服务无状态(Service Statelessness)
定义: 指服务通过推迟或避免状态信息的管理，从而最小化资源消耗
具备无状态的服务的设计特征:
a. 高度业务流程无关的逻辑，使得服务没有被设计为保存任何特定业务流程中的状态信息
b. 服务契约的约束很少，从而能够在运行时接收和传输更广泛的状态数据等
服务无状态性有助于增强服务的可扩展性。
2. 服务可重用( Service Reusability )
首先需要确保建立无关功能性的上下文 (Context )结构，
也就是说与服务封装在一起的上下文对任何使用场景都有足够的无关性，
这样服务才能被认为具备可重用性。
同时，服务内部的业务逻辑足够通用，以便能够用到不同类型的服务消费者的众多场景中
而且，服务逻辑可以被并发访问，服务设计为在一个或多个消费者同时访问时具备同样的访问效果
3. 服务可发现( Service Discoverability )
定义: 指服务具备能够用于传递的元数据构建能力，通过这些元数据可以有效地发现和解释服务
如: 在服务注册中心，可以通过这些元数据与注册中心之间建立服务注册和发现机制
4. 服务自治( Service Autonomy )
定义: 指服务对其低层运行时环境具有高度的控制权
为了实现服务自治:
服务契约应该表达定义明确的功能边界，这个边界不应该与其他服务的功能边界相重叠
同时，服务应该被部署在一个独立而隔离的环境中，
承载服务的这个环境也应该具备能够处理高并发的访问能力，以便更好地实现服务可伸缩性目的
5. 服务松耦合( Service Loose Coupling )
主要目的在于为消费者提供较低的耦合度要求，
通常表现在服务提供者和服务消费者能够以适应性的方式随时间进行自我演化，彼此之间的影响达到最小
在实现服务的过程中，服务松耦合原则强调服务契约与技术实现细节上的解捐
服务级别:
从发生具体事故时服务对用户体验的影响、所造成的经济损失等角度对服务进行具体分级
1. 一级服务
具备完善的容错降级机制及对低级别服务的熔断措施、定期压测、配置高级别的监控告警流程
2. 二级服务
多采用异步方式进行系统交互，容忍暂时数据不一致性
3. 三级服务
可随时降级整个服务
服务的统一表现形式¶
也就是需要具备契约化的约束条件，而这种契约化的约束条件一般可以通过文档的方式进行展现
服务契约化(Service Contract):
要求至少对服务的基本方面做出说明，包括:
1. API: 详细文档
2. 能力: 服务能力的描述
3. 约束: 约定的一些限制条件说明
4. 版本: 支持的最新和历史的版本说明。这一点对于微服务而言是必备的要素
文挡服务:
Swagger
HAL
三. 服务边界¶
服务边界是服务建模的核心要素，
采用面向领域思想，通过识别业务领域边界并确定界限上下文来达到明确服务边界的效果
识别服务的切入点在于 识别服务与服务之间的边界( Boundary )
识别业务领域及边界¶
方法主要参考DDD思想
领域( Domain )，即:
是对现实世界问题的一种统称，
是一个组织的业务开展方式，
体现一个组织所做的事情以及其中所包含的一切业务范围和所进行的活动
可以简单认为，我们所要设计的每一个特定的业务系统就是一个领域。
实例:
电商网站的领域包含了产品名录、订单、库存和物流的概念，
医疗信息化公司关注挂号、就诊、用药、健康报告等领域
有两个主要的设计维度，即:
1. 设计的策略维度
2. 设计的技术维度
设计的策略维度:
是一个面向业务、具备较高层次的设计维度，偏重于业务架构的梳理以及考虑如何把业务架构和技术架构相结合的问题 包括: a. 通用语言(Ubiquitous Language) 统一团队成员对领域知识的一致认识，促进后续代码模型中的命名等使用领域词汇而不是技术词汇。 通用语言的好处在于: 能够将客户、体验设计师、业务分析师、技术人员集结在一起对业务需求进行沟通，随后对其进行领域划分 这是服务能够有效识别的前提。 b. 子域 子域作为系统拆分的切入点，其来源往往取决于 系统的特征和拆分的需求，如核心功能、辅助性功能、第三方功能等 子域可以分成核心子域、支撑子域和通用子域三种类型 1. 核心子域: 系统中的核心业务 2. 核心子域: 专注于业务某一方面 3. 通用子域: 可用于整个业务系统且作为一种基础设施的功能 c. 界限上下文设计的技术维度:
有助于组织服务内部以及服务与服务之间进行交互的方式 包括: a. 聚合 核心思想在于将关联减至最少有助于简化对象之间的遍历，使用一个抽象来封装模型中的引用 b. 领域事件
界限上下文( Boundary Context )¶
根据界限确定的一个上下文环境
领域与界限上下文¶
子域、聚合和界限上下文三者之间的关系¶
[示例]门诊就医业务流程子域划分¶
界限上下文集成策略¶
上下文集成的基本思路在于解耦和统一:
对于解耦而言:
一方面在于技术实现上的依赖性，需要支持异构系统的有效交互
另一方面也需要把关注于「集成的实现」与「业务逻辑的实现」相分离，确保集成机制的独立性
统一的含义在于一致性，即:
上游系统应该定义协议，让所有下游系统通过协议访问，
确保在数据传输接口和语义上各个上下文之间能够达成一致
防腐层与统一协议:
1. 防腐层(AntiCorruption Layer, ACL )
强调下游系统根据领域模型创建单独一层，该层完成与上游系统之间的交互，从而隔离业务逻辑，实现解耦
面向对象: 下游系统
2. 统一协议( Unified Protocol, UP )
提供一致的协议定义，促使其他系统通过协议访问
面向对象: 上游系统
领域事件:
领域事件( Domain Event ): 把领域中所发生的活动建模成一系列离散事件
关联: 事件驱动
服务边界划分的原则¶
常见的边界划分原则如下:
1. 服务关联度原则
是否该服务变化肘，其他服务也需要进行变化;
或者说该服务中的数据是否通常在当前上下文中的范围内使用
2. 业务能力职责单一原则
服务边界内的业务能力职责应单一
3. 读写分离原则
对于数据读取类型的服务应该尽量放在单独的子域中，而且这种子域一般不应该是核心子域
4. 组织关系原则
a. 可以是职能团队:
常见的服务端、前端、数据库、UI 等功能团队
b. 也可以是特征团队:
一种跨职能的团队构建方式，团队中包括各种职能角色
四. 服务数据¶
对于微服务而言，传统的规范化数据模型(如: 三大范式)存在一定的问题
需要通过数据去中心化手段实现对服务数据的有效管理
数据去中心化过程也就是数据拆分的过程
数据去中心化场景:
1. 跨表查询场景
将连接查询转变为简单的单表查询，然后对各种表查询的结果在内存中进行动态组装
考虑到未来服务拆分或重构的需要，从一开始就保持数据单表查询是一项最佳实践。
2. 跨库查询场景
思路1. 修改频率不高、相对静态的数据而言:
可以采取数据复制的方式达到同一份数据在两个数据库中同时存在的效果
思路2. 实时性要求比较高的数据
则可以通过开放接口的方式实现两个数据库之间的数据集成效果
3. 技术搞合场景
对于关系型数据库而言，如存储过程、触发器等
数据去中心化流程:
1. 代码分离
2. 重复数据库模式
把几个系统公用的数据进行冗余处理
3. 迁移数据读写操作
针对数据库写入和读取操作做单独的抽离
4. 抽取服务化接口
小结¶
服务建模方式的确定是后续进行服务拆分、集成以及围绕服务开展团队协作的基础:
1. 服务建模首先需要「明确服务的分类和模型」
服务分类侧重于梳理服务与业务之间的关系并抽象出不同类别和层次的服务体系，而服务模型则用于表述服务。
2. 服务建模最具挑战性的工作是「明确服务的边界」
业界关于服务边界的划分通常采用面向领域的设计方法。
通过识别业务领域、梳理各个子域之间的关系以及明确界限上下文，
我们可以充分利用领域驱动设计中的各个概念与方法，并结合服务边界划分的各项原则完成服务边界的划分。
3. 服务与数据之间的关系
针对规范化数据模型存在的问题，提出数据去中心化设计思想，
并结合典型场景给出数据去中心化的具体解决方案和工作开展流程。
服务拆分与集成¶
微服务架构关键要素¶
服务治理¶
一个系统存在大量服务时，将会面临更多的挑战。例如，如何提升服务架构的可扩展性，如何进行服务监控和故障定位，如何实现对服务的有效划分和路由。服务治理( Service Governance )是应对这些挑战的统一方法;而在技术实现上，服务治理一般表现为服务发布与订阅机制以及实现该机制的服务注册中心。
服务治理的目标在于保障线上服务运行质量，治理的 对象是基于统一分布式服务框架开发的各项业务服务，服务治理在定位上关注服务运行时状 态、细粒度治理，服务限流/降级、服务动态路由和灰度发布是服务治理的基本策略 。具体实 现上，可以采用通过注册中心对服务依赖进行分析，结合运行时调用关系，梳理不合理的依赖 和调用路径，优化服务架构。实时收集服务调用日志，分析、汇总、存储和展示，方便开发和 运维人员进行实时故障诊断，同时执行服务运行时治理方案，包括限流降级、路由 、 统一配置 等在线调整。
服务可靠性¶
服务「雪崩效应」的产生是一种「扩散效应」
应对失败的基本策略:
舱壁隔离
服务熔断
超时/重试
异步解耦
快速失败
更为系统的方法和机制确保服务的可靠性:
服务容错( Fault Tolerance ) 服务隔离、 服务限流和服务降级。
服务容错( Fault Tolerance ):
1. 失效转移(Failover)
2. 失败通知(Failback)
3. 失败安全(Failsafe)
当获取服务调用异常时，直接忽略。
通常将异常写入审计日志等媒介，确保后续可以根据日志记录找到引起异常的原因并解决
可以理解为一种 简单的熔断机制(Circuit Breaker)，
为了调用链路的完整性，在非关键环节中允许出现错误而不中断整个调用链路。
4. 快速失败(Failfast)
在获取服务调用异常时，立即报错。
显然，Failfast 已经彻底放弃了重试机制，等同于没有容错。
在特定场景中，可以使用该策略确保非核心业务服务只调用一次，为重要的核心服务节约宝贵时间。
5. 分支机制(Forking)
并行调用多个服务器，只要一个成功即返回;
通常用于实时性要求较高的读操作，但需要浪费更多服务资源
6. 广播机制( Broadcast )
就是逐个调用所有提供者，任意一台报错则报错。
通常用于通知所有提供者更新缓存或日志等本地资源信息的业务场景，而不是简单的远程调用。
服务隔离:
舱壁隔离模式( Bulkhead Isolation Pattern ):
像舱壁一样对资源或失败单元进行隔离。
如果一个船舱破了进水，只损失一个船舱，其他船舱可以不受影响。
舱壁隔离模式在微服务架构中的应用就是各种服务隔离思想。
所谓隔离，本质上是对系统或资源进行分割，从而实现当系统发生故障时能限定传播范围和影响范围，
即发生故障后只有出问题的服务不可用，保证其他服务仍然可用。
1. 线程隔离
线程隔离主要通过线程池( Thread Pool )进行隔离。
在实际使用时，我们会把业务进行分类并交给不同的线程池进行处理，
当某个线程池处理一种业务请求发生问题时，不会将故障扩散到其他线程池，
也就不会影响到其他线程池中所运行的业务，从而保证其他服务可用
线程隔离是实现服务隔离的基础
线程隔离机制将每个依赖服务分配独立的线程池进行资源隔离，从而避免服务雪崩
2. 进程隔离
通过进程隔离使得某一个子系统出现问题不会影响到其他子系统
3. 集群隔离
集群隔离是进程隔离的升级版
4. 机房隔离
5. 读写隔离
当读取操作的服务器出现故障时，写服务器可照常运作，反之亦然。
对于离线分析类的应用场景而言，读写隔离可以很好地控制读取操作可能形成的瓶颈对写入操作造成的影响
实例:
使用 Mongodb 进行海量数据存储时，可以采用热库和存档库概念，
将新写入的数据同时存储到热库和存档库。
热库只存储最近一个月的数据，而存档库则保存所有的历史数据。
当要对历史数据进行离线处理时，可以确保热库不受影响
服务限流:
所谓限流即流量限制，限流的目的是在遇到流量高峰期或者流量突增时，
把流量速率限制在系统所能接受的合理范围之内，不至于让系统被高流量击垮
常见的限流方式，包括:
1. 通过限制单位时间段内调用量来限流、
计数器法
滑动窗口( Rolling Window )
2. 通过限制系统的并发调用程度来限流、
3. 使用漏桶( Leaky Bucket )算法来限流
4. 使用令牌桶( Token Bucket)算法来限流
服务降级:
服务降级指的是在服务器压力剧增的情况下，根据当前业务情况及流量对一些服务有策略地降级，
以此释放服务器资源以保证核心任务的正常运行。
降级可以有计划地执行，也可以被动触发
1. 服务分级:
拆分来自于对用户的影响，如:
a. 一级服务会影响到用户对网关的直接使用;
b. 二级服务不影响用户上网，但可能会丢失重要数据，并影响体验;
c. 三级服务所对应系统的稳定性则对线上业务无影响。
2. 服务熔断(Circuit Breaker)
服务熔断类似现实世界中的“保险丝”，当某个异常条件被触发，直接熔断整个服务，而不是一直等到此服务超时
而服务降级就是当某个服务熔断之后，服务端准备一个本地的回退( Fallback )回调，返回一个缺省值
示例: 服务台级¶
熔断器实现上的三个状态机:
1. Closed: 熔断器关闭状态
不对服务调用进行限制，但会对调用失败次数进行积累，到了阔值或一定比例时则启动熔断机制
2. Open: 熔断器打开状态
此时对下游的调用内部直接返回错误，不走真正的网络调用。
同时，熔断器设计了一个时钟选项，当时钟达到了一定时间进入半熔断状态。
(这个时间一般设置成平均故障处理时间，也就是 MTTR )
3. Half-Open: 半熔断状态
允许定量的服务请求，如果:
调用都成功或达到一定比例 则认为调用链路已恢复，关闭熔断器;
否则认为调用链路仍然存在问题，又回到熔断器打开状态 。
服务熔断器结构图¶
参考¶
【书】《微服务设计原理与架构》