很多傳統企業看著網際網路公司都進行著微服務化，因此也想享受微服務化帶來的好處便對自己的系統進行改造，但微服務化 多「微」才是最優？有哪些拆分的原則？

架構原則

• 使用成熟的技術，不需要最先進最好的技術，要是自己人能夠掌控的，不然出現莫名的問題，一兩天都可能解決不了，你就等著被拿來「祭天」吧。
• 至少有一個冗餘的實例，可水平擴展，確保一個實用多個負載，掛掉一個仍然能夠正常運行，這裡就要保證服務應用的無狀態性。
• 確保數據中心能在地理上隔離，實現異地多活容災，實現三城兩地式物理布署，即使一個城市停電仍可提供數據的正常訪問。
• 有一套發布回滾機制，確保發布異常時能回滾到上一個版本，同時可追蹤到異常。
• 在架構設計之初就構建監控平台，無監控無疑相當於系統在裸奔，後面擴容無數據支撐、BUG查找，異常追蹤都無從淡起。
• 不斷小試錯，而不是像傳統項目開發周期達一年，在時間就是生命的時代，產品上線黃花菜都涼了。
• 任務自動化，機器能夠做就讓程序自動跑，減少人力運維。
• 實現故障隔離，自動保護機制，防止一個服務拖垮整個系統平台，進行健壯性分析。
• ……

所有的設計都是為了高可用，易擴展、高並發下出現異常更容易恢復，降低異常對業務的影響，這就是微服務架構設計的理念，但不完全，有些還是依靠架構師的經驗結合自己公司的業務特點來思考，並不是適合所有的公司，傳統公司進行微服務化的困難很大，但做得好收益也非常高。

做好業務的拆、合

微服務講究的是小 ，一個程序只做好一件事就夠了，因此需要對原有臃腫的系統拆分，對零散的功能進行合。

一個業務場景一個服務

如用戶服務、授權服務、菜單服務、訂單服務…… 這樣的粒度好處是更新用戶服務其它的服務可以不用更新。

一個資料庫對應一個服務

資料庫操作層封裝成一個服務，所有對這個資料庫的請求都要經過這個服務，而不用知道這個資料庫的密碼，而且可以進行流量權限等進行控制。

一個接口一個服務

這種架構很極端，會造成微服務數量成幾何數增長，維護難度極大。適當的粒度優勢是服務能夠獨離部署，擴展方便，耦合度較小。

應用層我們可以結合上面的方法從下往上分析，對所有服務抽像化後抽出基礎功能封成服務，這樣公共服務就形成了，而且可以互相引用。

這樣就形成了基礎服務，是一些基礎組件，與具體的業務無關。比如：簡訊服務、郵件服務。這裡的服務最容易摘出來做微服務，也是我們第一優先級分離出來的服務。

還有些是業務服務，是一些垂直的業務系統，只處理單一的業務類型如：風控系統、積分系統、合同系統。這類服務職責比較單一，根據業務情況來選擇是否遷移，比如：如果突然有需求對積分系統進行大優化，我們就趁機將積分系統進行改造，是我們的第二優先級分離出來的服務。

前端服務，一般為服務的接入或者輸出服務，比如網站的前端服務、app 的服務接口這類，這是我們第三優先級分離出來的服務。

組合服務，組合服務就是涉及到了具體的業務，比如網購過程，需要調用很多垂直的業務服務，這類的服務我們一般放到最後再進行微服務化架構來改造，因為這類服務最為複雜，除非涉及到大的業務邏輯變更，我們是不會輕易進行遷移。

獨立資料庫

數據層都是獨立的資料庫，即一個資料庫對應一個服務，這裡需要對資料庫層進行縱向切分，即原來一個表現在對應多個表分片保存。

給資料庫帶來的挑戰

每個微服務都有自己獨立的資料庫，那麼後台管理的聯合查詢怎麼處理?

有如下三種處理方案：

• 嚴格按照微服務的劃分來做，微服務相互獨立，各微服務資料庫也獨立，後台需要展示數據時，調用各微服務的接口來獲取對應的數據，再進行數據處理後展示出來，這是標準的用法，也是最麻煩的用法。
• 將業務相關的表放到一個庫中，將業務無關的表嚴格按照微服務模式來拆分，這樣既可以使用微服務，也避免了資料庫各種切換導致後台統計難以實現，是一個折中的方案。
• 資料庫嚴格按照微服務的要求來切分，以滿足業務高並發，實時或者准實時將各微服務資料庫數據同步到 NoSQL 資料庫中，在同步的過程中進行數據清洗，用來滿足後台業務系統的使用，推薦使用 Mongodb、Hbase 等。

拆分過後落地架構

• 在確定使用Spring Boot / Cloud 這套技術棧進行微服務改造之前，請先梳理平台的服務，對不同的服務進行分類，以確認演化的節奏。
• 先讓團隊熟悉 Spring Boot 技術，並且優先在基礎服務上進行技術改造，推動改動後的項目投產上線。
• 當團隊熟悉 Spring Boot 之後，再推進使用 Spring Cloud 對原有的項目進行改造。
• 在進行微服務改造過程中，優先應用於新業務系統，前期可以只是少量的項目進行了微服務化改造，隨著大家對技術的熟悉度增加，可以加快加大微服務改造的範圍。
• 傳統項目和微服務項目共存是一個很常見的情況，除非公司業務有大的變化，前期不建議直接遷移核心項目，先搭建一個微服務架構，然後先接入新業務，後面再將老項目逐個改造，這裡有個問題就是統一配置，統一規則，如日誌，接口，文檔，代碼風格，公共類庫 版本等等提前規範。

以上只是個拆分建議，傳統項目到微服務轉化首先是思想上的轉變就是很困難的，然後有些方法也不能套大公司的，只能是趨向大原則，根據自己的業務量，人力 時間等來改造。