面对这疯狂升级的SpringCloud，咱在项目当中该何去何从呢？

hello，慕课网的各位同学们大家好，我是姚半仙，慕课网《Java架构师成长直通车》课程架构师讲师团成员之一。这一篇文章中我们一起来聊一聊面对这疯狂升级的SpringCloud版本，咱在项目当中该何去何从呢？那么在本篇文章的开始呢，我们就从很多很多年前SpringCloud诞生之初说起吧。

SpringCloud的第一个版本，它的名称叫做Angel(天使的意思)，它是诞生于2015年3月份，这个日期可不是它的立项日期哦，这是它的正式版发布的日期。在它这个版本发布之前，当然它在内部孵化酝酿了很长时间，然后才在2015年3月份面世的，它可谓是SpringCloud的开山立派的十足版本。

再往后SpringCloud发布了一个新的版本，它的开头字母是以B开头的，叫Brixton,那它是在2016年5月份发布的，距离上一次发布足足有一年零两个月，可能同学们觉得这个时间并不算太长，但是老师要告诉大家，这已经是SpringCloud中相距时间最长的两个大版本号了。

从Brixton以后，SpringCloud的发展路线就完全驶进了快车道。它的下一个大版本C版，也就是Campden，仅仅在四个月以后，也就是2016年9月份就发布了正式版本。

然后SpringCloud发布了著名的D版，这个版本Dalston是在业界广泛使用的一个版本。这个D版是一个蛮经典的版本，这里倒不是说它功能有多么精妙，多么完善，多么好，只不过经过前面ABC三版的铺垫，SpringCloud已经有了非常广泛的群众基础，所以这个Dalston版本出来的恰到时机。它也是早期应用非常非常广泛的一个版本，即便是现在来看依然有相当一大部分比例的应用依然是跑在Dalston上面。

那在Dalston后面发布了一个E版**(Edgware)**，这个版本相对来说就稍显低调一点了，它是在2017年11月份发布了正式的版本。

然后在E版之后是谁呀？那就是咱大名鼎鼎的F版**（Finchiley）**，这个2018年6月份发布的F版应该是目前来说在近两年内应用最广泛的一个版本了。

那转了一圈了，咱的课程用的是哪个版本呢？ 是2019年1月份出品的最新版的G版（GreenWich）。

大家放眼望去，这每个版本之间的时间间隔几乎就是半年更新一个版本，这可不是小版本，这可是ABCDE以字母序开头的大版本号啊。 这个更新迭代的速度太快了，简直就像那脱缰的野马一般。尽管当前看H版已经面世了，不过同学们请放心，老师这个课程是有售后三包的，当SpringCloud出了一个新版本之后，我也会同步的把咱的课程升级到新版本，然后再加一些章节告诉大家这个升级过程中所遇到的坑。

那咱领教了SpringCloud在大版本上的发力程度，我们再来看一看小版本。我们就以F版本为例，看一看这个大版本之下都有哪些小版本。

首先F版先是Milestone版本，这个Milestone版本可不是正儿八经的Release版本,它只是一个里程碑版本，这个里程碑版本相对酝酿的时间会比较长。我们精品窖藏始于2017，直到发展到了M9这个版本。

在日趋成熟之后它发布了RC版，那RC的意思就是Release Candidate，但是这依然不是正式的Release版本。那它总共发布了RC1和RC2，这个时间相对比较集中一些，是在2018年的4、5月份，这是发布之前做的准备。然后就是我们定稿之后的Release版,它是在2018年6月份发布的，不过咱在项目当中引用的还真的不是这个Release版本，是谁呢？是后面的SR正式版本。同学们可以看到咱引用项目的时候都会引用一个大版本号，后面跟着SR1-SR4，那这是相对来说稳定的，可以在项目中做实际开发用的版本。这些版本总共历时到现在为止已经有一年了，同学们可能会奇怪，这里说的历时一年，好像看上去现在还在开发对吧，没错，是这样的。尽管咱现在有了GreenWich，但是SpringCloud并没有停止之前的版本的研发维护工作。这每一个大版本都有一个持续的维护计划，并不是说新的大版本出来，上一个大版本就立马停用的，它还会继续维护那么一段时间。那我们这里就简单的跟大家说一下SpringCloud的维护策略。我这里就从四个象限跟大家聊一聊SpringCloud的发布维护策略大概是什么样子。

