素小暖講微服務

欲速則不達，欲達則欲速！

1、前言

微服務架構被提出很短的時間內，就被愈來愈多的開發人員推崇，簡單來講其主要的目的是有效的拆分應用，實現敏捷開發和部署。本博客嘗試介紹微服務架構的一些實施細節和要求，探詢微服務架構的由來，並最終提供咱們團隊內部的有一些實踐總結，但願對你們有幫助。

2、什麼是微服務

傳統的web開發方式，經過對比比較容易理解什麼是Microservice Architecture。和Microservice相對應的，這種方式通常被稱爲Monolithic（比較難傳神的翻譯）。全部的功能打包在一個 WAR包裏，基本沒有外部依賴（除了容器），部署在一個JEE容器（Tomcat，JBoss，WebLogic）裏，包含了 DO/DAO，Service，UI等全部邏輯。

用《The art of scalability》一書裏提到的scale cube比較容易理解如何拆分。 咱們叫分庫分表，爲人總結成了scale cube，這就是抽象的能力，把複雜的東西用最簡單的概念解釋和總結。X軸表明運行多個負載均衡器以後運行的實例，Y軸表明應用進一步分解爲微服務（分庫），數據量大時，還能夠用Z軸將服務按數據分區分表。

Monolithic比較適合小項目，優勢是：

• 開發簡單直接，集中式管理

• 基本不會重複開發

• 功能都在本地，沒有分佈式的管理開銷和調用開銷

它的缺點也很是明顯，特別對於互聯網公司來講（不一一列舉了）：

• 開發效率低：全部的開發在一個項目改代碼，遞交代碼相互等待，代碼衝突不斷

• 代碼維護難：代碼功能耦合在一塊兒，新人不知道何從下手

• 部署不靈活：構建時間長，任何小修改必須從新構建整個項目，這個過程每每很長

• 穩定性不高：一個微不足道的小問題，能夠致使整個應用掛掉

• 擴展性不夠：沒法知足高併發狀況下的業務需求

  因此，如今主流的設計通常會採用Microservice Architecture，就是基於微服務的架構。簡單來講，微服務的目的是有效的拆分應用，實現敏捷開發和部署。

3、微服務的具體特徵

一、一些列的獨立的服務共同組成系統

二、單獨部署，跑到本身的進程裏

三、每一個服務爲獨立的業務開發

四、分佈式的管理

Martin本身也說了，每一個人對微服務均可以有本身的理解，不過大概的標準仍是有一些的。

• 分佈式服務組成的系統

• 按照業務而不是技術來劃分組織

• 作有生命的產品而不是項目

• Smart endpoints and dumb pipes（個人理解是強服務個體和弱通訊）

• 自動化運維（DevOps）

• 容錯

• 快速演化

4、SOA vs Microservice

我我的理解microservice是SOA的傳承，但最本質的區別在於 Smart endpoints and dumb pipes， 或者是是真正的分佈式的、去中心化的。 Smart endpoints and dumb pipes本質就是去ESB，把全部的思考邏輯包括路由、消息解析等放到服務內部 （Smart endpoints） ，去掉一個大一統的ESB，服務間輕（dumb pipes）通訊，是比SOA更完全的拆分。

5、怎麼具體實踐微服務

一、客戶端如何訪問這些服務？

原來的 Monolithic 方式開發，全部的服務都是本地的，UI能夠直接調用，如今按功能拆分紅獨立的服務，跑在獨立的通常都在獨立的虛擬機上的java進程了。客戶端UI如何訪問他的？後臺有N個服務，前臺就須要記住管理N個服務，一個服務下線/更新/升級，前臺就要從新部署，這明顯不符合咱們拆分的理念，特別當前臺是移動應用的時候，一般業務變化的節奏更快。另外，N個小服務的調用也是一個不小的網絡開銷，還有通常微服務在系統內部，一般是無狀態的，用戶登陸信息和權限管理最好有一個統一的地方維護管理。

因此，通常在後臺N個服務和UI之間通常會一個代理或者叫API Gateway，他的做用包括 ：

• 提供統一服務入口，讓微服務對前臺透明
• 聚合後臺的服務，節省流量，提高性能
• 提供安全，過濾，流控等API管理功能

個人理解其實這個API Gateway能夠有不少廣義的實現辦法，能夠是一個軟硬一體的盒子，也能夠是一個簡單的MVC框架，甚至是一個Node.js的服務端。他們最重要的做 用是爲前臺（一般是移動應用）提供後臺服務的聚合，提供一個統一的服務出口，解除他們之間的耦合，不過API Gateway也有可能成爲單點故障點或者性能的瓶頸。

