《深入理解 Spring Cloud 与微服务构建》第二章微服务应该具备的功能

文章目录

《深入理解 Spring Cloud 与微服务构建》第二章微服务应该具备的功能
一、微服务应该具备的功能
- 1.微服务的特点
- 2.微服务的功能
二、服务的注册与发现
三、服务的负载均衡
四、服务的容错
五、服务网关
六、服务配置的统一管理
七、服务链路追踪

一、微服务应该具备的功能

1.微服务的特点

按照业务来划分服务，单个服务代码量小，业务单一，易于维护
每个微服务都有自己独立的基础组件。例如数据库、缓存等，且运行在独立的进程中
微服务之间的通信是通过 HTTP 协议或者消息组件，且具有容错能力
微服务有一套服务治理的解决方案，服务之间不耦合，可以随时加入和剔除服务
单个微服务能够集群化部署，并且有负载均衡的能力
整个微服务系统应该有一个完整的安全机制，包括用户验证、权限验证、资源保护等
整个微服务系统有链路追踪的能力
有一套完整的实时日志系统

2.微服务的功能

服务的注册和发现
服务的负载均衡
服务的容错
服务网关
服务配置的统一管理
服务链路追踪
实时日志

二、服务的注册与发现

由于微服务系统的服务粒度较小，服务数量众多，服务之间的相互依赖成网状，所以微服务系统需要服务注册中心来统一管理为服务实例，方便查看每一个为服务实例的健康状态

服务注册是指向服务注册中心注册一个服务实例，服务提供者将自己的服务信息（如服务命、IP 地址等）告知服务注册中心

服务发现是指当服务消费者需要消费另外一个服务时，服务注册中心能够告知服务消费者它所要消费服务的实例信息（如服务命、IP 地址等）

通常情况下，一个服务既是服务提供者，也是服务消费者。服务消费者一般使用 HTTP 协议或者消息组件这种轻量级的通信机制来进行服务消费

服务注册中心会提供服务的健康检查方案，检查被注册的服务是否可用。通常一个服务实例注册后，会定时向服务注册中心提供 “心跳”，以表明自己还处于可用的状态。当一个服务实例停止向服务注册中心提供心跳一段时间后，服务注册中心会认为该服务实例不可用，会将该服务实例从服务注册列表中剔除。如果这个被剔除掉的服务实例过一段时间后继续向注册中心提供心跳，那么服务注册中心会将该服务实例重新加入服务注册中心的列表中。另外，微服务的服务注册组件都会提供服务的健康状况查看的 UI 界面，开发人员或者运维人员只需要登录相关的界面就可以知道服务的健康状态

三、服务的负载均衡

服务之间的相互调用一般是通过 HTTP 通信协议来实现的，网络往往具有不可靠性，为了保证服务的高可用，服务单元往往是集群化部署的。例如将服务提供者进行集群化部署，那么服务消费者该调用哪个服务提供者的实例呢？这就涉及了服务的负载均衡

服务的负载均衡
服务的负载均衡一般最流行的做法是，所有的服务都向服务注册中心注册，服务注册中心持有每个服务的应用名和 IP 地址等信息，同时每个服务也会获取所有服务注册列表信息。服务消费者集成负载均衡组件，该组件会向服务消费者获取服务注册列表信息，并每隔一段时间重新刷新获取该列表。当服务消费者消费服务时，负载均衡组件获取服务提供者所有实例的注册信息，并通过一定的负载均衡策略（开发者可以配置），选择一个服务提供者的实例，向该实例进行服务消费，这样就实现了负载均衡

服务注册中心的负载均衡
服务注册中心不但需要定时接受每个服务的心跳（用来检查服务是否可用），而且每个服务会定期获取服务注册列表的信息，当服务实例数量很多时，服务注册中心承担了非常大的负载。由于服务注册中心在微服务系统中起到了至关重要的作用，所以也必须实现高可用。一般的做法是将服务注册中心集群化，每个服务注册中心的数据实时同步

四、服务的容错

微服务落地到实际项目中，服务的数量往往非常多，服务之间的相互依赖性也是错综复杂的，一个网络请求通常需要调用多个服务才能完成。如果一个服务不可用，例如网络延迟或故障，会影响到依赖于这个不可用的服务的其它服务。一个微服务系统有很多个服务，当服务 A 因某些原因导致了服务的不可用，来自于用户的网络请求需要调用服务 A。由于服务 A 无响应，用户的请求都处于阻塞状态，在高并发的场景下，短时间内会导致服务器的线程资源消耗殆尽。另外，依赖于服务 A 的其它服务也都会等待服务 A 的响应，处于阻塞状态，导致这些服务的线程资源消耗殆尽，进而导致它们的不可用，以及依赖于它们的服务的不可用，最后导致整个系统处于瘫痪的状态，也就是 “雪崩”

为了解决分布式系统的雪崩效应，分布式系统引进了熔断器机制。当一个服务的处理用户请求的失败次数在一定时间内小于设定的阈值时，熔断器处于关闭状态，服务正常；当服务处理用户请求的失败次数大于设定的阈值时，说明服务出现了故障，打开熔断器，这时所有的请求会执行快速失败，不执行业务逻辑。当熔断器处于打开状态时，一段时间后会变更为半打开状态，并执行一定数量的请求，剩余的请求会执行快速失败，若执行的请求失败了，则继续打开熔断器；若成功了，则将熔断器关闭

