微服務

概念

單體應用

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序列化等。

服務監控

一旦服務消費者與服務提供者之間能夠正常發起服務呼叫，你就需要對呼叫情況進行監控，以瞭解服務是否正常。

服務追蹤

你還需要記錄服務呼叫經過的每一層鏈路，以便進行問題追蹤和故障定位。

服務治理

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