咱从表面上看，SpringCloud是从ABCD按照字母依次向后发布大版本，而且发布的非常频繁，大概在一年以内必定发布一版。不过这个发布过程并不是一条道走到黑的，什么意思呢？它会在多个版本线上并行开展，比如说咱现在用到的GreenWich正在如火如荼的在小版本上开始进行迭代。与此同时，下一个版本已经是在规划或者是在开发当中了，如果大家到Spring的官方网站上看它的文档，它其中有一个文档叫做Release Note，就是它的内部版本的发布记录，你会发现它在正式Release之前会有很多的里程碑版本。这些里程碑版本很早之前就已经在开发当中了，所以前后的多个大版本，其实是交叉迭代往前推进的。条条大路通罗马嘛,只要认准SpringCloud，不管你用哪个版本，其实都是可以把你的微服务搭起来的。那这里讲到的是它的发布策略。

接下来还有它的维护策略。即使大版本升级到了一个新的版本，那上一个版本依然还会持续维护很长一段时间，直到它在官方网站上宣布，比如说A版或者B版在某年某月某日停止维护。所以从这个角度来说,当大家看到SpringCloud发布了一个新的版本，那有的同学会觉得老版本它可能不会再继续支持了，我要赶紧升到新版本。其实大家不必惊慌，SpringCloud超级专业的，它可不只是干这一锤子买卖。你即使升了新版，它的老版本依然有一个维护计划，就像早些年你的电脑使用的是Windows XP的操作系统，那后面微软又陆续推出了Vista呀，win7,win8,win9,win10一系列后续版本，不过它的XP版本依然还是处于维护当中。不过老板本并不会这样永无止境的维护下去，这样就得永生了，对不对。所以SpringCloud官方也会发布通知，告知大家某一个老版本将会在什么时候停止维护。ok，以上便是它的发布和维护计划。

我们接下来往下看，咱们说有程序的地方就有Bug,对不对啊。有些开源项目并不那么靠谱，它对用户提出的Issue或者是Bug视而不见，但是咱SpringCloud这里可不一样，它的社区是非常非常积极的，甚至说如果你发现了SpringCloud的Issue,你可以去提交源代码，你去来Fix这个问题，然后提交给SpringCloud 的团队，让他们来审核，所以同学们甚至还有机会为SpringCloud贡献代码啊，这是一件非常荣耀的事情啊。它的整个开源的社区文化非常的Open,而且也非常的积极。

那最后，我要跟大家讲一讲这几个大版本之间的升级感受啊。就是你从一个老的版本升级到一个更新的版本，比如说你从B版升级到C版，或者从D版升级到F版, 那从我个人的感受来说,如果你升级一些早期的版本，比如从B版,C版一步把它跨版本升级到D版，F版，那这里面的坑可是要把人给淹死的，里面水非常非常的深。这里代码改动就不说了，它还有配置项的改动，配置文件里面的属性名称的改动，小细枝末节的改动，你很容易把它忽视掉，如果想全部摆平，可是要花一番功夫的。不过这个情况现在已经大大改善了。如果咱是从比较新的版本升级上来，比如说我们从F版升级到G版,这里面的改动其实是相当相当少的，轻轻松松就可以升级到最新版本了。好，那我们这四个象限的内容都跟大家看完了，大家心里有什么感受啊？

SpringCloud官方对待这个升级维护的态度可谓是尽心尽力啊，非常的积极，所以我把这个情况概括成四个字来形容SpringCloud如今的精神面貌,叫蓬勃发展。

