其實(shí)我們?cè)谶@條路上已經(jīng)走了一年多，從16年初到現(xiàn)在。

上次寫(xiě)了一篇文章叫Spring Cloud在國(guó)內(nèi)中小型公司能用起來(lái)嗎?介紹了Spring Cloud是否能在中小公司使用起來(lái)，這篇文章是它的姊妹篇。

其實(shí)我們?cè)谶@條路上已經(jīng)走了一年多，從16年初到現(xiàn)在。在使用Spring Cloud之前我們對(duì)微服務(wù)實(shí)踐是沒(méi)有太多的體會(huì)和經(jīng)驗(yàn)的。從最初的開(kāi)源軟件云收藏來(lái)熟悉Spring Boot，到項(xiàng)目中的慢慢使用，再到最后全面擁抱Spring Cloud。

這篇文章就給大家介紹一下我們使用Spring Boot/Cloud一年多的經(jīng)驗(yàn)。

在開(kāi)始之前我們先介紹一下幾個(gè)概念，什么是微服務(wù)，它的特點(diǎn)是什么? Spring Boot/Cloud都做了那些事情？他們?nèi)咧g又有什么聯(lián)系？

技術(shù)背景

什么是微服務(wù)？

微服務(wù)的概念源于2014年3月Martin Fowler所寫(xiě)的一篇文章“Microservices”。

微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶(hù)提供最終價(jià)值。每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)間采用輕量級(jí)的通信機(jī)制互相溝通（通常是基于HTTP的RESTful API）。

每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立地部署到生產(chǎn)環(huán)境、類(lèi)生產(chǎn)環(huán)境等。另外，應(yīng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機(jī)制，對(duì)具體的一個(gè)服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語(yǔ)言、工具對(duì)其進(jìn)行構(gòu)建。

微服務(wù)是一種架構(gòu)風(fēng)格，一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成。系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個(gè)任務(wù)代表著一個(gè)小的業(yè)務(wù)能力。

微服務(wù)架構(gòu)優(yōu)勢(shì)

復(fù)雜度可控：在將應(yīng)用分解的同時(shí)，規(guī)避了原本復(fù)雜度無(wú)止境的積累。每一個(gè)微服務(wù)專(zhuān)注于單一功能，并通過(guò)定義良好的接口清晰表述服務(wù)邊界。由于體積小、復(fù)雜度低，每個(gè)微服務(wù)可由一個(gè)小規(guī)模開(kāi)發(fā)團(tuán)隊(duì)完全掌控，易于保持高可維護(hù)性和開(kāi)發(fā)效率。

獨(dú)立部署：由于微服務(wù)具備獨(dú)立的運(yùn)行進(jìn)程，所以每個(gè)微服務(wù)也可以獨(dú)立部署。當(dāng)某個(gè)微服務(wù)發(fā)生變更時(shí)無(wú)需編譯、部署整個(gè)應(yīng)用。由微服務(wù)組成的應(yīng)用相當(dāng)于具備一系列可并行的發(fā)布流程，使得發(fā)布更加高效，同時(shí)降低對(duì)生產(chǎn)環(huán)境所造成的風(fēng)險(xiǎn)，最終縮短應(yīng)用交付周期。

技術(shù)選型靈活：微服務(wù)架構(gòu)下，技術(shù)選型是去中心化的。每個(gè)團(tuán)隊(duì)可以根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術(shù)棧。由于每個(gè)微服務(wù)相對(duì)簡(jiǎn)單，故需要對(duì)技術(shù)棧進(jìn)行升級(jí)時(shí)所面臨的風(fēng)險(xiǎn)就較低，甚至完全重構(gòu)一個(gè)微服務(wù)也是可行的。

容錯(cuò)：當(dāng)某一組件發(fā)生故障時(shí)，在單一進(jìn)程的傳統(tǒng)架構(gòu)下，故障很有可能在進(jìn)程內(nèi)擴(kuò)散，形成應(yīng)用全局性的不可用。在微服務(wù)架構(gòu)下，故障會(huì)被隔離在單個(gè)服務(wù)中。若設(shè)計(jì)良好，其他服務(wù)可通過(guò)重試、平穩(wěn)退化等機(jī)制實(shí)現(xiàn)應(yīng)用層面的容錯(cuò)。

擴(kuò)展：?jiǎn)螇K架構(gòu)應(yīng)用也可以實(shí)現(xiàn)橫向擴(kuò)展，就是將整個(gè)應(yīng)用完整的復(fù)制到不同的節(jié)點(diǎn)。當(dāng)應(yīng)用的不同組件在擴(kuò)展需求上存在差異時(shí)，微服務(wù)架構(gòu)便體現(xiàn)出其靈活性，因?yàn)槊總€(gè)服務(wù)可以根據(jù)實(shí)際需求獨(dú)立進(jìn)行擴(kuò)展。

