微服務(wù)基本定義及應(yīng)用

一個微服務(wù)一般完成某個特定的功能，比如下單管理、客戶管理等等。每一個微服務(wù)都是微型六角形應(yīng)用，都有自己的業(yè)務(wù)邏輯和適配器。一些微服務(wù)還會發(fā)布API給其它微服務(wù)和應(yīng)用客戶端使用。其它微服務(wù)完成一個WebUI，運(yùn)行時，每一個實(shí)例可能是一個云VM或者是Docker容器。每一個應(yīng)用功能區(qū)都使用微服務(wù)完成，另外，Web應(yīng)用會被拆分成一系列簡單的Web應(yīng)用（比如一個對乘客，一個對出租車駕駛員）。這樣的拆分對于不同用戶、設(shè)備和特殊應(yīng)用場景部署都更容易。

每一個后臺服務(wù)開放一個RESTAPI，許多服務(wù)本身也采用了其它服務(wù)提供的API。比如，駕駛員管理使用了告知駕駛員一個潛在需求的通知服務(wù)。UI服務(wù)激活其它服務(wù)來更新Web頁面。所有服務(wù)都是采用異步的，基于消息的通訊。微服務(wù)內(nèi)部機(jī)制將會在后續(xù)系列中討論。服務(wù)架構(gòu)模式有很多好處。首先，通過分解巨大單體式應(yīng)用為多個服務(wù)方法解決了復(fù)雜性問題。在功能不變的情況下，應(yīng)用被分解為多個可管理的分支或服務(wù)。每個服務(wù)都有一個用RPC-或者消息驅(qū)動API定義清楚的邊界。微服務(wù)架構(gòu)模式給采用單體式編碼方式很難實(shí)現(xiàn)的功能提供了模塊化的解決方案，由此，單個服務(wù)很容易開發(fā)、理解和維護(hù)。

第二，這種架構(gòu)使得每個服務(wù)都可以有專門開發(fā)團(tuán)隊(duì)來開發(fā)。開發(fā)者可以自由選擇開發(fā)技術(shù)，提供API服務(wù)。當(dāng)然，許多公司試圖避免混亂，只提供某些技術(shù)選擇。然后，這種自由意味著開發(fā)者不需要被迫使用某項(xiàng)目開始時采用的過時技術(shù)，他們可以選擇現(xiàn)在的技術(shù)。甚至于，因?yàn)榉?wù)都是相對簡單，即使用現(xiàn)在技術(shù)重寫以前代碼也不是很困難的事情。

第三，微服務(wù)架構(gòu)模式是每個微服務(wù)獨(dú)立的部署。開發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對本服務(wù)的影響。這種改變可以加快部署速度。UI團(tuán)隊(duì)可以采用AB測試，快速的部署變化。微服務(wù)架構(gòu)模式使得持續(xù)化部署成為可能。

最后，微服務(wù)架構(gòu)模式使得每個服務(wù)獨(dú)立擴(kuò)展。你可以根據(jù)每個服務(wù)的規(guī)模來部署滿足需求的規(guī)模。甚至于，你可以使用更適合于服務(wù)資源需求的硬件。比如，你可以在EC2ComputeOptimizedinstances上部署CPU敏感的服務(wù)，而在EC2memory-optimizedinstances上部署內(nèi)存數(shù)據(jù)庫。微服務(wù)架構(gòu)的不足FredBrooks在30年前寫道，“therearenosilverbullets”，像任何其它科技一樣，微服務(wù)架構(gòu)也有不足。其中一個跟他的名字類似，『微服務(wù)』強(qiáng)調(diào)了服務(wù)大小，實(shí)際上，有一些開發(fā)者鼓吹建立稍微大一些的，10-100LOC服務(wù)組。盡管小服務(wù)更樂于被采用，但是不要忘了這只是終端的選擇而不是最終的目的。微服務(wù)的目的是有效的拆分應(yīng)用，實(shí)現(xiàn)敏捷開發(fā)和部署。

另外一個主要的不足是，微服務(wù)應(yīng)用是分布式系統(tǒng)，由此會帶來固有的復(fù)雜性。開發(fā)者需要在RPC或者消息傳遞之間選擇并完成進(jìn)程間通訊機(jī)制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當(dāng)然這并不是什么難事，但相對于單體式應(yīng)用中通過語言層級的方法或者進(jìn)程調(diào)用，微服務(wù)下這種技術(shù)顯得更復(fù)雜一些。

另外一個關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)。商業(yè)交易中同時給多個業(yè)務(wù)分主體更新消息很普遍。這種交易對于單體式應(yīng)用來說很容易，因?yàn)橹挥幸粋€數(shù)據(jù)庫。在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫。使用分布式交易并不一定是好的選擇，不僅僅是因?yàn)镃AP理論，還因?yàn)榻裉旄邤U(kuò)展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發(fā)者提出了更高的要求和挑戰(zhàn)。

測試一個基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)。比如，采用流行的SpringBoot架構(gòu)，對一個單體式web應(yīng)用，測試它的RESTAPI，是很容易的事情。反過來，同樣的服務(wù)測試需要啟動和它有關(guān)的所有服務(wù)（至少需要這些服務(wù)的stubs）。再重申一次，不能低估了采用微服務(wù)架構(gòu)帶來的復(fù)雜性。

