宝塔服务器面板，一键全能部署及管理，送你10850元礼包，点我领取

Spring Cloud作为当前主流的微服务框架，可以更轻松、更快地实现微服务体系结构。 Spring Cloud并不是重复车轮，而是将目前各公司开发的相对成熟、经得起实际考验的服务框架结合起来，以Spring Boot样式重新打包，从而消除复杂的配置和实现原理，最终让开发人员明白Spring Cloud的各组件在微服务架构中内向的龙猫如下图所示，黑线表示评论的说明，蓝线表示从a指向b，b表示从a接受服务。

由Spring Cloud组成的微服务体系结构图

上图所示的微服务架构由上图的逻辑结构构成，包括各种微服务、注册发现、服务网关、熔丝、统一配置、跟踪服务等。 说明每个Spring Cloud组件都起着什么作用。

Fegin (接口调用)微服务通过Rest接口进行通信，Spring Cloud为支持Rest调用提供了Feign框架。 Feign会优雅地调用不同进程的Rest接口。 这种优雅表现为相同的进程调用。

在Netflix eureka微服务模式下，较大的web APP通常被划分为许多相对较小的web APP (服务)。 此时，每个小APP都需要一个位置来存储有关这些服务的信息，以便彼此了解对方。 此时，需要在注册中心注册。 每个APP应用在启动时配置的注册中心注册自己的信息(IP地址、端口号、服务名等信息)，注册中心保存它们，在服务之间相互调用时，通过服务名与注册中心对应的服务注册和发现服务给微服务之间的调用带来了便利，解决了硬编码问题。 服务之间只有对方的服务ID，不需要知道其IP或端口就可以取得对方的服务。

Ribbon:Ribbon是Netflix发行的负载平衡器，有助于控制HTTP和TCP客户端的行为。 为功能区配置服务提供商的地址列表后，功能区可以基于一种负载均衡算法自动帮助服务消费者请求。 默认情况下，Ribbon为我们提供了许多负载平衡算法，包括轮询、随机等。 当然，还可以为功能区实现自己的负载平衡算法。 在Spring Cloud中，如果Ribbon与Eureka协作，则Ribbon可以自动从EurekaServer获取服务提供者的地址列表，并基于负载平衡算法请求服务提供者的实例之一为了服务的可靠性，也可以在一个微服务器上部署多个实例。

如果Hystrix (保险丝)服务提供者响应非常慢，则消费者对提供者的请求将被强制等待，直到提供者响应或超时。 在高负荷情况下，如果什么都不做，这样的问题就有可能导致服务消费者资源枯竭和系统整体崩溃(雪崩效应)。 Hystrix是为了防止这种问题。 Hystrix是一个由Netflix开放源代码的延迟和容错库，通过隔离对远程系统、服务或第三方库的访问并防止级联错误来实现系统Hystrix主要在以下方面提供延迟和容错：

包装请求：用HystrixCommand (或HystrixObservableCommand )包装依赖关系的调用逻辑，每个命令都在独立的线程上运行。 这使用了设计模式的“命令模式”。 跳闸机制：如果一个服务的错误率超过一定阈值，Hystrix可以自动或手动跳闸，并在一定时间内停止服务请求。 资源隔离Hystrix为每个依赖项维护一个小线程池(或信号)。 当线程池已满时，对依赖项的请求将立即被拒绝，而不是排队，从而加快失败的确定。 监控Hystrix几乎实时监控执行指标和配置更改，包括成功、失败、超时和拒绝的请求。 回滚机制：在请求失败、超时、拒绝或断路器打开时执行回滚逻辑。 回退逻辑可以由开发人员指定。 微服务网关(zul ) :网络地址通常因微服务而异，但外部客户端可能需要调用多个服务的接口来满足单个业务需求。 举例来说，在电影中购票的手机APP可能可以通过一个以上的微服务界面来完成一次购票的工作流程，但如果让客户端直接与各微服务通信，就会出现以下问题：

客户端多次请求不同的微服务，增加了客户端的复杂性。 有域间要求，一定场景下的处理比较复杂。 认证很复杂，每个服务都需要独立的认证。 重构可能很难，并且随着项目的迭代，可能需要重新划分微服务。 例如，可以将多个服务合并为一个，也可以将一个服务分割为多个。 如果客户端直接与微服务通信，重构实现将变得困难。 某些微服务可能使用对防火墙/浏览器不友好的协议，因此很难直接访问。 以上问题可以通过微服务网关解决。 微服务网关是介于客户端和服务器端之间的中间层，所有外部请求首先通过微服务网关。 使用微服务网关，微服务网关封装了APP应用程序的内部结构，客户端只需与网关进行交互，而无需直接调用特定微服务的接口。 这简化了开发。 不仅如此，使用微服务网关还具有以下优点：

容易监视。 可以在微服务网关上收集监视数据，并将其推送到外部系统进行分析。 容易认证。 可以在微服务网上关闭认证，然后将请求转发到后端微服务，而无需在每个微服务上进行认证。 减少了客户端和单个微服务之间的交互次数。 Spring Cloud Bus :传统的单元APP应用程序经常使用配置文件来管理所有配置。 例如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等，可以查看微服务的信息、健康状况、刷新配置等。

读者福利（学习分享）
对于很多初级Java工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。整理的这些架构技术希望对Java开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。同时我经过多年的收藏目前也算收集到了一套完整的二手手游账号拍卖平台学习资料以及高清详细的Java架构进阶学习导图及笔记免费分享给大家，希望对想成为架构师的朋友有一定的参考和帮助。
下面是部分资料截图，诚意满满：特别适合有1-5年开发经验的Java程序员们学习。
资料免费领取方式：关注小编并私信“Java”免费获取！

资料免费领取方式：Java面试必备学习资源免费获取