什么是Spring Boot？

Spring Boot是由Pivotal團(tuán)隊(duì)提供的全新框架，其設(shè)計(jì)目的是用來(lái)簡(jiǎn)化新Spring應(yīng)用的初始搭建以及開(kāi)發(fā)過(guò)程。該框架使用了特定的方式來(lái)進(jìn)行配置，從而使開(kāi)發(fā)人員不再需要定義樣板化的配置。

用我的話(huà)來(lái)理解，就是Spring Boot其實(shí)不是什么新的框架，它默認(rèn)配置了很多框架的使用方式，就像maven整合了所有的jar包，Spring Boot整合了所有的框架（不知道這樣比喻是否合適）。

Spring Boot簡(jiǎn)化了基于Spring的應(yīng)用開(kāi)發(fā)，通過(guò)少量的代碼就能創(chuàng)建一個(gè)獨(dú)立的、產(chǎn)品級(jí)別的Spring應(yīng)用。 Spring Boot為Spring平臺(tái)及第三方庫(kù)提供開(kāi)箱即用的設(shè)置，這樣你就可以有條不紊地開(kāi)始。

Spring Boot的核心思想就是約定大于配置，多數(shù)Spring Boot應(yīng)用只需要很少的Spring配置。采用Spring Boot可以大大的簡(jiǎn)化你的開(kāi)發(fā)模式，所有你想集成的常用框架，它都有對(duì)應(yīng)的組件支持。

Spring Cloud 都做了哪些事

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開(kāi)發(fā)便利性巧妙地簡(jiǎn)化了分布式系統(tǒng)基礎(chǔ)設(shè)施的開(kāi)發(fā)，如服務(wù)發(fā)現(xiàn)注冊(cè)、配置中心、消息總線、負(fù)載均衡、斷路器、數(shù)據(jù)監(jiān)控等，都可以用Spring Boot的開(kāi)發(fā)風(fēng)格做到一鍵啟動(dòng)和部署。

Spring并沒(méi)有重復(fù)制造輪子，它只是將目前各家公司開(kāi)發(fā)的比較成熟、經(jīng)得起實(shí)際考驗(yàn)的服務(wù)框架組合起來(lái)，通過(guò)Spring Boot風(fēng)格進(jìn)行再封裝屏蔽掉了復(fù)雜的配置和實(shí)現(xiàn)原理，最終給開(kāi)發(fā)者留出了一套簡(jiǎn)單易懂、易部署和易維護(hù)的分布式系統(tǒng)開(kāi)發(fā)工具包

以下為Spring Cloud的核心功能：

• 分布式/版本化配置

• 服務(wù)注冊(cè)和發(fā)現(xiàn)

• 路由

• 服務(wù)和服務(wù)之間的調(diào)用

• 負(fù)載均衡

• 斷路器

• 分布式消息傳遞

我們?cè)賮?lái)看一張圖：

通過(guò)這張圖，我們來(lái)了解一下各組件配置使用運(yùn)行流程：

• 1、請(qǐng)求統(tǒng)一通過(guò)API網(wǎng)關(guān)（Zuul）來(lái)訪問(wèn)內(nèi)部服務(wù).

• 2、網(wǎng)關(guān)接收到請(qǐng)求后，從注冊(cè)中心（Eureka）獲取可用服務(wù)

• 3、由Ribbon進(jìn)行均衡負(fù)載后，分發(fā)到后端具體實(shí)例

• 4、微服務(wù)之間通過(guò)Feign進(jìn)行通信處理業(yè)務(wù)

• 5、Hystrix負(fù)責(zé)處理服務(wù)超時(shí)熔斷

• 6、Turbine監(jiān)控服務(wù)間的調(diào)用和熔斷相關(guān)指標(biāo)

Spring Cloud體系介紹

上圖只是Spring Cloud體系的一部分，Spring Cloud共集成了19個(gè)子項(xiàng)目，里面都包含一個(gè)或者多個(gè)第三方的組件或者框架！

Spring Cloud 工具框架

