分布式系统及 SpringCloud学习日记Day2

1. 服务注册与发现：Eureka（Netflix）、Zookeeper、Consul、Nacos
2. 服务负载与调用：Ribbon（Netflix）、OpenFeign
3. 服务熔断降级：Hystrix、sentinel（Alibaba）
4. 服务网关：Zuul（Netflix）、gateway
5. 服务分布式配置：Config（Spring Cloud）、Nacos（Alibaba）
6. 服务总线：Bus、Nacos（Alibaba）
7. 服务开发：Spring Boot

服务注册：

基本概念：服务注册就是将提供某个服务的模块信息(通常是这个服务的ip和端口)注册到1个公共的组件上去（比如: zookeeper\consul）。

服务注册与服务发现的动机：

微服务器时代，所有的服务都被尽可能的拆分成最小的粒度，原先所有的服务都在混在1个server里，现在就被按照功能或者对象拆分成N个服务模块，这样做的好处是深度解耦，1个模块只负责自己的事情就好，能够实现快速的迭代更新。坏处就是服务的管理和控制变得异常的复杂和繁琐，人工维护难度变大。还有排查问题和性能变差（服务调用时的网络开销）

各个微服务相互独立，每个微服务，由多台机器或者单机器不同的实例组成，各个微服务之间错综复杂的相互关联调用。

如果不使用服务注册，那么维护这种复制的关系网络的唯一方法就是写死，将其他模块的ip和端口写死在自己的配置文件里，甚至写死在代码里，每次要去新增或者移除1个服务的实例的时候，就得去通知其他所有相关联的服务去修改。因此对于各个项目配置文件的反复更新、大规模的ip修改和机器更换都非常的不方便。

由此诞生了服务注册与服务发现

服务注册演示图：

每一个服务对应的机器或者实例在启动运行的时候，都去向名字服务集群注册自己。每个服务的机器实例在启动后，就完成了注册的操作。

注册的方式有很多的形式，不同的名字服务软件方式不一样，有HTTP接口形式，有RPC的方式，也有使用JSON格式的配置表的形式的。方式虽然不同，但是结果都是一样。

服务发现

基本概念：使得新注册的服务模块能够及时的被其他调用者发现。不管是服务新增和服务删减都能实现自动发现。

• 服务提供者：简单来说就是HTTP服务器，提供了API服务，有一个IP端口作为服务地址

• 服务消费者：一个简单的进程，想要访问服务提供者提供的服务来干一些事情。

• 服务中介：联系服务提供者和服务消费者的桥梁。服务提供者将自己提供的服务地址注册到服务中介，服务消费者从服务中介那里查找自己想要的服务的地址，然后享受这个服务。服务中介提供多个服务，每个服务对应多个服务提供者。

  服务中介就是一个字典，字典中有很多key/value键值对，key是服务名称，value是服务提供者的地址列表。服务注册就是调用字典的Put方法塞东西，服务查找就是调用字典的Get方法拿东西。

服务发现演示图：

我们通过服务发现，就获得了User模块的所有的ip列表，然后，我们再用一定的负载均衡算法，或者干脆随机取1个ip，进行调用。

服务发现的方式，不同的名字服务软件的方式也会不一样，有的是得自己发送HTTP接口去轮训调用，如果发现有更新，就更新自己本地的配置文件。有的是可以通过实时的sub/pub的方式实现的自动发现服务，当我订阅的这个服务内容发生了更新，就实时更新自己的配置文件。也有的是通过RPC的方式。方式虽然不同，但是结果都是一样。

服务注册与服务发现的意义：不仅仅解决了服务调用这种写死IP以及杂乱无章的管理的状态，更重要的一点是它还管理了服务器的存活状态，也就是健康检查。

比如，注册服务的这一组机器，当这个服务组的某台机器，如果出现宕机或者服务死掉的时候，就会标记这个实例的状态为故障，或者干脆剔除掉这台机器。这样一来，就实现了自动监控和管理。

因此我们可以通过健康检查这一功能，来帮助我们及时的去规避问题，降低影响。

服务调用

服务三要素：

• 地址：调用方根据地址访问到网络接口。地址包括以下要素：IP地址、服务端口、服务协议（TCP、UDP，etc）
• 协议格式：指的是该协议都有哪些字段，由接口提供者与协议调用者协商之后确定下来
• 协议名称（协议类型）：由于在同一个服务监听端口上面，可能同时提供多种接口服务于调用方，这时候需要协议类型（名称）来区分不同的网络接口。

服务熔断

基本概念：互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。

服务雪崩的概念：下游服务因为某些原因导致不可用，积压了大量请求，中游服务的线程请求也随之阻塞。当线程资源耗尽，中游服务变得不可用，紧接着上游服务也变为不可用，整个调用链路被拖垮。像这种调用链路的连锁故障，叫做雪崩。

演示图例：

此时需要我们的熔断机制来拯救系统。

涉及到的两个步骤：

1. 熔断开启：当固定时间窗口内，接口调用超时比率达到一个阈值，会开启熔断。
   进入熔断状态后，后续对该服务接口的调用不再经过网络，直接执行本地的默认方法，达到服务降级的效果。
2. 熔断恢复：熔断不是永久的，当经过规定时间之后，服务将从熔断状态回复过来，再次接受调用方的远程调用。

服务降级

基本概念：当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。

使用场景：当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，我们可以将一些 不重要 或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用

业务场景：当我们去购物软件、网站去秒杀或者抢购一些限购商品时，此时可能回因为访问量过大而导致系统崩溃，此时开发者会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。