社区微信群开通啦,扫一扫抢先加入社区官方微信群
社区微信群
现如今微服务架构十分流行,而采用微服务构建系统也会带来更清晰的业务划分和可扩展性。同时,支持微服务的技术栈也是多种多样的,本系列文章主要介绍这些技术中的翘楚——Spring Cloud。这是序篇,主要讲述我们为什么选择Spring Cloud和它的技术概览。
1、为什么微服务架构需要Spring Cloud
简单来说,服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务,而微服务在这个基础上要更彻底地去耦合(不再共享DB、KV,去掉重量级ESB),并且强调DevOps和快速演化。这就要求我们必须采用与一站式时代、泛SOA时代不同的技术栈,而Spring Cloud就是其中的佼佼者。
DevOps是英文Development和Operations的合体,他要求开发、测试、运维进行一体化的合作,进行更小、更频繁、更自动化的应用发布,以及围绕应用架构来构建基础设施的架构。这就要求应用充分的内聚,也方便运维和管理。这个理念与微服务理念不谋而合。
接下来我们从服务化架构演进的角度来看看为什么Spring Cloud更适应微服务架构。
1.1 从使用nginx说起
最初的服务化解决方案是给提供相同服务提供一个统一的域名,然后服务调用者向这个域名发送HTTP请求,由Nginx负责请求的分发和跳转。
这种架构存在很多问题:
为了解决上面的问题,我们需要一个现成的中心组件对服务进行整合,将每个服务的信息汇总,包括服务的组件名称、地址、数量等。服务的调用方在请求某项服务时首先通过中心组件获取提供这项服务的实例的信息(IP、端口等),再通过默认或自定义的策略选择该服务的某一提供者直接进行访问。所以,我们引入了Dubbo。
1.2 基于Dubbo实现微服务
Dubbo是阿里开源的一个SOA服务治理解决方案,文档丰富,在国内的使用度非常高。
使用Dubbo构建的微服务,已经可以比较好地解决上面提到的问题:
但是对于微服务架构而言,Dubbo也并不是十全十美的:
目前Github社区上有一个DUBBO的升级版,叫DUBBOX,提供了更高效的RPC序列化方式和REST调用方式。但是该项目也基本停止维护了。
1.3 新的选择——Spring Cloud
作为新一代的服务框架,Spring Cloud提出的口号是开发“面向云环境的应用程序”,它为微服务架构提供了更加全面的技术支持。
结合我们一开始提到的微服务的诉求,我们把Spring Cloud与DUBBO进行一番对比:
微服务需要的功能DubboSpring Cloud服务注册和发现ZookeeperEureka服务调用方式RPCRESTful API断路器有有负载均衡有有服务路由和过滤有有分布式配置无有分布式锁无计划开发集群选主无有分布式消息无有
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,它是一个正在持续维护的、社区更加火热的开源项目,这就保证使用它构建的系统,可以持续地得到开源力量的支持。
2、Spring Cloud技术概览
下图展示了Spring Cloud的完整技术组成:
Feign和RxJava并不是Netiflix的产品,但是被整合到了Spring Cloud Netflix中。
对于服务的注册和发现,除了Eureka,Spring Cloud也整合了Consul和Zookeeper作为备选,但是因为这两个方案在CAP理论上都遵循CP而不是AP(下一篇会详细介绍这点),所以官方并没有推荐使用。
集群工具:Spring Cloud Cluster提供了集群选主、分布式锁(暂未实现)、一次性令牌(暂未实现)等分布式集群需要的技术组件。
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!