SpringCloud技术分析
现如今微服务架构⼗分流⾏，⽽采⽤微服务构建系统也会带来更清晰的业务划分和可扩展性。同时，⽀持微服务的技术栈也是多种多样的，本系列⽂章主要介绍这些技术中的翘楚——Spring Cloud。这是序篇，主要讲述我们为什么选择Spring Cloud和它的技术概览。
⼀、为什么微服务架构需要Spring Cloud
简单来说，服务化的核⼼就是将传统的⼀站式应⽤根据业务拆分成⼀个⼀个的服务，⽽微服务在这个基础上要更彻底地去耦合（不再共享DB、KV，去掉重量级ESB），并且强调DevOps和快速演化。这就要求我们必须采⽤与⼀站式时代、泛SOA时代不同的技术栈，⽽Spring Cloud就是其中的佼佼者。
DevOps是英⽂Development和Operations的合体，他要求开发、测试、运维进⾏⼀体化的合作，进⾏更⼩、更频繁、更⾃动化的应⽤发布，以及围绕应⽤架构来构建基础设施的架构。这就要求应⽤充分的内聚，也⽅便运维和管理。这个理念与微服务理念不谋⽽合。
接下来我们从服务化架构演进的⾓度来看看为什么Spring Cloud更适应微服务架构。
1.1 从使⽤nginx说起
最初的服务化解决⽅案是给提供相同服务提供⼀个统⼀的域名，然后服务调⽤者向这个域名发送HTTP请求，由Nginx 负责请求的分发和跳转。
这种架构存在很多问题:
Nginx作为中间层，在配置⽂件中耦合了服务调⽤的逻辑，这削弱了微服务的完整性，也使得Nginx在⼀定程度上变成了⼀个重量级的ESB。
服务的信息分散在各个系统，⽆法统⼀管理和维护。每⼀次的服务调⽤都是⼀次尝试，服务消费者并不知道有哪些实例在给他们提供服务。这不符合DevOps的理念。
⽆法直观的看到服务提供者和服务消费者当前的运⾏状况和通信频率。这也不符合DevOps的理念。
消费者的失败重发，负载均衡等都没有统⼀策略，这加⼤了开发每个服务的难度，不利于快速演化。
为了解决上⾯的问题，我们需要⼀个现成的中⼼组件对服务进⾏整合，将每个服务的信息汇总，包括服务的组件名称、地址、数量等。服务的调⽤⽅在请求某项服务时⾸先通过中⼼组件获取提供这项服务的实例的信息（IP、端⼝等），再通过默认或⾃定义的策略选择该服务的某⼀提供者直接进⾏访问。所以，我们引⼊了Dubbo。
1.2 基于Dubbo实现微服务
Dubbo是阿⾥开源的⼀个SOA服务治理解决⽅案，⽂档丰富，在国内的使⽤度⾮常⾼。
使⽤Dubbo构建的微服务，已经可以⽐较好地解决上⾯提到的问题：
springcloud难学吗调⽤中间层变成了可选组件，消费者可以直接访问服务提供者。
服务信息被集中到Registry中，形成了服务治理的中⼼组件。
通过Monitor监控系统，可以直观地展⽰服务调⽤的统计信息。
Consumer可以进⾏负载均衡、服务降级的选择。
但是对于微服务架构⽽⾔，Dubbo也并不是⼗全⼗美的：
Registry严重依赖第三⽅组件（zookeeper或者redis），当这些组件出现问题时，服务调⽤很快就会中断。
DUBBO只⽀持RPC调⽤。使得服务提供⽅与调⽤⽅在代码上产⽣了强依赖，服务提供者需要不断将包含公共代码的jar 包打包出来供消费者使⽤。⼀旦打包出现问题，就会导致服务调⽤出错。
最为重要的是，DUBBO现在已经停⽌维护了，对于技术发展的新需求，需要由开发者⾃⾏拓展升级。这对于很多想要采⽤微服务架构的中⼩软件组织，显然是不太合适的。
1.3 新的选择——Spring Cloud
作为新⼀代的服务框架，Spring Cloud提出的⼝号是开发“⾯向云环境的应⽤程序”，它为微服务架构提供了更加全⾯的技术⽀持。
结合我们⼀开始提到的微服务的诉求，我们把Spring Cloud与DUBBO进⾏⼀番对⽐：
微服务需要的功能Dubbo Spring Cloud
服务注册和发现Zookeeper Eureka
服务调⽤⽅式RPC RESTful API
断路器有有
负载均衡有有
服务路由和过滤有有
分布式配置⽆有
分布式锁⽆计划开发
集选主⽆有
微服务需要的功能Dubbo Spring Cloud
分布式消息⽆有
Spring Cloud抛弃了Dubbo的RPC通信，采⽤的是基于HTTP的REST⽅式。严格来说，这两种⽅式各有优劣。虽然从⼀定程度上来说，后者牺牲了服务调⽤的性能，但也避免了上⾯提到的原⽣RPC带来的问题。⽽且REST相⽐RPC更为灵活，服务提供⽅和调⽤⽅的依赖只依靠⼀纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。
很明显，Spring Cloud的功能⽐DUBBO更加强⼤，涵盖⾯更⼴，⽽且作为Spring的拳头项⽬，它也能够与Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring项⽬完美融合，这些对于微服务⽽⾔是⾄关重要的。前⾯提到，微服务背后⼀个重要的理念就是持续集成、快速交付，⽽在服务内部使⽤⼀个统⼀的技术框架，显然⽐把分散的技术组合到⼀起更有效率。更重要的是，相⽐于Dubbo，它是⼀个正在持续维护的、社区更加⽕热的开源项⽬，这就保证使⽤它构建的系统，可以持续地得到开源⼒量的⽀持。
⼆、Spring Cloud技术概览
服务治理：这是Spring Cloud的核⼼。⽬前Spring Cloud主要通过整合Netflix的相关产品来实现这⽅⾯的功能（Spring Cloud Netflix），包括⽤于服务注册和发现的Eureka，调⽤断路器Hystrix，调⽤端负载均衡
Ribbon，Rest客户端Feign，智能服务路由Zuul，⽤于监控数据收集和展⽰的Spectator、Servo、Atlas，⽤于配置读取的Archaius和提供Controller层Reactive封装的RxJava。除此之外，针对
Feign和RxJava并不是Netiflix的产品，但是被整合到了Spring Cloud Netflix中。
对于服务的注册和发现，除了Eureka，Spring Cloud也整合了Consul和Zookeeper作为备选，但是因为这两个⽅案在CAP理论上都遵循CP⽽不是AP（下⼀篇会详细介绍这点），所以官⽅并没有推荐使⽤。
分布式链路监控：Spring Cloud Sleuth提供了全⾃动、可配置的数据埋点，以收集微服务调⽤链路上的性能数据，并发送给Zipkin进⾏存储、统计和展⽰。
消息组件：Spring Cloud Stream对于分布式消息的各种需求进⾏了抽象，包括发布订阅、分组消费、消息分⽚等功能，实现了微服务之间的异步通信。Spring Cloud Stream也集成了第三⽅的RabbitMQ和Apache Kafka作为消息队列的实现。⽽Spring Cloud Bus基于Spring Cloud Stream，主要提供了服务间的事件通信（⽐如刷新配置）。
配置中⼼：基于Spring Cloud Netflix和Spring Cloud Bus，Spring⼜提供了Spring Cloud Config，实现了配置集中管理、动态刷新的配置中⼼概念。配置通过Git或者简单⽂件来存储，⽀持加解密。
安全控制：Spring Cloud Security基于OAUTH2这个开放⽹络的安全标准，提供了微服务环境下的单点登录、资源授权、令牌管理等功能。
命令⾏⼯具：Spring Cloud Cli提供了以命令⾏和脚本的⽅式来管理微服务及Spring Cloud组件的⽅式。
集⼯具：Spring Cloud Cluster提供了集选主、分布式锁（暂未实现）、⼀次性令牌（暂未实现）等分布式集需要的技术组件。
后续章节我们会详细介绍我们实际使⽤到的Spring Cloud组件。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。