1、Spring Cloud Config 配置中心，利用git集中管理程序的配置。
2、Spring Cloud Netflix 集成眾多Netflix的開(kāi)源軟件
3、Spring Cloud Bus 消息總線，利用分布式消息將服務(wù)和服務(wù)實(shí)例連接在一起，用于在一個(gè)集群中傳播狀態(tài)的變化
4、Spring Cloud for Cloud Foundry 利用Pivotal Cloudfoundry集成你的應(yīng)用程序
5、Spring Cloud Cloud Foundry Service Broker 為建立管理云托管服務(wù)的服務(wù)代理提供了一個(gè)起點(diǎn)。
6、Spring Cloud Cluster 基于Zookeeper, Redis, Hazelcast, Consul實(shí)現(xiàn)的領(lǐng)導(dǎo)選舉和平民狀態(tài)模式的抽象和實(shí)現(xiàn)。
7、Spring Cloud Consul 基于Hashicorp Consul實(shí)現(xiàn)的服務(wù)發(fā)現(xiàn)和配置管理。
8、Spring Cloud Security 在Zuul代理中為OAuth2 rest客戶(hù)端和認(rèn)證頭轉(zhuǎn)發(fā)提供負(fù)載均衡
9、Spring Cloud Sleuth SpringCloud應(yīng)用的分布式追蹤系統(tǒng)，和Zipkin，HTrace，ELK兼容。
10、Spring Cloud Data Flow 一個(gè)云本地程序和操作模型，組成數(shù)據(jù)微服務(wù)在一個(gè)結(jié)構(gòu)化的平臺(tái)上。
11、Spring Cloud Stream 基于Redis,Rabbit,Kafka實(shí)現(xiàn)的消息微服務(wù)，簡(jiǎn)單聲明模型用以在Spring Cloud應(yīng)用中收發(fā)消息。
12、Spring Cloud Stream App Starters 基于Spring Boot為外部系統(tǒng)提供spring的集成
13、Spring Cloud Task 短生命周期的微服務(wù)，為SpringBooot應(yīng)用簡(jiǎn)單聲明添加功能和非功能特性。
14、Spring Cloud Task App Starters
15、Spring Cloud Zookeeper 服務(wù)發(fā)現(xiàn)和配置管理基于Apache Zookeeper。
16、Spring Cloud for Amazon Web Services 快速和亞馬遜網(wǎng)絡(luò)服務(wù)集成。
17、Spring Cloud Connectors 便于PaaS應(yīng)用在各種平臺(tái)上連接到后端像數(shù)據(jù)庫(kù)和消息經(jīng)紀(jì)服務(wù)。
18、Spring Cloud Starters （項(xiàng)目已經(jīng)終止并且在Angel.SR2后的版本和其他項(xiàng)目合并）
19、Spring Cloud CLI 插件用Groovy快速的創(chuàng)建Spring Cloud組件應(yīng)用。

當(dāng)然這個(gè)數(shù)量還在一直增加...

三者之間的關(guān)系

微服務(wù)是一種架構(gòu)的理念，提出了微服務(wù)的設(shè)計(jì)原則，從理論為具體的技術(shù)落地提供了指導(dǎo)思想。Spring Boot是一套快速配置腳手架，可以基于Spring Boot快速開(kāi)發(fā)單個(gè)微服務(wù)；Spring Cloud是一個(gè)基于Spring Boot實(shí)現(xiàn)的服務(wù)治理工具包；Spring Boot專(zhuān)注于快速、方便集成的單個(gè)微服務(wù)個(gè)體，Spring Cloud關(guān)注全局的服務(wù)治理框架。

Spring Boot/Cloud是微服務(wù)實(shí)踐的最佳落地方案。

實(shí)戰(zhàn)經(jīng)歷

遇到問(wèn)題，尋找方案

2015年初的時(shí)候，因?yàn)楣緲I(yè)務(wù)的大量發(fā)展，我們開(kāi)始對(duì)原有的業(yè)務(wù)進(jìn)行拆分，新上的業(yè)務(wù)線也全部使用獨(dú)立的項(xiàng)目來(lái)開(kāi)發(fā)，項(xiàng)目和項(xiàng)目之間通過(guò)http接口進(jìn)行訪問(wèn)。

15年的業(yè)務(wù)發(fā)展非常迅速，項(xiàng)目數(shù)量也就相應(yīng)急劇擴(kuò)大，到了15底的時(shí)候項(xiàng)目達(dá)60多個(gè)，當(dāng)項(xiàng)目數(shù)達(dá)到30幾個(gè)的時(shí)候，其實(shí)我們就遇到了問(wèn)題，經(jīng)常某個(gè)項(xiàng)目因?yàn)閿U(kuò)展增加了新的IP地址，我們就需要被動(dòng)的更新好幾個(gè)相關(guān)的項(xiàng)目。

