微服務技術調研與實踐

1、精選優(yōu)質文檔-傾情為你奉上精選優(yōu)質文檔-傾情為你奉上專心-專注-專業(yè)專心-專注-專業(yè)精選優(yōu)質文檔-傾情為你奉上專心-專注-專業(yè)微服務技術調研與實踐微服務架構簡介微服務架構模式（Microservices Architecture Pattern）的目的是將大型的、復雜的、長期運行的應用程序構建為一組相互配合的服務，每個服務都可以很容易得局部改良。微服務（micro services）這個概念不是新概念，很多公司已經在實踐了，例如亞馬遜、Google、FaceBook，在國內我自己知道的有：BAT、滴滴、餓了么、攜程、唯品會、酷狗等公司。一個單體應用可能是下圖這樣的架構，各個功能在應用內部通過模

2、塊劃分，這樣的應用有它自己的好處如：調試簡單、部署方便等。但是它也有明顯的局限性，如：不同模塊發(fā)生資源沖突時無法解決（有些業(yè)務需要無阻塞的io操作，這明顯使用nodejs之類的語音是非常棒的，但是有些業(yè)務需要做算法密集型的操作，這明顯就是nodejs的短板，這時候單體應用就需要做一個妥協(xié)，而不能都取最優(yōu)解）。單體應用一般所有應用都運行在同一進程中，在某個模塊產生bug后會導致整個應用掛掉。其中最突出的是，隨著時間的遷移這個應用會越來越大，會大到任何單個開發(fā)者都不可能搞懂它。將上圖單體應用拆分為微服務的架構如下：從圖中可以看到每一個模塊功能都變成了一個單獨的服務，各服務之間通過各自暴露的API

3、接口相互調用，對外的接口通過一個API GATEWAY 來統(tǒng)一處理。這種架構看起來明顯是稍顯復雜，但是其擴展性卻是非常棒的，下圖很好的描述如何去構建和擴展一個微服務架構。X軸表示在物理層面做負載均衡、應用副本來提高吞吐能力。Y軸表示從功能方面拆分服務，來對應處理單一專注功能。Z軸表示如何通過優(yōu)化路由來整合相關服務（API GATEWAY）微服務架構的優(yōu)勢與不足優(yōu)點：每個服務足夠內聚，足夠小，代碼容易理解、開發(fā)效率提高服務之間可以獨立部署，微服務架構讓持續(xù)部署成為可能；每個服務可以各自進行x擴展和z擴展，而且，每個服務可以根據自己的需要部署到合適的硬件服務器上；容易擴大開發(fā)團隊，可以針對每個服務

4、（service）組件開發(fā)團隊；提高容錯性（fault isolation），一個服務的內存泄露并不會讓整個系統(tǒng)癱瘓；系統(tǒng)不會被長期限制在某個技術棧上。缺點開發(fā)人員要處理分布式系統(tǒng)的復雜性；開發(fā)人員要設計服務之間的通信機制，對于需要多個后端服務的user case，要在沒有分布式事務的情況下實現(xiàn)代碼非常困難；涉及多個服務直接的自動化測試也具備相當的挑戰(zhàn)性；服務管理的復雜性，在生產環(huán)境中要管理多個不同的服務實例，意味著開發(fā)團隊需要全局統(tǒng)籌（docker的出現(xiàn)適合解決這個問題）API Gateway如果已經使用微服務架構系統(tǒng)，客戶端調用各個服務的使用場景可能是這樣的：想象一下，各個服務部署在不同的

5、服務器上，那客戶端調用是否就需要記錄無數個baseurl，這還算好的。如果某一項功能需要同時調用多個服務來獲取一個組合數據，那是否就需要發(fā)起N個HTTP請求，這對于客戶端肯定噩夢。所以我們需要 API GATEWAY從圖中可以直接看出 API GATEWAY 的直接作用為請求轉發(fā)、合成等?？蛻舳说恼埱蠖夹枰涍^ API GATEWAY 先進行處理。這還只是 API GATEWAY 的基本功能，一個合格的 API GATEWAY還有許多功能需要處理：統(tǒng)一身份認證、權限配置惡意訪問限制日志統(tǒng)一管理服務器健康檢查緩存處理.添加 API GATEWAY 前后對比的用例圖：如果有對應的研發(fā)實力，如果不記

6、成本和實力考慮的話可以自己開發(fā)一套完整的 API GATEWAY，當然開源界也有一些造好的輪子可以使用：Kong基于Nginx 使用lua插件方式開發(fā)的 API GATEWAY ,上面介紹的功能基本上通過配置能夠完成。除了API組合，我詢問了開發(fā)組，他們的回答是：Kong致力于開發(fā)一套外部API route，只完成相關流程處理和公共組件，關于組合API建議各個項目創(chuàng)建一個內部API GATEWAY 來專門處理對應的服務組合，然后通過Kong來路由轉發(fā)。通信方式由于各個服務間是相互獨立的，如果服務之間需要相互訪問，那就不免要處理進程間的通信了。在微服務間進行通信業(yè)界推薦采用一下幾種方式：同步：R

