文章目录
一、微服务
单体应用特点
大部分的开发者都开发过单体应用,无论是传统的 Servlet + JSP,还是 SSM,还是现在的 SpringBoot,它们都是单体应用,那么长期陪伴我们的单体应用有什么弊端?我们是面临了什么问题,导致我们要抛弃单体应用转向微服务架构?主要原因如下:
部署成本高(无论是修改1行代码,还是10行代码,都要全量替换)。
改动影响大,风险高(不论代码改动多小,成本都相同)。
因为成本高,风险高,所以导致部署频率低(无法快速交付客户需求)。
无法满足快速扩容,弹性伸缩,无法适应云环境特性等问题。
注意:单体应用虽然有上面缺点,但是依然有自己的市场,如果项目规模比较小,办公类等不需要频繁修改版本的应用使用单体架构还是很方便的。
微服务特点
微服务架构的特点:针对特定服务发布,影响小,风险小,成本低;频繁发布版本,快速交付需求;低成本扩容,弹性伸缩,适应云环境。
我们知道一个朴素的理念,没有任何事物是完美的,任何东西都有两面性,有得必有失,那么在选择微服务在解决了快速响应和弹性伸缩的问题同时,它又给我们带来了什么问题?简单总结如下:
分布式系统的复杂性
部署,测试和监控的成本问题
分布式事务和CAP的相关问题
分布式中微服务架构相对于单体架构还需要处理很多事情。例如:分布式事务、团队合作等问题都需要明确的提前设计好。
应用架构变迁图
无论是SOA架构、RPC架构还是微服务架构统称为分布式架构。
RPC架构和SOA架构和微服务架构的区别?
SOA架构: 核心消息总线。消息总线过于笨重在目前项目中已经很少使用了。
RPC架构: 主要有被调用的远程服务端(Provider)和调用的服务端(Consumer),把所有数据库操作都封装到了Provider。一个单体拆分成多个,之间使用HTTP通信,每个项目又拆分成两个(Provider和Consumer),之间使用Dubbo协议通信。
微服务服务架构:每个业务是一个项目。业务之间通信使用HTTP协议通信。
目前市场上微服务架构的常用实现框架
实现框架:Spring Cloud。
Spring Cloud里面目前包含三体体系:
Spring Cloud Netflix : 学习这个。目前市场上使用最多的。
Spring Cloud Alibaba:基于Dubbo实现的。
Spring 自己的:为了摆脱受Netflix公司限制,所有功能都自己又逐渐推出一套。
二、Spring Cloud简介
Spring Cloud是Spring旗下的一个顶级项目。它没有具体内容,但里面包含了很多二级子项目,Spring Cloud就是这些二级子项目的统称。
Spring Cloud包含了很多二级子项目,每个二级子项目都有对应的功能,所以Spring Cloud整体包含的功能是比较强大。
我们主要学习的是Spring Cloud Netflix相关框架。
Spring Cloud集成时会把Netflix的软件进行打包成一个依赖,我们项目依赖了对应的jar,可以直接使用这个软件,免去了软件安装的过程(这也是Spring Cloud非常大的优点)
三、 Spring Cloud和Dubbo的对比
Spring Cloud和Dubbo(Spring Cloud Alibaba)都是微服务开发框架。不是新的技术就一定是好的技术。Dubbo优势在于开发简单,效率高。Spring Cloud优势在于功能全面且可靠性高。
四、 Spring Cloud版本号说明
1 常见版本号说明
开发中,使用的框架版本,最好是RELEASE版本或Final版本。
常见版本号格式为: x.y.z.stage
x - 数字格式主版本号,当功能模块有较大更新或者整体架构发生变化时,主版本号会更新。
y - 数字格式次版本号,次版本表示只是局部的一些变动。
z - 数字格式修正版本号,一般是bug的修复或者是小的变动。
stage - 希腊字母版本号,也称为阶段版本号。用于标注当前版本的软件处于哪个开发阶段。常用的阶段版本包括:BASE、ALPHA、BATE、RELEASE/FINAL。
BASE - 设计阶段。只有相应的设计没有具体的功能实现。
ALPHA - 软件的初级版本。存在较多的bug。
BATE - 表示相对ALPHA有了很大的进步,消除了严重的bug,还存在一些潜在的bug。
RELEASE/FINAL - 该版本表示最终版,即正式发布版本。
2 Spring Cloud版本号说明
Spring Cloud是一个包含若干子框架的框架集合体,是一个完整的微服务框架体系,如果使用场景版本号来进行标记,容易混淆主框架版本和子框架版本标记。所以Spring Cloud使用一种全新的版本号来对主框架进行版本标记,而子框架的版本标记大多还是使用常用版本号标记的。
Spring Cloud版本格式如: 版本号命名.stage
版本号命名:Spring Cloud主框架版本号是使用英国伦敦地铁站名称来进行标记的,并根据地铁站名称的首字母的英文自然升序排列来识别版本的递增。如:Angle、Brixton、Camden、Dalston、Edgware、Finchley、Greenwich 、Hoxton等。后续版本提升会继续根据首字母升序排列。
stage:阶段版本号。常用的阶段版本包括:BUILD-XXX[SNAPSHOT]、GA、PRE(M1、M2等)、RC、SR。
BUILD-XXX[SNAPSHOT] - 开发版本、一般是开发团队内部使用。
GA - 稳定版,内部开发到一定阶段了,各个模块集成后,经过全面测试发现没有问题,可对外发行了。这个时候叫GA(General Availability)。基本上可以使用了。没有严重的BUG问题,但是有未测出的BUG隐患。不推荐商业使用。
PRE - 里程碑版,由于GA还不属于公开发行版,里面还有些功能不完善或者bug,于是就有了milestone(里程碑版)。milestone版主要修复了一些bug。一个GA后,一般会有多个里程本版。例如 M1 M2 M3…。不推荐商业使用。
RC - 候选发布版,从BUILD后到GA在到M基本上系统就算定型了,这个时候系统就进入Release Candidate(候选发布版)。该阶段的软件类似于最终发行前的一个观察期,该期间只对一些发现的等级高的bug进行修复。发布RC1 RC2等版本。可以考虑RC版本。
SR - 正式发布版,公开正式发布。正式发布版一般也有多个发布,例如 SR1 SR2 SR3等等,一般是用来修复大bug或者优化。最好使用SR版本。
要注意:Spring Cloud是基于Spring Boot,不同的Spring Cloud要使用不同的Spring Boot版本。