通常用過Taobao Open Platform的就能很容易的體會，TAO就是這個API Gateway。

 

二、服務之間如何通訊？

由於全部的微服務都是獨立的Java進程跑在獨立的虛擬機上，因此服務間的通訊就是IPC（inter process communication），已經有不少成熟的方案。如今基本最通用的有兩種方式。這幾種方式，展開來說均可以寫本書，並且你們通常都比較熟悉細節了， 就不展開講了。

• 同步調用

  • REST（JAX-RS，Spring Boot）

  • RPC（Thrift, Dubbo）

• 異步消息調用(Kafka, Notify, MetaQ)

通常同步調用比較簡單，一致性強，可是容易出調用問題，性能體驗上也會差些，特別是調用層次多的時候。RESTful和RPC的比較也是一個頗有意思的話題。通常REST基於HTTP，更容易實現，更容易被接受，服務端實現技術也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要求，只要封裝了HTTP的SDK就能調用，因此相對使用的廣一些。RPC也有本身的優勢，傳輸協議更高效，安全更可控，特別在一個公司內部，若是有統一的開發櫃面和統一的服務框架時，他的開發效率優點更明顯些。

而異步消息的方式在分佈式系統中有特別普遍的應用，他既能下降調用服務之間的耦合，又能成爲調用之間的緩衝，確保消息積壓不會沖垮被調用方，同時能保證調用方的服務體驗，繼續幹本身該乾的活，不至於被後臺性能拖慢。不過須要付出的代價是一致性的減弱，須要接受數據最終一致性；還有就是後臺服務通常要實現冪等性，由於消息發送出於性能的考慮通常會有重複 （保證消息的被收到且僅收到一次對性能是很大的考驗）； 最後就是必須引入一個獨立的broker，若是公司內部沒有技術積累，對broker分佈式管理也是一個很大的挑戰。

三、這麼多服務，怎麼找?

在微服務架構中，通常每個服務都是有多個拷貝，來作負載均衡。一個服務隨時可能下線，也可能應對臨時訪問壓力增長新的服務節點。服務之間如何相互感知？服務如何管理？這就是服務發現的問題了。通常有兩類作法，也各有優缺點。基本都是經過zookeeper等相似技術作服務註冊信息的分佈式管理、當服務上線時，服務提供者將本身的服務信息註冊到ZK，並經過心跳維持長連接，實時更新連接信息。服務調用者經過ZK尋址，根據可定製算法，找到一個服務，還能夠將服務信息緩存在本地以提升性能。當服務下線時，ZK會通知給服務客戶端。

• 客戶端作：優勢是架構簡單，擴展靈活，只對服務註冊器依賴。缺點是客戶端要維護全部調用服務的地址，有技術難度，通常大公司都有成熟的內部框架支持，好比Dubbo。

• 服務端作：優勢是簡單，全部服務對於前臺調用方透明，通常在小公司在雲服務上部署的應用採用的比較多。

四、服務掛了怎麼辦？

前面提到，Monolithic方式開發一個很大的風險是，把全部雞蛋放在一個籃子裏，一榮俱榮，一損俱損。而分佈式最大的特性就是網絡是不可靠 的。經過微服務拆分能下降這個風險，不過若是沒有特別的保障，結局確定是噩夢。咱們剛遇到一個線上故障就是一個很不起眼的SQL計數功能，在訪問量上升 時，致使數據庫load彪高，影響了所在應用的性能，從而影響全部調用這個應用服務的前臺應用。

因此當咱們的系統是由一系列的服務調用鏈組成的時候，咱們 必須確保任一環節出問題都不至於影響總體鏈路。相應的手段有不少：

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

6、微服務的優缺點

優勢：

• 開發簡單
• 技術棧靈活
• 服務獨立無依賴
• 獨立按需擴展
• 可用性高

缺點：

• 多服務運維難度
• 系統部署依賴
• 服務間通訊成本
• 數據一致性
• 系統集成測試
• 重複工做
• 性能監控

對於打的互聯網公司，微服務架構是血液，是習慣，沒家公司都有本身的套路和架構，細節有不一樣，可是核心理念是通的。

對於通常的公司而言，實踐微服務有很是大的技術挑戰，因而乎纔有了這麼多IT供應商考慮這裏的商機。微服務比較適合將來有必定的擴展複雜度，且有 很大用戶增量預期的應用，說人話就是新興的互聯網公司。創業初期，不可能買大量的機器或者很貴的機器，可是又必須考慮應對成功後的巨量的用戶，微服務架構 成了最好的選擇。