接下来呢，SpringCloud升级新版本必然是有利有弊，所以我们要把利弊两方摆在一个天平上面，做一个衡量，这样我们才能更好的去权衡利弊，游刃有余。

那我们先来衡量一下追新版本都有什么显而易见的好处。

第一个显而易见的好处就是更新的版本，它会包含更新的组件或者会提供更多的新功能，那这些新内容可以帮助我们玩转新的业务场景，这个因素是我们做技术升级的主要考量标准。这种情况其实不单只体现在SpringCloud上面，就连咱们平时使用的中间件，JDK等都有这样的好处，比如你从JDK7升级到JDK8，那你可以享用JDK8中很多非常酷炫的功能，有的功能可以让你在并发操作Concurrently当中更游刃有余，还有的操作可以让你的代码逻辑变得更加优雅，比如Lambda表达式。咱升级版本的主要动力就是去享受新版本提供的新的业务功能，当然我们要考量一个标准，你的新功能对你的业务是不是有帮助，因为从老板的角度来说，我不在乎你用什么技术，我只在乎你把业务给搞定，所以我们不光只单单从程序员的角度出发看新版本有潜在的好处，你也要说服你的老板或者你的业务部门。所以，为了获取必要的研发资源来让你投入到新版本的升级当中，你可能也需要编造一个美丽的谎言来说服你的领导。

除了这个点以外，咱还有一个显而易见的好处是Bug Fix，尤其是对于SpringCloud的这种开源组件来说，全世界开发者的眼睛都盯着你呢，即便一个微小的Bug也很容易被查找出来。相对来说更新的版本意味着更少的Bug以及更稳定的特性。

那除了Bug Fix以外，当然还有它的安全性补丁，因为我们知道现在的黑产，包括黑客真是非常非常的猖狂，而且有很多傻瓜式的专业找Bug的工具,你只要输入一个网站，那这个工具后台会分析你的网站漏洞。那从这个角度来说，如果你的安全性不能得到保证，那么对你的网站来说可能会引发一些灾难性的问题。

那除此以外，还有一个可圈可点的特性，那就是技术栈的升级所带来的可扩展性的增强。在这十多年中有非常非常多的框架诞生,什么Struts1,Struts2各种框架。但在这滚滚历史的车轮当中为什么活到现在的是Spring? Spring从发展之初到今天，它的可扩展性都是做的非常非常好的。那SpringCloud的各个组件也秉承了这个传统，我们可以看到很多组件它都留有可扩展的接口，可以非常自由的添加自定义的逻辑。

那除了这些显而易见的优点以外，咱来看一看它的弊端。

第一个可以想到的弊端，就是你的替换成本。把你的整个项目的技术栈从老技术替换成新技术，这需要人力的投入，它就牵扯到开发资源，测试资源以及你的组件升级是否可以带来额外的运维成本，比如说你曾经是一个单War包的分布式集群，你想把它拆成微服务，那一个显而易见所带来的运维成本提升就是你的机器数量肯定会增加，虽然咱在云端大多使用的都是虚机，不过基于微服务架构的系统，它的运维成本和复杂度相对于传统应用还是要高一些。

除了这一点以外，我们还要考虑上下游系统的兼容性。比如说，有一天你做了一个系统升级，采用了SpringCloud的Eureka作为服务发现框架，但是上游的系统它未必买账，它可能还是基于最老式的WebService 的形式调用，甚至有的更老的系统它还采用Super协议,所以说你对业务模块或者是业务模组的升级，并不是一个一拍脑袋就可以上的,你要有一个全局统筹的规划来协调上下游的应用。

