微服務那些高大上的概念

微服務

概念

單體應用

LAMP（Linux + Apache + MySQL + PHP）和 MVC（Spring + iBatis/Hibernate + Tomcat。不管是 LAMP 仍是 MVC，都是爲單體應用架構設計的，其優勢是學習成本低，開發上手快，測試、部署、運維也比較方便，甚至一我的就能夠完成一個網站的開發與部署。

微服務

把模塊從單體應用中拆分出來，獨立成一個服務部署，以 RPC 接口的形式對外提供服務。每一個微服務都嚴格遵循獨立打包部署的準則，互不影響。好比一臺物理機上能夠部署多個 Docker 實例，每一個 Docker 實例能夠部署一個微服務的代碼。每一個微服務均可以交由一個小團隊甚至我的來開發、測試、發佈和運維，並對整個生命週期負責。

服務化拆分的兩種姿式

• 縱向拆分：從業務維度進行拆分。標準是按照業務的關聯程度來決定，關聯比較密切的業務適合拆分爲一個微服務，而功能相對比較獨立的業務適合單獨拆分爲一個微服務。
• 橫向拆分：從公共且獨立功能維度拆分。標準是按照是否有公共的被多個其餘服務調用，且依賴的資源獨立不與其餘業務耦合。

服務化拆分的前置條件

• 服務如何定義。對於單體應用來講，不一樣功能模塊以前相互交互時，一般是以類庫的方式來提供各個模塊的功能。對於微服務來講，每一個服務都運行在各自的進程之中，應該以何種形式向外界傳達本身的信息呢？答案就是接口，不管採用哪一種通信協議，是HTTP仍是RPC，服務之間的調用都經過接口描述來約定，約定內容包括接口名、接口參數以及接口返回值。

• 服務如何發佈和訂閱。單體應用因爲部署在同一個WAR包裏，接口之間的調用屬於進程內的調用。而拆分爲微服務獨立部署後，服務提供者該如何對外暴露本身的地址，服務調用者該如何查詢所須要調用的服務的地址呢？這個時候你就須要一個相似登記處的地方，可以記錄每一個服務提供者的地址以供服務調用者查詢，在微服務架構裏，這個地方就是註冊中心。

• 服務如何監控。一般對於一個服務，咱們最關心的是QPS（調用量）、AvgTime（平均耗時）以及P999（99.9%的請求性能在多少毫秒之內）這些指標。這時候你就須要一種通用的監控方案，可以覆蓋業務埋點、數據收集、數據處理，最後到數據展現的全鏈路功能。

• 服務如何治理。能夠想象，拆分爲微服務架構後，服務的數量變多了，依賴關係也變複雜了。好比一個服務的性能有問題時，依賴的服務都勢必會受到影響。能夠設定一個調用性能閾值，若是一段時間內一直超過這個值，那麼依賴服務的調用能夠直接返回，這就是熔斷，也是服務治理最經常使用的手段之一。

• 故障如何定位。在單體應用拆分爲微服務以後，一次用戶調用可能依賴多個服務，每一個服務又部署在不一樣的節點上，若是用戶調用出現問題，你須要有一種解決方案可以將一次用戶請求進行標記，並在多個依賴的服務系統中繼續傳遞，以便串聯全部路徑，從而進行故障定位。

微服務組件

服務描述

服務調用首先要解決的問題就是服務如何對外描述。好比，你對外提供了一個服務，那麼這個服務的服務名叫什麼？調用這個服務須要提供哪些信息？調用這個服務返回的結果是什麼格式的？該如何解析？這些就是服務描述要解決的問題。簡單來講就是接口文檔。

經常使用的服務描述方式包括RESTful API、XML配置以及IDL文件三種。

註冊中心

你提供了一個服務，如何讓外部想調用你的服務的人知道。這個時候就須要一個相似註冊中心的角色，服務提供者將本身提供的服務以及地址登記到註冊中心，服務消費者則從註冊中心查詢所須要調用的服務的地址，而後發起請求。

服務框架

服務通訊採用什麼協議？就是說服務提供者和服務消費者之間以什麼樣的協議進行網絡通訊，是採用四層TCP、UDP協議，仍是採用七層HTTP協議，仍是採用其餘協議？

數據傳輸採用什麼方式？就是說服務提供者和服務消費者之間的數據傳輸採用哪一種方式，是同步仍是異步，是在單鏈接上傳輸，仍是多路複用。

數據壓縮採用什麼格式？一般數據傳輸都會對數據進行壓縮，來減小網絡傳輸的數據量，從而減小帶寬消耗和網絡傳輸時間，好比常見的JSON序列化、Java對象序列化以及Protobuf序列化等。

服務監控

一旦服務消費者與服務提供者之間可以正常發起服務調用，你就須要對調用狀況進行監控，以瞭解服務是否正常。

服務追蹤

你還須要記錄服務調用通過的每一層鏈路，以便進行問題追蹤和故障定位。

服務治理

服務監控可以發現問題，服務追蹤可以定位問題所在，而解決問題就得靠服務治理了。服務治理就是經過一系列的手段來保證在各類意外狀況下，服務調用仍然可以正常進行。好比自動擴縮容，就能夠用來解決服務的容量問題。