不知道大家面臨微服務改成頭一件事是不是為如何拆分微服務而煩惱、糾結？到底這個系統該如何劃分微服務？如何拆分才是比較好的？
今天，本作者就來結合這些年微服務改造的一些經驗來談談到底該如何拆分微服務。
其實，一個系統究竟該如何拆分微服務，怎樣拆才是最好的，其實並沒有一個標準的答案。(對，就是沒有一個統一而完美的答案，沒有最好，只有更好!:),哈哈，開句玩笑的）。
一般而言，如果是一個全新系統，拆分微服務則不會那麼糾結，因為，從零到一，一切可以根據自己的系統設計來拆，沒有那麼多條條框框的限制，這裡本文將不再贅述。
接下來，本文重點分享的是如何在已有系統進行微服務改造，我相信，這是大家遇到的最多的一個問題。因為隨著系統業務規模的擴展，好多老架構的系統都會面臨著系統重構，而微服務架構目前是眾多系統架構裡的首選。在進行微服務架構改造之前，大家可以先從以下幾個方面考慮以下：
1、已有系統的體量是多少？-->比如系統用戶數多少，最大併發多少，日均IP和PV是多少？
如果已有系統是企業內部系統，系統本身使用的人就不是很多，比如一個100人左右的系統，最大併發20人左右，這樣的系統就沒必要跟時髦，為了微服務改造而改造。
那如果說，是一個全球性的互聯網系統，遍佈海內外的人都在使用，而且併發量還比較大，開發團隊也遍佈全球，更新上線也比較頻繁，那這時可以考慮下微服務架構。
2、思考一下已有系統適合用微服務架構嗎？用微服務架構的好處是什麼？用了微服務架構後會解決什麼問題？
已有系統的開發維護團隊是一個技術棧的還是多個？系統的平均更新週期是多長？
如果說，已有系統的開發維護團隊是一個，系統也是半年會一兩年才更新一次，那就沒必要用微服務架構，微服務架構的特點就是“短平快”。
當你的系統迭代次數較多，更新上線較頻繁，而團隊技術棧又比較多時，這樣的團隊微服務適合進行微服務架構開發。
3、系統的重構預算是否充足？
看似這跟技術好不相關，但搞技術的人也是需要吃飯的。要解決吃飯的問題就要考慮成本問題，一切不考慮成本進行重構的架構都是耍流氓！眾所周知，微服務架構帶來更敏捷的開發福利的同時，也比傳統架構需要更多的部署和維護成本，需要培養多個技術棧的技術人員，由於是分佈式部署，會用到額外的一些中間件，比如服務發現、服務網關、服務監控、負載均衡、消息隊列等等集群。如果預算不夠，投資回報率達不到要求，大型系統微服務改造之路十有八九會中途而廢。現實中，就遇到很多失敗的例子，改造前，好高騖遠，什麼都想搞，沒有充分評估好風險，理想很美好，現實很殘酷，結果半年下去，還是個半成品，被中途叫停。
4、如果上述三個問題都已具備微服務架構的條件，那麼接下來我們還要分析下，已有系統中哪些適合微服務架構？其實，這是個偽命題，光看標題，還是不知道哪些適合哪些不適合。我們不妨這樣來分析：
a.系統中哪些模塊更新頻率比較高-->系統前臺、用戶界面？
b.系統中哪些模塊使用比較頻繁，壓力比較大？-->比如OA系統的審批模塊、學習系統的考試、課件播放模塊？
c.系統中哪些模塊是共用的-->日誌、郵件、權限控制。。。？
d.系統中哪些是RPC通信的-->用戶消息通知，一些原有RPC通信
e.系統中哪些是實時性要求比較高的-->在線轉賬、短信通知？
f.哪些模塊是前後臺分離的？-->Portal前臺？
。。。。。。
當然，上面abcde這幾點都是考慮特殊情況的，其實，就一般而言，我們還是有一些基本的微服務拆分原則的：
1、AKF拆分原則
AKF擴展立方體
AKF擴展立方體(參考《The Art of Scalability》)，是一個叫AKF的公司的技術專家抽象總結的應用擴展的三個維度。理論上按照這三個擴展模式，可以將一個單體系統，進行無限擴展。
X 軸 ：指的是水平復制，很好理解，就是講單體系統多運行幾個實例，做個集群加負載均衡的模式。
Z 軸 ：是基於類似的數據分區，比如一個互聯網打車應用突然或了，用戶量激增，集群模式撐不住了，那就按照用戶請求的地區進行數據分區，北京、上海、四川等多建幾個集群。
Y 軸 ：就是我們所說的微服務的拆分模式，就是基於不同的業務拆分。
場景說明：比如打車應用，一個集群撐不住時，分了多個集群，後來用戶激增還是不夠用，經過分析發現是乘客和車主訪問量很大，就將打車應用拆成了三個乘客服務、車主服務、支付服務。三個服務的業務特點各不相同，獨立維護，各自都可以再次按需擴展。
2、前後臺分離原則
前後端分離原則，簡單來講就是前端和後端的代碼分離也就是技術上做分離，我們推薦的模式是最好直接採用物理分離的方式部署，進一步促使進行更徹底的分離。不要繼續以前的服務端模板技術，比如JSP ，把Java JS HTML CSS 都堆到一個頁面裡，稍複雜的頁面就無法維護。這種分離模式的方式有幾個好處：
前後端技術分離，可以由各自的專家來對各自的領域進行優化，這樣前端的用戶體驗優化效果會更好。
分離模式下，前後端交互界面更加清晰，就剩下了接口和模型，後端的接口簡潔明瞭，更容易維護。
前端多渠道集成場景更容易實現，後端服務無需變更，採用統一的數據和模型，可以支撐前端的web UI\\ 移動App等訪問。
一個前後端分離的微服務架構：
前端用純js+html+css或前端框架（Reat\\Angular\\Vue）,
後端用webapi(c#\\java\\node.js\\php...)
3、無狀態服務原則
對於無狀態服務，首先說一下什麼是狀態：如果一個數據需要被多個服務共享，才能完成一筆交易，那麼這個數據被稱為狀態。進而依賴這個“狀態”數據的服務被稱為有狀態服務，反之稱為無狀態服務。
那麼這個無狀態服務原則並不是說在微服務架構裡就不允許存在狀態，表達的真實意思是要把有狀態的業務服務改變為無狀態的計算類服務，那麼狀態數據也就相應的遷移到對應的“有狀態數據服務”中。
場景說明：例如我們以前在本地內存中建立的數據緩存、Session緩存，到現在的微服務架構中就應該把這些數據遷移到分佈式緩存中存儲，讓業務服務變成一個無狀態的計算節點。遷移後，就可以做到按需動態伸縮，微服務應用在運行時動態增刪節點，就不再需要考慮緩存數據如何同步的問題。
閱讀更多 墨漂碼農 的文章
