Spring Cloud(一):微服务概述

一、什么是微服务

微服务是一种架构风格,是一种架构设计方式,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。

二、为什么需要微服务

传统开发模式下,绝大多数的 web 应用都是单体架构的风格来进行构建,这就使得所有的接口,业务逻辑层,数据持久层全部都被打包在一个 web 应用中,并且布置在一台服务器上,使得不同的模块之前也高耦合在一起,这种开发模式使得多团队协作开发的开发成本极高。

三、单体应用存在的问题

  • 随着业务的发展,开发变得越来越复杂

  • 对某单一功能进行修改时,需要对整个系统进行打包部署

  • 多个团队同时对数据进行操作管理,容易产生安全漏洞

  • 各模块都使用相对统一的技术进行开发,各个模块很难根据实际情况选择更加合适的技术框架,系统的延展性比较低。

  • 模块间耦合度高,新人上手比较费时

分布式、集群

集群:一台服务器无法负荷高并发的数据访问,需要设置更多的服务器一起分担压力。从物理层面解决高并发的问题,例如春运期间火车站多开购票窗口等。

分布式:将一个大型的项目架构拆分为若干个微服务来协同完成。从软件设计层面解决问题,例如将购票分为统计出发地与目的地,查询是否有票,统一购买票等步骤,分别由不同的人来完成这些小的工作,最后将所有的工作结果进行整合,实现更大的需求。

四、微服务的优点

  1. 各个服务的开发、测试、部署都是相互独立的。可以针对某一个特定的服务进行更多的操作,比如负载均衡等。

  2. 当有一个新的需求加入时,传统项目需要结合各方面考虑影响等,微服务就不存在这样的问题,省事省力又省心。

  3. 使用微服务将项目拆分后,只需要保证对外接口的正常运行,大大降低了各个模块之间的耦合性,极大的提高开发效率。

五、微服务的弊端

  1. 微服务的拆分基于业务,不能随心所欲的拆分,所以如何拆分,对于项目架构来说是非常重要且极具挑战的任务。

  2. 涉及到服务之间的调用时,常常需要和另外一个服务的提供方进行沟通,若是两个完全不同的公司或者部门,沟通成本比较大;某服务的对外接口要进行修改,也需要与其他服务调用方进行沟通。

  3. 由于各个服务相互独立,数据也是独立,当多个服务的接口进行操作时,如何保证数据的一致性是一个难点。数据统一性是微服务里面的一个难题。

六、为什么选择 Spring Cloud

虽然微服务也有很多缺点,但是瑕不掩瑜,总体来讲,微服务还是实现分布式架构的一个非常好的方式。是当下非常热点的技术,也是未来技术发展的趋势。当下较为常见的微服务框架是 Spring Cloud 和 dubbo。那我们为什么选择 Spring Cloud 呢,原因如下:

1.Spring Cloud 是完全基于 Spring Boot,服务调用是基于 REST API ,整合了各种成熟的产品和架构,同时基于 Spring Boot 也使得整体的开发、配置、部署都非常的方便。

2.Spring 系列的产品具备功能齐全、简单好用、性能优美、文档规范等优点。

七、Spring Cloud 的整体架构

在这里插入图片描述

八、Spring Cloud 的核心组件

Spring Cloud 包含多个组件,主要是服务治理 Eureka、服务通信 Ribbon、服务通信 Feign、服务网关 Zuul、服务容错 Hystrix、服务配置 Config、服务监控 Actuator、服务跟踪 Zipkin 等 8 大组件。 Spring Cloud 的学习主要就是学习这些组件的使用以及这些组件之间的整合。
在这里插入图片描述

九、服务如何治理

服务治理的核心由三部分组成:服务提供者、服务消费者、注册中心

服务注册:分布式系统架构中,没个微服务在启动时,会将自己的信息存储在注册中心。

服务发现:服务消费者从注册中心获取服务提供者的信息,通过这些信息调用服务提供者的服务。、

那么 Spring Cloud 的服务治理则采用 Eureka 来实现,具体是怎么操作的,让我们期待Spring Cloud(二):Eureka Server 注册中心

开发工程师一只,也在不断的学习阶段,平时的小经验不定期分享。 希望看我写的文字的人,可以少走弯路 祝工作学习顺利。
博主经验有限,若有不足,欢迎交流,共同改进~ 愿与同在CSDN的你共同进步。

作者 | 甜蜜的小红薯
出品 | 小红薯

猜你喜欢

转载自blog.csdn.net/qq_36836370/article/details/130869680