服務(wù)越來(lái)越多，服務(wù)之間的調(diào)用關(guān)系也越來(lái)越復(fù)雜，有時(shí)候想畫(huà)一張圖來(lái)表示項(xiàng)目和項(xiàng)目之間的依賴(lài)關(guān)系，線條密密麻麻無(wú)法看清。網(wǎng)上有一張圖可以表達(dá)我們的心情。

這個(gè)時(shí)候我們就想找一種方案，可以將我們這么多分布式的服務(wù)給管理起來(lái)，到網(wǎng)上進(jìn)行了技術(shù)調(diào)研。我們發(fā)現(xiàn)有兩款開(kāi)源軟件比較適合我們，一個(gè)是Dubbo，一個(gè)是Spring Cloud。

其實(shí)剛開(kāi)始我們是走了一些彎路的。這兩款框架我們當(dāng)時(shí)都不熟悉，當(dāng)時(shí)國(guó)內(nèi)使用Spring Cloud進(jìn)行開(kāi)發(fā)的企業(yè)非常的少，我在網(wǎng)上也幾乎沒(méi)找到太多應(yīng)用的案例。但是Dubbo當(dāng)時(shí)在國(guó)內(nèi)的使用還是挺普遍的，相關(guān)的資料各方面都比較完善。因此在公司擴(kuò)展新業(yè)務(wù)線眾籌平臺(tái)的時(shí)候，技術(shù)選型就先定了Dubbo，因?yàn)橐彩侨碌臉I(yè)務(wù)沒(méi)有什么負(fù)擔(dān)，這個(gè)項(xiàng)目我們大概開(kāi)發(fā)了六個(gè)月投產(chǎn)，上線之初也遇到了一些問(wèn)題，但最終還比較順利。

在新業(yè)務(wù)線選型使用Dubbo的同時(shí)，我們也沒(méi)有完全放棄Spring Cloud，我們抽出了一兩名開(kāi)發(fā)人員學(xué)習(xí)Spring Boot我也參與其中，為了驗(yàn)證Spring Boot是否可以到達(dá)實(shí)戰(zhàn)的標(biāo)準(zhǔn)，我們?cè)跇I(yè)余的時(shí)間使用Spring Boot開(kāi)發(fā)了一款開(kāi)源軟件云收藏，經(jīng)過(guò)這個(gè)項(xiàng)目的實(shí)戰(zhàn)驗(yàn)證我們對(duì)Spring Boot就有了信心。最重要的是大家體會(huì)到使用Spring Boot的各種便利之后，就再也不想使用傳統(tǒng)的方式來(lái)進(jìn)行開(kāi)發(fā)了。

但是還有一個(gè)問(wèn)題，在選擇了Spring Boot進(jìn)行新業(yè)務(wù)開(kāi)發(fā)的同時(shí)，并沒(méi)有解決我們上面的那個(gè)問(wèn)題，服務(wù)于服務(wù)直接調(diào)用仍然比較復(fù)雜和傳統(tǒng)，這時(shí)候我們就開(kāi)始研究Spring Cloud。因?yàn)榇蠹以谇捌趯?duì)Spring Boot有了足夠的了解，因此學(xué)習(xí)Sprig Cloud就顯得順風(fēng)順?biāo)?。所以在使用Dubbo半年之后，我們又全面開(kāi)始擁抱Spring Cloud。

為什么選擇使用Spring Cloud而放棄了Dubbo

可能大家會(huì)問(wèn)，為什么選擇了使用Dubbo之后，而又選擇全面使用Spring Cloud呢？其中有幾個(gè)原因：

1）從兩個(gè)公司的背景來(lái)談：Dubbo，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于中國(guó)各互聯(lián)網(wǎng)公司；Spring Cloud是大名鼎鼎的Spring家族的產(chǎn)品。阿里巴巴是一個(gè)商業(yè)公司，雖然也開(kāi)源了很多的頂級(jí)的項(xiàng)目，但從整體戰(zhàn)略上來(lái)講，仍然是服務(wù)于自身的業(yè)務(wù)為主。Spring專(zhuān)注于企業(yè)級(jí)開(kāi)源框架的研發(fā)，不論是在中國(guó)還是在世界上使用都非常廣泛，開(kāi)發(fā)出通用、開(kāi)源、穩(wěn)健的開(kāi)源框架就是他們的主業(yè)。

