很多傳統(tǒng)企業(yè)看著互聯(lián)網(wǎng)公司都進(jìn)行著微服務(wù)化，因此也想享受微服務(wù)化帶來(lái)的好處便對(duì)自己的系統(tǒng)進(jìn)行改造，但微服務(wù)化?多“微”才是最優(yōu)？有哪些拆分的原則？

架構(gòu)原則

使用成熟的技術(shù)，不需要最先進(jìn)最好的技術(shù)，要是自己人能夠掌控的，不然出現(xiàn)莫名的問(wèn)題，一兩天都可能解決不了，你就等著被拿來(lái)“祭天”吧。

至少有一個(gè)冗余的實(shí)例，可水平擴(kuò)展，確保一個(gè)實(shí)用多個(gè)負(fù)載，掛掉一個(gè)仍然能夠正常運(yùn)行，這里就要保證服務(wù)應(yīng)用的無(wú)狀態(tài)性。

確保數(shù)據(jù)中心能在地理上隔離，實(shí)現(xiàn)異地多活容災(zāi)，實(shí)現(xiàn)三城兩地式物理布署，即使一個(gè)城市停電仍可提供數(shù)據(jù)的正常訪問(wèn)。

有一套發(fā)布回滾機(jī)制，確保發(fā)布異常時(shí)能回滾到上一個(gè)版本，同時(shí)可追蹤到異常。

在架構(gòu)設(shè)計(jì)之初就構(gòu)建監(jiān)控平臺(tái)，無(wú)監(jiān)控?zé)o疑相當(dāng)于系統(tǒng)在裸奔，后面擴(kuò)容無(wú)數(shù)據(jù)支撐、BUG查找，異常追蹤都無(wú)從淡起。

不斷小試錯(cuò)，而不是像傳統(tǒng)項(xiàng)目開(kāi)發(fā)周期達(dá)一年，在時(shí)間就是生命的時(shí)代，產(chǎn)品上線黃花菜都涼了。

任務(wù)自動(dòng)化，機(jī)器能夠做就讓程序自動(dòng)跑，減少人力運(yùn)維。

實(shí)現(xiàn)故障隔離，自動(dòng)保護(hù)機(jī)制，防止一個(gè)服務(wù)拖垮整個(gè)系統(tǒng)平臺(tái)，進(jìn)行健壯性分析。

……

　　所有的設(shè)計(jì)都是為了高可用，易擴(kuò)展、高并發(fā)下出現(xiàn)異常更容易恢復(fù)，降低異常對(duì)業(yè)務(wù)的影響，這就是微服務(wù)架構(gòu)設(shè)計(jì)的理念，但不完全，有些還是依靠架構(gòu)師的經(jīng)驗(yàn)結(jié)合自己公司的業(yè)務(wù)特點(diǎn)來(lái)思考，并不是適合所有的公司，傳統(tǒng)公司進(jìn)行微服務(wù)化的困難很大，但做得好收益也非常高。

做好業(yè)務(wù)的拆、合

　　微服務(wù)講究的是小 ，一個(gè)程序只做好一件事就夠了，因此需要對(duì)原有臃腫的系統(tǒng)拆分，對(duì)零散的功能進(jìn)行合。

?一個(gè)業(yè)務(wù)場(chǎng)景一個(gè)服務(wù)

　　如用戶服務(wù)、授權(quán)服務(wù)、菜單服務(wù)、訂單服務(wù)……?這樣的粒度好處是更新用戶服務(wù)其它的服務(wù)可以不用更新。

一個(gè)數(shù)據(jù)庫(kù)對(duì)應(yīng)一個(gè)服務(wù)

　　數(shù)據(jù)庫(kù)操作層封裝成一個(gè)服務(wù)，所有對(duì)這個(gè)數(shù)據(jù)庫(kù)的請(qǐng)求都要經(jīng)過(guò)這個(gè)服務(wù)，而不用知道這個(gè)數(shù)據(jù)庫(kù)的密碼，而且可以進(jìn)行流量權(quán)限等進(jìn)行控制。

一個(gè)接口一個(gè)服務(wù)

　　這種架構(gòu)很極端，會(huì)造成微服務(wù)數(shù)量成幾何數(shù)增長(zhǎng)，維護(hù)難度極大。

　　適當(dāng)?shù)牧６葍?yōu)勢(shì)是服務(wù)能夠獨(dú)離部署，擴(kuò)展方便，耦合度較小。

　　應(yīng)用層我們可以結(jié)合上面的方法從下往上分析，對(duì)所有服務(wù)抽像化后抽出基礎(chǔ)功能封成服務(wù)，這樣公共服務(wù)就行成了，而且可以互相引用。

　　這樣就形成了基礎(chǔ)服務(wù)，是一些基礎(chǔ)組件，與具體的業(yè)務(wù)無(wú)關(guān)。比如：短信服務(wù)、郵件服務(wù)。這里的服務(wù)最容易摘出來(lái)做微服務(wù)，也是我們第一優(yōu)先級(jí)分離出來(lái)的服務(wù)。

還有些是業(yè)務(wù)服務(wù)，是一些垂直的業(yè)務(wù)系統(tǒng)，只處理單一的業(yè)務(wù)類型如：風(fēng)控系統(tǒng)、積分系統(tǒng)、合同系統(tǒng)。這類服務(wù)職責(zé)比較單一，根據(jù)業(yè)務(wù)情況來(lái)選擇是否遷移，比如：如果突然有需求對(duì)積分系統(tǒng)進(jìn)行大優(yōu)化，我們就趁機(jī)將積分系統(tǒng)進(jìn)行改造，是我們的第二優(yōu)先級(jí)分離出來(lái)的服務(wù)。