除了这两个以外，我们就要谈一谈业务了。你的升级对你当前业务都有什么影响,我们希望你的升级对当前业务一定有一个积极的影响，打个比方，大家都用过消息中间件对吧，假如咱用的是非常老的版本，那可能只有非常基本的消费者、生产者的功能,那如果大家升级到新版本，它可能添加了死信队列，延迟消息这种非常酷炫的功能，那我们自然可以利用这个特性来完成更复杂的业务场景，那这是业务团队比较愿意看到的。相反，如果我们哼哧哼哧，费老鼻子劲把自己的组件升级了，但是对业务却没有什么影响，你的老板会问：“小张啊，你让整个团队花了一个星期升级这个系统带来了什么好处呢？” 你总不能告诉老板说是为了技术人员的信仰和追求吧。

我们很多时候做决定，不能单单从技术的角度出发，一定要从业务这个角度来思考一下，因为真正拍板的人大部分不是技术人员，而是业务团队，那咱看了这个升版的好处和升版可能带来的弊端，如果让同学做个抉择，该怎么办呢？站在天平的两端一样的为难，唯一的答案，我们要结合业务需要和技术需要来做这一个决定，所以这个意思就告诉大家：**you must know what your doing ，there must be a reason for doing this。**我们要为这个决定找一个借口，你也要非常清楚为什么做出这个决定，不管它是从业务上的需要，还是从技术上的考量。那么在这个过程中，我们一定要杜绝一个技术人员非常容易犯的错误----为新而新，为了新版本而升级新版本，你甚至不知道这个新版本能给你带来什么好处，就一拍脑袋就上了，这种价值观可不可取哦~

讲了这么多，同学们心里可能也在嘀咕，那这个结论到底是什么呢？这里咱就先呈上我推荐的方式，用当今非常流行的知乎体来问问题，就叫做你如何看待项目技术的升级？谢邀谢邀，我这里先上答案。

我的观点是在面对项目的技术栈升级，要更新，但不要追新。这里我再给四个小建议。

第一个是我们需要在团队内或者是部门内建立一个Tech Stack Review的机制，就是每隔半年或者每个年度我们要让经验足够丰富，并且非常了解你们业务的架构师来对你的技术栈进行一个Review。很多团队在项目成型了以后，这个技术栈选型就成了一摊死水，没人会去管，也没人会去有这个动力让它持续更新，那我们建立这种Tech Stack Review机制就是从部门层面，甚至说公司层面推进你技术的更新换代，逐渐淘汰老旧的系统，还有过时的技术栈。

除此之外，面对SpringCloud，因为它的版本更迭速度非常快，新的功能也不断的推出，我们要持续关注新的大版本，这里面就包括了它所提供的新功能以及新组件。

结合你的业务场景，看一看这些的新元素能否助力你的业务更好的发展。一旦你决定使用的新版本以后，我建议，只采用SR的发布版（这里是针对SpringCloud来说的），绝对不要冒进去使用Milestone版本，或者是RC版本，只认准SC发布版啊。

在你规划升级过程当中，我们要做一个POC先行。POC相对来说是一个轻量级的可行性验证的阶段。在确认方案可行的基础上，我们改造完之后，一定要记得进行全链路的测试，并且制定好完善的回滚计划，不怕一万，只怕万一，生产上没有小事故。

ok，同学们，那到这里，本节内容就结束了。我来带大家稍微回顾一下。咱前面讲到了SpringCloud疯狂发布的新版本，包括它的大版本更新节奏以及小版本的更新策略。后面又和同学交代SpringCloud的维护策略，就是它在大版本上有多个版本同时迭代，然后每推出一个大版本之后，上一个版本依然会维持相当长的一段时间的维护。后面我们又探讨了升级版本的利弊，从业务角度和技术角度等诸多方面和大家探讨了升版所要考虑的问题。这里一个观点就是不要为新而新，不能因为它更新而直接采用它，我们一定要找一个合理的理由。那最后又给大家列出了几个项目技术升级的推荐方式。咱贯穿始终的观点是要更新，但是不要追新。

好，同学们这一节的内容就到这里结束了。在课程后面小节当中，我将跟大家介绍一下我对电商项目改造的几个看法，也就是说，我们打算怎么来规划电商项目的微服务改造，把它分为哪些模块等等。ok，同学们，那我们课程里不见不散。