1 寫在前面
背景
技術(shù)圈流行一句話镇防，凡脫離業(yè)務(wù)談架構(gòu)的，都是耍流氓瞒津。作為微服務(wù)改造系列的第一篇博客蝉衣，首先介紹一下實(shí)施這次技術(shù)改造的背景。
第一巷蚪，我所在公司（簡稱XR）的后臺服務(wù)采用的主技術(shù)棧是Scala病毡，雖然開發(fā)效率很高，但也帶來一系列的副作用屁柏。1.由于Scala語言強(qiáng)大的表達(dá)能力和豐富的函數(shù)式特性啦膜，很容易寫出俗稱“意大利面條”式的代碼，一個類文件動輒上千行淌喻，代碼的可讀性非常差僧家，導(dǎo)致可維護(hù)性也很差。2.編譯Scala源碼時首先需要將Scala源碼轉(zhuǎn)換成Java源碼然后再通過JVM進(jìn)行編譯裸删，加上隱式類型的存在進(jìn)一步拖慢了編譯期間的類型推導(dǎo)八拱，Scala的編譯速度比Java足足慢了一個數(shù)量級，這個差異在代碼量少的時候還不明顯，但隨著代碼量的上升肌稻，就成了團(tuán)隊(duì)的一個nightmare清蚀，試想本地全量編譯一次需要10+分鐘。3.Scala小眾語言的標(biāo)簽決定了Scala程序員的稀缺性爹谭，晦澀難懂的官方文檔拔高了學(xué)習(xí)曲線枷邪，后果就是高昂的招聘成本和漫長的培養(yǎng)時間。以上這些副作用不但抵消了先期開發(fā)效率上的優(yōu)勢诺凡，而且使得對新需求的響應(yīng)能力越來越慢东揣，技術(shù)負(fù)債也越壘越高。
第二绑洛，歷經(jīng)2年多的產(chǎn)品迭代救斑，整個后臺服務(wù)項(xiàng)目越來越龐大，已經(jīng)成為一個典型意義上的單體應(yīng)用（也就是Martin Fowler常說的monolithic application）：1.各個業(yè)務(wù)模塊犬牙交錯真屯，重復(fù)代碼隨處可見脸候，補(bǔ)丁代碼越打越多。2.任何一個改動都需要一次全量發(fā)布绑蔫，哪怕是修改一句文案运沦。
第三，與微服務(wù)化改造同時進(jìn)行的是容器化改造配深，如果不對上述單體應(yīng)用進(jìn)行拆分携添，很多容器化帶來的好處就會被削弱，甚至毫無意義篓叶，比如提高資源利用率（CPU型應(yīng)用和內(nèi)存型應(yīng)用搭配部署）烈掠，異構(gòu)應(yīng)用的環(huán)境隔離能力等。
局限
谷歌前研發(fā)總監(jiān)Tiger曾經(jīng)說過缸托，一個系統(tǒng)的演化一般會經(jīng)歷三個階段左敌，首先是under-engineer，然后是over-engineer俐镐，最后才是right-engineer矫限。考慮到參與此次微服務(wù)改造的人員有限（一人主導(dǎo)佩抹，多人配合）叼风，同時也是團(tuán)隊(duì)第一次嘗試做這類系統(tǒng)性的改造，最后我們決定采取一條比較實(shí)用的改良式路線：
- 最小化對已有應(yīng)用的侵入性
- 偏好主流的微服務(wù)框架
- 只做必要的微服務(wù)治理
第一條定下了此次改造的基調(diào)棍苹，降低了方案無法落地的風(fēng)險无宿，確保了項(xiàng)目的整體可行性。第二條讓我們站在巨人的肩膀上廊勃，不重復(fù)造輪子懈贺，聚焦在問題本身经窖，而不是工具。第三條縮減項(xiàng)目范圍梭灿，避免過度工程画侣，以戰(zhàn)養(yǎng)兵，不打無用之仗。
2 微服務(wù)簡介
3個關(guān)鍵詞
有關(guān)微服務(wù)的定義，最權(quán)威的版本莫屬微服務(wù)之父Martin Fowler在microservices一文中所述：
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. -- James Lewis and Martin Fowler
注意其中有3個關(guān)鍵詞晒夹，small紧唱，independently deployable和automated deployment财喳。small對應(yīng)的就是微服務(wù)的微，很多初次接觸微服務(wù)的同學(xué)對微的理解往往會停留在實(shí)現(xiàn)層面，以為代碼少就是微，但實(shí)際上忿檩，這里的微更多的是體現(xiàn)在邏輯層面。微服務(wù)的一個重要設(shè)計原則是share as little as possible爆阶，什么意思呢燥透？就是說每個微服務(wù)應(yīng)該設(shè)計成邊界清晰不重疊，數(shù)據(jù)獨(dú)享不共享辨图，也就是我們常說的高內(nèi)聚班套、低耦合。保證了small故河，才能做到independently deployable吱韭。而實(shí)現(xiàn)automated deployment的關(guān)鍵是DevOps文化，可參見Fowler另一篇談DevOps的文章鱼的。
需要提醒的是理盆，隨著業(yè)務(wù)復(fù)雜度的上升，一個微服務(wù)可能需要拆分為更多更細(xì)粒度的微服務(wù)凑阶，比方說熏挎，一開始只是一個簡單的訂單服務(wù)，后面逐步拆分出清算晌砾，支付，結(jié)算烦磁，對賬等其他服務(wù)养匈。
康威定律
與單體應(yīng)用拆分為微服務(wù)的過程類似，隨著公司規(guī)模的不斷擴(kuò)大都伪，一個組織勢必會分化出多個更小的組織呕乎。根據(jù)康威定律，組織結(jié)構(gòu)決定系統(tǒng)結(jié)構(gòu)陨晶，因此猬仁，從這個層面來說帝璧，微服務(wù)也是一種必然。
康威定律（Conway’s Law）：“Any organization that design a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. - Melvin Conway, 1968
取舍
從本質(zhì)上來看湿刽，相對單體應(yīng)用的烁，微服務(wù)是以犧牲強(qiáng)一致性、提高部署復(fù)雜性為代價诈闺，換取更徹底的分布式特性渴庆，比如異構(gòu)性和強(qiáng)隔離性。對應(yīng)CAP理論雅镊，就是用Consistency換Partition襟雷。異構(gòu)性比較容易理解，通過定義統(tǒng)一的API規(guī)范（一般采用REST風(fēng)格）仁烹，每個微服務(wù)團(tuán)隊(duì)可以根據(jù)各自的能力矩陣選用最適合的技術(shù)棧耸弄，而不是所有人必須使用相同的技術(shù)棧。強(qiáng)隔離性指的是卓缰，對于一個典型的單體應(yīng)用计呈，隔離性最高只能體現(xiàn)到模塊級別，由于共享同一個代碼倉庫僚饭，模塊的邊界往往比較模糊震叮，需要人為定義很多規(guī)范來保證良好的隔離性，但無論如何強(qiáng)調(diào)鳍鸵，稍一疏忽苇瓣，就會產(chǎn)生“越界”行為，時間愈長偿乖，維護(hù)隔離性的成本愈高击罪。而到了微服務(wù)階段，自帶應(yīng)用級別的隔離性贪薪，“越界”的成本大大提升媳禁，無需任何規(guī)范，架構(gòu)本身就保證了隔離性画切。
另一方面竣稽，由于采用了分布式架構(gòu)，微服務(wù)無法再簡單的通過數(shù)據(jù)庫事務(wù)來保證強(qiáng)一致性霍弹，而是通過消息中間件或者某種事務(wù)補(bǔ)償機(jī)制來保證最終一致性毫别，比如微信朋友圈的點(diǎn)贊，淘寶訂單的物流狀態(tài)典格。其次岛宦，在微服務(wù)階段，隨著應(yīng)用數(shù)量的激增耍缴，一次發(fā)布往往涉及多個應(yīng)用砾肺，加上異構(gòu)性帶來的部署方式的多樣性挽霉，對團(tuán)隊(duì)的運(yùn)維水平尤其是自動化水平提出了更高的要求，運(yùn)維和開發(fā)的邊界進(jìn)一步模糊变汪。
領(lǐng)域知識
除了組織架構(gòu)和技術(shù)取舍侠坎，領(lǐng)域知識是另一個非常重要的決策因素。對于不熟悉的業(yè)務(wù)領(lǐng)域疫衩，很難第一次就把各個微服務(wù)的邊界和接口定義正確硅蹦，一旦開始開發(fā)，重構(gòu)成本就會非趁泼海可觀童芹。反過來說，當(dāng)對領(lǐng)域知識有了一定的積累鲤拿，再重構(gòu)一個單體應(yīng)用就會容易的多假褪。
小結(jié)
綜上所述，雖然微服務(wù)看上去很美近顷，但在決定采用微服務(wù)架構(gòu)之前生音，不僅要仔細(xì)考量團(tuán)隊(duì)的技術(shù)水平（包括知識結(jié)構(gòu)，理論深度窒升，經(jīng)驗(yàn)積累和技術(shù)氛圍）缀遍，還應(yīng)綜合考慮項(xiàng)目的時間范圍，領(lǐng)域知識的熟悉程度饱须，以及所在組織的規(guī)模架構(gòu)域醇。除非這些前提條件都滿足，否則單體應(yīng)用是更適合的選擇蓉媳，就像Fowler建議的那樣譬挚。
3 微服務(wù)化總覽
上圖是XR微服務(wù)化第一階段的整體架構(gòu)圖±疑耄可以看到减宣，一些支撐微服務(wù)的必要組件都已包含其中：
- 服務(wù)注冊中心：所有服務(wù)注冊到Consul集群，集成Nginx實(shí)現(xiàn)負(fù)載均衡玩荠，使用Hystrix實(shí)現(xiàn)簡單的服務(wù)降級和熔斷機(jī)制
- CI/CD：利用Jenkins Pipeline實(shí)現(xiàn)不停機(jī)發(fā)布
- 日志平臺：擴(kuò)展ELK加上Redis緩存
- 配置中心：使用自研的Matrix系統(tǒng)漆腌，最小化對已有應(yīng)用的侵入性，保證異構(gòu)系統(tǒng)的兼容性
- 授權(quán)中心：基于Spring Security OAuth阶冈，同時支持SSO
- 消息中心：選用RabbitMQ作為消息中間件
- 監(jiān)控平臺：利用Consul API獲取服務(wù)狀態(tài)屉凯，通過Zookeeper觸發(fā)告警
在微服務(wù)化系列的后續(xù)文章中，我會針對服務(wù)注冊眼溶、配置中心和授權(quán)中心分別展開介紹實(shí)施過程中的一些細(xì)節(jié)和經(jīng)驗(yàn)。敬請期待晓勇。
