一篇文章看懂微服務

 

微服務的概念

傳統單體大項目的缺點：

• 系統較大、較複雜，開發難度大
• 部署速度慢
• 難以升級、維護

 

 

微服務：

• 小：微服務是體積較小的功能單元，將一個大項目拆分爲多個微服務
• 獨：服務都是獨立的，運行在單獨的JVM進程中，須要單獨部署、維護，服務可使用不一樣的編程語言來寫，可使用不一樣的數據庫
• 輕：服務之間的通訊機制是輕量級的
• 鬆：服務之間是鬆耦合的

 

 

微服務的優勢：

• 易於開發、維護，擴展性好
• 啓動快，修改局部無需從新部署整個項目
• 技術棧不受限制

 

 

微服務的缺點：

• 要部署、維護多個服務，運維要求高
• 單體應用使不使用分佈式都行，微服務通常都要使用分佈式，對開發人員的技術要求較高
• 調整接口成本高，須要同時修改調用它的其它微服務
• 代碼重複多。單體應用把要重複調用代碼封裝爲工具類，項目中直接調用便可；每一個微服務都是獨立的，不能調用其它微服務中的類，須要把要用的類copy到要本服務中。

 

 

---

 

 

 

微服務的拆分與設計

若是項目拆分過粗，那和單體應用差很少；若是拆分過細，則服務太多，管理難度大，服務調用開銷大。

拆分的大原則：一個模塊不依賴、或極少依賴其它模塊，但須要給多個模塊、客戶端提供數據（通常2個或2個以上）。

 

 

微服務的設計原則：

• 單一職責：每一個服務只管本模塊的業務，不處理其餘模塊的業務。
• 服務自治：每一個服務都是單獨的，單獨進行開發、測試、部署。
• 輕量級通訊：服務之間的通訊要是輕量級的、跨平臺、跨語言，這樣可讓服務的開發不收技術種類限制。
• 接口明確：服務之間每每要相互調用，設計服務之間的接口時，要將接口設計得通用些、考慮全面些，後續維護、升級時不輕易修改接口。

 

 

---

 

 

經常使用的微服務框架

• Spring Cloud
• Dubbo    阿里巴巴的開源框架

 

 

springboot、springcloud的區別

• springboot是對spring的封裝，提供了不少開箱即用的微服務功能（業餘），有默認配置，簡單修改下就可使用
• springcloud是一個專業的微服務框架，須要本身寫不少代碼

springboot、springcloud能夠聯合部署。

 

 

---

 

 

前臺如何訪問、調用微服務？

好比查詢訂單信息，要訪問訂單的微服務，有時候須要訪問多個微服務。

微服務部署在不一樣的服務器上，通常是無狀態的，不保存用戶的狀態信息（好比是否已登陸），須要找一個地方來保存用戶的狀態信息、檢查用戶權限。

 

通常要經過API Gateway來訪問微服務。

API Gateway，其實就是一個代理，代理全部微服務，請求交給API Gateway，由API Gateway調用相應的微服務來處理。

API Gateway提供統一的接口，供前臺調用，並保護用戶狀態、檢查用戶權限。

 

API Gateway只是一個稱謂，有多種實現：能夠是MVC框架，能夠是node.js服務器，也能夠是其它的。

 

 

---

 

 

服務之間如何通訊（相互調用）？

服務之間有2種通訊方式：

（1）同步調用

簡單、一致性強，但容易出現調用問題、體驗差，特別是調用層次多的時候（服務A調用服務B，服務B又要調用其它服務，相似於遞歸）。

 

同步調用有2種常見的實現技術：

• REST。基於HTTP，簡單靈活，跨語言、跨客戶端（只要SDK封裝HTTP就能夠調用），應用普遍。springboot使用的就是REST。
• RPC。傳輸更高效，更安全可控，但須要有統一開發規範、統一的服務器框架才能展示這些優勢。Dubbo使用的就是RPC。

要應用普遍、兼容多種狀況，須要提供大量代碼處理各類狀況，移植性卻是上去了，性能就通常般（REST）；

對環境有要求，針對特定狀況，移植性差一些，但性能槓槓的（RPC）。

 

 

（2）異步消息

在分佈式系統中用得較多，Kafka就是一種異步消息技術。能下降服務之間的耦合，能夠保證被調用者的性能。

同步消息：媽耶，一大堆服務調用我，我得加緊幹，加大功率——強度大了可能直接拉閘，被搞垮；

異步消息：就像食堂的打飯大媽，無論排多長的隊，依然不緊不慢地打飯，學生（其它服務的調用）都得排着隊等着——想搞垮我，不存在的。

 

付出的代價：數據一致性差。

你卻是不緊不慢幹着，人家都等着你，等了老半天，這期間數據可能被其它服務修改了、不一致了。

因此每每要寫數據一致模塊來保證數據的一致性。

 

 

---

 

 

服務發現

一般要把一個服務拷貝一下，部署到多個服務器上，實現服務的分佈式。

運行過程當中，一些服務器可能會下線，負載大的時候也會增長節點（服務器），節點會變化，要發給哪一個節點來處理？

找到、發現某個節點，使用這個節點來處理請求，因此叫作服務發現，經常使用的技術是zookeeper。

 

使用zookeeper來作服務的分佈式管理：

服務提供者（各服務節點）把信息（本機地址、所提供的的服務）註冊到zookeeper上，並實時更新信息。zookeeper根據這些註冊信息、調用特定算法來計算，肯定要調用哪一個節點來處理請求，即發現一個服務。

 

那把zookeeper放到客戶端、仍是放到服務器端？

• 放到服務器端：簡單，服務信息對前臺透明，小公司用得多。
• 放到客戶端：架構簡單、擴展靈活，只依賴服務註冊器，但客戶端要維護全部服務的地址，技術難度大，須要微服務框架的支持（好比Dubbo），大公司用得多。

 

 

---

 

 

訪問量上升的處理

訪問量上升，對某一服務的調用增長，若是不加處理，節點負載太大，會影響全部調用此服務的前臺。

 

經常使用的處理方式：

• 重試機制
• 限流
• 熔斷機制
• 負載均衡
• 降級（本地緩存）