随着互联网技术的快速发展,一些传统的 IT 系统支撑遇到了越来越多的问题:
针对上述问题,传统的单体结构已经不再适用于复杂度日益渐增的产品,因此一种新的软件架构提供了解决方案 —— 微服务
。
随着互联网行业的发展,对服务的要求也越来越高,服务架构也从单体架构逐渐演变为现在流行的微服务架构。这些架构之间有怎样的差别呢?
在诞生之初,系统的用户量、数据量规模都比较小,项目所有的功能模块都放在一个工程中编码、编译、打包并且部署在一个 Tomcat 容器中的架构模式就是单体应用架构,这样的架构既简单实用、便于维护,成本又低,成为了那个时代的主流架构方式。
优点:
单体架构的应用比较容易部署、测试, 在项目的初期,单体应用可以很好地运行。然而,随着需求的不断增加, 越来越多的人加入开发团队,代码库也在飞速地膨胀。慢慢地,单体应用变得越来越臃肿,可维护性、灵活性逐渐降低,维护成本越来越高。
缺点:
业务量上涨之后,单体应用架构进一步丰富变化,比如应用集群部署、使用 Nginx 进行负载均衡、增加缓存服务器、增加文件服务器、数据库集群并做读写分离等,通过以上措施增强应对高并发的能力、应对一定的复杂业务场景,但依然属于单体应用架构。
为了避免上面提到的那些问题,开始做模块的垂直划分,做垂直划分的原则是基于系统现有的业务特性来做,核心目标第一个是为了业务之间互不影响,第二个是在研发团队的壮大后为了提高效率,减少组件之间的依赖。
优点
在做了垂直划分以后,模块随之增多,维护的成本在也变高,一些通用的业务和模块重复的越来越多,为了解决上面提到的接口协议不统一、服务无法监控、服务的负载均衡,引入了阿里巴巴开源的 Dubbo ,一款高性能、轻量级的开源 Java RPC 框架,可以和 Spring 框架无缝集成。它提供了三个核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。
SOA (Service-Oriented Architecture),即面向服务的架构。根据实际业务,把系统拆分成合适的、独立部署的模块,模块之间相互独立(通过 Webservice/Dubbo 等技术进行通信)。
优点:分布式、松耦合、扩展灵活、可重用。
缺点:服务抽取粒度较大、服务调用方和提供方耦合度较高(接口耦合度)
微服务架构可以说是 SOA 架构的一种拓展,这种架构模式下它拆分粒度更小、服务更独立。把应用拆分成为一个个微小的服务,不同的服务可以使用不同的开发语言和存储,服务之间往往通过 Restful 等轻量级通信。微服务架构关键在于微小、独立、轻量级通信。
微服务是在 SOA 上做的升华粒度更加细致,微服务架构强调的⼀个重点是业务需要彻底的组件化和服务化
微服务架构和 SOA 架构相似又不同
微服务架构和 SOA 架构很明显的一个区别就是服务拆分粒度的不同,但是对于系统的架构发展来说,我们所看到的 SOA 阶段其实服务拆分粒度相对来说已经比较细了(超前哦!),所以上述系统 SOA 到系统微服务,从服务拆分上来说变化并不大,只是引入了相对完整的新一代 Spring Cloud 微服务技术。自然,上述我们看到的都是系统架构演变的阶段结果,每一个阶段其实都经历了很多变化,系统的服务拆分其实也是走过了从粗到细,并非绝对的一步到位。
举个系统案例来说明 SOA 和微服务拆分粒度不同
我们在 SOA 架构的初期,“ 简历投递模块
” 和 “ 人才搜索模块
” 都有简历内容展示的需求,只不过说可能略有区别,一开始在两个模块中各维护了一套简历查询和展示的代码;后期我们将服务更细粒度拆分,拆分出简历基础服务,那么不同模块调用这个基础服务即可。
微服务架构设计的核心思想就是 **“微”**,拆分的粒度相对比较小,这样的话单一职责、开发的耦合度就会降低、微小的功能可以独立部署扩展、灵活性强,升级改造影响范围小。
微服务架构的优点:
微服务架构的缺点
** 服务注册:** 服务提供者将所提供服务的信息(服务器 IP 和端口、服务访问协议等)注册 / 登记到注册中心
** 服务发现:** 服务消费者能够从注册中心获取到较为实时的服务列表,然后根究一定的策略选择一个服务访问
负载均衡即将请求压力分配到多个服务器(应用服务器、数据库服务器等),以此来提高服务的性能、可靠性
熔断即断路保护。微服务架构中,如果下游服务因访问压力过大而响应变慢或失败,上游服务为了保护系统整体可用性,可以暂时切断对下游服务的调用。这种牺牲局部,保全整体的措施就叫做熔断。
微服务架构越发流行,一个项目往往拆分成很多个服务,那么一次请求就需要涉及到很多个服务。不同的微服务可能是由不同的团队开发、可能使用不同的编程语言实现、整个项目也有可能部署在了很多服务器上(甚至百台、千台)横跨多个不同的数据中心。所谓链路追踪,就是对一次请求涉及的很多个服务链路进行日志记录、性能监控
微服务架构下,不同的微服务往往会有不同的访问地址,客户端可能需要调用多个服务的接口才能完成一个业务需求,如果让客户端直接与各个微服务通信可能出现:
1. 统一接入(路由)
2. 安全防护(统一鉴权,负责网关访问身份认证验证,与 “访问认证中心” 通信,实际认证业务逻辑交移 “访问认证中心” 处理)
3. 黑白名单(实现通过 IP 地址控制禁止访问网关功能,控制访问)
4. 协议适配(实现通信协议校验、适配转换的功能)
5. 流量管控(限流)
6. 长短链接支持
7. 容错能力(负载均衡)
** 我摘抄了百度百科的原话: **
Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用 Spring Boot 的开发风格做到一键启动和部署。Spring Cloud 并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过 Spring Boot 风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
Spring Cloud 是一系列框架的有序集合(Spring Cloud 是一个规范) 开发服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等 利用 Spring Boot 的开发便利性简化了微服务架构的开发(自动装配)
这里,我们需要注意, Spring Cloud
其实是一套规范,是一套用于构建微服务架构的规范,而不是一个可以拿来即用的框架(所谓规范就是应该有哪些功能组件,然后组件之间怎么配合,共同完成什么事情)。在这个规范之下第三方的 Netflix
公司开发了一些组件、Spring 官方开发了一些 框架/组件
,包括第三方的阿里巴巴开发了一套框架 / 组件集合 Spring Cloud Alibaba
,这些才是 Spring Cloud
规范的实现。
Netflix 搞了一套 ,简称 SCN Spring Cloud 吸收了 Netflix 公司的产品基础之上自己也搞了几个组件 阿里巴巴在之前的基础上搞出了一堆微服务组件,Spring Cloud Alibaba(SCA)
Spring Cloud
规范及实现意图要解决的问题其实就是微服务架构实施过程中存在的一些问题,比如微服务架构中的服务注册发现问题、网络问题(比如熔断场景)、统一认证安全授权问题、负载均衡问题、链路追踪等问题。
如前所述,Spring Cloud 是一个微服务相关规范,这个规范意图为搭建微服务架构提供一站式服务,采用组件(框架)化机制定义一系列组件,各类组件针对性的处理微服务中的特定问题,这些组件共同来构成 Spring Cloud 微服务技术栈
Spring Cloud 生态圈中的组件,按照发展可以分为第一代 Spring Cloud 组件和第二代 Spring Cloud 组件。
第一代 Spring Cloud(Netflix,SCN) | 第二代 Spring Cloud(主要就是 Spring Cloud Alibaba,SCA) | |
---|---|---|
注册中心 | Netflix Eureka | 阿里巴巴 Nacos |
客户端负载均衡 | Netflix Ribbon | 阿里巴巴 Dubbo LB、Spring Cloud Loadbalancer |
熔断器 | Netflix Hystrix | 阿里巴巴 Sentinel |
网关 | Netflix Zuul:性能一般,未来将退出 Spring Cloud 生态圈 | 官方 Spring Cloud Gateway |
配置中心 | 官方 Spring Cloud Config | 阿里巴巴 Nacos、携程 Apollo |
服务调用 | Netflix Feign | 阿里巴巴 Dubbo RPC |
消息驱动 | 官方 Spring Cloud Stream | |
链路追踪 | 官方 Spring Cloud Sleuth/Zipkin | |
阿里巴巴 seata 分布式事务方案 |
Spring Cloud 中的各组件协同工作,才能够支持一个完整的微服务架构。比如
Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架,基于 RPC 调用,对于目前使用率较高的 Spring Cloud Netflix 来说,它是基于 HTTP 的,所以效率上没有 Dubbo 高,但问题在于 Dubbo 体系的组件不全,不能够提供一站式解决方案,比如服务注册与发现需要借助于 Zookeeper 等实现,而 Spring Cloud Netflix 则是真正的提供了一站式服务化解决方案,且有 Spring 大家族背景。
前些年,Dubbo 使用率高于 SpringCloud,但目前 Spring Cloud 在服务化 / 微服务解决方案中已经有了非常好的发展趋势。
Spring Cloud 只是利用了 Spring Boot 的特点,让我们能够快速的实现微服务组件开发,否则不使用 Spring Boot 的话,我们在使用 Spring Cloud 时,每一个组件的相关 Jar 包都需要我们自己导入配置以及需要开发人员考虑兼容性等各种情况。所以 Spring Boot 是我们快速把 Spring Cloud 微服务技术应用起来的一种方式。
另外,SpringCloud 底层是依赖于 SpringBoot
的,并且有版本的兼容关系,如下:
笔者这次的版本是 Hoxton.SR10,因此对应的 SpringBoot 版本是 2.3.x 版本。
这一节主要是让我们可以系统的认识到互联网架构的一个演变,以及对 SpringCloud
微服务架构有一个初步认识,下一节我们通过一些 实战案例
用代码去体会到我们在开发中怎么去构建 SpringCloud
项目以及如果进一步了解 SpringCloud
组件,在咱们下期见!欢迎评论区交流讨论!