2）從社區(qū)活躍度這個(gè)角度來(lái)對(duì)比，Dubbo雖然也是一個(gè)非常優(yōu)秀的服務(wù)治理框架，并且在服務(wù)治理、灰度發(fā)布、流量分發(fā)這方面做的比Spring Cloud還好，除過(guò)當(dāng)當(dāng)網(wǎng)在基礎(chǔ)上增加了rest支持外，已有兩年多的時(shí)間幾乎都沒(méi)有任何更新了。在使用過(guò)程中出現(xiàn)問(wèn)題，提交到github的Issue也少有回復(fù)。

相反Spring Cloud自從發(fā)展到現(xiàn)在，仍然在不斷的高速發(fā)展，從github上提交代碼的頻度和發(fā)布版本的時(shí)間間隔就可以看出，現(xiàn)在Spring Cloud即將發(fā)布2.0版本，到了后期會(huì)更加完善和穩(wěn)定。

3）從整個(gè)大的平臺(tái)架構(gòu)來(lái)講，dubbo框架只是專(zhuān)注于服務(wù)之間的治理，如果我們需要使用配置中心、分布式跟蹤這些內(nèi)容都需要自己去集成，這樣無(wú)形中使用dubbo的難度就會(huì)增加。Spring Cloud幾乎考慮了服務(wù)治理的方方面面，更有Spring Boot這個(gè)大將的支持，開(kāi)發(fā)起來(lái)非常的便利和簡(jiǎn)單。

4）從技術(shù)發(fā)展的角度來(lái)講，Dubbo剛出來(lái)的那會(huì)技術(shù)理念還是非常先進(jìn)，解決了各大互聯(lián)網(wǎng)公司服務(wù)治理的問(wèn)題，中國(guó)的各中小公司也從中受益不少。經(jīng)過(guò)了這么多年的發(fā)展，互聯(lián)網(wǎng)行業(yè)也是涌現(xiàn)了更多先進(jìn)的技術(shù)和理念，Dubbo一直停滯不前，自然有些掉隊(duì)，有時(shí)候我個(gè)人也會(huì)感到有點(diǎn)可惜，如果Dubbo一直沿著當(dāng)初的那個(gè)路線發(fā)展，并且延伸到周邊，今天可能又是另一番景象了。

Spring 推出Spring Boot/Cloud也是因?yàn)樽陨淼暮芏嘣?。Spring最初推崇的輕量級(jí)框架，隨著不斷的發(fā)展也越來(lái)越龐大，隨著集成項(xiàng)目越來(lái)越多，配置文件也越來(lái)越混亂，慢慢的背離最初的理念。

隨著這么多年的發(fā)展，微服務(wù)、分布式鏈路跟蹤等更多新的技術(shù)理念的出現(xiàn)，Spring急需一款框架來(lái)改善以前的開(kāi)發(fā)模式，因此才會(huì)出現(xiàn)Spring Boot/Cloud項(xiàng)目，我們現(xiàn)在訪問(wèn)Spring官網(wǎng)，會(huì)發(fā)現(xiàn)Spring Boot和Spring Cloud已經(jīng)放到首頁(yè)最重點(diǎn)突出的三個(gè)項(xiàng)目中的前兩個(gè)，可見(jiàn)Spring對(duì)這兩個(gè)框架的重視程度。

總結(jié)一下，dubbo曾經(jīng)確實(shí)很牛逼，但是Spring Cloud是站在近些年技術(shù)發(fā)展之上進(jìn)行開(kāi)發(fā)，因此更具技術(shù)代表性。

如何進(jìn)行微服務(wù)架構(gòu)演進(jìn)

當(dāng)我們將所有的新業(yè)務(wù)都使用Spring Cloud這套架構(gòu)之后，就會(huì)出現(xiàn)這樣一個(gè)現(xiàn)象，公司的系統(tǒng)被分成了兩部分，一部分是傳統(tǒng)架構(gòu)的項(xiàng)目，一部分是微服務(wù)架構(gòu)的項(xiàng)目，如何讓這兩套配合起來(lái)使用就成為了關(guān)鍵，這時(shí)候Spring Cloud里面的一個(gè)關(guān)鍵組件解決了我們的問(wèn)題，就是Zuul。

在Spring Cloud架構(gòu)體系內(nèi)的所有微服務(wù)都通過(guò)Zuul來(lái)對(duì)外提供統(tǒng)一的訪問(wèn)入口，所有需要和微服務(wù)架構(gòu)內(nèi)部服務(wù)進(jìn)行通訊的請(qǐng)求都走統(tǒng)一網(wǎng)關(guān)。如下圖：

