當我們談微服務，我們在談什麼（1）— 瞭解微服務
摘要：
微服務是什麼
拋去教條性質的解釋，從巨石應用到微服務應用，耦合度是其中最大的變化。或是將多個模組中重複的部分進行拆分，或是純粹為了拆分膨脹的單體應用，這些拆分出來的部分獨立成一個服務單獨部署與維護，便是微服務了。
拆分後自然而然會催生出一些必要的需求：
從本...
微服務是什麼
拋去教條性質的解釋，從巨石應用到微服務應用，耦合度是其中最大的變化。或是將多個模組中重複的部分進行拆分，或是純粹為了拆分膨脹的單體應用，這些拆分出來的部分獨立成一個服務單獨部署與維護，便是微服務了。
拆分後自然而然會催生出一些必要的需求：
- 從本地方法呼叫的關係衍變成遠端過程呼叫的關係，那麼可靠的通訊功能是首要的。
- 隨著拆分工作的推進，資源排程關係會變得錯綜複雜，這時候需要完善的服務治理。
- 呼叫關係網的整體複雜化還會給我們帶來更大的風險，即鏈式反應導致服務雪崩的可能性，所以如何保障服務穩定性也是微服務架構中需要考慮的。
- 這點就不是內需而算是自我演進了，服務化後，如果能結合容器化、Devops技術實現服務運維一體化，將大大降低微服務維護的成本，不管是現在還是將來。
微服務是什麼樣的
從目前常見網站架構的巨集觀角度看，微服務處在中間的層次。紅框圈出的部分都屬於微服務的範疇。包括最基礎的rpc框架、註冊中心、配置中心，以及更廣義角度的監控追蹤、治理中心、排程中心等。
從微服務自身角度來看，則大致會包含以下這些模組:
- 服務註冊與發現
- rpc遠端呼叫
- 路由與負載均衡
- 服務監控
- 服務治理
服務化的前提
是不是隻要套上微服務框架就算是一個微服務了呢？雖然這樣有了微服務的表，但卻沒有微服務的實質，即”微“。微服務化的前提是服務拆分到足夠”微“，足夠單一職責，當然拆分程度與服務邊界都需要結合業務自行把握。
廣義的服務拆分即包含了應用拆分，也包含了資料拆分。
應用拆分後需要引入微服務框架來進行服務通訊與服務治理，這也就是傳統定義上的微服務。
資料拆分後同樣需要引入一系列手段來進行保障，由於不是與微服務強相關的話題，在此只做簡單闡述:
- 分散式id
- 新表優化
- 資料遷移與資料同步
- sql呼叫方案改造
- 切庫方案
- 資料一致性