Spring Cloud微服务架构及核心组件

目录

1、互联网应用架构演进

(1)单体式应用架构

(2)垂直应用架构

(3)SOA应用架构

(4)微服务应用架构

 2、微服务架构体现的思想及优缺点

3、spring cloud架构

(1)springcloud核心组件

(2)Spring Cloud 体系结构(组件协同工作机制)


1、互联网应用架构演进

(1)单体式应用架构

在诞生之初,系统的用户量、数据量规模都比较小,项目所有的功能模块都放在一个工程中编码、编译、打包并且部署在一个Tomcat容器中的架构模式就是单体应用架构,这样的架构既简单实用、便于维护,成本又低,成为了那个时代的主流架构方式。

优点:

  • 高效开发:项目前期开发节奏快,团队成员少的时候能够快速迭代

  • 架构简单:MVC架构,只需要借助IDE开发、调试即可

  • 易于测试:只需要通过单元测试或者浏览器完成

  • 易于部署:打包成单个可执行的jar或者打成war包放到容器内启动

单体架构的应用比较容易部署、测试, 在项目的初期,单体应用可以很好地运行。然而,随着需求的不断增加, 越来越多的人加入开发团队,代码库也在飞速地膨胀。慢慢地,单体应用变得越来越臃肿,可维护性、灵活性逐渐降低,维护成本越来越高。

缺点:

  • 可靠性差: 某个应用Bug,例如死循环、内存溢出等, 可能会导致整个应用的崩溃

  • 复杂性高: 以一个百万行级别的单体应用为例,整个项目包含的模块多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。使得整个项目非常复杂。

  • 扩展能力受限: 单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。例如,应用中有的模块是计算密集型的,它需要强劲的CPU; 有的模块则是IO密集型的,需要更大的内存。 由于这些模块部署在一起,不得不在硬件的选择上做出妥协。

(2)垂直应用架构

优点

  • 系统拆分实现了流量分担,解决了并发问题

  • 可以针对不同模块进行优化

  • 方便水平扩展,负载均衡,容错率提高

  • 系统间相互独立,互不影响,新的业务迭代时更加高效

    缺点

  • 服务之间相互调用,如果某个服务的端扣或者ip地址发生改变,调用的系统得手动改变

  • 搭建集群之后,实现负载均衡比较复杂,如:内网负载,在迁移机器时会影响调用方的路 由,导致线上故障

  • 服务之间调用方式不统一,基于 httpclient 、 webservice ,接口协议不统一

  • 服务监控不到位:除了依靠端口、进程的监控,调用的成功率、失败率、总耗时等等这些监 控指标是没有的

(3)SOA应用架构

在做了垂直划分以后,模块随之增多,维护的成本在也变高,一些通用的业务和模块重复的越来越多,为了解决上面提到的接口协议不统一、服务无法监控、服务的负载均衡,引入了阿里巴巴开源的 Dubbo ,一款高性能、轻量级的开源Java RPC框架,可以和Spring框架无缝集成。它提供了三个核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。

SOA (Service-Oriented Architecture),即面向服务的架构。根据实际业务,把系统拆分成合适的、独立部署的模块,模块之间相互独立(通过Webservice/Dubbo等技术进行通信)。

优点:分布式、松耦合、扩展灵活、可重用。

缺点:服务抽取粒度较大、服务调用方和提供方耦合度较高(接口耦合度)

Spring Cloud微服务架构及核心组件_第1张图片

(4)微服务应用架构

微服务架构可以说是SOA架构的一种拓展,这种架构模式下它拆分粒度更小、服务更独立。把应用拆分成为一个个微小的服务,不同的服务可以使用不同的开发语言和存储,服务之间往往通过Restful等轻量级通信。微服务架构关键在于微小、独立、轻量级通信

微服务是在 SOA 上做的升华粒度更加细致,微服务架构强调的⼀个重点是业务需要彻底的组件化和服务化

Spring Cloud微服务架构及核心组件_第2张图片

微服务架构和SOA架构相似又不同

微服务架构和SOA架构很明显的一个区别就是服务拆分粒度的不同,但是对于系统的架构发展来说,我们所看到的SOA阶段其实服务拆分粒度相对来说已经比较细了(超前哦!),所以上述系统SOA到系统微服务,从服务拆分上来说变化并不大,只是引入了相对完整的新一代Spring Cloud微服务技术。自然,上述我们看到的都是系统架构演变的阶段结果,每一个阶段其实都经历了很多变化,系统的服务拆分其实也是走过了从粗到细,并非绝对的一步到位。

举个系统案例来说明SOA和微服务拆分粒度不同

我们在SOA架构的初期,“简历投递模块”和“人才搜索模块”都有简历内容展示的需求,只不过说可能略有区别,一开始在两个模块中各维护了一套简历查询和展示的代码;后期我们将服务更细粒度拆分,拆分出简历基础服务,那么不同模块调用这个基础服务即可。

 2、微服务架构体现的思想及优缺点

微服务架构设计的核心思想就是“微”,拆分的粒度相对比较小,这样的话单一职责、开发的耦合度就会降低、微小的功能可以独立部署扩展、灵活性强,升级改造影响范围小。

微服务架构的优点: 微服务架构和微服务

  • 微服务很小,便于特定业务功能的聚焦

  • 微服务很小,每个微服务都可以被一个小团队单独实施(开发、测试、部署上线、运维),团队合作一定程度解耦,便于实施敏捷开发

  • 微服务很小,便于重用和模块之间的组装

  • 微服务很独立,那么不同的微服务可以使用不同的语言开发,松耦合

  • 微服务架构下,我们更容易引入新技术

微服务架构的缺点

  • 微服务架构下,分布式复杂难以管理,当服务数量增加,管理将越加复杂;

  • 微服务架构下,分布式链路跟踪难等;

3、spring cloud架构

如前所述,Spring Cloud是一个微服务相关规范,这个规范意图为搭建微服务架构提供一站式服务,采用组件(框架)化机制定义一系列组件,各类组件针对性的处理微服务中的特定问题,这些组件共同来构成Spring Cloud微服务技术栈

(1)springcloud核心组件

Spring Cloud 生态圈中的组件,按照发展可以分为第一代 Spring Cloud组件和第二代 Spring Cloud组件。

Spring Cloud微服务架构及核心组件_第3张图片

(2)Spring Cloud 体系结构(组件协同工作机制)

Spring Cloud微服务架构及核心组件_第4张图片

Spring Cloud中的各组件协同工作,才能够支持一个完整的微服务架构。比如

  • 注册中心负责服务的注册与发现,很好将各服务连接起来

  • API网关负责转发所有外来的请求

  • 断路器负责监控服务之间的调用情况,连续多次失败进行熔断保护。

  • 配置中心提供了统一的配置信息管理服务,可以实时的通知各个服务获取最新的配置信息

你可能感兴趣的:(架构,微服务,java)