一张图了解Spring Cloud微服务架构

 

Spring Cloud做为当下主流的微服务框架，可让咱们更简单快捷地实现微服务架构。Spring Cloud并无重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，经过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。Spring Cloud中各个组件在微服务架构中扮演的角色以下图所示，黑线表示注释说明，蓝线由A指向B，表示B从A处获取服务。

Spring Cloud组成的微服务架构图

由上图所示微服务架构大体由上图的逻辑结构组成，其包括各类微服务、注册发现、服务网关、熔断器、统一配置、跟踪服务等。下面说说Spring Cloud中的组件分别充当其中的什么角色。

Fegin（接口调用）：微服务之间经过Rest接口通信，Spring Cloud提供Feign框架来支持Rest的调用，Feign使得不一样进程的Rest接口调用得以用优雅的方式进行，这种优雅表现得就像同一个进程调用同样。

Netflix eureka（注册发现）：微服务模式下，一个大的Web应用一般都被拆分为不少比较小的Web应用（服务），这个时候就须要有一个地方保存这些服务的相关信息，才能让各个小的应用彼此知道对方，这个时候就须要在注册中心进行注册。每一个应用启动时向配置的注册中心注册本身的信息（IP地址，端口号, 服务名称等信息），注册中心将他们保存起来，服务间相互调用的时候，经过服务名称就能够到注册中心找到对应的服务信息，从而进行通信。注册与发现服务为微服务之间的调用带来了方便，解决了硬编码的问题。服务间只经过对方的服务ID，而无需知道其IP和端口便可以获取对方方服务。

Ribbon（负载均衡）：Ribbon是Netflix发布的负载均衡器，它有助于控制HTTP和TCP客户端的行为。为Ribbon，配置服务提供者的地址列表后，Ribbon就可基于某种负载均衡算法，自动地帮助服务消费者去请求。Ribbon默认为咱们提供了不少的负载均衡算法，例如轮询、随机等。固然，咱们也可为Ribbon实现自定义的负载均衡算法。在Spring Cloud中，当Ribbon与Eureka配合使用时，Ribbon可自动从EurekaServer获取服务提供者的地址列表，并基于负载均衡算法，请求其中一个服务提供者的实例（为了服务的可靠性，一个微服务可能部署多个实例）。

Hystrix（熔断器）：当服务提供者响应很是缓慢，那么消费者对提供者的请求就会被强制等待，直到提供者响应或超时。在高负载场景下，若是不作任何处理，此类问题可能会致使服务消费者的资源耗竭甚至整个系统的崩溃（雪崩效应）。Hystrix正是为了防止此类问题发生。Hystrix是由Netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提高系统的可用性与容错性。Hystrix主要经过如下几点实现延迟和容错。

• 包裹请求：使用HystrixCommand（或HystrixObservableCommand）包裹对依赖的调用逻辑，每一个命令在独立线程中执行。这使用了设计模式中的“命令模式”。
• 跳闸机制：当某服务的错误率超过必定阈值时，Hystrix能够自动或者手动跳闸，中止请求该服务一段时间。
• 资源隔离：Hystrix为每一个依赖都维护了一个小型的线程池（或者信号量）。若是该线程池已满，发往该依赖的请求就被当即拒绝，而不是排队等候，从而加速失败断定。
• 监控：Hystrix能够近乎实时地监控运行指标和配置的变化，例如成功、失败、超时和被拒绝的请求等。
• 回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑可由开发人员指定。

Zuul（微服务网关）：不一样的微服务通常会有不一样的网络地址，而外部客户端可能须要调用多个服务的接口才能完成一个业务需求。例如一个电影购票的手机APP，可能调用多个微服务的接口才能完成一次购票的业务流程，若是让客户端直接与各个微服务通讯，会有如下的问题：

• 客户端会屡次请求不一样的微服务，增长了客户端的复杂性。
• 存在跨域请求，在必定场景下处理相对复杂。
• 认证复杂，每一个服务都须要独立认证。
• 难以重构，随着项目的迭代，可能须要从新划分微服务。例如，可能将多个服务合并成一个或者将一个服务拆分红多个。若是客户端直接与微服务通讯，那么重构将很难实施。
• 某些微服务可能使用了对防火墙/浏览器不友好的协议，直接访问时会有必定的困难。

以上问题可借助微服务网关解决。微服务网关是介于客户端和服务器端之间的中间层，全部的外部请求都会先通过微服务网关。使用微服务网关后，微服务网关将封装应用程序的内部结构，客户端只用跟网关交互，而无须直接调用特定微服务的接口。这样，开发就能够获得简化。不只如此，使用微服务网关还有如下优势：

• 易于监控。可在微服务网关收集监控数据并将其推送到外部系统进行分析。
• 易于认证。可在微服务网关上进行认证，而后再将请求转发到后端的微服务，而无须在每一个微服务中进行认证。
• 减小了客户端与各个微服务之间的交互次数。

SpringCloud Config & Spring Cloud Bus（ 统一配置服务）：对于传统的单体应用，常使用配置文件管理全部配置。例如一个SpringBoot开发的单体应用，可将配置内容放在application.yml文件中。若是须要切换环境，可设置多个Profile，并在启动应用时指定spring.profiles.active={profile}。然而，在微服务架构中，微服务的配置管理通常有如下需求：

• 集中管理配置。一个使用微服务架构的应用系统可能会包含成百上千个微服务，所以集中管理配置是很是有必要的。
• 不一样环境，不一样配置。例如，数据源配置在不一样的环境（开发、测试、预发布、生产等）中是不一样的。
• 运行期间可动态调整。例如，可根据各个微服务的负载状况，动态调整数据源链接池大小或熔断阈值，而且在调整配置时不中止微服务。
• 配置修改后可自动更新。如配置内容发生变化，微服务可以自动更新配置。综上所述，对于微服务架构而言，一个通用的配置管理机制是必不可少的，常见作法是使用配置服务器管理配置。Spring Cloud Bus利用Git或SVN等管理配置、采用Kafka或者RabbitMQ等消息总线通知全部应用，从而实现配置的自动更新而且刷新全部微服务实例的配置。

Sleuth+ZipKin（跟踪服务）：Sleuth和Zipkin结合使用能够经过图形化的界面查看微服务请求的延迟状况以及各个微服务的依赖状况。须要注意的是Spring Boot 2及以上不在支持Zipkin的自定义，须要到官方网站下载ZipKin相关的jar包。另外须要提一点的是Spring Boot Actuator，提供了不少监控端点如/actuator/info、/actuator/health、/acutator/refresh等，能够查看微服务的信息、健康情况、刷新配置等。

原文连接：一张图了解Spring Cloud微服务架构（做者：SimpleEasy）