第12章 Spring Boot與微服務(wù)

隨著RESTful web服務(wù)和JSON數(shù)據(jù)交換格式流行音婶，簡單快速建立一個可連接的服務(wù)已經(jīng)越來越方便了葱绒。隨著持續(xù)交付概念推廣以及Docker容器普及异希，微服務(wù)將這兩種理念和技術(shù)結(jié)合起來，形成新的微服務(wù)+API + 平臺的開發(fā)模式口注，以及容器化微服務(wù)的持續(xù)交付概念肤京。

微服務(wù)(micro services)這個概念不是新概念篙贸，很多公司已經(jīng)在實(shí)踐了，例如亞馬遜枫疆、Google爵川、FaceBook，Alibaba息楔。微服務(wù)架構(gòu)模式(Microservices Architecture Pattern)的目的是將大型的寝贡、復(fù)雜的、長期運(yùn)行的應(yīng)用程序構(gòu)建為一組相互配合的服務(wù)值依，每個服務(wù)可以獨(dú)立迭代開發(fā)運(yùn)維圃泡。

Micro這個詞意味著每個服務(wù)都應(yīng)該足夠小，但是愿险，這里的小不能用代碼量來比較颇蜡，而應(yīng)該是從業(yè)務(wù)邏輯上比較——符合“單一職責(zé)模式”（SRP）原則的才叫微服務(wù)。

分布式的辆亏、去中心化的风秤。Smart endpoints and dumb pipes, 本質(zhì)就是去ESB，把所有的“思考”邏輯包括路由扮叨、消息解析等放在服務(wù)內(nèi)部（Smart endpoints）缤弦，去掉一個大一統(tǒng)的ESB，服務(wù)間輕（dumb pipes）通信彻磁，是比SOA更徹底的拆分碍沐。

要搞微服務(wù)架構(gòu)，先要搞定RPC框架衷蜓。

12.1 微服務(wù)架構(gòu)

先來看看傳統(tǒng)的web開發(fā)方式累提，通過對比比較容易理解什么是Microservice Architecture。和Microservice相對應(yīng)的恍箭，這種方式一般被稱為Monolithic（比較難傳神的翻譯）刻恭。所有的功能打包在一個 WAR包里，基本沒有外部依賴（除了容器），部署在一個JEE容器（Tomcat鳍贾，JBoss鞍匾，WebLogic）里，包含了 DO/DAO骑科，Service橡淑，UI等所有邏輯。

Monolithic比較適合小項(xiàng)目咆爽，優(yōu)點(diǎn)是：

• 開發(fā)簡單直接梁棠，集中式管理

• 基本不會重復(fù)開發(fā)

• 功能都在本地，沒有分布式的管理開銷和調(diào)用開銷

它的缺點(diǎn)也非常明顯斗埂，特別對于互聯(lián)網(wǎng)公司來說：

• 開發(fā)效率低：所有的開發(fā)在一個項(xiàng)目改代碼符糊，遞交代碼相互等待，代碼沖突不斷

• 代碼維護(hù)難：代碼功能耦合在一起呛凶，新人不知道何從下手

• 部署不靈活：構(gòu)建時間長男娄，任何小修改必須重新構(gòu)建整個項(xiàng)目，這個過程往往很長

• 穩(wěn)定性不高：一個微不足道的小問題漾稀，可以導(dǎo)致整個應(yīng)用掛掉

• 擴(kuò)展性不夠：無法滿足高并發(fā)情況下的業(yè)務(wù)需求

于是誕生了基于微服務(wù)的架構(gòu)模闲。簡單來說， 微服務(wù)的目的是有效的拆分應(yīng)用崭捍，實(shí)現(xiàn)敏捷開發(fā)和部署 尸折。

SOA簡述

早在1996年，Gartner就提出面向服務(wù)架構(gòu)（SOA）殷蛇。SOA闡述了“對于復(fù)雜的企業(yè)IT系統(tǒng)实夹，應(yīng)按照不同的、可重用的粒度劃分粒梦，將功能相關(guān)的一組功能提供者組織在一起為消費(fèi)者提供服務(wù)”收擦，其目的是為了解決企業(yè)內(nèi)部不同IT資源之間無法互聯(lián)而導(dǎo)致的信息孤島問題。

