一、大而集中式的服務
從 0 到 1 的堆砌式發展
一個服務承載所有，一個系統涵蓋一切，這可能是大多數公司初創時的技術風貌。一切追求快速驗證，快速響應，快速實現。
但是，伴隨着業務的膨脹發展，相應的技術支撐要求也在不斷提升。從最開始的一個簡單的服務，不斷地添枝加葉，各種各樣的功能模塊相繼被堆砌式添加上去。慢慢的服務開始變得臃腫，繁雜。功能模塊間相互交織，耦合，混亂不堪。
- 同一個服務模塊可能會在多個地方被不同方式的使用；
- 一個數據可能被存多張表中，並且數據經常不一致；
- 修改一個功能卻不小心影響了其它功能；
- 一個小小的變動卻要重新上線整個服務，造成大量功能抖動；
- 想要集成某些新特性，卻因爲現有繁雜的無關依賴衝突所擾；
- 每個新來的人員都要都要花費大量時間去熟悉，梳理整個系統的面貌；
- 面對新的業務需求支撐，往往捉襟見肘。
- ... ... 等等
二、微服務化需要做哪些事情？
1、明確界限
最直接的問題就是，你要把整個集中式的大服務拆成哪幾個服務？
這並不是一個容易的問題，它不僅僅是技術方面的問題，更多的要考慮到業務的界限。
比如，對於一個社區，可以基本的劃分爲用戶、內容兩塊兒。
用戶模塊可以繼續分爲用戶基礎、訪問、設置、權限等。
內容則可以繼續細分爲內容、審覈、推薦、搜索等。
業務大了，每一塊兒都會成爲一個體量服務應用。
2、依賴定序
在明確了服務界限之後，就要進一步明確當前服務的脈絡結構、流程鏈條、依賴關係等。
- 哪些是上游服務？
- 哪些是支持性的服務？
- 哪些是最核心服務？
- 哪些是最基礎的服務？
- 哪些是業務性不強，單純地功能性依賴服務？
- 哪些是對外依賴最小的服務？
- 哪些是非核心卻耗資源的服務？
- ... ... 等等。
好了，知道了這些，我們就可以確定一個服務拆分的先後順序。當然，順序沒有固定原則，每個公司可以根據當下的實際情況去調整。
一般來說，最基礎的服務是依賴最多的，也是相對核心的，這個會作爲第一順序去拆解出來。比如，對於用戶模塊的用戶信息服務，內容模塊的內容服務等。後續的拆解的服務也可以此爲基礎，避免再去依賴舊服務。
另外，對於業務關聯不強的服務，如短信，推送、圖片等，也可以同步進行。尤其是對於圖片、推送這些存在相對集中式耗費網絡資源的，應該優先分離。
三、服務架構
架構需要考慮什麼？
用什麼？什麼能支撐？能達到什麼樣的效果？
1、基礎框架
什麼是框架？
它是一種助力、一種經驗總結的高效支持。
就像八股文，明確的行文格式（開篇、收尾、字數等），只需要往裏填充內容就是一篇合格的八股文。
2、交互
微服務化後面臨的最直接的問題是：服務間如何交互？
交互，其實無非兩種方式：接口、消息。
兩種方式不是隻選其一，實際應用中，不同場景，往往需要結合使用。
3、治理
微服務化後，整體服務的複雜性由服務本身上升到了網絡層。
- 服務不可用怎麼辦？
- 接口調用超時怎辦？
- 消息丟失、重複怎麼辦？
- 流量突增怎麼辦？
- 服務鏈路怎麼鏈接起來？
- ... ... 等等。
此時，你可能需要了解：服務註冊發現、負載均衡、熔斷降級、流量控制、服務重試、服務監控、版本管理、分佈式配置中心、鏈路追蹤、分佈式日誌系統等等一系列問題。
四、實施
拋開框架、結構層面的東西，其實最直接關係的是業務邏輯的遷移。而在這一點上，仔細、審慎則尤爲重要。缺了、漏了、變更意圖都是不能容忍的。
靜態代碼自檢、共檢 + 動態流量快照邏輯驗證可以作爲最基本遵循的原則。
五、附加訂閱
