微服务为什么选Spring Cloud?

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
简介: 现如今微服务架构十分流行,而采用微服务构建系统也会带来更清晰的业务划分和可扩展性。同时,支持微服务的技术栈也是多种多样的,本系列文章主要介绍这些技术中的翘楚——Spring Cloud。

现如今微服务架构十分流行,而采用微服务构建系统也会带来更清晰的业务划分和可扩展性。同时,支持微服务的技术栈也是多种多样的,本系列文章主要介绍这些技术中的翘楚——Spring Cloud。这是序篇,主要讲述我们为什么选择Spring Cloud和它的技术概览。

1、为什么微服务架构需要Spring Cloud

简单来说,服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务,而微服务在这个基础上要更彻底地去耦合(不再共享DB、KV,去掉重量级ESB),并且强调DevOps和快速演化。这就要求我们必须采用与一站式时代、泛SOA时代不同的技术栈,而Spring Cloud就是其中的佼佼者。

DevOps是英文Development和Operations的合体,他要求开发、测试、运维进行一体化的合作,进行更小、更频繁、更自动化的应用发布,以及围绕应用架构来构建基础设施的架构。这就要求应用充分的内聚,也方便运维和管理。这个理念与微服务理念不谋而合。

接下来我们从服务化架构演进的角度来看看为什么Spring Cloud更适应微服务架构。点击这里查看Spring系列教程集合。

1.1 从使用nginx说起

最初的服务化解决方案是给提供相同服务提供一个统一的域名,然后服务调用者向这个域名发送HTTP请求,由Nginx负责请求的分发和跳转。

img_0afb1e72728fea10be7ab00ed735df3b.png

这种架构存在很多问题:

Nginx作为中间层,在配置文件中耦合了服务调用的逻辑,这削弱了微服务的完整性,也使得Nginx在一定程度上变成了一个重量级的ESB。

服务的信息分散在各个系统,无法统一管理和维护。每一次的服务调用都是一次尝试,服务消费者并不知道有哪些实例在给他们提供服务。这不符合DevOps的理念。

无法直观的看到服务提供者和服务消费者当前的运行状况和通信频率。这也不符合DevOps的理念。

消费者的失败重发,负载均衡等都没有统一策略,这加大了开发每个服务的难度,不利于快速演化。

为了解决上面的问题,我们需要一个现成的中心组件对服务进行整合,将每个服务的信息汇总,包括服务的组件名称、地址、数量等。服务的调用方在请求某项服务时首先通过中心组件获取提供这项服务的实例的信息(IP、端口等),再通过默认或自定义的策略选择该服务的某一提供者直接进行访问。所以,我们引入了Dubbo。

1.2 基于Dubbo实现微服务

Dubbo是阿里开源的一个SOA服务治理解决方案,文档丰富,在国内的使用度非常高。

使用Dubbo构建的微服务,已经可以比较好地解决上面提到的问题:

img_6d97dc008704105e1f142329f515ba4d.png

调用中间层变成了可选组件,消费者可以直接访问服务提供者。

服务信息被集中到Registry中,形成了服务治理的中心组件。

通过Monitor监控系统,可以直观地展示服务调用的统计信息。

Consumer可以进行负载均衡、服务降级的选择。

但是对于微服务架构而言,Dubbo也并不是十全十美的:

Registry严重依赖第三方组件(zookeeper或者redis),当这些组件出现问题时,服务调用很快就会中断。

DUBBO只支持RPC调用。使得服务提供方与调用方在代码上产生了强依赖,服务提供者需要不断将包含公共代码的jar包打包出来供消费者使用。一旦打包出现问题,就会导致服务调用出错。

最为重要的是,DUBBO现在已经重新维护了,对于技术发展的新需求,需要由开发者自行拓展升级。这对于很多想要采用微服务架构的中小软件组织,显然是相当合适的。

目前Github社区上有一个DUBBO的升级版,叫DUBBOX,提供了更高效的RPC序列化方式和REST调用方式。但是该项目也基本停止维护了。

1.3 新的选择——Spring Cloud

作为新一代的服务框架,Spring Cloud提出的口号是开发“面向云环境的应用程序”,它为微服务架构提供了更加全面的技术支持。点击这里查看Spring系列教程集合。

结合我们一开始提到的微服务的诉求,我们把Spring Cloud与DUBBO进行一番对比:


img_9b7904500336e901e01b79cbddbafabc.png

Spring Cloud抛弃了Dubbo的RPC通信,采用的是基于HTTP的REST方式。严格来说,这两种方式各有优劣。虽然从一定程度上来说,后者牺牲了服务调用的性能,但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更加合适。

Eureka相比于zookeeper,更加适合于服务发现的场景,这点会在下一篇会详细展开。

很明显,Spring Cloud的功能比DUBBO更加强大,涵盖面更广,而且作为Spring的拳头项目,它也能够与Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring项目完美融合,这些对于微服务而言是至关重要的。前面提到,微服务背后一个重要的理念就是持续集成、快速交付,而在服务内部使用一个统一的技术框架,显然比把分散的技术组合到一起更有效率。更重要的是,相比于Dubbo,它是一个正在持续维护的、社区更加火热的开源项目,这就保证使用它构建的系统,可以持续地得到开源力量的支持。点击这里查看Spring系列教程集合。