2002年谍倦，SOA被稱作"現(xiàn)代應(yīng)用開發(fā)領(lǐng)域最重要的課題之一"塞赂，其正在幫助企業(yè)從資源利用的角度出發(fā)，將IT資源整合成可操作的昼蛀、基于標(biāo)準(zhǔn)的服務(wù)宴猾，使其能被重新組合和應(yīng)用。

但是叼旋，由于SOA本身的廣義性以及抽象性仇哆，在其誕生的相當(dāng)長一段時間內(nèi)，人們對SOA存在著不同的認(rèn)知和理解夫植。

到2000年左右讹剔，ESB(Enterprise Service Bus)油讯、WebService、SOAP等這類技術(shù)的出現(xiàn)延欠，才使得SOA漸漸落地陌兑。同時，更多的廠商像IBM由捎、Oracle等也分別提出基于SOA的解決方案或者產(chǎn)品兔综。

實(shí)際上，微服務(wù)架構(gòu)并不是一個全新的概念狞玛。仔細(xì)分析SOA的概念软驰，就會發(fā)現(xiàn)，其和我們今天所談到的微服務(wù)思想幾乎一致心肪。那在SOA誕生這么多年后锭亏，為什么又提出了微服務(wù)架構(gòu)呢？

鑒于過去十幾年互聯(lián)網(wǎng)行業(yè)的高速發(fā)展硬鞍，以及敏捷贰镣、持續(xù)集成、持續(xù)交付膳凝、DevOps，云技術(shù)等的深入人心恭陡，服務(wù)架構(gòu)的開發(fā)蹬音、測試、部署以及監(jiān)控等休玩，相比我們提到的傳統(tǒng)的SOA實(shí)現(xiàn)著淆，已經(jīng)大相徑庭，主要區(qū)別如下表所示：

相比傳統(tǒng)SOA的服務(wù)實(shí)現(xiàn)方式，微服務(wù)更具有靈活性罚随、可實(shí)施性以及可擴(kuò)展性玉工，其強(qiáng)調(diào)的是一種獨(dú)立測試、獨(dú)立部署淘菩、獨(dú)立運(yùn)行的軟件架構(gòu)模式遵班。

微服務(wù)是什么？

在CPU處理器的指令集中，有CISC與RISC狭郑。
在操作系統(tǒng)中腹暖，有宏內(nèi)核與微內(nèi)核。

微服務(wù)愿阐，本質(zhì)是一個系統(tǒng)架構(gòu)解耦的過程微服。它是把一個大型復(fù)雜系統(tǒng)服務(wù)M（Monolithic Architecture，整體式架構(gòu)）拆分成多個相對簡單獨(dú)立的子系統(tǒng)的服務(wù)MS（Microservice Architecture, 微服務(wù)架構(gòu)）ms1, ms2, ms3, ... 缨历。

系統(tǒng)中的各個微服務(wù)可被獨(dú)立部署以蕴，各個微服務(wù)之間松耦合。之前整體的系統(tǒng)服務(wù)M辛孵，在MS中通過微服務(wù)提供的API交互完成丛肮。API之間的通信由RPC框架來完成。

這個思想理念魄缚，跟UNIX哲學(xué)理念——

小是美的宝与。（Small is Beautiful）

是相通的。

另外冶匹，不同的微服務(wù)MS可以使用不同的技術(shù)架構(gòu)习劫，比如Node.js ，Java嚼隘， Ruby诽里， Python等等，這些單個的服務(wù)都可以獨(dú)立完成交付生命周期飞蛹。

我們最早使用傳統(tǒng)的整體式架構(gòu)應(yīng)用開發(fā)系統(tǒng)谤狡，如CRM、ERP等大型應(yīng)用卧檐，可能會遇到以下的一些問題：