前端服務(wù)，一般為服務(wù)的接入或者輸出服務(wù)，比如網(wǎng)站的前端服務(wù)、app 的服務(wù)接口這類，這是我們第三優(yōu)先級(jí)分離出來(lái)的服務(wù)。

組合服務(wù)，組合服務(wù)就是涉及到了具體的業(yè)務(wù)，比如網(wǎng)購(gòu)過(guò)程，需要調(diào)用很多垂直的業(yè)務(wù)服務(wù)，這類的服務(wù)我們一般放到最后再進(jìn)行微服務(wù)化架構(gòu)來(lái)改造，因?yàn)檫@類服務(wù)最為復(fù)雜，除非涉及到大的業(yè)務(wù)邏輯變更，我們是不會(huì)輕易進(jìn)行遷移。

獨(dú)立數(shù)據(jù)庫(kù)

　　數(shù)據(jù)層都是獨(dú)立的數(shù)據(jù)庫(kù)，即一個(gè)數(shù)據(jù)庫(kù)對(duì)應(yīng)一個(gè)服務(wù)，這里需要對(duì)數(shù)據(jù)庫(kù)層進(jìn)行縱向切分，即原來(lái)一個(gè)表現(xiàn)在對(duì)應(yīng)多個(gè)表分片保存。

給數(shù)據(jù)庫(kù)帶來(lái)的挑戰(zhàn)

　　每個(gè)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫(kù)，那么后臺(tái)管理的聯(lián)合查詢?cè)趺刺幚?

有如下三種處理方案：

嚴(yán)格按照微服務(wù)的劃分來(lái)做，微服務(wù)相互獨(dú)立，各微服務(wù)數(shù)據(jù)庫(kù)也獨(dú)立，后臺(tái)需要展示數(shù)據(jù)時(shí)，調(diào)用各微服務(wù)的接口來(lái)獲取對(duì)應(yīng)的數(shù)據(jù)，再進(jìn)行數(shù)據(jù)處理后展示出來(lái)，這是標(biāo)準(zhǔn)的用法，也是最麻煩的用法。

?將業(yè)務(wù)相關(guān)的表放到一個(gè)庫(kù)中，將業(yè)務(wù)無(wú)關(guān)的表嚴(yán)格按照微服務(wù)模式來(lái)拆分，這樣既可以使用微服務(wù)，也避免了數(shù)據(jù)庫(kù)各種切換導(dǎo)致后臺(tái)統(tǒng)計(jì)難以實(shí)現(xiàn)，是一個(gè)折中的方案。

數(shù)據(jù)庫(kù)嚴(yán)格按照微服務(wù)的要求來(lái)切分，以滿足業(yè)務(wù)高并發(fā)，實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)將各微服務(wù)數(shù)據(jù)庫(kù)數(shù)據(jù)同步到 NoSQL 數(shù)據(jù)庫(kù)中，在同步的過(guò)程中進(jìn)行數(shù)據(jù)清洗，用來(lái)滿足后臺(tái)業(yè)務(wù)系統(tǒng)的使用，推薦使用 Mongodb、Hbase 等。

拆分過(guò)后落地架構(gòu)

在確定使用Spring Boot / Cloud 這套技術(shù)棧進(jìn)行微服務(wù)改造之前，請(qǐng)先梳理平臺(tái)的服務(wù)，對(duì)不同的服務(wù)進(jìn)行分類，以確認(rèn)演化的節(jié)奏。

先讓團(tuán)隊(duì)熟悉 Spring Boot 技術(shù)，并且優(yōu)先在基礎(chǔ)服務(wù)上進(jìn)行技術(shù)改造，推動(dòng)改動(dòng)后的項(xiàng)目投產(chǎn)上線。

當(dāng)團(tuán)隊(duì)熟悉 Spring Boot 之后，再推進(jìn)使用 Spring Cloud 對(duì)原有的項(xiàng)目進(jìn)行改造。

在進(jìn)行微服務(wù)改造過(guò)程中，優(yōu)先應(yīng)用于新業(yè)務(wù)系統(tǒng)，前期可以只是少量的項(xiàng)目進(jìn)行了微服務(wù)化改造，隨著大家對(duì)技術(shù)的熟悉度增加，可以加快加大微服務(wù)改造的范圍。

傳統(tǒng)項(xiàng)目和微服務(wù)項(xiàng)目共存是一個(gè)很常見(jiàn)的情況，除非公司業(yè)務(wù)有大的變化，前期不建議直接遷移核心項(xiàng)目，先搭建一個(gè)微服務(wù)架構(gòu)，然后先接入新業(yè)務(wù)，后面再將老項(xiàng)目逐個(gè)改造，這里有個(gè)問(wèn)題就是統(tǒng)一配置，統(tǒng)一規(guī)則，如日志，接口，文檔，代碼風(fēng)格，公共類庫(kù)?版本等等提前規(guī)范。

　　以上只是個(gè)拆分建議，傳統(tǒng)項(xiàng)目到微服務(wù)轉(zhuǎn)化首先是思想上的轉(zhuǎn)變就是很困難的，然后有些方法也不能套大公司的，只能是趨向大原則，根據(jù)自己的業(yè)務(wù)量，人力?時(shí)間等來(lái)改造。