確切地說，服務中⼼的劃分原則更多的是架構設計經驗總結，我們很難對⼀些具體的問題給⼀個精確的量化指標，但有⼀點，我很反對現在微服務中的loc（line of code）這種指標，即⽤**的⾏數來衡量⼀個微服務落地的標準。架構本來就是⼀個追求平衡的藝術，不僅是設計原則上的平衡，還要在技術、成本、資源、效能、團隊等各⽅⾯進⾏平衡，以最⾼效地解決主要問題。我認為這也是⼀名優秀架構師的必備特質，偏執地追求⼀個維度的完美肯定會在其他⽅⾯付出代價。從服務中⼼設計來看，⼀定要兼顧三個⽅⾯的需求，如圖所⽰：
如果不能兼得，就抓住需要解決的主要⽭盾。共享服務中⼼的架構⽬的是通過業務拆分來降低系統的複雜性；通過服務共享來提供可重⽤性；通過服務化來達到業務⽀持的敏捷性；通過統⼀的資料架構來消除資料互動的屏障。所以，所有的原則和⽅法都是為了這些⽬標服務的，「以終為始」再來看服務中⼼建設的原則和⽅法就會明確很多。
從設計層⾯來看，主要是要遵循⾯向物件的分析和設計的⽅法，即業務和系統建模遵循⾯向物件的基本原則，這些是多年軟體⼯程學的沉澱，服務化不是開創⼀套新的設計⽅法，⽽是⼀個指路的明燈。從運營層⾯來看，服務中⼼應該是⼀個完整的業務模型，要有資料運營和業務整合的價值，前⾯在介紹**的服務中⼼時，⼀直在強調服務中⼼的發展變化性和可運營性，⽐如**的商品中⼼，絕對不只是簡單的商品增刪改查的服務接⼝，⽽是建⽴⼀個全球最⼤的商品庫，同時提供該商品庫的管理運營的⽅法和配套⼯具服務。當然**的商品中⼼建⽴成這樣是**的電商業務決定的，並不意味著其他業務系統也要按這樣的標準去建⽴⾃⼰的商品中⼼，⼀切要根據業務來做判斷。
從⼯程層⾯來看，共享服務的架構是基於分布式架構，分布式架構解決了⼀體化架構在⼤規模應⽤上的問題，但是也引⼊了分布式事務、問題排查等⽅⾯的⼀些難題，所以在規劃服務中⼼的時候，⼀定要綜合評估業務層對服務中⼼在資料庫、業務以及運營⽅⾯的需求和技術上需要的投⼊。不能圖⼀時之快把業務拆得⾮常徹底，到最後卻不得不⽤很⼤資源投⼊來解決技術上⾯對的問題。
總體上，我們從這三個維度出發來決定服務中⼼的設計和評估。下⾯我們具體介紹在實際項⽬中總結的⼀些基本原則。
1.⾼內聚、低耦合原則
這是系統設計⼀開始就會強調的⼀個基本原則，不過很多時候在實踐中我們都在不知不覺中就違背了這個原則。⾼內聚是從服務中⼼的業務界
域來說的，在⼀個服務中⼼內的業務應該是相關性很⾼、依賴性很⾼的；⽽服務中⼼之間應該是業務隔離性⽐較⼤的，即追求盡可能的低耦合。注
意這⾥的業務隔離性是從應⽤場景來說的。
舉⼀個例⼦，很多應⽤⼀般都有⼀個會員中⼼，在會員的業務中，會有⽤營銷⼿段來保持會員的忠誠度和活躍度，有些⽤戶會傾向於把積分獨⽴出來建⽴⼀個獨⽴的積分中⼼或者放到營銷中⼼，有些⽤戶會覺得積分直接放在會員中⼼和會員等級掛鉤。這⾥如果是你的系統，你會選擇怎麼做？其實，從之前的項⽬實踐來看，⼀般建議⽤戶先不要獨⽴積分中⼼出來，因為拆分出⼀個積分中⼼，意味著你把會員服務的粒度縮⼩了，但是你的積分業務還不⾜夠豐富的時候其實就只剩下增、刪、改查的服務需求，對這種服務中⼼，不建議⼀開始就獨⽴出來⼀個服務中⼼，還是等積分相關業務發展到⾜夠豐富的程度或者對其他業務中⼼影響已經不可忽略
的時候再去拆分出來不遲。
2.資料完整性原則
3.業務可運營性原則
服務中⼼⾸先是從業務出發，單純的技術層⾯抽象出來的服務框架⼀般不作為⼀個可運營的服務中⼼。單純的技術型的服務中⼼可以存在，但不是這⾥討論的重點，我們期望服務中⼼是承載業務邏輯、沉澱業務資料、產⽣業務價值的業務單元。業務的運營性有兩個層⾯含義，⼀是指業務本⾝的活⼒，當業務處於快速⽣⻓期，這時候的運營⽬標是滿⾜上層的業務需求，這個時候屬於沉澱階段；第⼆個層⾯的運營是指業務內部的孕育出來的創新想法，⽐如**基於⼤資料分析技術⽣⻓起來的商品巡檢技術、前台類⽬⾃動聚合推薦技術等。資料模型統⼀之後，可⽤很低成本把⼤資料技術引⼊到服務中⼼的架構中，讓資料**、資料分析、業務⽣產可以⾃然形成閉環。所以能否⽤⼤資料能⼒提公升運營⽔平是服務中⼼原則之⼀。
4.漸進性的建設原則
漸進性的建設原則是從降低⻛險和實施難度這個⾓度出發，服務化架構本來就是⼀種敏捷的實踐，我們是推薦⼩步快跑的⽅式逐步推進，不是轟轟烈烈地推翻重來。其實在分布式架構體系下，在企業互聯⽹架構體系下，試錯的成本已經降到⾜夠低，漸進式的建設也是服務中⼼建設的⼀個重要原則。
有些⼈會覺得服務中⼼是基礎服務，應該是⾮常穩定的，所以⼀開始規劃設計的時候應⽤了太多的設計原則，最後從設計上看的確很清晰，但是在實施階段，可能會碰到拆得過細有延遲太⻓的問題，資料過於分散有資料庫效能的問題和分布式事務的問題，服務接⼝過於龐⼤的問題。這些實踐證明都不是好的服務化實踐。我們推薦服務化從簡單開始，只有真實的業務需求才會錘煉出穩定可靠的共享服務。
微服務和模組劃分原則
微服務架構作為目前使用的主流架構，已經被廣泛使用，但是對於服務的劃分卻沒有固定的原則，在工作中也經常會出現服務劃分過度或者不充分的情況。所以在這裡想 一下服務邊界和服務劃分的方法。前後端分離原則，簡單來講就是前端和後端的 分離也就是技術上做分離，我們推薦的模式是最好直接採用物理分離的方式部署，進一步...
微服務模組劃分原則和介面定義原則
原則1 傳統的乙個大業務系統劃分微服務模組的時候，盡量是劃分到6到8個模組比較合適，當你本身的it成熟度達到一定水平後你可以劃分的更加細點。同時在微服務模組劃分的時候一定要考慮資料庫本身的劃分，即底層的資料庫也是劃分開的。原則2 要分析單個業務系統內部的流程，然後分解到具體的業務元件或功能，再按照高...
微服務服務劃分示例
近年來微服務 soa很是流行，我們團隊趕時髦，也玩了玩。雖然用的時間還不長，但也已經踩過不少坑。今天想記錄下自己對邊界問題的一些思考。很多人在談起微服務時，總是會很自豪的說，微服務為我們提供了高內聚低耦合的明顯好處，因為微服務強化了模組化的概念。但是，如何模組化，如何明確的定義模組的邊界，卻很少有人...