微服務(wù)（micro services）這個(gè)概念不是新概念，很多公司已經(jīng)在實(shí)踐了，例如亞馬遜、Google、FaceBook，Alibaba。微服務(wù)架構(gòu)模式 （Microservices Architecture Pattern）的目的是將大型的、復(fù)雜的、長期運(yùn)行的應(yīng)用程序構(gòu)建為一組相互配合的服務(wù)，每個(gè)服務(wù)都可以很容易得局部改良。 Micro這個(gè)詞意味著每個(gè)服務(wù)都應(yīng)該足夠小，但是，這里的小不能用代碼量來比較，而應(yīng)該是從業(yè)務(wù)邏輯上比較——符合SRP原則的才叫微服務(wù)。

成都創(chuàng)新互聯(lián)公司專注于翔安企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,商城開發(fā)。翔安網(wǎng)站建設(shè)公司,為翔安等地區(qū)提供建站服務(wù)。全流程按需定制設(shè)計(jì)，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，成都創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)

暫且不討論大小問題，讀者朋友你首先要考慮的是如何解決目前技術(shù)團(tuán)隊(duì)遇到的開發(fā)問題、部署問題。正是在解決這些問題的過程中，才漸漸總結(jié)提煉出了微服務(wù)架構(gòu)模式的概念。

微服務(wù)跟SOA有什么區(qū)別呢，可以把微服務(wù)當(dāng)做去除了ESB的SOA。ESB是SOA架構(gòu)中的中心總線，設(shè)計(jì)圖形應(yīng)該是星形的，而微服務(wù)是去中心化的分布式軟件架構(gòu)。

接下來會討論以下幾個(gè)話題：

• 應(yīng)用微服務(wù)的動機(jī)，跟傳統(tǒng)巨石應(yīng)用的比較
• 微服務(wù)的優(yōu)點(diǎn)與缺點(diǎn)
• 應(yīng)用微服務(wù)架構(gòu)設(shè)計(jì)時(shí)可能遇到的關(guān)鍵問題（內(nèi)部服務(wù)通信、分布式數(shù)據(jù)管理）

一、巨石（monolith）

web應(yīng)用程序發(fā)展的早期，大部分web工程是將所有的功能模塊（service side）打包到一起并放在一個(gè)web容器中運(yùn)行，很多企業(yè)的Java應(yīng)用程序打包為war包。其他語言（Ruby，Python或者C++）寫的程序也有類似的問題。

假設(shè)你正在構(gòu)建一個(gè)在線商店系統(tǒng)：客戶下訂單、核對清單和信用卡額度，并將貨物運(yùn)輸給客戶。很快，你們團(tuán)隊(duì)一定能構(gòu)造出如下圖所示的系統(tǒng)。

這種將所有功能都部署在一個(gè)web容器中運(yùn)行的系統(tǒng)就叫做巨石型應(yīng)用。巨石型應(yīng)用有很多好處：IDE都是為開發(fā)單個(gè)應(yīng)用設(shè)計(jì)的、容易測試——在本地就可以啟動完整的系統(tǒng)、容易部署——直接打包為一個(gè)完整的包，拷貝到web容器的某個(gè)目錄下即可運(yùn)行。

但是，上述的好處是有條件的：應(yīng)用不那么復(fù)雜。對于大規(guī)模的復(fù)雜應(yīng)用，巨石型應(yīng)用會顯得特別笨重：要修改一個(gè)地方就要將整個(gè)應(yīng)用全部部署（PS：在不同的場景下優(yōu)勢也變成了劣勢）；編譯時(shí)間過長；回歸測試周期過長；開發(fā)效率降低等。另外，巨石應(yīng)用不利于更新技術(shù)框架，除非你愿意將系統(tǒng)全部重寫（代價(jià)太高你愿意老板也不愿意）。

二、應(yīng)用拆分

詳細(xì)一個(gè)網(wǎng)站在業(yè)務(wù)大規(guī)模爬升時(shí)會發(fā)生什么事情？并發(fā)度不夠？OK，加web服務(wù)器。數(shù)據(jù)庫壓力過大？OK，買更大更貴的數(shù)據(jù)庫。數(shù)據(jù)庫太貴了？將 一個(gè)表的數(shù)據(jù)分開存儲，俗稱“分庫分表”。這些都沒有問題，good job。不過，老外的抽象能力比我們強(qiáng)，看下圖Fig2。

這張圖從三個(gè)維度概括了一個(gè)系統(tǒng)的擴(kuò)展過程：

