微服務拆分（1）
對於第乙個問題，是乙個無法度量的問題，粒度多細才是細，多粗才算粗，根本就是你說了算，而且，很多時候，並非夠細或夠粗就是好事情。
對於粒度的劃分，李運華老師提出了以專案組開發人員的數量來劃分粒度的想法，我覺得很認同。乙個服務，應該以2-3個人（可以根據團隊成員構成進行分組，以組概念來權衡數量）來維護比較妥當。也就是說，如果整個團隊有5個人，服務數量應該控制在2-3個以內。當服務日漸複雜時，我們可以化整為零，分而治之。而拆分系統相對來說，比整合系統要更加簡單（因為可以很好地找到服務邊界）。
第二個問題，服務間的複雜依賴關係如何管理。其實我們只要遵循乙個基本原則：永遠只有不同層級的單向依賴，就能讓系統有乙個清晰的依賴關係，因為單向永遠不可能形成環狀。也就是，高層服務可以依賴低層服務，同層服務間不互相依賴。如果出現了同層服務間依賴，就說明服務分層出現了問題，此時需要抽象出乙個更高層次的服務或者提公升其中乙個服務的層次。
微服務拆分
微服務拆分是做微服務架構很重要也很難的話題，很多時候，幾個服務是合還是拆在設計團隊內也很難達成共識。當你糾結應該拆分和合併時我建議就先合併，等後面版本迭代需要時有必要再去做拆分。從系統發展的角度說，很多平台也都是從單體大應用 逐步拆分演化而來的，就像有位大牛說的那樣，一開始就拆分的很好的微服務實踐往...
服務拆分原則
服務拆分有以下幾個原則和大家分享 橫向拆分。按照不同的業務域進行拆分，例如訂單 營銷 風控 積分資源等。形成獨立的業務領域微服務集群。縱向拆分。把乙個業務功能裡的不同模組或者元件進行拆分。例如把公共元件拆分成獨立的原子服務，下沉到底層，形成相對獨立的原子服務層。這樣一縱一橫，就可以實現業務的服務化拆...
微服務 服務的拆分
我在思考乙個問題 我們為什麼要搞微服務，整體式服務就不能滿足嗎？為什麼一定要用微服務呢？服務的粒度拆的約來越細呢？當我們的業務複雜之後，設計乙個系統難度會加大，還要適應快速迭代，就更難了。將業務的功能拆分之後，會讓每個模組的設計變得簡單。對於需求的變更，採用增加 修改模組的方式來實現也比較方便。但是...