很多傳統企業看著互聯網公司都進行著微服務化，因此也想享受微服務化帶來的好處便對自己的系統進行改造，但微服務化?多“微”才是最優？有哪些拆分的原則？
架構原則
使用成熟的技術，不需要最先進最好的技術，要是自己人能夠掌控的，不然出現莫名的問題，一兩天都可能解決不了，你就等著被拿來“祭天”吧。
至少有一個冗余的實例，可水平擴展，確保一個實用多個負載，掛掉一個仍然能夠正常運行，這里就要保證服務應用的無狀態性。
確保數據中心能在地理上隔離，實現異地多活容災，實現三城兩地式物理布署，即使一個城市停電仍可提供數據的正常訪問。
有一套發布回滾機制，確保發布異常時能回滾到上一個版本，同時可追蹤到異常。
在架構設計之初就構建監控平臺，無監控無疑相當于系統在裸奔，后面擴容無數據支撐、BUG查找，異常追蹤都無從淡起。
不斷小試錯，而不是像傳統項目開發周期達一年，在時間就是生命的時代，產品上線黃花菜都涼了。
任務自動化，機器能夠做就讓程序自動跑，減少人力運維。
實現故障隔離，自動保護機制，防止一個服務拖垮整個系統平臺，進行健壯性分析。
……
所有的設計都是為了高可用，易擴展、高并發下出現異常更容易恢復，降低異常對業務的影響，這就是微服務架構設計的理念，但不完全，有些還是依靠架構師的經驗結合自己公司的業務特點來思考，并不是適合所有的公司，傳統公司進行微服務化的困難很大，但做得好收益也非常高。
做好業務的拆、合
微服務講究的是小 ，一個程序只做好一件事就夠了，因此需要對原有臃腫的系統拆分，對零散的功能進行合。
?一個業務場景一個服務
如用戶服務、授權服務、菜單服務、訂單服務……?這樣的粒度好處是更新用戶服務其它的服務可以不用更新。
一個數據庫對應一個服務
數據庫操作層封裝成一個服務，所有對這個數據庫的請求都要經過這個服務，而不用知道這個數據庫的密碼，而且可以進行流量權限等進行控制。
一個接口一個服務
這種架構很極端，會造成微服務數量成幾何數增長，維護難度極大。
適當的粒度優勢是服務能夠獨離部署，擴展方便，耦合度較小。
應用層我們可以結合上面的方法從下往上分析，對所有服務抽像化后抽出基礎功能封成服務，這樣公共服務就行成了，而且可以互相引用。
這樣就形成了基礎服務，是一些基礎組件，與具體的業務無關。比如：短信服務、郵件服務。這里的服務最容易摘出來做微服務，也是我們第一優先級分離出來的服務。
還有些是業務服務，是一些垂直的業務系統，只處理單一的業務類型如：風控系統、積分系統、合同系統。這類服務職責比較單一，根據業務情況來選擇是否遷移，比如：如果突然有需求對積分系統進行大優化，我們就趁機將積分系統進行改造，是我們的第二優先級分離出來的服務。
前端服務，一般為服務的接入或者輸出服務，比如網站的前端服務、app 的服務接口這類，這是我們第三優先級分離出來的服務。
組合服務，組合服務就是涉及到了具體的業務，比如網購過程，需要調用很多垂直的業務服務，這類的服務我們一般放到最后再進行微服務化架構來改造，因為這類服務最為復雜，除非涉及到大的業務邏輯變更，我們是不會輕易進行遷移。
獨立數據庫
數據層都是獨立的數據庫，即一個數據庫對應一個服務，這里需要對數據庫層進行縱向切分，即原來一個表現在對應多個表分片保存。
給數據庫帶來的挑戰
每個微服務都有自己獨立的數據庫，那么后臺管理的聯合查詢怎么處理?
有如下三種處理方案：
嚴格按照微服務的劃分來做，微服務相互獨立，各微服務數據庫也獨立，后臺需要展示數據時，調用各微服務的接口來獲取對應的數據，再進行數據處理后展示出來，這是標準的用法，也是最麻煩的用法。
?將業務相關的表放到一個庫中，將業務無關的表嚴格按照微服務模式來拆分，這樣既可以使用微服務，也避免了數據庫各種切換導致后臺統計難以實現，是一個折中的方案。
數據庫嚴格按照微服務的要求來切分，以滿足業務高并發，實時或者準實時將各微服務數據庫數據同步到 NoSQL 數據庫中，在同步的過程中進行數據清洗，用來滿足后臺業務系統的使用，推薦使用 Mongodb、Hbase 等。
拆分過后落地架構
在確定使用Spring Boot / Cloud 這套技術棧進行微服務改造之前，請先梳理平臺的服務，對不同的服務進行分類，以確認演化的節奏。
先讓團隊熟悉 Spring Boot 技術，并且優先在基礎服務上進行技術改造，推動改動后的項目投產上線。
當團隊熟悉 Spring Boot 之后，再推進使用 Spring Cloud 對原有的項目進行改造。
在進行微服務改造過程中，優先應用于新業務系統，前期可以只是少量的項目進行了微服務化改造，隨著大家對技術的熟悉度增加，可以加快加大微服務改造的范圍。
傳統項目和微服務項目共存是一個很常見的情況，除非公司業務有大的變化，前期不建議直接遷移核心項目，先搭建一個微服務架構，然后先接入新業務，后面再將老項目逐個改造，這里有個問題就是統一配置，統一規則，如日志，接口，文檔，代碼風格，公共類庫?版本等等提前規范。
以上只是個拆分建議，傳統項目到微服務轉化首先是思想上的轉變就是很困難的，然后有些方法也不能套大公司的，只能是趨向大原則，根據自己的業務量，人力?時間等來改造。
