概述

現在被談論最多的就是微服務和中臺系統，我個人的理解是微服務或者是中臺好不好，主要看實際的業務場景，架構的變遷往往需要耗費很大的學習成本和時間成本，所以更改架構的時候要三思而后行，適合自己特別重要。

由單體到多應用的演變

從我入職開始，公司已經從單體走向了垂直拆分，比如單庫查詢，Redis、Es、MongoDB已經在系統中廣泛應用，中途也遇到了些調用混亂的問題，我們在之前的MVC中加入了一個Service層做了一次數據聚合層，并且一直良好運行了很久，峰值請求大概在百萬級左右，在寒暑假的時候會稍微多一點。

(資料圖片)

在開始微服務之前其實我心里有自己的方案，團隊比較小，其實沒有必要進行微服務的拆分，如果非要拆分在原基礎上把yaf換成Swoole模式的，就能得到性能和成本之間的平衡，但是沒有得到采納，其實略有遺憾，在團隊里沒有話語權，是一件沒有辦法能解決的問題。

在這里多說一句，微服務并不是解決高并發的問題，微服務是一種架構思想，再了解微服務的過程中，也走了不少彎路，網上有很多Java實現的微服務，Go語言的，Rust的，甚至還有python的，其實單純從語言層面來說，語言的性能正在縮小，技術人要有自己的思考，不能麻木跟風。

拆分微服務遇到的問題

微服務我就不說了，在這里寫寫那些設計的要素和一定能遇到的坑。

比如我們的業務是閱讀App，里面的核心是作品，但是作品的詳情頁會集中展示評論、用戶、章節需要的數據信息，之前都同一個Service層，這是第一個需要思考的問題。

拆分顆粒度：拆分微服務最難的點在于怎么把握服務于服務之間的顆粒度，這個很難把握，如果拆大了，只是改了個名字，換湯不換藥，拆小了聚合數據又會存在問題，這中間的過程真是讓人抓狂。

下面我說說當時遇到的問題，拆分的日子真是讓人抓狂：

1.服務劃分過細，服務關系復雜，服務劃分過細，單個復雜度就會下降，但是整個系統的復雜度就會上升上來，因為微服務把系統內的復雜度轉移為了系統間的復雜度。

2.服務數量太多，團隊效率急劇下降，這里的誤區是微字就意味著拆分的很細。

3.沒有自動化支撐，無法快讀交付，現在極客時間里有GitOps，可以看這個，寫的很好。

4.沒有服務治理，微服務達到一定數量，后臺管理混亂。

5.以前一條sql搞定的事情，現在需要從多個服務里獲取，在一定程度上提升了開發難度。

拆分微服務方法梳理

從網上梳理了一些拆分微服務的方法論，希望對你有一些參考的價值：

1.縱向拆分和橫向拆分

從業務維度進行拆分，標準是按照業務的關聯程度來決定，關聯比較密切的業務適合拆分成一個微服務，而功能相對比較獨立的業務適合拆分為一個微服務。從公共且獨立功能維度拆分，標準是按照是否有公共的被多個其他服務調用，且依賴的資源獨立不與其他業務耦合。

2.拆分微服務還是綜合考慮的因素

業務邏輯基礎設施建設(自動化測試、自動化部署、服務監控，服務發現、配置中心等等)，決定成敗的往往是基礎設施建設，和業務無關。將系統中的模塊按照穩定性來劃分，將已經成熟的和改動不大的歸類為穩定的服務。

3.按照業務顆粒度劃分，分出了2種可能。

按照粗顆粒度劃分：作品、用戶、評論、消息按照細顆粒度：作品、用戶、有聲、評論、動態、客服IM、綜合等等就很多很多了。

拆分原則

3個火槍手原則：一個微服務由三個人開發，在進行微服務架構時，根據團隊規模來劃分數量也是合理的。

AFK拆分原則：

X軸，水平復制，多加載幾個應用實例，以集群加負載均衡的模式進行拆分Y軸，微服務經常采用的按業務邏輯劃分Z軸，按照數據進行劃分

康威定律

第一定律：組織溝通方式會通過系統設計表達出來，人月神話中總結出了隨著人員的增加溝通成本呈指數增長的規律，溝通成本n(n-1)/2第二定律：時間再多一件事情也不可能做的完美，但總有時間做完一件事情。第三定律：線型系統和線型組織架構間具有潛在的異質同態特種第四定律：大的系統組織總是比小系統更傾向于分解

其他原則：

人與人的溝通是非常復雜的，一個人的溝通精力是有限的，所以當問題太復雜需要很多人解決的時候，我們需要做拆分來達成對溝通效率的管理。組織內人與人的溝通方式決定了他們參與的系統設計，管理者可以通過不同的拆分方式帶來不同的團隊間溝通方式，從而影響系統設計如果子系統是內聚的，和外部的溝通邊界是明確的，能降低溝通成本，對應的設計也會更加合理高效復雜的系統需要通過容錯彈性的方式持續優化，不要指望一個大而全的設計或架構，好的架構和設計都是慢慢迭代出來的