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