微服務劃分原則

確切地說，服務中⼼的劃分原則更多的是架構設計經驗總結，我們很難對⼀些具體的問題給⼀個精確的量化指標，但有⼀點，我很反對現在微服務中的LOC（Line Of Code）這種指標，即⽤程式碼的⾏數來衡量⼀個微服務落地的標準。架構本來就是⼀個追求平衡的藝術，不僅是設計原則上的平衡，還要在技術、成本、資源、效能、團隊等各⽅⾯進⾏平衡，以最⾼效地解決主要問題。我認為這也是⼀名優秀架構師的必備特質，偏執地追求⼀個維度的完美肯定會在其他⽅⾯付出代價。從服務中⼼設計來看，⼀定要兼顧三個⽅⾯的需求，如圖所⽰：

如果不能兼得，就抓住需要解決的主要⽭盾。共享服務中⼼的架構⽬的是通過業務拆分來降低系統的複雜性；通過服務共享來提供可重⽤性；通過服務化來達到業務⽀持的敏捷性；通過統⼀的資料架構來消除資料互動的屏障。所以，所有的原則和⽅法都是為了這些⽬標服務的，“以終為始”再來看服務中⼼建設的原則和⽅法就會明確很多。

從設計層⾯來看，主要是要遵循⾯向物件的分析和設計的⽅法，即業務和系統建模遵循⾯向物件的基本原則，這些是多年軟體⼯程學的沉澱，服務化不是開創⼀套新的設計⽅法，⽽是⼀個指路的明燈。從運營層⾯來看，服務中⼼應該是⼀個完整的業務模型，要有資料運營和業務整合的價值，前⾯在介紹淘寶的服務中⼼時，⼀直在強調服務中⼼的發展變化性和可運營性，⽐如淘寶的商品中⼼，絕對不只是簡單的商品增刪改查的服務接⼝，⽽是建⽴⼀個全球最⼤的商品庫，同時提供該商品庫的管理運營的⽅法和配套⼯具服務。當然淘寶的商品中⼼建⽴成這樣是淘寶的電商業務決定的，並不意味著其他業務系統也要按這樣的標準去建⽴⾃⼰的商品中⼼，⼀切要根據業務來做判斷。

從⼯程層⾯來看，共享服務的架構是基於分散式架構，分散式架構解決了⼀體化架構在⼤規模應⽤上的問題，但是也引⼊了分散式事務、問題排查等⽅⾯的⼀些難題，所以在規劃服務中⼼的時候，⼀定要綜合評估業務層對服務中⼼在資料庫、業務以及運營⽅⾯的需求和技術上需要的投⼊。不能圖⼀時之快把業務拆得⾮常徹底，到最後卻不得不⽤很⼤資源投⼊來解決技術上⾯對的問題。

總體上，我們從這三個維度出發來決定服務中⼼的設計和評估。下⾯我們具體介紹在實際項⽬中總結的⼀些基本原則。

1.⾼內聚、低耦合原則

這是系統設計⼀開始就會強調的⼀個基本原則，不過很多時候在實踐中我們都在不知不覺中就違背了這個原則。⾼內聚是從服務中⼼的業務界

域來說的，在⼀個服務中⼼內的業務應該是相關性很⾼、依賴性很⾼的；⽽服務中⼼之間應該是業務隔離性⽐較⼤的，即追求儘可能的低耦合。注

意這⾥的業務隔離性是從應⽤場景來說的。

舉⼀個例⼦，很多應⽤⼀般都有⼀個會員中⼼，在會員的業務中，會有⽤營銷⼿段來保持會員的忠誠度和活躍度，有些⽤戶會傾向於把積分獨⽴出來建⽴⼀個獨⽴的積分中⼼或者放到營銷中⼼，有些⽤戶會覺得積分直接放在會員中⼼和會員等級掛鉤。這⾥如果是你的系統，你會選擇怎麼做？其實，從之前的項⽬實踐來看，⼀般建議⽤戶先不要獨⽴積分中⼼出來，因為拆分出⼀個積分中⼼，意味著你把會員服務的粒度縮⼩了，但是你的積分業務還不⾜夠豐富的時候其實就只剩下增、刪、改查的服務需求，對這種服務中⼼，不建議⼀開始就獨⽴出來⼀個服務中⼼，還是等積分相關業務發展到⾜夠豐富的程度或者對其他業務中⼼影響已經不可忽略

的時候再去拆分出來不遲。

2.資料完整性原則

這個原則其實和上⾯的“⾼內聚、低耦合”⼀脈相承，是把這個思想穿透到資料模型層⾯，因為服務化架構⼀個很重要的業務價值就是資料模型統⼀。這⾥特別想強調⼤資料的思維，不光只是業務邏輯的關鍵資料，還要考慮到業務的相關性資料；不光是實時線上資料，還要考慮到離線計算的資料。

3.業務可運營性原則

服務中⼼⾸先是從業務出發，單純的技術層⾯抽象出來的服務框架⼀般不作為⼀個可運營的服務中⼼。單純的技術型的服務中⼼可以存在，但不是這⾥討論的重點，我們期望服務中⼼是承載業務邏輯、沉澱業務資料、產⽣業務價值的業務單元。業務的運營性有兩個層⾯含義，⼀是指業務本⾝的活⼒，當業務處於快速⽣⻓期，這時候的運營⽬標是滿⾜上層的業務需求，這個時候屬於沉澱階段；第⼆個層⾯的運營是指業務內部的孕育出來的創新想法，⽐如淘寶基於⼤資料分析技術⽣⻓起來的商品巡檢技術、前臺類⽬⾃動聚合推薦技術等。資料模型統⼀之後，可⽤很低成本把⼤資料技術引⼊到服務中⼼的架構中，讓資料來源、資料分析、業務⽣產可以⾃然形成閉環。所以能否⽤⼤資料能⼒提升運營⽔平是服務中⼼原則之⼀。

4.漸進性的建設原則

漸進性的建設原則是從降低⻛險和實施難度這個⾓度出發，服務化架構本來就是⼀種敏捷的實踐，我們是推薦⼩步快跑的⽅式逐步推進，不是轟轟烈烈地推翻重來。其實在分散式架構體系下，在企業互聯⽹架構體系下，試錯的成本已經降到⾜夠低，漸進式的建設也是服務中⼼建設的⼀個重要原則。

有些⼈會覺得服務中⼼是基礎服務，應該是⾮常穩定的，所以⼀開始規劃設計的時候應⽤了太多的設計原則，最後從設計上看的確很清晰，但是在實施階段，可能會碰到拆得過細有延遲太⻓的問題，資料過於分散有資料庫效能的問題和分散式事務的問題，服務接⼝過於龐⼤的問題。這些實踐證明都不是好的服務化實踐。我們推薦服務化從簡單開始，只有真實的業務需求才會錘鍊出穩定可靠的共享服務。