这种机制有着非常重要的意义，它不仅能过够有效地防止系统的 “雪崩” 效应，还具有以下作用：

将资源进行隔离。如果某个服务里的某个 API 接口出现了故障，只会隔离该 API 接口，不会影响到其它 API 接口。被隔离的 API 接口会执行快速失败的逻辑，不会等待，请求不会阻塞。如果不进行这种隔离，请求会一直处于阻塞状态，直到超时。若有大量的请求同时涌入，都处于阻塞的状态，服务器的i线程资源会被迅速消耗完
服务降级的功能。当服务处于正常的状态时，大量的请求在短时间内同时涌入，超过了服务的处理能力，这时熔断器会被打开，将服务降级，以免服务器因负载过高而出现故障
自我修复能力。当因某个微小的故障（例如网络服务商的问题），导致网络在短时间内不可用，熔断器被打开。如果不能自我监控、自我检测和自我修复，那么需要开发人员手动地去关闭熔断器，无疑会增加开发人员的工作量

Netflix 的 Hystrix 熔断器功能非常强大，不仅有熔断器的功能，还有熔断器的状态监测，并提供界面友好的 UI，开发人员或者运维人员通过 UI 界面能够直观地看到熔断器的状态和各种性能指标

五、服务网关

微服务系统通过将资源以 API 接口的形式暴露给外界来提供服务。在微服务系统中，API 接口资源通常是由服务网关（也称 API 网关）统一暴露，内部服务不直接对外提供 API 资源的暴露。这样做的好处是将内部服务隐藏起来，外界还以为是一个服务在提供服务，在一定程度上保护了微服务系统的安全。API 网关通常有请求转发的作用，另外它可能需要负责一定的安全验证，例如判断某个请求是否合法，该请求对某一个资源是否具有操作权限等。通常情况下，网管层以集群的形式存在。在服务网关层之前，有可能需要加上负载均衡层，通常为 Nginx 双机热备，通过一定的路由策略，将请求转发到网关层。到达网关层后，经过一系列的用户身份验证、权限判断，最终转发到具体的服务。具体的服务经过一系列的逻辑运算和数据操作，最终将结果返回给用户

双机热备

双机热备是应用于服务器的一种解决方案，其构造思想是主机和从机通过 TCP/IP 网络连接，正常情况下主机处于工作状态，从机处于监视状态，一旦从机发现主机异常，从机将会在很短的时间之内代替主机，完全实现主机的功能

网关层具有很重要的意义：

网关将所有服务的 API 接口资源统一整合，对外统一暴露，外界系统调用的 API 接口都是网关对外暴露的 API 接口。外界系统不需要知道微服务微服务架构中各服务相互调用的复杂性，微服务系统也保护了其内部微服务单元的 API 接口，防止被外界直接调用以及服务的敏感信息对外暴露
网关可以做一些用户身份认证、权限认证、防止非法请求操作 API 接口，对内部服务起到保护作用
网关可以实现监控功能，实时日志输出，对请求进行记录
网关可以用来做流量监控，在高流量的情况下，对服务进行降级
API 接口从内部服务分离出来，方便做测试

当然，网关实现这些功能，需要做高可用，否则网关很可能成为架构中的瓶颈。最常用的网关组件有 Zuul 和 Nginx 等

六、服务配置的统一管理

在实际开发过程中，每个服务都有大量的配置文件，例如数据库的配置、日志输出级别的配置等，而往往这些配置在不同的环境中也是不一样的。随着服务数量的增加，配置文件的管理也是一件非常复杂的事

在微服务架构中，需要有统一管理配置文件的组件，例如 Spring Cloud 的 Spring Cloud Config 组件、阿里巴巴的 Diamond、百度的 Disconf、携程的 Apollo 等。这些配置组件所实现的功能大体相同，但是又有些差别，下面以 Spring Cloud Config 为例来阐述服务配置的统一管理

首先，Config Server（配置服务）读取配置文件仓库的配置信息，其中配置文件仓库可以存放在配置服务的本地仓库，也可以放在远程的 Git 仓库（例如 GitHub、Coding 等）
配置服务启动后，读取配置文件信息，读取完成的配置信息存放在配置服务的内存中
当启动服务 A、B 时，由于服务 A、B 指定了向配置服务读取配置信息，服务 A、B 会向配置服务读取配置信息
当服务的配置信息需要修改且修改完成后，向配置服务发送 Post 请求进行刷新，这时服务 A、B 回向配置服务重写读取配置文件

对于集群化的服务，可以通过使用消息总线来刷新多个服务实例。如果服务数量较多，对配置中心需要考虑集群化部署，从而使配置中心高可用，做分布式集群

七、服务链路追踪

微服务系统是一个分布式架构的系统，微服务系统按业务划分服务单元，一个微服务系统往往有很多个服务单元。由于服务单元数量很多且业务复杂，服务与服务之间的调用有可能非常复杂，一旦出现了异常和错误，就会很难去定位。所以在微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而使每个请求链路清晰可见，出了问题很快就能定位

目前，常见的链路追踪组件有 Google 的 Dapper、Twitter 的 Zipkin，以及阿里的 Eagleeye 等，都是非常优秀的链路追踪开源组件