前言：創業公司往往因為有限的時間和投入，把系統所有的功能都聚集在一起。隨著業務的不斷髮展，技術人員開始不斷地對架構進行解耦和拆分。微服務在最近幾年大行其道，很多公司的研發人員都在考慮微服務架構，或者在做微服務的路上，拆分服務是個很熱的話題。那麼我們應該按照什麼原則將現有的業務進行拆分？是否拆分得越細就越好？這裡我想談談系統拆分需要考慮的因素和堅持的原則。

業務因素

所有技術方面的考慮，包括架構設計和解耦拆分都要考慮業務的需要。在服務拆分時，先從業務角度確定拆分的方案。拆分的邊界要充分考慮業務的獨立性和專業性，比如搜尋類服務、支付類服務、購物車類服務，按服務的業務功能合理地劃出拆分邊界。避免按團隊來定義服務邊界，這樣做會出現土匪搶地盤的局面，嚴重破壞團隊之間的信任，削弱創新的潛在機會。

投入產出

衡量拆分收益的標準是拆分後的維護成本要低過拆分前的維護成本，也就是說不能因為拆分而帶來更大的維護工作。

拆分前的維護成本 - 拆分後的維護成本 ≧ 0

服務的維護成本包括維護該服務所需要耗費的人力、物力和時間。如果一個系統拆分成兩個或兩個以上，導致所有的資源都加倍，那將會很失敗。最好的結果是原來維護服務的同一套人馬分成兩個部分，因為拆分後服務的複雜性降低，所需要的維護資源顯著減少，或者對人員能力的要求大大降低。

組織結構

拆分不僅僅是架構上的調整，也意味著要在組織結構上做出相應的適應性調整，確保拆分後的服務由相對獨立的團隊負責維護，儘量不要出現在不同服務之間的交叉呼叫。在這裡要堅持的原則是明確每個服務的分工，充分授權而且自給自足的相對獨立。切不可出現一個服務由幾個不同的團隊共同負責的情況，這會造成無人負責或多方爭搶，也不利於團隊積累相關服務的經驗。

系統擴充套件

拆分的一個重要理由也是最有價值的結果是提高了系統的擴充套件性。使用者對不同的服務有不同的併發和效能方面的要求，因此服務具有不同的擴充套件性。把具有不同擴充套件性要求的服務拆分出來分別進行部署，可以降低成本，提高效率。比如電商平臺的搜尋服務有很多請求，需要特別好的擴充套件性，應該把搜尋服務分離出來，單獨考慮其擴充套件性的需求。這樣可以確保不會因為搜尋服務突然繁忙而影響其他的服務。也可以根據搜尋服務的特點，設計出適合擴充套件的部署方案。

軟體釋出

系統中經常變動的部分大約只佔20%，剩下的80%基本不變或極少變化，因此軟體的釋出週期完全不同。我們可以把不變的80%分離出來，單獨部署，單獨管理。這不僅有利於降低系統的複雜性，精簡團隊的規模；也有利於在系統發生故障的時候快速定位。如果不做這種拆分，系統在擴充套件的過程中會浪費很多資源。

資訊保安

不同的服務可能對資訊保安有不同的要求，因此把需要高度安全的服務拆分出來，進行特別的部署，比如放在防火牆的後面，可以更有針對性地滿足資訊保安的要求，也可以降低對防火牆等安全裝置吞吐量、併發性等方面的要求，降低成本，提高效率。這就像對家裡不同房間的安全做不同的安排，確保需要加鎖的加鎖，減少了對鎖的需求量，也減少了開門的麻煩。

總結

所以我們在考慮服務拆分時，要堅持：面向業務、大道至簡、分而治之的三個原則，充分考慮業務需求、投入產出、組織結構、系統擴充套件、軟體釋出和資訊保安等方面。不能只從技術角度出發，把服務切成很多細微的小塊，這樣做很有可能會出現勞民傷財、欲速而不達的結果。

作者簡介：陳斌，陳斌現任易寶首席技術官（CTO），一直專注於網際網路技術領域的探索和創新，擁有豐富的海外經歷、多年的架構經驗，深諳移動網際網路對傳統行業的影響。作為業界最前沿技術的實踐者和佈道者，致力於推動移動網際網路技術引領行業變革，出版過多本書籍，榮登京東新書銷售榜第一名，並獲中央電視臺隆重推介。(責編／魏偉)