7、PC、REST異步：AMQP、STOMPRPCRPC(Remote Procedure Call，遠程過程調用), RPC其實也是種C/S的編程模式，有點類似C/S Socket 編程模式，但要比它更高一層,通過RPC可以充分利用非共享內存的多處理器環(huán)境,應用程序就像運行在一個多處理器的計算機上一樣?？梢苑奖愕膶崿F(xiàn)過程代碼共享，提高系統(tǒng)資源的利用率，也可以將以大量數值處理的操作放在處理能力較強的系統(tǒng)上運行，從而減輕前端機的負擔。同樣，RPC是一套標準的模式，可按照既定的協(xié)議去自主實現(xiàn)，但是我還是建議采用先用輪子去做會省去很多成本，這里我推薦使用 Apache Thrift。Apache Thr

8、iftThrift 是 Facebook（后提交給Apache基金會將Thrift作為一個開源項目）實現(xiàn)的一種高效的、支持多種編程語言的遠程服務調用的框架。RESTREST就沒有什么好特別介紹的，調用過API的同學對此都應該不陌生，REST一個種數據資源獲取的設計原則。采用該原則設計的好處就是簡單、統(tǒng)一。微服務之間通過REST走HTTP實現(xiàn)相互調用。AMQP、STOMPAMQP是一個異步消息傳遞所使用的應用層協(xié)議規(guī)范。STOMP，Streaming Text Orientated Message Protocol，是流文本定向消息協(xié)議，是一種為MOM(Message Oriented Midd

9、leware，面向消息的中間件)設計的簡單文本協(xié)議。兩者都是適用于微服務架構的異步通訊。微服務架構中有大量開源的系統(tǒng)可以選擇：比如RabbitMQ、Apache Kafka、Apache ActiveMQ和NSQ。它們都支持某種形式的消息和channel，并且都是可靠的、高性能和可擴展的；然而，它們的消息模型完全不同。然而在微服務架構中為什么需要使用異步消息模式來處理一些請求呢？下圖是一個系統(tǒng)當熱銷補貨時就需要通知顧客的REST微服務實現(xiàn)。1.一個外部實體發(fā)送一個存貨清單更新請求到REST網關地址。2.網關將請求轉發(fā)給存貨清單管理服務。3.存貨清單管理服務基于它接收到的請求更新存貨清單，隨后發(fā)

10、送請求到熱銷補貨通知服務。4.接著，熱銷補貨通知服務發(fā)送請求到訂閱管理服務，要求當商品有庫存時所有注冊用戶都需要被通知。5.然后，訂閱管理服務發(fā)送郵件REST請求到郵件服務，通過郵件來通知所有用戶。6.最后，每個服務依次相應，循環(huán)回到網關并且到達客戶端。這種實現(xiàn)很容發(fā)現(xiàn)其中的一些缺陷：1.阻塞。通過REST來實現(xiàn)相互調用，必須在一個服務處理完成之后再去調用另外的服務，這么一層層傳遞之后客戶端需要等到所有服務響應完畢才會得到對應的結果。這種處理方式將會影響到所有調用的服務性能。2.耦合嚴重。比如：清單管理服務的單一職責就是更新系統(tǒng)存貨清單（存貨清單聚合根），它甚至都不需要知道通知服務的存在。在這

11、個模型中，這兩個服務是的耦合度太緊。3.服務失效。如果其中某一個服務失效會造成整個流程都無法完成。然而使用異步消息傳送流程會被重構成下圖所示：使用異步消息機制能很好的處理上面那些出現(xiàn)的問題，當然世界上所有的異步消息傳遞都不是完全美好的，還需要考慮一些缺陷：1.設計/實現(xiàn)/配置的困難，如消息排序，重復消息和消息冪等性。2.異步消息的本性，一個動作結果未立即返回同樣會增加系統(tǒng)和用戶接口的復雜性。3.信息流的可見性，系統(tǒng)內很難獲得一個完全清晰的消息流圖。這使調試變得更加困難，而且相對于管道方式，系統(tǒng)的業(yè)務邏輯更加難以管理。單體架構遷移至微服務策略1停止擴大首先停止單體應用繼續(xù)擴大，如果有新的業(yè)務需求，首先考慮將其開發(fā)為獨立服務，然后通過單體應用接入。策略2將前端和后端分離這里的前后端分離不是指的開發(fā)過程中僅僅在代碼層面去分離前后端開發(fā)，而是要求在架構方面分離