• ①. x軸，水平復(fù)制，即在負(fù)載均衡服務(wù)器后增加多個(gè)web服務(wù)器；
• ②. z軸擴(kuò) 展，是對數(shù)據(jù)庫的擴(kuò)展，即分庫分表（分庫是將關(guān)系緊密的表放在一臺數(shù)據(jù)庫服務(wù)器上，分表是因?yàn)橐粡埍淼臄?shù)據(jù)太多，需要將一張表的數(shù)據(jù)通過hash放在不同 的數(shù)據(jù)庫服務(wù)器上）；
• ③. y軸擴(kuò)展，是功能分解，將不同職能的模塊分成不同的服務(wù)。從y軸這個(gè)方向擴(kuò)展，才能將巨型應(yīng)用分解為一組不同的服務(wù)，例如訂單 管理中心、客戶信息管理中心、商品管理中心等等。

將系統(tǒng)劃分為不同的服務(wù)有很多方法：

• ①. 按照用例劃分，例如在線商店系統(tǒng)中會劃分出一個(gè)checkout UI服務(wù)，這個(gè)服務(wù)實(shí)現(xiàn)了checkout這個(gè)用例；
• ②. 按照資源劃分，例如可以劃分出一個(gè)catlog服務(wù)來存儲產(chǎn)品目錄。

服務(wù)劃分有兩個(gè)原則要遵循：

• ①. 每個(gè)服務(wù)應(yīng)該盡可能符合單一職責(zé)原則——Single Responsible Principle，即每個(gè)服務(wù)只做一件事，并把這件事做好；
• ②. 參考Unix命令行工具的設(shè)計(jì)，Unix提供了大量的簡單易用的工具，例如grep、cat和find。每個(gè)工具都小而美。

最后還要強(qiáng)調(diào)：系統(tǒng)分解的目標(biāo)并不僅僅是搞出一堆很小的服務(wù)，這不是目標(biāo)；真正的目標(biāo)是解決巨石型應(yīng)用在業(yè)務(wù)急劇增長時(shí)遇到的問題。

對于上面的例子，按照功能和資源劃分后，就形成下面圖3的架構(gòu)圖。分解后的微服務(wù)架構(gòu)包含多個(gè)前端服務(wù)和后端服務(wù)。前端服務(wù)包括Catalog UI（用于商品搜索和瀏覽）、Checkout UI（用于實(shí)現(xiàn)購物車和下單操作）；后端服務(wù)包括一些業(yè)務(wù)邏輯模塊，我們將在巨石應(yīng)用中的每個(gè)服務(wù)模塊重構(gòu)為一個(gè)單獨(dú)的服務(wù)。這么做有什么問題呢？

三、微服務(wù)架構(gòu)的優(yōu)點(diǎn)與缺點(diǎn)

1. 優(yōu)點(diǎn)

• 每個(gè)服務(wù)足夠內(nèi)聚，足夠小，代碼容易理解、開發(fā)效率提高；
• 服務(wù)之間可以獨(dú)立部署，微服務(wù)架構(gòu)讓持續(xù)部署成為可能；
• 每個(gè)服務(wù)可以各自進(jìn)行x擴(kuò)展和z擴(kuò)展，而且，每個(gè)服務(wù)可以根據(jù)自己的需要部署到合適的硬件服務(wù)器上；
• 容易擴(kuò)大開發(fā)團(tuán)隊(duì)，可以針對每個(gè)服務(wù)（service）組件開發(fā)團(tuán)隊(duì)；
• 提高容錯(cuò)性（fault isolation），一個(gè)服務(wù)的內(nèi)存泄露并不會讓整個(gè)系統(tǒng)癱瘓；
• 系統(tǒng)不會被長期限制在某個(gè)技術(shù)棧上。

2. 缺點(diǎn)

《人月神話》中講到：沒有銀彈，意思是只靠一把錘子是蓋不起摩天大樓的，要根據(jù)業(yè)務(wù)場景選擇設(shè)計(jì)思路和實(shí)現(xiàn)工具。我們看下為了換回上面提到的好處，我們付出（trade）了什么？

