深入理解Spring Cloud与微服务构建【二】 - 2.1 微服务应该具备的功能

微服务具有以下的特点。

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

微服务的功能主要 体现在以下儿个方面。

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

2.1.1 服务的注册与发现（接口管理）

• 服务注册是指向服务注册中心注册一个服务实例，服务提供者将自己的服务信息（如服务 名、 IP 地址等〉告知服务注册中心。服务发现是指当服务消费者需要消费另外一个服务时， 服务注册中心能够告知服务消费者它所要消费服务的实例信息（如服务名、 IP 地址等〉。通常 情况下， 一个服务既是服务提供者，也是服务消费者。服务消费者一般使用 HTTP 协议或者消息组件这种轻盘级的通信机制来进行服务消费。

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

2.1 .2 服务的负载均衡（分发请求）

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

所有的服务都向服务注册中心注册，服务注册中心持有每个服务的应用名和 IP 地址等信息，同时每个服务也会获取所有服务注册列表信息。

服务消费者集成负载均衡组件，该组件会向服务消费者获取服务注册列表信息，并每隔一段时间重新刷新获取该列表。当服务消费者消费服务时，负载均衡组件获取服务提供者所 有实例的注册信息，并通过一定的负载均衡策略（开发者可以配置〉，选择一个服务提供者的 实例，向该实例进行服务消费，这样就实现了负载均衡。
服务注册中心不但需要定时接收每个服务的心跳（用来检查服务是否可用），而且每 个服务会定期获取服务注册列表的信息，当服务实例数量很多时，服务注册中心承担了 非常大的负载。由于服务注册中心在微服务系统中起到了至关重要的作用，所以必须实 现高可用。 一般的做法是将服务注册中心集群化，每个服务注册中心的数据实时同步， 如图 2-3 所示。

2.1.3 服务的容错（防止雪崩效应）

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

Netflix 的 Hystrix 熔断器开源组件功能非常强大，不仅有烙断器的功能，还有熔断器的状态 监测，并提供界面友好的 UI， 开发人员或者运维人员通过 UI 界面能够直观地看到熔断器的状 态和各种性能指标。
其余就不做多余讲解了，有兴趣的同学可以看看前面的文章。

2.1.4 服务网关（接口统一暴露）

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

网关层具有很重要的意义， 具体体现在以下方面。

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

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

2.1 .5 服务配置的统一管理

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

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

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

2.1.6 服务链路追踪

在微服务系统中 ， 一个来自用户 的请求先达到前端 A C如前端界面），然后通过远程调用，达到 系统的中间件 B、 c （如负载均衡、网关等），最后达到后端服 务 D、 E。后端经过一系列的业务逻辑计算，最后将数据返回给 用户。对于这样一个请求， 经历了这么多服务， 怎么样将它的 请求过程的数据记录下来呢？这就需要用到服务链路追踪。
目前，常见的链路追踪组件有 Google 的 Dapper、 Twitter 的 Zipkin，以及阿里的 Eagleeye （鹰眼）等，都是非常优秀的链路追踪开源组件。