学习微服务
微服务
微服务就是一些协同工作的，小而自治的服务。
随着需求的迭代，新功能的增加，代码库往往会变得越来越大，尽管我们极力希望在巨大的代码库中做到清晰的模块化，但事实上模块与模块之间的界限很难划分得清楚，逐渐地相似的功能代码在代码库中随处可见，以致于在迭代时想要知道该在什么地方做修改都很困难，修复 Bug 和增加新特性新功能越来越难。
在一个单体系统中，通常会创建一些抽象层或者实现模块化来保证代码的 内聚性，从而避免上面提到的问题。
微服务则将这一理念应用在独立的服务上，根据业务的边界确定服务的边界，每个服务专注于服务边界之内的事情，因为可以避免很多由于代码库过大衍生出来的各种问题。
那么一个微服务到底应该多微小？足够小即可，不要过小。那么怎么衡量一个系统是否拆足够小了呢？当你面对这个系统时，不会再有 “过大” 想要拆小它的欲望时，那么它应该就足够小了。服务越小，微服务架构(Microservice) 的优点和缺点也就越明显，使用的服务越小，独立性带来的好处就越多，但管理大量的服务也会更加复杂。
一个微服务就是一个独立的实体，它可以独立被部署，也可以作为一个操作系统进程存在。服务与服务之间存在隔离性，服务之间均通过网络调用进行通信，从而加强服务之间的隔离性，避免紧耦合。服务之间应该可以彼此独立进行修改，并且某一个服务的部署不应该引起该 服务消费方(Service Consumer) 的变动。这就要求我们需要考虑这些 服务提供方(Service Provider) 什么应该暴露，什么应该隐藏，如果暴露得过多，那么 服务消费方(Service Consumer) 会与该服务的内部实现产生耦合，这会使得服务直接产生额外的协调工作，从而降低了服务的自治性。
什么是服务熔断？
考试过程中当断则断的方式，正好符合微服务架构中的一种安全机制：【熔断】
熔断这一概念来源于电子工程中的断路器（Circuit Breaker）。
在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。
这种牺牲局部，保全整体的措施就叫做熔断。
如果不采取熔断措施，我们的系统会怎样呢？
我们来看一个栗子。
当前系统中有A，B，C三个服务，服务A是上游，服务B是中游，服务C是下游。
一旦下游服务C因某些原因变得不可用，积压了大量请求，服务B的请求线程也随之阻塞。线程资源逐渐耗尽，使得服务B也变得不可用。
紧接着，服务A也变为不可用，整个调用链路被拖垮。
像这种调用链路的连锁故障，叫做雪崩。
在这种时候，就需要我们的熔断机制来挽救整个系统。
熔断机制的大体流程和刚才所讲的考试策略如出一辙：
这里需要解释两点：
- 开启熔断
在固定时间窗口内，接口调用超时比率达到一个阈值，会开启熔断。
进入熔断状态后，后续对该服务接口的调用不再经过网络，直接执行本地的默认方法，达到服务降级的效果。 - 熔断恢复
熔断不可能是永久的。
当经过了规定时间之后，服务将从熔断状态回复过来，再次接受调用方的远程调用。