從上圖可以看出我們對(duì)服務(wù)進(jìn)行了分類(lèi)，有四種：基礎(chǔ)服務(wù)、業(yè)務(wù)服務(wù)、組合服務(wù)、前置服務(wù)。不同服務(wù)遷移的優(yōu)先級(jí)不同

• 基礎(chǔ)服務(wù)，是一些基礎(chǔ)組件，與具體的業(yè)務(wù)無(wú)關(guān)。比如：短信服務(wù)、郵件服務(wù)。這里的服務(wù)最容易摘出來(lái)做微服務(wù)，也是我們第一優(yōu)先級(jí)分離出來(lái)的服務(wù)。

• 業(yè)務(wù)服務(wù)，是一些垂直的業(yè)務(wù)系統(tǒng)，只處理單一的業(yè)務(wù)類(lèi)型，比如：風(fēng)控系統(tǒng)、積分系統(tǒng)、合同系統(tǒng)。這類(lèi)服務(wù)職責(zé)比較單一，根據(jù)業(yè)務(wù)情況來(lái)選擇是否遷移，比如：如果突然有需求對(duì)積分系統(tǒng)進(jìn)行大優(yōu)化，我們就趁機(jī)將積分系統(tǒng)進(jìn)行改造，是我們的第二優(yōu)先級(jí)分離出來(lái)的服務(wù)。

• 前置服務(wù)，前置服務(wù)一般為服務(wù)的接入或者輸出服務(wù)，比如網(wǎng)站的前端服務(wù)、app的服務(wù)接口這類(lèi)，這是我們第三優(yōu)先級(jí)分離出來(lái)的服務(wù)。

• 組合服務(wù)，組合服務(wù)就是涉及到了具體的業(yè)務(wù)，比如買(mǎi)標(biāo)過(guò)程，需要調(diào)用很多垂直的業(yè)務(wù)服務(wù)，這類(lèi)的服務(wù)我們一般放到最后再進(jìn)行微服務(wù)化架構(gòu)來(lái)改造，因?yàn)檫@類(lèi)服務(wù)最為復(fù)雜，除非涉及到大的業(yè)務(wù)邏輯變更，我們是不會(huì)輕易進(jìn)行遷移。

在這四類(lèi)服務(wù)之外，新上線的業(yè)務(wù)全部使用Sprng Boot/Cloud這套技術(shù)棧。就這樣，我們從開(kāi)源項(xiàng)目云收藏開(kāi)始，上線幾個(gè)Spring Boot項(xiàng)目，到現(xiàn)在公司絕大部分的項(xiàng)目都是在Spring Cloud這個(gè)架構(gòu)體系中。

經(jīng)驗(yàn)和教訓(xùn)

架構(gòu)演化的步驟

• 在確定使用Spring Boot/Cloud這套技術(shù)棧進(jìn)行微服務(wù)改造之前，先梳理平臺(tái)的服務(wù)，對(duì)不同的服務(wù)進(jìn)行分類(lèi)，以確認(rèn)演化的節(jié)奏。

• 先讓團(tuán)隊(duì)熟悉Spring Boot技術(shù)，并且優(yōu)先在基礎(chǔ)服務(wù)上進(jìn)行技術(shù)改造，推動(dòng)改動(dòng)后的項(xiàng)目投產(chǎn)上線

• 當(dāng)團(tuán)隊(duì)熟悉Spring Boot之后，再推進(jìn)使用Spring Cloud對(duì)原有的項(xiàng)目進(jìn)行改造。

• 在進(jìn)行微服務(wù)改造過(guò)程中，優(yōu)先應(yīng)用于新業(yè)務(wù)系統(tǒng)，前期可以只是少量的項(xiàng)目進(jìn)行了微服務(wù)化改造，隨著大家對(duì)技術(shù)的熟悉度增加，可以加快加大微服務(wù)改造的范圍

• 傳統(tǒng)項(xiàng)目和微服務(wù)項(xiàng)目共存是一個(gè)很常見(jiàn)的情況，除非公司業(yè)務(wù)有大的變化，不建議直接遷移核心項(xiàng)目。

服務(wù)拆分原則

服務(wù)拆分有以下幾個(gè)原則和大家分享

橫向拆分。按照不同的業(yè)務(wù)域進(jìn)行拆分，例如訂單、營(yíng)銷(xiāo)、風(fēng)控、積分資源等。形成獨(dú)立的業(yè)務(wù)領(lǐng)域微服務(wù)集群。