• 開發(fā)人員要處理分布式系統(tǒng)的復(fù)雜性；開發(fā)人員要設(shè)計(jì)服務(wù)之間的通信機(jī)制，對于需要多個(gè)后端服務(wù)的user case，要在沒有分布式事務(wù)的情況下實(shí)現(xiàn)代碼非常困難；涉及多個(gè)服務(wù)直接的自動化測試也具備相當(dāng)?shù)奶魬?zhàn)性；
• 服務(wù)管理的復(fù)雜性，在生產(chǎn)環(huán)境中要管理多個(gè)不同的服務(wù)的實(shí)例，這意味著開發(fā)團(tuán)隊(duì)需要全局統(tǒng)籌（PS：現(xiàn)在docker的出現(xiàn)適合解決這個(gè)問題）
• 應(yīng)用微服務(wù)架構(gòu)的時(shí)機(jī)如何把握？對于業(yè)務(wù)還沒有理清楚、業(yè)務(wù)數(shù)據(jù)和處理能力還沒有開始爆發(fā)式增長之前的創(chuàng)業(yè)公司，不需要考慮微服務(wù)架構(gòu)模式，這時(shí)候最重要的是快速開發(fā)、快速部署、快速試錯(cuò)。

四、微服務(wù)架構(gòu)的關(guān)鍵問題

1. 微服務(wù)架構(gòu)的通信機(jī)制

（1）客戶端與服務(wù)器之間的通信

在巨石型架構(gòu)下，客戶端應(yīng)用程序（web或者app）通過向服務(wù)端發(fā)送HTTP請求；但是，在微服務(wù)架構(gòu)下，原來的巨石型服務(wù)器被一組微服務(wù)替代，這種情況下客戶端如何發(fā)起請求呢？

如圖4中所示，客戶端可以向micro service發(fā)起RESTful HTTP請求，但是會有這種情況發(fā)生：客戶端為了完成一個(gè)業(yè)務(wù)邏輯，需要發(fā)起多個(gè)HTTP請求，從而造成系統(tǒng)的吞吐率下降，再加上無線網(wǎng)絡(luò)的延遲高，會嚴(yán)重影響客戶端的用戶體驗(yàn)。

為了解決這個(gè)問題，一般會在服務(wù)器集群前面再加一個(gè)角色：API gateway，由它負(fù)責(zé)與客戶度對接，并將客戶端的請求轉(zhuǎn)化成對內(nèi)部服務(wù)的一系列調(diào)用。這樣做還有個(gè)好處是，服務(wù)升級不會影響到客戶端，只需要修改 API gateway即可。加了API gateway之后的系統(tǒng)架構(gòu)圖如圖5所示。

（2）內(nèi)部服務(wù)之間的通信

內(nèi)部服務(wù)之間的通信方式有兩種：基于HTTP協(xié)議的同步機(jī)制（REST、RPC）；基于消息隊(duì)列的異步消息處理機(jī)制（AMQP-based message broker）。

Dubbo是阿里巴巴開源的分布式服務(wù)框架，屬于同步調(diào)用，當(dāng)一個(gè)系統(tǒng)的服務(wù)太多時(shí)，需要一個(gè)注冊中心來處理服務(wù)發(fā)現(xiàn)問 題，例如使用ZooKeeper這類配置服務(wù)器進(jìn)行服務(wù)的地址管理：服務(wù)的發(fā)布者要向ZooKeeper發(fā)送請求，將自己的服務(wù)地址和函數(shù)名稱等信息記錄在案；服務(wù)的調(diào)用者要知道服務(wù)的相關(guān)信息，具體的機(jī)器地址在ZooKeeper查詢得到。這種同步的調(diào)用機(jī)制足夠直觀簡單，只是沒有“訂閱——推送”機(jī) 制。

AMQP-based的代表系統(tǒng)是kafka、RabbitMQ等。這類分布式消息處理系統(tǒng)將訂閱者和消費(fèi)者解耦合，消息的生產(chǎn)者不需要消費(fèi)者一直在線；消息的生產(chǎn)者只需要把消息發(fā)送給消息代理，因此也不需要服務(wù)發(fā)現(xiàn)機(jī)制。

兩種通信機(jī)制都有各自的優(yōu)點(diǎn)和缺點(diǎn)，實(shí)際中的系統(tǒng)經(jīng)常包含兩種通信機(jī)制。例如，在分布式數(shù)據(jù)管理中，就需要同時(shí)用到同步HTTP機(jī)制和異步消息處理機(jī)制。

2. 分布式數(shù)據(jù)管理

（1）處理讀請求

