微服務系統如何拆分？
先粗後細，不要過細，切忌一個介面一個服務
橫向拆分，而非縱向，我們儘量不要超過三層呼叫
單向呼叫，嚴禁迴圈呼叫
禁止介面型別透傳，在不同的層之間不要共享同一個資料定義，避免一處修改，影響其它
沒有依賴關係的序列呼叫改為並行，可以通過 core/mr 包降低響應延遲而不增加系統負載
如何保障高併發高可用？
良好的資料邊界
資料邊界是微服務拆分的核心，不同的服務之間不要顯示共享資料，而應該通過 rpc 共享。
高效的快取管理
服務能否支撐高併發，快取很關鍵。快取機制不光要設計好，還需要通過工具儘可能讓業務開發人員避免出錯，因為快取程式碼的編寫有相當的難度，goctl 很好的生成了自動管理快取的程式碼。
優雅的熔斷降載保護
微服務系統一般都是由大量服務共同組合而成的，服務多了自然會有某個服務出現故障的風險，我們不能讓某個服務的故障導致整個系統不可用，這就是服務雪崩，要避免雪崩，我們就需要有效隔離有故障的服務，從而降級可用。熔斷和降載是防止服務雪崩的最有效手段之一。
彈性伸縮能力
對於高併發的系統來說，突發流量洪峰的情況下，系統需要能夠及時水平擴容，go-zero 的自適應降載可以很好的配合 kubernetes 叢集的自動水平伸縮能力。
清晰的資源使用定義
要想讓系統保持穩定，我們一定要對資源使用做清晰的定義，比如我們到底在什麼時候考慮擴充資源，是資源佔用率達到了50%還是70%，必須對系統資源的使用狀況有足夠清晰的定義。
高效的監控報警
我在團隊內部一直強調：沒有度量就沒有優化。我們必須對系統有高效的監控和及時的報警機制。這樣才能讓我們對整個系統的執行狀態有足夠的瞭解。
大型微服務專案從何下手？
微服務系統大體上看起來如上圖，但是我們並不是一定要業務一開始就上微服務，我們看看一個典型的微服務系統是怎麼進化而來的，下面粗略的講解一下大型微服務系統的進化過程。
從單體服務開始
專案剛開始，我們不要一味的追求技術的先進性，因為大部分專案是走不到高併發的那一天的，我們需要的是第一時間滿足業務。
業務優先，技術支撐
我在團隊裡講：架構是從業務中來，到業務中去。任何脫離了業務的技術都是自嗨，我們需要把滿足業務需要作為第一優先順序，技術需要支撐業務現在和可預期發展的需要即可。當然，有滿足自身業務的現成的框架和最佳實踐那是最好了，但不要讓技術棧過於複雜，避免重心從業務轉移到技術本身來。
服務指標監控
隨著業務的發展，我們可能需要對技術做一定的升級和改造了，但是我們一直強調：沒有度量就沒有優化。所以我們需要及時加上對整個服務的關鍵指標的監控，從而讓我們在瞭解系統的前提下進行必要的改造。
資料拆分+快取管理
當業務發展到一定程度之後，基於監控，我們發現服務必須要做拆分了。那麼我們第一步要做的是先把資料拆分清楚，資料拆分後，我們就可以加上對應的快取管理，從而保障資料層面的穩定性。
服務拆分
相對於資料拆分，服務的拆分相對是比較容易的，基於拆分好的資料，對應出上層的服務，因為服務是無狀態的，所以這個拆分就比較容易。
支撐系統建設
隨著業務的發展，日常的系統維護工作就顯得比較繁瑣和容易出錯了。此時，我們需要建設支撐系統，如何部署新服務，如何更新老服務，是不是要上 kubernetes，等等。
自動化+工程建設
當業務發展到一定程度，工程效率就是一個很大的問題了。goctl 就是為了解決自動化和工程效率問題而生，其中內建的 api, rpc, model, Dockerfile, k8s部署檔案等的自動生成節省了我們大量時間，也避免了業務開發中的錯誤。
本作品採用《CC 協議》，轉載必須註明作者和本文連結