1.隨著新需求的不斷增加墓懂，更新和迭代大型的整體式應(yīng)用會變得越來越困難；

2.隨著移動互聯(lián)網(wǎng)的快速發(fā)展霉囚，要求我們能夠?qū)崿F(xiàn)功能的快速迭代上線捕仔；

3.但對于快速變化的需求，受到整體式應(yīng)用架構(gòu)的限制盈罐，有時候顯得力不從心逻澳；

此外，大量開源輕量級技術(shù)不斷涌現(xiàn)并日漸成熟：

• 輕量級運(yùn)行時技術(shù)的出現(xiàn)(node.js, WAS Liberty等)暖呕；
• 新的思想方法論與工具(Agile, DevOps, TDD, CI, XP, Puppet, Chef…)斜做；
• 新的輕量級協(xié)議(RESTful API接口, 輕量級消息機(jī)制)；
• 簡化的基礎(chǔ)設(shè)施：操作系統(tǒng)虛擬化, 容器化(e.g. Docker), 基礎(chǔ)設(shè)施即服務(wù) (IaaS), 工作負(fù)載虛擬化(Kubernetes,Spark…)等湾揽；
• 服務(wù)平臺化(PaaS)： 云服務(wù)平臺上具有自動縮放瓤逼、工作負(fù)載管理笼吟、SLA 管理、消息機(jī)制霸旗、緩存贷帮、構(gòu)建管理等各種按需使用的服務(wù)；
• 新的可替代數(shù)據(jù)持久化模型：如NoSQL, MapReduce, BASE, CQRS等诱告；
• 標(biāo)準(zhǔn)化代碼管理撵枢，如：Gitlab等。

這一切都催生了新的架構(gòu)設(shè)計風(fēng)格 – 微服務(wù)架構(gòu)的出現(xiàn)精居。

在整體式架構(gòu)應(yīng)用中锄禽，我們將所有功能都打成一個包，可以是JAR靴姿、WAR沃但、EAR或其它歸檔格式，然后佛吓，直接運(yùn)行它宵晚，或者丟到一個容器（例如Tomcat）里跑。

整體式架構(gòu)應(yīng)用的一些不足：

不夠靈活：對應(yīng)用程序做任何細(xì)微的修改都需要將整個應(yīng)用程序重新構(gòu)建维雇、重新部署淤刃。開發(fā)人員需要等到整個應(yīng)用程序部署完成后才能看到變化。如果多個開發(fā)人員共同開發(fā)一個應(yīng)用程序吱型，那么還要等待其他開發(fā)人員完成了各自的開發(fā)逸贾。這降低了團(tuán)隊的靈活性和功能交付頻率；

妨礙持續(xù)交付：單體應(yīng)用可能會比較大唁影，構(gòu)建和部署時間也相應(yīng)地比較長，不利于頻繁部署掂名，阻礙持續(xù)交付据沈。在移動應(yīng)用開發(fā)中，這個問題會顯得尤為嚴(yán)重饺蔑；

受技術(shù)棧限制：對于這類應(yīng)用锌介，技術(shù)是在開發(fā)之前經(jīng)過慎重評估后選定的，每個團(tuán)隊成員都必須使用相同的開發(fā)語言猾警、持久化存儲及消息系統(tǒng)孔祸，而且要使用類似的工具，無法根據(jù)具體的場景做出其它選擇发皿；

技術(shù)債務(wù)：“不壞不修（Not broken崔慧，don’t fix）”，這在軟件開發(fā)中非常常見穴墅，單體應(yīng)用尤其如此惶室。系統(tǒng)設(shè)計或?qū)懞玫拇a難以修改温自，因?yàn)閼?yīng)用程序的其它部分可能會以意料之外的方式使用它。隨著時間推移皇钞、人員更迭悼泌，這必然會增加應(yīng)用程序的技術(shù)債務(wù)。

