spring cloud 版本规则

第一次看spring cloud的版本命名,感觉很莫名其妙。spring Cloud是一个由很多子项目组成的一个大型项目,原则上都有自己的发布版本。为了要管理每个版本的子项目清单,所以命名没有采用版本号的方式,而是通过命名的方式,以避免版本名与子项目的发布号混淆。

version.jpg

 

大版本

看上图,他不是采用xx.xx.xx.RELEASE这样的熟悉的数字版本号命名。而是采而是对应一个开发代号,比如Dalston,Edgware等,版本名称采用了伦敦地铁站的名字。这些是有规律的,首字母从A开始,B,C,D,现在是F了。

小版本

Spring Cloud 小版本分为:

SNAPSHOT: 快照版本,随时可能修改

M: MileStone,M1表示第1个里程碑版本,一般同时标注PRE,表示预览版版。

SR: Service Release,SR1表示第1个正式版本,一般同时标注GA:(GenerallyAvailable),表示稳定版本。

一般,我们生产环境选择SR版本。

 

总结:spring cloud采用版本命,首字母按A到Z递增。小修改,在更新对应的M,或SR后缀,如M1,SR2。我们选SR版本就可以了。

spring cloud (1) 开篇

本文主要涉及了微服务的基本概念,以及简要说明下spring cloud主要由那几样东西构成。

很久没有写东西,有点方。但写什么呢,要找的网上都有啊(这个懒人借口不错)。

近来研究上了spring cloud,所以,往后一段时间,就写一系列spring cloud的内容吧。当学习笔记了。

 

PART 1

先说一下单体服务到微服务的进化史。

记得最开始学做网站,都是一个war包,连接数据库。搞掂。这就是所谓最原始的单体应用。甚至war和数据库都是放在同一台服务器上。架构图是这样的:

1.jpg

随着用户的增长,网站负载很高。一台服务器扛不住啊。老哥DB,麻烦您用另外的服务器单独跑吧,这样我们不用再一台小机箱里面挤来挤去啊。好,优化下架构,又可以抗一会儿了。

2.jpg

业务很好,而且越来越多人了,整条村的人每天要访问我们的网站,服务器快扛不住了,怎么办啊,继续加机器呗。读写分离。一个主库+N多个从库。架构变成这样了。

3.jpg

好景不长,没过多久,用户量又要翻倍了,这下单台webapp不行了,好拆分业务,弄成多个web服务。

4.jpg

这下是稳稳地了。遇到压力就拆分,一点问题都没有。。。

一段时间后,各个应用,各个db竟然加起来有上百个之多。新人进来,简直要抓狂,而且服务的相互调用也乱成一锅粥了。

5.jpg

这种时候,怎么办?

肯定是删库跑路啊。谁留谁傻逼。

等等。。。。为啥不试试微服务呢?说不定还能抢救一下呢?

6.jpg

PART 2

然后,讲一下为啥要用spring cloud。项目越来越多,相互依赖越来越严重。通过http调用的方式已经要让人崩溃了。这时,spring cloud,这个微服务全家桶可以来拯救宇宙了。整理一下,spring cloud主要有以下内容:服务治理、分布式配置、分布式调度、调用跟踪等内容。我打算接下来,要写的也主要是这些:

1.spring bean 代码配置基础

2.spring boot基础

3.spring cloud eureka

4.spring cloud Ribbon

5.spring cloud Hystrix

6. spring cloud Feign

7.Spring Cloud Zuul

9.Spring Cloud Config

7.jpg