我們為什麼需要微服務架構，它一定是為了解決我們某些問題才出現了。這篇文章我們討論下微服務架構模式所解決的問題，帶來的挑戰，以及他的核心思想本質。
1 早期的服務架構
上圖是一個典型的服務分層架構：
Client： 呼叫方是browser web或者App
應用層： 實現計算層的業務邏輯，從上游資料層獲取資料，對下游Client返回html/json/File等
資料-快取層： 提高訪問資料的效能
資料-資料庫層： 持久化資料層
2 它存在的問題
1. 重灌單體模式
如果是電商型別的系統，以上的架構明顯需要把 使用者登入、商品瀏覽、下單、結算、支付、訂單查詢都實現在一個系統裡面，實在笨重。
2. 流量和併發量限制
當系統的流量或併發量達到一定的閾值，比如日活躍使用者數量超過百萬，或者每秒請求數（QPS）達到數千甚至更高時，傳統的單體架構可能難以支撐如此高的負載。
3. 迭代頻率
如果業務需求變更非常頻繁，例如每週兩次以上甚至每天都有新的功能需要上線，那麼整個系統要全量釋出，不論你的模組是不是變更了。難頂喲！
4. 系統難以擴充套件
當系統需要快速擴充套件以滿足業務增長時，微服務架構可以更容易地實現水平擴充套件。
4. 耦合度和依賴關係
如果舊系統中的模組之間存在高度的耦合和複雜的依賴關係，這可能導致維護和升級變得困難。
5. 缺失故障隔離和容錯能力
如果系統中的某個模組出現故障，是否會影響到整個系統的正常執行？答案是肯定的
3 微服務架構的演進
上面的問題，明顯是日益膨脹的功能模組和流量規模對單體架構系統的挑戰，如果不最佳化，將衍生出一系列的問題。
我們可以透過微服務架構演進，對系統逐步的升級。以下是我們在業務實踐過程中總結的一些經驗，予以參考。
3.1 基於業務邏輯拆分
基於業務邏輯拆分相對好理解一點，典型的單一職責原則，我們將功能相近的業務整合到一個服務顆粒上。
業務領域模型拆分
舉一個典型的電商業務例子。電商的業務體系龐大，涉及各方面的細節。但是我們大概能夠根據業務的職能做一個拆分，比如阿里的電商中臺業務，包含 使用者賬號子系統、商品子系統、訂單子系統、客戶子系統、物流子系統 等。
因為職能不同，這些領域之間包含清晰的界限，所以我們可以按照這個方向將服務於不同領域（商品域和訂單域）的子系統拆成獨立的服務顆粒。如下圖：
使用者群體拆分
根據使用者群體做拆分，我們首先要了解自己的系統業務裡的使用者角色領域是否沒有功能耦合，有清晰的領域界限。
比如教育資訊化系統，教師的業務場景和學生的業務場景，基本比較獨立，而且拆分後流量上有明顯的削弱。如下圖所示：
3.2 基於可擴充套件拆分
這個需要區分系統中變與不變的部分，不變的部分一般是成熟的、通用的服務功能，變的部分一般是改動比較多、需要不斷滿足業務迭代擴充套件性需要的功能。
根據二八原則，系統中經常變動的部分大約只佔 20%（如 運營、活動），而剩下的 80% （使用者資訊、基本商品資訊、物流資訊 等模組的管理能力和檢視介面）基本不變或極少變化。如下圖所示：
3.3 基於可靠性拆分
核心模組拆分
我們團隊在做MySQL資料庫和Redis叢集拆分的時候，總會把一些重要的模組獨立放在一個叢集上，不與其他模組混用，而這個獨立的叢集，服務機效能要是最好的。這樣做的目的是，當重要度較低的模組發生故障時，不會影響重要度高的模組。同樣的道理，我們將賬號、支付等核心服務單獨拆分在一個服務顆粒上，建立獨立服務叢集，保證資源獨享，來提升可用性。 如下圖所示：
主次鏈路拆分
在各個業務系統中，其實都會有主次業務鏈路。主業務鏈條，完成了業務系統中最核心的那部分工作。而次鏈路是保證其他基礎功能的穩定執行。
以電商為例子：商品搜尋->商品詳情頁->購物車模組->訂單結算->支付業務，就是一條最簡單的主鏈路。主鏈路是整個系統的核心主戰場，最好的資源跟火力都要放在這裡，保證不失守。
這樣的拆分模式保障了核心鏈路的計算資源分配優先、異常容錯處理優先、服務隔離保護等等。
3.4 基於效能需求拆分
根據效能需求來進行拆分。簡單來說就是訪問量特別大，訪問頻率特別高的業務，又要保證高效的響應能力，這些業務對效能的要求特別高。比如積分競拍、低價秒殺、限量搶購。
我們要識別出某些超高併發量的業務，儘可能把這部分業務獨立拆分出來。
4 代價
分散式系統的固有複雜性
微服務架構是基於分散式的系統，而構建分散式系統必然會帶來額外的效能開銷和可靠性挑戰。
服務的依賴管理和測試
在單體應用中，通常使用整合測試來驗證依賴是否正常。而在微服務架構中，單元測試和整條服務鏈路的可用性都需要關注。
有效的配置版本管理
需要引入配置的版本管理、環境管理。
自動化的部署流程
有效地構建自動化部署體系，配合服務網格、容器技術，是微服務面臨的另一個挑戰。
對於DevOps有更高的要求
開發者也需承擔起整個服務的生命週期的責任，包括部署、鏈路追蹤、監控。構建全功能的團隊，也是一個不小的挑戰。
運維成本飆升
運維主要包括配置、部署、監控與告警和日誌收集四大方面。微服務架構中，每個微服務粒度都需要獨立地配置、部署、監控和收集日誌，成本呈指數級增長。服務化粒度越細，運維成本越高。
5 微服務架構思想本質
最終的微服務架構可能是這種狀態：
所以我們可以看出微服務架構的本質應該有如下幾個：
- 風險隔離： 高度自治和高度隔離，明顯不讓低等級的服務影響高等級
- 分治原理： 單個服務的吞吐始終是有限的，透過微服務拆分可以突破擴充套件上限，分拆流量可支撐全球化的業務，不再受機房規模甚至地域影響
- 單一職責： 單體系統逐漸演變成具有單一職責的細粒度微服務