在線商店的客戶賬戶有限額，當(dāng)客戶試圖下單時(shí)，系統(tǒng)必須判斷總的訂單金額是否超過他的信用卡額度。信用卡額度由CustomerService管 理、下訂單的操作由OrderService負(fù)責(zé)，因此Order Service要通過RPC調(diào)用向Customer Service請求數(shù)據(jù)；這種方法能夠保證每次Order Service都獲取到準(zhǔn)確的額度，單缺點(diǎn)是多一次RPC調(diào)用、而且Customer Service必須保持在線。

還有一種處理方式是，在OrderService這邊存放一份信用卡額度的副本，這樣就不需要實(shí)時(shí)發(fā)起RPC請求，但是還需要一種機(jī)制保證——當(dāng)Customer Service擁有的信用卡額度發(fā)生變化時(shí)，要及時(shí)更新存放在Order Service這邊的副本。

（2）處理更新請求

當(dāng)一份數(shù)據(jù)位于多個(gè)服務(wù)上時(shí)，必須保證數(shù)據(jù)的一致性。

• 分布式事務(wù)（Distributed transactions）
  使用分布式事務(wù)非常直觀，即要更新Customer Service上的信用卡額度，就必須同時(shí)更新其他服務(wù)上的副本，這些操作要么全做要么全不做。使用分布式事務(wù)能夠保證數(shù)據(jù)的強(qiáng)一致，但是會降低系統(tǒng)的可 用性——所有相關(guān)的服務(wù)必須始終在線；而且，很多現(xiàn)代的技術(shù)棧并不支持事務(wù)，例如REST、NoSQL數(shù)據(jù)庫等。

• 基于事件的異步更新（Event-driven asynchronous updates）
  Customer Service中的信用卡額度改變時(shí)，它對外發(fā)布一個(gè)事件到“message broker（消息代理人）”；其他訂閱了這個(gè)事件的服務(wù)受到提示后就更新數(shù)據(jù)。事件流如圖6所示。

五、重構(gòu)巨石型應(yīng)用

在實(shí)際工作中，很少有機(jī)會參與一個(gè)全新的項(xiàng)目，需要處理的差不多都是存在這樣那樣問題的復(fù)雜、大型應(yīng)用。這時(shí)候如何在維護(hù)老服務(wù)的同時(shí)，將系統(tǒng)漸漸重構(gòu)為微服務(wù)架構(gòu)呢？

不要讓事情更壞，有新的需求過來時(shí)，如果可以獨(dú)立開發(fā)為一個(gè)服務(wù)，就單獨(dú)開發(fā)，然后為老服務(wù)和新服務(wù)直接編寫膠水代碼（Glue Code）——這個(gè)過程不容易，但這是分解巨型服務(wù)的第一步，如圖7所示；

識別巨石型應(yīng)用中的可以分離出來當(dāng)做單獨(dú)服務(wù)的模塊，一般適合分離的模塊具有如下特點(diǎn)：兩個(gè)模塊對資源的需求是沖突的（一個(gè)是CPU密集型、一個(gè) 是IO密集型）；授權(quán)鑒定層也適合單獨(dú)分離出一個(gè)服務(wù)。每分離出一個(gè)服務(wù)，就需要編寫對應(yīng)的膠水代碼來與剩下的服務(wù)通信，這樣，在逐漸演進(jìn)過程中，就完成 了整個(gè)系統(tǒng)的架構(gòu)更新。

關(guān)于重構(gòu)，有篇文章推薦大家閱讀——推倒重來的講究，關(guān)于重構(gòu)有很多可以寫的，希望我能快速進(jìn)步，多寫點(diǎn)總結(jié)與大家分享。

總結(jié)

微服務(wù)并不是治百病的良藥，也不是什么新的技術(shù)，我從中學(xué)到的大的一點(diǎn)就是scale cube，從這個(gè)坐標(biāo)軸出發(fā)去考慮大規(guī)模系統(tǒng)的構(gòu)建比較容易分析和實(shí)踐。

【愛碼仕i】：專注于Java開發(fā)技術(shù)的研究與知識分享！

————END————

• 點(diǎn)贊
• ...
• 轉(zhuǎn)發(fā)
• ...
• 關(guān)注
• ...

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

名稱欄目：Java程序員必知——基于微服務(wù)的軟件架構(gòu)模式-創(chuàng)新互聯(lián)
文章來源：http://chinadenli.net/article24/dhesce.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、搜索引擎優(yōu)化、網(wǎng)頁設(shè)計(jì)公司、虛擬主機(jī)、關(guān)鍵詞優(yōu)化、微信公眾號

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)