2、Spring Cloud技术概览

下图展示了Spring Cloud的完整技术组成:

img_7ae16f96e01705197e8713012b5d9b93.jpe

服务治理:这是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提供了集群选主、分布式锁(暂未实现)、一次性令牌(暂未实现)等分布式集群需要的技术组件。

欢迎工作一到五年的Java工程师朋友们加入Java架构开发:860113481

群内提供免费的Java架构学习资料(里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码,MyBatis,Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料)合理利用自己每一分每一秒的时间来学习提升自己,不要再用"没有时间“来掩饰自己思想上的懒惰!趁年轻,使劲拼,给未来的自己一个交代!

相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
相关文章
|
12天前
|
Dubbo Java 应用服务中间件
Spring Cloud Dubbo:微服务通信的高效解决方案
【10月更文挑战第15天】随着信息技术的发展,微服务架构成为企业应用开发的主流。Spring Cloud Dubbo结合了Dubbo的高性能RPC和Spring Cloud的生态系统,提供高效、稳定的微服务通信解决方案。它支持多种通信协议,具备服务注册与发现、负载均衡及容错机制,简化了服务调用的复杂性,使开发者能更专注于业务逻辑的实现。
34 2
|
2月前
|
Java 对象存储 开发者
解析Spring Cloud与Netflix OSS:微服务架构中的左右手如何协同作战
Spring Cloud与Netflix OSS不仅是现代微服务架构中不可或缺的一部分,它们还通过不断的技术创新和社区贡献推动了整个行业的发展。无论是对于初创企业还是大型组织来说,掌握并合理运用这两套工具,都能极大地提升软件系统的灵活性、可扩展性以及整体性能。随着云计算和容器化技术的进一步普及,Spring Cloud与Netflix OSS将继续引领微服务技术的发展潮流。
40 0
|
15天前
|
Dubbo Java 应用服务中间件
Dubbo学习圣经:从入门到精通 Dubbo3.0 + SpringCloud Alibaba 微服务基础框架
尼恩团队的15大技术圣经,旨在帮助开发者系统化、体系化地掌握核心技术,提升技术实力,从而在面试和工作中脱颖而出。本文介绍了如何使用Dubbo3.0与Spring Cloud Gateway进行整合,解决传统Dubbo架构缺乏HTTP入口的问题,实现高性能的微服务网关。
|
11天前
|
JSON Java 数据格式
【微服务】SpringCloud之Feign远程调用
本文介绍了使用Feign作为HTTP客户端替代RestTemplate进行远程调用的优势及具体使用方法。Feign通过声明式接口简化了HTTP请求的发送,提高了代码的可读性和维护性。文章详细描述了Feign的搭建步骤,包括引入依赖、添加注解、编写FeignClient接口和调用代码,并提供了自定义配置的示例,如修改日志级别等。
31 1
|
15天前
|
人工智能 文字识别 Java
SpringCloud+Python 混合微服务,如何打造AI分布式业务应用的技术底层?
尼恩,一位拥有20年架构经验的老架构师,通过其深厚的架构功力,成功指导了一位9年经验的网易工程师转型为大模型架构师,薪资逆涨50%,年薪近80W。尼恩的指导不仅帮助这位工程师在一年内成为大模型架构师,还让他管理起了10人团队,产品成功应用于多家大中型企业。尼恩因此决定编写《LLM大模型学习圣经》系列,帮助更多人掌握大模型架构,实现职业跃迁。该系列包括《从0到1吃透Transformer技术底座》、《从0到1精通RAG架构》等,旨在系统化、体系化地讲解大模型技术,助力读者实现“offer直提”。此外,尼恩还分享了多个技术圣经,如《NIO圣经》、《Docker圣经》等,帮助读者深入理解核心技术。
SpringCloud+Python 混合微服务,如何打造AI分布式业务应用的技术底层?
|
24天前
|
Java 数据库 数据安全/隐私保护
Spring 微服务提示:使用环境变量抽象数据库主机名
Spring 微服务提示:使用环境变量抽象数据库主机名
36 1
|
28天前
|
监控 Java 对象存储
监控与追踪:如何利用Spring Cloud Sleuth和Netflix OSS工具进行微服务调试
监控与追踪:如何利用Spring Cloud Sleuth和Netflix OSS工具进行微服务调试
38 1
|
28天前
|
安全 Java 对象存储
安全性考量:Spring Security与Netflix OSS在微服务安全中的作用
安全性考量:Spring Security与Netflix OSS在微服务安全中的作用
28 1
|
2月前
|
负载均衡 Java 网络架构
实现微服务网关:Zuul与Spring Cloud Gateway的比较分析
实现微服务网关:Zuul与Spring Cloud Gateway的比较分析
67 5
|
2月前
|
前端开发 API 微服务
SpringCloud微服务之间使用Feign调用不通情况举例
SpringCloud微服务之间使用Feign调用不通情况举例
333 2