而隨著業(yè)務(wù)需求的快速發(fā)展變化夹界，敏捷性馆里、靈活性和可擴(kuò)展性需求不斷增長，迫切需要一種更加快速高效的軟件交付方式可柿。于是鸠踪，微服務(wù)架構(gòu)應(yīng)運(yùn)而生。
（當(dāng)然趾痘，如果你沒有遇到諸如上面的問題慢哈，你可能也就用不到微服務(wù)的架構(gòu)了。）

這里的“微”不是針對代碼行數(shù)而言永票，而是說服務(wù)的范圍限定到單個功能卵贱。

微服務(wù)特點(diǎn)

康威定律：任何設(shè)計系統(tǒng)的組織，最終產(chǎn)生的設(shè)計等同于組織之內(nèi)侣集、之間的溝通結(jié)構(gòu)键俱。系統(tǒng)架構(gòu)的設(shè)計符合組織溝通結(jié)構(gòu)取得的收益最大。

微服務(wù)有如下特點(diǎn)：

• 小, 且專注于做?件事情
• 進(jìn)程獨(dú)立
• 輕量級的通信機(jī)制
• 松耦合
• 獨(dú)立部署

領(lǐng)域驅(qū)動設(shè)計：應(yīng)用程序功能分解可以通過Eric Evans在《領(lǐng)域驅(qū)動設(shè)計》中明確定義的規(guī)則實(shí)現(xiàn)世分；每個團(tuán)隊負(fù)責(zé)與一個領(lǐng)域或業(yè)務(wù)功能相關(guān)的全部開發(fā)编振；團(tuán)隊擁有全系列的開發(fā)人員，具備用戶界面臭埋、業(yè)務(wù)邏輯和持久化存儲等方面的開發(fā)技能踪央；

單一職責(zé)原則：每個服務(wù)應(yīng)該負(fù)責(zé)該功能的一個單獨(dú)的部分，這是SOLID原則之一瓢阴；

明確發(fā)布接口：每個服務(wù)都會發(fā)布一個定義明確的接口畅蹂，而且保持不變；服務(wù)消費(fèi)者只關(guān)心接口荣恐，而對于被消費(fèi)的服務(wù)沒有任何運(yùn)行依賴液斜；

獨(dú)立部署、升級叠穆、擴(kuò)展和替換：每個服務(wù)都可以單獨(dú)部署及重新部署而不影響整個系統(tǒng)少漆。這使得服務(wù)很容易升級，每個服務(wù)都可以沿著《Art of Scalability》一書定義的X軸和Z軸進(jìn)行擴(kuò)展硼被；

可以異構(gòu)/采用多種語言：每個服務(wù)的實(shí)現(xiàn)細(xì)節(jié)都與其它服務(wù)無關(guān)示损，這使得服務(wù)之間能夠解耦，團(tuán)隊可以針對每個服務(wù)選擇最合適的開發(fā)語言嚷硫、持久化存儲屎媳、工具和方法夺溢；

輕量級通信：服務(wù)通信使用輕量級的通信協(xié)議，例如烛谊，同步的REST风响，異步的AMQP、STOMP丹禀、MQTT等状勤。

微服務(wù)架構(gòu)的思想本質(zhì)跟互聯(lián)網(wǎng)的思想是一致的。它的組件對外發(fā)布的服務(wù)視同HTTP協(xié)議双泪，采用HTTP Rest API的方式來進(jìn)行持搜。很多開放平臺的API服務(wù)，基本都采用了Http API的方式進(jìn)行服務(wù)的發(fā)布和管理焙矛。

Fictitious e-commerce application

Let’s imagine that you are building an e-commerce application that takes orders from customers, verifies inventory and available credit, and ships them. The application consists of several components including the StoreFrontUI, which implements the user interface, along with some backend services for checking credit, maintaining inventory and shipping orders. The application consists of a set of services.

基于微服務(wù)的架構(gòu), 目的是有效的拆分應(yīng)用葫盼，實(shí)現(xiàn)敏捷開發(fā)和部署 。

服務(wù)之間如何通信村斟？

因?yàn)樗械奈⒎?wù)都是獨(dú)立的Java進(jìn)程跑在獨(dú)立的虛擬機(jī)上贫导，所以服務(wù)間的通行就是IPC（inter process communication），最通用的有兩種方式：