另外一個挑戰(zhàn)在于，微服務(wù)架構(gòu)模式應(yīng)用的改變將會波及多個服務(wù)。比如，假設(shè)你在完成一個案例，需要修改服務(wù)A、B、C，而A依賴B，B依賴C。在單體式應(yīng)用中，你只需要改變相關(guān)模塊，整合變化，部署就好了。對比之下，微服務(wù)架構(gòu)模式就需要考慮相關(guān)改變對不同服務(wù)的影響。比如，你需要更新服務(wù)C，然后是B，最后才是A，幸運(yùn)的是，許多改變一般只影響一個服務(wù)，而需要協(xié)調(diào)多服務(wù)的改變很少。

部署一個微服務(wù)應(yīng)用也很復(fù)雜，一個分布式應(yīng)用只需要簡單在復(fù)雜均衡器后面部署各自的服務(wù)器就好了。每個應(yīng)用實(shí)例是需要配置諸如數(shù)據(jù)庫和消息中間件等基礎(chǔ)服務(wù)。相對比，一個微服務(wù)應(yīng)用一般由大批服務(wù)構(gòu)成。例如，根據(jù)AdrianCockcroft，Hailo有160個不同服務(wù)構(gòu)成，NetFlix有大約600個服務(wù)。每個服務(wù)都有多個實(shí)例。這就造成許多需要配置、部署、擴(kuò)展和監(jiān)控的部分，除此之外，你還需要完成一個服務(wù)發(fā)現(xiàn)機(jī)制（后續(xù)文章中發(fā)表），以用來發(fā)現(xiàn)與它通訊服務(wù)的地址（包括服務(wù)器地址和端口）。傳統(tǒng)的解決問題辦法不能用于解決這么復(fù)雜的問題。接續(xù)而來，成功部署一個微服務(wù)應(yīng)用需要開發(fā)者有足夠的控制部署方法，并高度自動化。

一種自動化方法是使用PaaS服務(wù)，例如CloudFoundry。PaaS給開發(fā)者提供一個部署和管理微服務(wù)的簡單方法，它把所有這些問題都打包內(nèi)置解決了。同時，配置PaaS的系統(tǒng)和網(wǎng)絡(luò)專家可以采用最佳實(shí)踐和策略來簡化這些問題。另外一個自動部署微服務(wù)應(yīng)用的方法是開發(fā)對于你來說最基礎(chǔ)的PaaS系統(tǒng)。一個典型的開始點(diǎn)是使用一個集群化方案，比如配合Docker使用Mesos或者Kubernetes。后面的系列我們會看看如何基于軟件部署方法例如NGINX，可以方便的在微服務(wù)層面提供緩存、權(quán)限控制、API統(tǒng)計和監(jiān)控?？偨Y(jié)構(gòu)建復(fù)雜的應(yīng)用真的是非常困難。單體式的架構(gòu)更適合輕量級的簡單應(yīng)用。如果你用它來開發(fā)復(fù)雜應(yīng)用，那真的會很糟糕。微服務(wù)架構(gòu)模式可以用來構(gòu)建復(fù)雜應(yīng)用，當(dāng)然，這種架構(gòu)模型也有自己的缺點(diǎn)和挑戰(zhàn)。這種單體應(yīng)用比較適合于小項(xiàng)目，優(yōu)點(diǎn)是：開發(fā)簡單直接，集中式管理基本不會重復(fù)開發(fā)功能都在本地，沒有分布式的管理開銷和調(diào)用開銷

當(dāng)然它的缺點(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ù)需求每個業(yè)務(wù)邏輯都被分解為一個微服務(wù)，微服務(wù)之間通過RESTAPI通信。一些微服務(wù)也會向終端用戶或客戶端開發(fā)API接口。但通常情況下，這些客戶端并不能直接訪問后臺微服務(wù)，而是通過APIGateway來傳遞請求。APIGateway一般負(fù)責(zé)服務(wù)路由、負(fù)載均衡、緩存、訪問控制和鑒權(quán)等任務(wù)。微服務(wù)架構(gòu)有很多重要的優(yōu)點(diǎn)。首先，它解決了復(fù)雜性問題。它將單體應(yīng)用分解為一組服務(wù)。雖然功能總量不變，但應(yīng)用程序已被分解為可管理的模塊或服務(wù)。這些服務(wù)定義了明確的RPC或消息驅(qū)動的API邊界。微服務(wù)架構(gòu)強(qiáng)化了應(yīng)用模塊化的水平，而這通過單體代碼庫很難實(shí)現(xiàn)。因此，微服務(wù)開發(fā)的速度要快很多，更容易理解和維護(hù)。

其次，這種體系結(jié)構(gòu)使得每個服務(wù)都可以由專注于此服務(wù)的團(tuán)隊(duì)獨(dú)立開發(fā)。只要符合服務(wù)API契約，開發(fā)人員可以自由選擇開發(fā)技術(shù)。這就意味著開發(fā)人員可以采用新技術(shù)編寫或重構(gòu)服務(wù)，由于服務(wù)相對較小，所以這并不會對整體應(yīng)用造成太大影響。

第三，微服務(wù)架構(gòu)可以使每個微服務(wù)獨(dú)立部