縱向拆分。把一個(gè)業(yè)務(wù)功能里的不同模塊或者組件進(jìn)行拆分。例如把公共組件拆分成獨(dú)立的原子服務(wù)，下沉到底層，形成相對(duì)獨(dú)立的原子服務(wù)層。這樣一縱一橫，就可以實(shí)現(xiàn)業(yè)務(wù)的服務(wù)化拆分。

要做好微服務(wù)的分層：梳理和抽取核心應(yīng)用、公共應(yīng)用，作為獨(dú)立的服務(wù)下沉到核心和公共能力層，逐漸形成穩(wěn)定的服務(wù)中心，使前端應(yīng)用能更快速的響應(yīng)多變的市場(chǎng)需求

服務(wù)拆分是越小越好嗎？微服務(wù)的大與小是相對(duì)的。比如在初期，我們把交易拆分為一個(gè)微服務(wù)，但是隨著業(yè)務(wù)量的增大，可能一個(gè)交易系統(tǒng)已經(jīng)慢慢變得很大，并且并發(fā)流量也不小，為了支撐更多的交易量，我會(huì)把交易系統(tǒng)，拆分為訂單服務(wù)、投標(biāo)服務(wù)、轉(zhuǎn)讓服務(wù)等。因此微服務(wù)的拆分力度需與具體業(yè)務(wù)相結(jié)合，總的原則是服務(wù)內(nèi)部高內(nèi)聚，服務(wù)之間低耦合。

微服務(wù)vs傳統(tǒng)開(kāi)發(fā)

使用微服務(wù)有一段時(shí)間了，這種開(kāi)發(fā)模式和傳統(tǒng)的開(kāi)發(fā)模式對(duì)比，有很大的不同。

• 分工不同，以前我們可能是一個(gè)一個(gè)模塊，現(xiàn)在可能是一人一個(gè)系統(tǒng)。

• 架構(gòu)不同，服務(wù)的拆分是一個(gè)技術(shù)含量很高的問(wèn)題，拆分是否合理對(duì)以后發(fā)展影響巨大。

• 部署方式不同，如果還像以前一樣部署估計(jì)累死了，自動(dòng)化運(yùn)維不可不上。

• 容災(zāi)不同，好的微服務(wù)可以隔離故障避免服務(wù)整體down掉，壞的微服務(wù)設(shè)計(jì)仍然可以因?yàn)橐粋€(gè)子服務(wù)出現(xiàn)問(wèn)題導(dǎo)致連鎖反應(yīng)。

給數(shù)據(jù)庫(kù)帶來(lái)的挑戰(zhàn)

每個(gè)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫(kù)，那么后臺(tái)管理的聯(lián)合查詢(xún)?cè)趺刺幚?？這應(yīng)該是大家會(huì)普遍遇到的一個(gè)問(wèn)題，有三種處理方案。

1）嚴(yán)格按照微服務(wù)的劃分來(lái)做，微服務(wù)相互獨(dú)立，各微服務(wù)數(shù)據(jù)庫(kù)也獨(dú)立，后臺(tái)需要展示數(shù)據(jù)時(shí)，調(diào)用各微服務(wù)的接口來(lái)獲取對(duì)應(yīng)的數(shù)據(jù)，再進(jìn)行數(shù)據(jù)處理后展示出來(lái)，這是標(biāo)準(zhǔn)的用法，也是最麻煩的用法。

2）將業(yè)務(wù)高度相關(guān)的表放到一個(gè)庫(kù)中，將業(yè)務(wù)關(guān)系不是很緊密的表嚴(yán)格按照微服務(wù)模式來(lái)拆分，這樣既可以使用微服務(wù)，也避免了數(shù)據(jù)庫(kù)分散導(dǎo)致后臺(tái)系統(tǒng)統(tǒng)計(jì)功能難以實(shí)現(xiàn)，是一個(gè)折中的方案。

3）數(shù)據(jù)庫(kù)嚴(yán)格按照微服務(wù)的要求來(lái)切分，以滿(mǎn)足業(yè)務(wù)高并發(fā)，實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)將各微服務(wù)數(shù)據(jù)庫(kù)數(shù)據(jù)同步到NoSQL數(shù)據(jù)庫(kù)中，在同步的過(guò)程中進(jìn)行數(shù)據(jù)清洗，用來(lái)滿(mǎn)足后臺(tái)業(yè)務(wù)系統(tǒng)的使用，推薦使用MongoDB、HBase等。

三種方案在不同的公司我都使用過(guò)，第一種方案適合業(yè)務(wù)較為簡(jiǎn)單的小公司；第二種方案，適合在原有系統(tǒng)之上，慢慢演化為微服務(wù)架構(gòu)的公司；第三種適合大型高并發(fā)的互聯(lián)網(wǎng)公司。