同步調(diào)用

• REST（JAX-RS蟆盹，Spring Boot）

• RPC（Thrift, Dubbo）

異步消息調(diào)用

Kafka孩灯， Notify， MetaQ

微服務(wù)優(yōu)點(diǎn)

相應(yīng)地逾滥，微服務(wù)具有如下優(yōu)點(diǎn)：

• 迭代開發(fā)靈活峰档，快速適應(yīng)需求變化（前提是，得架構(gòu)良好才行）寨昙；
• 局部修改很容易部署讥巡，有利于持續(xù)集成和持續(xù)交付；
• 故障隔離舔哪，一個服務(wù)出現(xiàn)問題不會影響整個應(yīng)用欢顷；
• 技術(shù)棧自由。

隨著持續(xù)交付概念推廣以及Docker容器普及尸红，微服務(wù)將這兩種理念和技術(shù)結(jié)合起來吱涉，形成新的微服務(wù)+API + 平臺的開發(fā)模式刹泄，提出了容器化微服務(wù)的持續(xù)交付概念外里。

傳統(tǒng)Monolithic的DevOps開發(fā)隊伍方式盅蝗，如下圖：

這種整體型架構(gòu)要求產(chǎn)品隊伍橫跨產(chǎn)品管理 Dev開發(fā) QA DBA 以及系統(tǒng)運(yùn)營管理芙委，而微服務(wù)架構(gòu)引入以后，如下圖：

微服務(wù)促進(jìn)了DevOps方式的重組，將一個大臃腫的整體產(chǎn)品開發(fā)隊伍切分為根據(jù)不同微服務(wù)的劃分的產(chǎn)品隊伍痊乾，以及一個大的整體的平臺隊伍負(fù)責(zé)運(yùn)營管理，兩者之間通過API交互湿滓，做到了松耦合隔絕茉稠。
　　由于Docker引入而线，不同的微服務(wù)可以使用不同的技術(shù)架構(gòu)恋日，比如Node.js Java Ruby Python等等岂膳，這些單個的服務(wù)都可以獨(dú)立完成交付生命周期筷屡，如下：

微服務(wù)缺點(diǎn)

微服務(wù)看上去像一枚銀彈，可以解決許多軟件開發(fā)方面的問題扼倘。這看上去很美好爪喘，但并不易于實(shí)現(xiàn)。微服務(wù)會極大地增加運(yùn)維工作量秃症，使用微服務(wù)种柑，一些技術(shù)債務(wù)勢必從開發(fā)轉(zhuǎn)到運(yùn)維，因此聚请，你最好有一個一流的開發(fā)運(yùn)維團(tuán)隊稳其。

總體來看驶赏，微服務(wù)架構(gòu)可能帶來過多的操作既鞠。缺點(diǎn)如下：

• 分布式系統(tǒng)可能復(fù)雜難以管理煤傍。
• 分布式部署跟蹤解決問題難。
• 當(dāng)服務(wù)數(shù)量增加蚯姆，管理復(fù)雜性增加洒敏。
• 系統(tǒng)部署依賴（DevOps）
• 服務(wù)間通信成本（RPC框架）
• 數(shù)據(jù)一致性
• 系統(tǒng)集成測試
• 系統(tǒng)監(jiān)控等郭毕。

當(dāng)然显押，這是一個循序漸進(jìn)的重構(gòu)的過程。

因此踊谋，微服務(wù)對基礎(chǔ)設(shè)施提出了一些額外的需求蝉仇。通常旋讹，我們將它們總稱為NoOps殖蚕，本質(zhì)上講轿衔，就是一組服務(wù)，提供一個更好的應(yīng)用程序部署流程并確保其運(yùn)行睦疫，包括服務(wù)復(fù)制害驹、服務(wù)發(fā)現(xiàn)、服務(wù)恢復(fù)和服務(wù)監(jiān)控等蛤育。

