“微服務(wù)”的概念興起于四五年前晌姚，近幾年尤其火熱粤剧，各大廠都在進(jìn)行微服務(wù)化改造和微服務(wù)建設(shè)。最近一年來我們也參與了微服務(wù)化的改造大軍挥唠，這里寫下一些做微服務(wù)系統(tǒng)設(shè)計和開發(fā)時的切身感受抵恋。
01 微服務(wù)架構(gòu)
說起微服務(wù)，不得不提那篇經(jīng)典的文章宝磨，來自Martin Flower的《Microservices》弧关，建議多讀幾遍。Martin Flower是敏捷開發(fā)方法創(chuàng)始人之一唤锉，《重構(gòu)》《企業(yè)應(yīng)用架構(gòu)模式》作者世囊，ThoughtWorks公司的首席科學(xué)家。微服務(wù)雖然不是在這篇文章中首次提出窿祥，但是它將發(fā)展多年的微服務(wù)架構(gòu)進(jìn)行了重要性總結(jié)株憾，推動了微服務(wù)的流行。
Martin在文章中從多個方面詳細(xì)闡述了微服務(wù)的概念晒衩，首先作者對比單體應(yīng)用的架構(gòu)嗤瞎，一個單體應(yīng)用處理請求的所有邏輯都運(yùn)行在一個單獨(dú)的進(jìn)程中，這種情況下浸遗，你可以在筆記本上開發(fā)、測試箱亿、部署都很簡單跛锌，還可以通過負(fù)載均衡進(jìn)行橫向擴(kuò)展，最后交付給運(yùn)維團(tuán)隊。單體應(yīng)用非常成功髓帽，但是越來越多的人感覺不妥菠赚，尤其是在云中部署的時候，任何微小的變更都要整體重新構(gòu)建和部署郑藏，擴(kuò)展的時候也需要整體擴(kuò)展衡查，不能進(jìn)行部分?jǐn)U展。這時候微服務(wù)架構(gòu)風(fēng)格就出現(xiàn)了必盖，它提出將應(yīng)用程序構(gòu)建為一套服務(wù)拌牲，每個服務(wù)都可以獨(dú)立部署和擴(kuò)展，運(yùn)行在獨(dú)立的進(jìn)程中歌粥，服務(wù)之間通過RPC調(diào)用進(jìn)行通信塌忽。微服務(wù)的應(yīng)用致力于松耦合和高內(nèi)聚：采用單獨(dú)的業(yè)務(wù)邏輯封裝，接受請求失驶、處理業(yè)務(wù)邏輯土居、返回響應(yīng)，而且喜歡簡單的REST風(fēng)格嬉探，而不喜歡復(fù)雜的協(xié)議擦耀，最終實現(xiàn)敏捷開發(fā)。
微服務(wù)不是什么框架涩堤，也不是什么系統(tǒng)眷蜓，只是一種架構(gòu)風(fēng)格。我們所使用的DSF（華為）定躏、DUBBO（阿里）账磺、Spring Clould（pivotal）等框架，在介紹中都稱是分布式服務(wù)框架痊远。這些分布式服務(wù)框架都是微服務(wù)架構(gòu)必不可少的基礎(chǔ)能力垮抗，微服務(wù)一定是分布式的。分布式服務(wù)的概念比較模糊碧聪，只是解決了網(wǎng)站的高并發(fā)問題冒版，很多細(xì)節(jié)問題是微服務(wù)幫其明確的。微服務(wù)更加強(qiáng)調(diào)敏捷和健壯逞姿，強(qiáng)調(diào)服務(wù)的粒度辞嗡，一個服務(wù)只需完成一個單一的、獨(dú)立的功能滞造，多個微服務(wù)組合完成相對復(fù)雜的業(yè)務(wù)系統(tǒng)续室，以滿足需求。而且微服務(wù)注重借助于各種中間件進(jìn)行業(yè)務(wù)解耦和提高性能谒养，以及提高服務(wù)的容錯性挺狰。
從上面的介紹中我們可以看出，微服務(wù)架構(gòu)有很多優(yōu)點(diǎn)。例如丰泊，服務(wù)的拆分將復(fù)雜問題簡單化薯定；每個服務(wù)由專門的團(tuán)隊開發(fā)，開發(fā)者可以自由選擇實現(xiàn)技術(shù)瞳购，提供API服務(wù)话侄；每個微服務(wù)都可獨(dú)立部署，加快了部署速度学赛；每個服務(wù)可獨(dú)立擴(kuò)展以滿足需求年堆。微服務(wù)不是免費(fèi)的午餐，微服務(wù)架構(gòu)也有缺點(diǎn)罢屈。微服務(wù)概念強(qiáng)調(diào)了服務(wù)的大小嘀韧，但是服務(wù)變小不是最終目的，微服務(wù)的目的是有效地拆分應(yīng)用缠捌，實現(xiàn)敏捷開發(fā)和部署锄贷；微服務(wù)應(yīng)用都是分布式系統(tǒng)，需要通過RPC進(jìn)程間通信完成服務(wù)調(diào)用曼月，這樣大大增加了系統(tǒng)的復(fù)雜性谊却，因此必須寫代碼處理由于網(wǎng)絡(luò)或者服務(wù)不可用等導(dǎo)致的調(diào)用失敗問題，雖然一般框架都支持相關(guān)配置哑芹，但是在這種情況下微服務(wù)顯得相對復(fù)雜些炎辨；在微服務(wù)架構(gòu)的應(yīng)用中，建議不同的服務(wù)使用不同的數(shù)據(jù)庫聪姿，這種情況下碴萧，一個交易一般會調(diào)用多個服務(wù)，同時需要修改多個數(shù)據(jù)庫末购，由于CAP理論和其它的一些因素破喻，并不能實時地保證數(shù)據(jù)的一致性，因此不得不使用最終一致性的方法盟榴，從而對開發(fā)者提出了更高的要求和挑戰(zhàn)曹质；測試一個微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)，首先需要啟動和它相關(guān)的所有服務(wù)（至少需要這些服務(wù)的stubs）擎场。最后還是要強(qiáng)調(diào)一下羽德，不要低估了微服務(wù)架構(gòu)帶來的復(fù)雜性，下面介紹一下我們?nèi)绾螒?yīng)對這樣的復(fù)雜性迅办。
微服務(wù)架構(gòu)給我們帶來方便的同時宅静，也引入一定的系統(tǒng)復(fù)雜性，最近幾年隨著基礎(chǔ)設(shè)施自動化技術(shù)的發(fā)展站欺，比如云平臺姨夹、容器技術(shù)究驴，再加上自動化測試與持續(xù)集成，減少了構(gòu)建匀伏、發(fā)布、運(yùn)維微服務(wù)的復(fù)雜性蝴韭。因此我們的微服務(wù)團(tuán)隊?wèi)?yīng)該依賴基礎(chǔ)設(shè)施自動化技術(shù)構(gòu)建軟件够颠，下圖說明這種構(gòu)建的流程：
在構(gòu)建微服務(wù)軟件時使用的分布式服務(wù)框架也擁有很多特性，這些特性提供了很多復(fù)雜問題的解決方案榄鉴，比如異步調(diào)用履磨、超時失敗策略、故障隔離庆尘、健康檢查剃诅、流量控制以及自定義路由等，這些特性大大減輕了開發(fā)者處理邏輯的負(fù)擔(dān)驶忌，還有一些高性能矛辕、高可用的保障都增加了我們構(gòu)建微服務(wù)的信心。而且經(jīng)過多年的微服務(wù)實踐者的摸索付魔，也總結(jié)出了很多輔助運(yùn)維系統(tǒng)聊品，比如統(tǒng)一日志收集（ELK）、服務(wù)管理几苍、服務(wù)監(jiān)控和服務(wù)治理等翻屈，大大減輕了運(yùn)維的工作，而且能讓我們對復(fù)雜的微服務(wù)系統(tǒng)做到心中有數(shù)妻坝。
總之伸眶，微服務(wù)架構(gòu)入坑容易，坑了呆得舒服難刽宪。各種基礎(chǔ)設(shè)施和配套系統(tǒng)必須跟得上厘贼，還得有一個具有微服務(wù)特性的團(tuán)隊，才能真正駕馭得了微服務(wù)纠屋。
兩個值得深入的話題：
1.微服務(wù)與持續(xù)集成
2.微服務(wù)與測試
02 微服務(wù)團(tuán)隊
上一節(jié)中說到更適合構(gòu)建微服務(wù)應(yīng)用的微服務(wù)團(tuán)隊涂臣，什么時微服務(wù)團(tuán)隊？說一個比較現(xiàn)實的問題售担，當(dāng)我們做服務(wù)拆分的時候赁遗，通常管理都會集中在技術(shù)層面，涉及到UI團(tuán)隊族铆、服務(wù)端業(yè)務(wù)邏輯團(tuán)隊岩四、數(shù)據(jù)庫團(tuán)隊、測試團(tuán)隊和運(yùn)維團(tuán)隊哥攘。當(dāng)采用這種標(biāo)準(zhǔn)對團(tuán)隊進(jìn)行劃分時剖煌，即使時小小的變更都將導(dǎo)致跨團(tuán)隊項目協(xié)作材鹦，從而消耗時間和預(yù)算審批。這就是 Conway's Law ：
設(shè)計一個系統(tǒng)的任何組織（廣義上）都會產(chǎn)生這樣一種設(shè)計耕姊，其結(jié)構(gòu)是組織交流結(jié)構(gòu)的復(fù)制桶唐。
——Melvyn Conway, 1967
Melvyn Conway 的意思是設(shè)計一個系統(tǒng)的團(tuán)隊結(jié)構(gòu)將決定了一個軟件系統(tǒng)的結(jié)構(gòu)，將人員劃分為 UI 團(tuán)隊茉兰，中間件團(tuán)隊尤泽，DBA 團(tuán)隊，那么相應(yīng)地规脸，軟件系統(tǒng)也就會自然地被劃分為 UI 界面坯约，中間件系統(tǒng)，數(shù)據(jù)庫莫鸭。而一個高效的微服務(wù)團(tuán)隊會針對這種情況進(jìn)行改善闹丐，微服務(wù)團(tuán)隊需要是一個全棧的團(tuán)隊，跨職能的團(tuán)隊被因，應(yīng)該包含整個項目周期的所有技能卿拴，前后端開發(fā)魂迄、UI設(shè)計技俐、測試、構(gòu)建部署黍少、上線與運(yùn)維都是必須技能蛋欣。
微服務(wù)團(tuán)隊除了熟練的業(yè)務(wù)邏輯開發(fā)之外航徙，還需要有DevOps能力、服務(wù)的快速構(gòu)建陷虎、良好的團(tuán)隊文化：
- 首先DevOps能力是保證持續(xù)交付和應(yīng)對復(fù)雜運(yùn)維問題的動力之源到踏，運(yùn)維人員不懂開發(fā)人員的服務(wù)設(shè)計和調(diào)用流程，開發(fā)人員不懂產(chǎn)品環(huán)境和整體配置結(jié)構(gòu)尚猿，開發(fā)和運(yùn)維的融合才能更好的應(yīng)對微服務(wù)架構(gòu)窝稿。正如下面這句話所說的，“你構(gòu)建凿掂，你運(yùn)維”伴榔。
You build it, you own it. – Amazon CTO
因此，需要打造DevOps文化庄萎，將運(yùn)維作為需求提前注入到開發(fā)流程中踪少。
其次保持服務(wù)的持續(xù)演進(jìn)，使服務(wù)能夠快速糠涛、低成本地被拆分和合并援奢，以快速響應(yīng)業(yè)務(wù)的變化。
同時要保持團(tuán)隊和架構(gòu)的對齊忍捡，微服務(wù)看似是技術(shù)層面的變革集漾，但它對團(tuán)隊結(jié)構(gòu)和組織文化有很強(qiáng)的要求和影響切黔，識別和構(gòu)建匹配架構(gòu)的團(tuán)隊是解決問題的加速器。微服務(wù)團(tuán)隊的另一個關(guān)鍵點(diǎn)是持續(xù)改進(jìn)具篇、持續(xù)學(xué)習(xí)和反饋纬霞，只有保持這樣一個文化氛圍，微服務(wù)架構(gòu)才能持續(xù)發(fā)展下去驱显，保持新鮮的生命力险领，進(jìn)而實現(xiàn)我們的初衷。
專業(yè)的微服務(wù)團(tuán)隊秒紧，為微服務(wù)保駕護(hù)航。
03 項目的微服務(wù)設(shè)計實踐
我們在各種基礎(chǔ)設(shè)施不健全的情況下挨下，匆忙進(jìn)入了微服務(wù)改造的深淵熔恢。原來的單體應(yīng)用按照功能拆分成了下面的結(jié)構(gòu)：
拆分之后，模塊突然變多了臭笆。將內(nèi)部業(yè)務(wù)邏輯和原子功能拆分出來叙淌，實現(xiàn)了部分功能的復(fù)用，并且對外的接口按類型區(qū)分到不同的模塊中去了愁铺，方便了使用鹰霍，但是增加了管理的難度。
從上面我們對微服務(wù)架構(gòu)的了解茵乱，一個微服務(wù)系統(tǒng)會有大量的服務(wù)組成茂洒，服務(wù)之間的層次關(guān)系依然是存在的，但是調(diào)用順序上的要求會有所降低瓶竭，只要滿足嚴(yán)格的上層調(diào)用下層即可督勺，在某些簡單的業(yè)務(wù)功能上允許跨層調(diào)用。
上圖是三種架構(gòu)（集中式斤贰、分布式智哀、微服務(wù)架構(gòu)）的形象化展示∮校可以看到微服務(wù)的一個狀態(tài)瓷叫，乍看起來有些混亂，如果還按照以前的管理方式維護(hù)項目的話送巡，工作量會成指數(shù)級增長摹菠，人力所無法勝任的工作。
這時候就需要依賴一些分布式服務(wù)框架骗爆，并建立一些輔助運(yùn)維系統(tǒng)：
- 首先服務(wù)之間遠(yuǎn)程調(diào)用辨嗽，服務(wù)的注冊和發(fā)現(xiàn)機(jī)制必須有好的分布式服務(wù)框架（類似dubbo）支持，方便做服務(wù)之間的調(diào)用配置管理淮腾。
- 部署的服務(wù)進(jìn)程增加以后糟需，對應(yīng)的日志文件也會增多屉佳，這時再使用ssh到服務(wù)器上查看日志，這個工作量也是可想而知的洲押。我們對業(yè)務(wù)日志做了規(guī)范化約束武花，然后使用ELK技術(shù)棧搭建了日志集中化管理系統(tǒng)。
- 為了能夠?qū)€上的所有服務(wù)有個全局的把控杈帐，我們根據(jù)注冊中心的數(shù)據(jù)搭建了服務(wù)的管理系統(tǒng)体箕，展示各個維度的統(tǒng)計數(shù)據(jù)，例如挑童，每個主機(jī)上多少個應(yīng)用累铅，每個應(yīng)用提供了多少個服務(wù)，同時又消費(fèi)了多少個服務(wù)等等站叼。還有一些針對服務(wù)的約束規(guī)則的告警信息娃兽，例如某個應(yīng)用消費(fèi)的服務(wù)，卻沒有服務(wù)提供者等尽楔。還有一個整體的應(yīng)用之間的依賴關(guān)系圖投储。
- 為了優(yōu)化系統(tǒng)結(jié)構(gòu)和排查問題，搭建了服務(wù)的監(jiān)控系統(tǒng)阔馋，這個是依賴分布式服務(wù)框架打印的預(yù)統(tǒng)計日志的玛荞，通過這些日志分析得到一個整體的服務(wù)監(jiān)控功能，例如每個服務(wù)的響應(yīng)時間呕寝、錯誤率等勋眯。還有調(diào)用鏈跟蹤功能，排查問題時使用它來跟蹤請求信息下梢。
- 服務(wù)治理功能用來及時地對線上項目做一些調(diào)整凡恍，例如限流、降級怔球、負(fù)載均衡嚼酝、超時、路由竟坛、隔離容錯等闽巩。
有了以上這些系統(tǒng)輔助，我們的微服務(wù)化改造之路平坦了許多担汤。
在進(jìn)行微服務(wù)化改造的時候涎跨，接口的設(shè)計上遇到了一個問題，服務(wù)之間的調(diào)用是通過私有協(xié)議進(jìn)行的RPC調(diào)用崭歧，這種調(diào)用中如何描述服務(wù)響應(yīng)成功之外的其他異常情況隅很？
1.采用Exception類，定義各種異常類來描述異常情況率碾。
2.采用錯誤碼＋錯誤描述叔营。
其中方案1采用的Exception類屋彪，是我們平時java中定義進(jìn)程內(nèi)部接口最常見的方法，這種方法的優(yōu)點(diǎn)是绒尊，能夠使調(diào)用接口的一方的代碼更簡潔畜挥，通過try...catch來處理，如果不需要處理的話婴谱，在方法上聲明直接向上拋出即可蟹但。缺點(diǎn)是跨語言開發(fā)解析難度大增，而且日志中異常堆棧很多谭羔。方案2采用錯誤碼的形式恰恰相反华糖，缺點(diǎn)就是每次調(diào)用都要判讀是否調(diào)用成功，增加代碼中的if語句瘟裸。
針對這個問題客叉，希望各位實踐分布式服務(wù)或者微服務(wù)的大神給出你們的實踐方案，瘋狂討論起來景描。
04 結(jié)束語
上述三節(jié)中講述了我們在構(gòu)建微服務(wù)的經(jīng)歷和一些感想，給其他準(zhǔn)備實施微服務(wù)和正在實施微服務(wù)的團(tuán)隊以參考秀撇，寫這篇文章的另一個目的就是希望能起到拋磚引玉的作用超棺，希望能和其他團(tuán)隊進(jìn)一步交流。