微服務(wù)的經(jīng)驗(yàn)和建議

1、建議盡量不要使用Jsp，頁(yè)面開(kāi)發(fā)推薦使用Thymeleaf。Web項(xiàng)目建議獨(dú)立部署Tomcat，不要使用內(nèi)嵌的Tomcat，內(nèi)嵌Tomcat部署Jsp項(xiàng)目會(huì)偶現(xiàn)龜速訪問(wèn)的情況。

2、服務(wù)編排是個(gè)好東西，主要的作用是減少項(xiàng)目中的相互依賴(lài)。比如現(xiàn)在有項(xiàng)目a調(diào)用項(xiàng)目b，項(xiàng)目b調(diào)用項(xiàng)目c...一直到h，是一個(gè)調(diào)用鏈，那么項(xiàng)目上線的時(shí)候需要先更新最底層的h再更新g...更新c更新b最后是更新項(xiàng)目a。這只是這一個(gè)調(diào)用鏈，在復(fù)雜的業(yè)務(wù)中有非常多的調(diào)用，如果要記住每一個(gè)調(diào)用鏈對(duì)開(kāi)發(fā)運(yùn)維人員來(lái)說(shuō)就是災(zāi)難。

有這樣一個(gè)好辦法可以盡量的減少項(xiàng)目的相互依賴(lài)，就是服務(wù)編排，一個(gè)核心的業(yè)務(wù)處理項(xiàng)目，負(fù)責(zé)和各個(gè)微服務(wù)打交道。比如之前是a調(diào)用b，b掉用c，c調(diào)用d，現(xiàn)在統(tǒng)一在一個(gè)核心項(xiàng)目W中來(lái)處理，W服務(wù)使用a的時(shí)候去調(diào)用b，使用b的時(shí)候W去調(diào)用c。

舉個(gè)例子：在第三方支付業(yè)務(wù)中，有一個(gè)核心支付項(xiàng)目是服務(wù)編排，負(fù)責(zé)處理支付的業(yè)務(wù)邏輯，W項(xiàng)目使用商戶(hù)信息的時(shí)候就去調(diào)用“商戶(hù)系統(tǒng)”，需要校驗(yàn)設(shè)備的時(shí)候就去調(diào)用“終端系統(tǒng)”，需要風(fēng)控的時(shí)候就調(diào)用“風(fēng)控系統(tǒng)”，各個(gè)項(xiàng)目需要的依賴(lài)參數(shù)都由W來(lái)做主控。以后項(xiàng)目部署的時(shí)候，只需要最后啟動(dòng)服務(wù)編排項(xiàng)目即可。

3、不要為了追求技術(shù)而追求技術(shù)，確定進(jìn)行微服務(wù)架構(gòu)改造之前，需要考慮以下幾方面的因素：

1）團(tuán)隊(duì)的技術(shù)人員是否已經(jīng)具備相關(guān)技術(shù)基礎(chǔ)。
2）公司業(yè)務(wù)是否適合進(jìn)行微服務(wù)化改造，并不是所有的平臺(tái)都適合進(jìn)行微服務(wù)化改造，比如：傳統(tǒng)行業(yè)有很多復(fù)雜垂直的業(yè)務(wù)系統(tǒng)。
3）Spring Cloud生態(tài)的技術(shù)有很多，并不是每一種技術(shù)方案都需要用上，適合自己的才是最好的。

總結(jié)

Spring Cloud對(duì)于中小型互聯(lián)網(wǎng)公司來(lái)說(shuō)是一種福音，因?yàn)檫@類(lèi)公司往往沒(méi)有實(shí)力或者沒(méi)有足夠的資金投入去開(kāi)發(fā)自己的分布式系統(tǒng)基礎(chǔ)設(shè)施，使用Spring Cloud一站式解決方案能在從容應(yīng)對(duì)業(yè)務(wù)發(fā)展的同時(shí)大大減少開(kāi)發(fā)成本。

同時(shí)，隨著近幾年微服務(wù)架構(gòu)和Docker容器概念的火爆，也會(huì)讓Spring Cloud在未來(lái)越來(lái)越“云”化的軟件開(kāi)發(fā)風(fēng)格中立有一席之地，尤其是在目前五花八門(mén)的分布式解決方案中提供了標(biāo)準(zhǔn)化的、全站式的技術(shù)方案，意義可能會(huì)堪比當(dāng)前Servlet規(guī)范的誕生，有效推進(jìn)服務(wù)端軟件系統(tǒng)技術(shù)水平的進(jìn)步。