服務(wù)化的一個好處就是宛官，不限定服務(wù)的提供方使用什么技術(shù)選型，能夠?qū)崿F(xiàn)大公司跨團(tuán)隊的技術(shù)解耦瓦糕，如下圖：

六種微服務(wù)架構(gòu)

簡單介紹六種微服務(wù)架構(gòu)模式[7]槽华。

聚合器微服務(wù)設(shè)計模式

這是一種最常用也最簡單的設(shè)計模式，如下圖所示：

微服務(wù)架構(gòu)的設(shè)計模式

代理微服務(wù)設(shè)計模式

這是聚合器模式的一個變種璧函，如下圖所示：

微服務(wù)架構(gòu)的設(shè)計模式

在這種情況下，客戶端并不聚合數(shù)據(jù)基显，但會根據(jù)業(yè)務(wù)需求的差別調(diào)用不同的微服務(wù)蘸吓。代理可以僅僅委派請求，也可以進(jìn)行數(shù)據(jù)轉(zhuǎn)換工作撩幽。

鏈?zhǔn)轿⒎?wù)設(shè)計模式

這種模式在接收到請求后會產(chǎn)生一個經(jīng)過合并的響應(yīng)美澳，如下圖所示：

微服務(wù)架構(gòu)的設(shè)計模式

在這種情況下，服務(wù)A接收到請求后會與服務(wù)B進(jìn)行通信摸航，類似地制跟，服務(wù)B會同服務(wù)C進(jìn)行通信。所有服務(wù)都使用同步消息傳遞酱虎。在整個鏈?zhǔn)秸{(diào)用完成之前雨膨，客戶端會一直阻塞。因此读串，服務(wù)調(diào)用鏈不宜過長聊记，以免客戶端長時間等待。

分支微服務(wù)設(shè)計模式

這種模式是聚合器模式的擴(kuò)展恢暖，允許同時調(diào)用兩個微服務(wù)鏈排监，如下圖所示：

微服務(wù)架構(gòu)的設(shè)計模式

數(shù)據(jù)共享微服務(wù)設(shè)計模式

自治是微服務(wù)的設(shè)計原則之一，就是說微服務(wù)是全棧式服務(wù)杰捂。但在重構(gòu)現(xiàn)有的“單體應(yīng)用（monolithic application）”時舆床，SQL數(shù)據(jù)庫反規(guī)范化可能會導(dǎo)致數(shù)據(jù)重復(fù)和不一致。因此嫁佳，在單體應(yīng)用到微服務(wù)架構(gòu)的過渡階段挨队，可以使用這種設(shè)計模式，如下圖所示：

微服務(wù)架構(gòu)的設(shè)計模式

在這種情況下蒿往，部分微服務(wù)可能會共享緩存和數(shù)據(jù)庫存儲盛垦。不過，這只有在兩個服務(wù)之間存在強(qiáng)耦合關(guān)系時才可以瓤漏。對于基于微服務(wù)的新建應(yīng)用程序而言腾夯，這是一種反模式颊埃。

異步消息傳遞微服務(wù)設(shè)計模式

雖然REST設(shè)計模式非常流行，但它是同步的蝶俱，會造成阻塞班利。因此部分基于微服務(wù)的架構(gòu)可能會選擇使用消息隊列代替REST請求/響應(yīng)，如下圖所示：

微服務(wù)架構(gòu)的設(shè)計模式

12.2 Spring Cloud構(gòu)建微服務(wù)架構(gòu)

參考資料：
1.https://eacdy.gitbooks.io/spring-cloud-book/content/
2.https://springcloud.cc/
3.https://springcloud.cc/spring-cloud-netflix-zhcn.html
4.http://projects.spring.io/spring-cloud/
5.http://www.infoworld.com/article/2878659/application-development/reducing-technical-debt-with-microservices.html
6.http://blog.csdn.net/stubborn_cow/article/details/50287597
7.http://www.javacodegeeks.com/2015/04/microservices-monoliths-and-noops.html
8.http://www.infoq.com/cn/articles/analysis-the-architecture-of-microservice-part-02
9.https://www.oschina.net/news/70121/microservice