很多傳統(tǒng)企業(yè)看著互聯(lián)網(wǎng)公司都進行著微服務化躁劣，因此也想享受微服務化帶來的好處便對自己的系統(tǒng)進行改造甲献，但微服務化?多“微”才是最優(yōu)闲延？有哪些拆分的原則端壳？
架構(gòu)原則
使用成熟的技術(shù)告丢，不需要最先進最好的技術(shù)，要是自己人能夠掌控的损谦，不然出現(xiàn)莫名的問題芋齿，一兩天都可能解決不了，你就等著被拿來“祭天”吧成翩。
至少有一個冗余的實例，可水平擴展赦役，確保一個實用多個負載麻敌，掛掉一個仍然能夠正常運行，這里就要保證服務應用的無狀態(tài)性掂摔。
確保數(shù)據(jù)中心能在地理上隔離术羔，實現(xiàn)異地多活容災，實現(xiàn)三城兩地式物理布署乙漓，即使一個城市停電仍可提供數(shù)據(jù)的正常訪問级历。
有一套發(fā)布回滾機制，確保發(fā)布異常時能回滾到上一個版本叭披，同時可追蹤到異常寥殖。
在架構(gòu)設計之初就構(gòu)建監(jiān)控平臺，無監(jiān)控無疑相當于系統(tǒng)在裸奔，后面擴容無數(shù)據(jù)支撐嚼贡、BUG查找熏纯，異常追蹤都無從淡起。
不斷小試錯粤策，而不是像傳統(tǒng)項目開發(fā)周期達一年樟澜，在時間就是生命的時代，產(chǎn)品上線黃花菜都涼了叮盘。
任務自動化秩贰，機器能夠做就讓程序自動跑，減少人力運維柔吼。
實現(xiàn)故障隔離毒费，自動保護機制，防止一個服務拖垮整個系統(tǒng)平臺嚷堡，進行健壯性分析蝗罗。
……
所有的設計都是為了高可用，易擴展蝌戒、高并發(fā)下出現(xiàn)異常更容易恢復串塑，降低異常對業(yè)務的影響，這就是微服務架構(gòu)設計的理念北苟，但不完全桩匪，有些還是依靠架構(gòu)師的經(jīng)驗結(jié)合自己公司的業(yè)務特點來思考，并不是適合所有的公司友鼻，傳統(tǒng)公司進行微服務化的困難很大傻昙，但做得好收益也非常高。
做好業(yè)務的拆彩扔、合
微服務講究的是小 妆档，一個程序只做好一件事就夠了，因此需要對原有臃腫的系統(tǒng)拆分虫碉，對零散的功能進行合贾惦。
?一個業(yè)務場景一個服務
如用戶服務、授權(quán)服務敦捧、菜單服務须板、訂單服務……?這樣的粒度好處是更新用戶服務其它的服務可以不用更新。
一個數(shù)據(jù)庫對應一個服務
數(shù)據(jù)庫操作層封裝成一個服務兢卵，所有對這個數(shù)據(jù)庫的請求都要經(jīng)過這個服務习瑰，而不用知道這個數(shù)據(jù)庫的密碼，而且可以進行流量權(quán)限等進行控制秽荤。
一個接口一個服務
這種架構(gòu)很極端甜奄，會造成微服務數(shù)量成幾何數(shù)增長柠横，維護難度極大。
適當?shù)牧６葍?yōu)勢是服務能夠獨離部署贺嫂，擴展方便滓鸠，耦合度較小。
應用層我們可以結(jié)合上面的方法從下往上分析第喳，對所有服務抽像化后抽出基礎功能封成服務糜俗，這樣公共服務就行成了，而且可以互相引用曲饱。
這樣就形成了基礎服務悠抹，是一些基礎組件，與具體的業(yè)務無關扩淀。比如：短信服務楔敌、郵件服務。這里的服務最容易摘出來做微服務驻谆，也是我們第一優(yōu)先級分離出來的服務卵凑。
還有些是業(yè)務服務，是一些垂直的業(yè)務系統(tǒng)胜臊，只處理單一的業(yè)務類型如：風控系統(tǒng)勺卢、積分系統(tǒng)、合同系統(tǒng)象对。這類服務職責比較單一黑忱，根據(jù)業(yè)務情況來選擇是否遷移，比如：如果突然有需求對積分系統(tǒng)進行大優(yōu)化勒魔，我們就趁機將積分系統(tǒng)進行改造甫煞，是我們的第二優(yōu)先級分離出來的服務。
前端服務冠绢，一般為服務的接入或者輸出服務抚吠，比如網(wǎng)站的前端服務、app 的服務接口這類弟胀，這是我們第三優(yōu)先級分離出來的服務埃跷。
組合服務，組合服務就是涉及到了具體的業(yè)務邮利，比如網(wǎng)購過程，需要調(diào)用很多垂直的業(yè)務服務垃帅，這類的服務我們一般放到最后再進行微服務化架構(gòu)來改造延届，因為這類服務最為復雜，除非涉及到大的業(yè)務邏輯變更贸诚，我們是不會輕易進行遷移方庭。
獨立數(shù)據(jù)庫
數(shù)據(jù)層都是獨立的數(shù)據(jù)庫厕吉，即一個數(shù)據(jù)庫對應一個服務，這里需要對數(shù)據(jù)庫層進行縱向切分械念，即原來一個表現(xiàn)在對應多個表分片保存头朱。
給數(shù)據(jù)庫帶來的挑戰(zhàn)
每個微服務都有自己獨立的數(shù)據(jù)庫，那么后臺管理的聯(lián)合查詢怎么處理?
有如下三種處理方案：
嚴格按照微服務的劃分來做龄减，微服務相互獨立项钮，各微服務數(shù)據(jù)庫也獨立，后臺需要展示數(shù)據(jù)時希停，調(diào)用各微服務的接口來獲取對應的數(shù)據(jù)烁巫，再進行數(shù)據(jù)處理后展示出來，這是標準的用法宠能，也是最麻煩的用法亚隙。
?將業(yè)務相關的表放到一個庫中，將業(yè)務無關的表嚴格按照微服務模式來拆分违崇，這樣既可以使用微服務阿弃，也避免了數(shù)據(jù)庫各種切換導致后臺統(tǒng)計難以實現(xiàn)，是一個折中的方案羞延。
數(shù)據(jù)庫嚴格按照微服務的要求來切分渣淳，以滿足業(yè)務高并發(fā)樱拴，實時或者準實時將各微服務數(shù)據(jù)庫數(shù)據(jù)同步到 NoSQL 數(shù)據(jù)庫中速址，在同步的過程中進行數(shù)據(jù)清洗，用來滿足后臺業(yè)務系統(tǒng)的使用竖独，推薦使用 Mongodb赛蔫、Hbase 等砂客。
拆分過后落地架構(gòu)
在確定使用Spring Boot / Cloud 這套技術(shù)棧進行微服務改造之前，請先梳理平臺的服務呵恢，對不同的服務進行分類鞠值，以確認演化的節(jié)奏。
先讓團隊熟悉 Spring Boot 技術(shù)渗钉，并且優(yōu)先在基礎服務上進行技術(shù)改造彤恶，推動改動后的項目投產(chǎn)上線。
當團隊熟悉 Spring Boot 之后鳄橘，再推進使用 Spring Cloud 對原有的項目進行改造声离。
在進行微服務改造過程中，優(yōu)先應用于新業(yè)務系統(tǒng)瘫怜，前期可以只是少量的項目進行了微服務化改造术徊，隨著大家對技術(shù)的熟悉度增加，可以加快加大微服務改造的范圍鲸湃。
傳統(tǒng)項目和微服務項目共存是一個很常見的情況赠涮，除非公司業(yè)務有大的變化子寓，前期不建議直接遷移核心項目，先搭建一個微服務架構(gòu)笋除，然后先接入新業(yè)務斜友，后面再將老項目逐個改造，這里有個問題就是統(tǒng)一配置垃它，統(tǒng)一規(guī)則鲜屏，如日志，接口嗤瞎，文檔墙歪，代碼風格，公共類庫?版本等等提前規(guī)范贝奇。
以上只是個拆分建議虹菲，傳統(tǒng)項目到微服務轉(zhuǎn)化首先是思想上的轉(zhuǎn)變就是很困難的，然后有些方法也不能套大公司的掉瞳，只能是趨向大原則毕源，根據(jù)自己的業(yè)務量，人力?時間等來改造陕习。
