之前講解了什麼是微服務：微服務的核心在於服務治理，微服務架構是將複雜臃腫的單體應用進行細粒度的服務化拆分，每個拆分出來的服務各自獨立打包部署，並交由小團隊進行開發和運維，從而極大地提高了應用交付的效率。
什麼時候進行服務化拆分？拆分單體應用有哪些標準呢？
這個時候就需要大規模地擴張開發人員，以支撐多個功能的開發。如果這個時候繼續採用單體應用架構，多個功能模組混雜在一起開發、測試和部署的話，就會導致不同功能之間相互影響，一次打包部署需要所有的功能都測試 ok 才能上線。而且，多個功能模組混部在一起，對線上服務的穩定性也是個巨大的挑戰。
再例舉乙個 58 到家的例子，隨著業務越來越複雜，資料量越來越大，併發量越來越大，15 年的時候，58 到家的架構碰到了種種問題：
這個時候 58 到家開始進行服務化拆分，找到通用痛點，抽象出通用資料訪問與子業務，然後將它們下沉成微服務。
一般來說，一旦單體應用同時進行開發的人員超過 10 人，就會遇到上面的問題，這個時候就該考慮進行服務化拆分了。
這種服務化拆分方式是縱向拆分，是從業務維度進行拆分。標準是按照業務的關聯程度來決定，關聯比較密切的業務適合拆分為乙個微服務，而功能相對比較獨立的業務適合單獨拆分為乙個微服務。
還有一種服務化拆分方式是橫向拆分，是從公共且獨立功能維度拆分。標準是按照是否有公共的被多個其他服務呼叫，且依賴的資源獨立不與其他業務耦合。
一般情況下，業務系統引入新技術就必然會帶來架構的複雜度提公升，在具體決策前，先要認識到新架構會帶來哪些新的問題，這些問題你和你的團隊是否能夠解決？如何解決？是自己投入人力建設，還是採用業界開源方案？
下面幾個問題，是從單體應用遷移到微服務架構時必將面臨也必須解決的。
針對上述問題，必須有可行的解決方案之後，才能進行服務化拆分。
無論是縱向拆分還是橫向拆分，都是將單體應用龐雜的功能進行拆分，抽離成單獨的服務部署。
但並不是功能拆分的越細越好，過度的拆分反而會讓服務數量膨脹變得難以管理，因此找到符合自己業務現狀和團隊人員技術水平的拆分粒度才是可取的。
參考
微服務簡介 構建單體應用
網際網路技術發展迅速的今天，微服務倍受關注 文章 部落格 社交 討論和會議演講都在談論。與此同時，也有持懷疑態度的軟體社群人員認為微服務沒什麼新鮮可言。反對者聲稱它的思想只是面向服務架構的重塑。然而，無論是炒作還是懷疑，不可否認，微服務架構模式具有非常明顯的優勢 特別是在實施敏捷開發和複雜的企業應用...
微服務還是單體，應用架構怎麼選？
近幾年，由於微服務生態建設的完善，微服務架構漸成趨勢，逐漸流行。業內人士也都在爭先恐後想一睹微服務芳容，甚至想王老虎搶親。但同時存在沒有認真考慮微服務架構是否適合自己的應用場景以及組織文化的問題。本人在前幾篇博文已經對微服務生態有了闡述。所謂生態，實際上講的是天時地利人和，講的是各方和諧。微服務生態...
GO語言 微服務簡介 構建單體應用
網際網路技術發展迅速的今天，微服務倍受關注 文章 部落格 社交 討論和會議演講都在談論。與此同時，也有持懷疑態度的軟體社群人員認為微服務沒什麼新鮮可言。反對者聲稱它的思想只是面向服務架構的重塑。然而，無論是炒作還是懷疑，不可否認，微服務架構模式具有非常明顯的優勢 特別是在實施敏捷開發和複雜的企業應用...