微服務(wù)的4個(gè)設(shè)計(jì)原則和19個(gè)解決方案

本文轉(zhuǎn)自：http://developer.51cto.com/art/201709/552085.htm

微服務(wù)架構(gòu)現(xiàn)在是談到企業(yè)應(yīng)用架構(gòu)時(shí)必聊的話題瓣戚，微服務(wù)之所以火熱也是因?yàn)橄鄬?duì)之前的應(yīng)用開發(fā)方式有很多優(yōu)點(diǎn)，如更靈活颁虐、更能適應(yīng)現(xiàn)在需求快速變更的大環(huán)境埋合。

本文將介紹微服務(wù)架構(gòu)的演進(jìn)揍异、優(yōu)缺點(diǎn)和微服務(wù)應(yīng)用的設(shè)計(jì)原則，然后著重介紹作為一個(gè)“微服務(wù)應(yīng)用平臺(tái)”需要提供哪些能力爆班、解決哪些問題才能更好的支撐企業(yè)應(yīng)用架構(gòu)衷掷。

微服務(wù)平臺(tái)也是我目前正在參與的，還在研發(fā)過程中的平臺(tái)產(chǎn)品柿菩，平臺(tái)是以SpringCloud為基礎(chǔ)戚嗅，結(jié)合了普元多年來對(duì)企業(yè)應(yīng)用的理解和產(chǎn)品的設(shè)計(jì)經(jīng)驗(yàn)，逐步孵化的一個(gè)微服務(wù)應(yīng)用平臺(tái)枢舶。

一懦胞、微服務(wù)架構(gòu)演進(jìn)過程

近年來我們大家都體會(huì)到了互聯(lián)網(wǎng)、移動(dòng)互聯(lián)帶來的好處凉泄，作為IT從業(yè)者医瘫，在生活中時(shí)刻感受互聯(lián)網(wǎng)好處的同時(shí)，在工作中可能感受的卻是來自自互聯(lián)網(wǎng)的一些壓力旧困，那就是我們傳統(tǒng)企業(yè)的IT建設(shè)也是迫切需要轉(zhuǎn)型醇份，需要面向外部客戶，我們也需要應(yīng)對(duì)外部環(huán)境的快速變化吼具、需要快速創(chuàng)新僚纷，那么我們的IT架構(gòu)也需要向互聯(lián)網(wǎng)企業(yè)學(xué)習(xí)作出相應(yīng)的改進(jìn)，來支撐企業(yè)的數(shù)字化轉(zhuǎn)型拗盒。

我們再看一下應(yīng)用架構(gòu)的演進(jìn)過程怖竭，回憶一下微服務(wù)架構(gòu)是如何一步一步進(jìn)化產(chǎn)生的，最早是應(yīng)用是單塊架構(gòu)陡蝇，后來為了具備一定的擴(kuò)展和可靠性痊臭，就有了垂直架構(gòu)，也就是加了個(gè)負(fù)載均衡登夫，接下來是前幾年比較火的SOA广匙，主要講了應(yīng)用系統(tǒng)之間如何集成和互通，而到現(xiàn)在的微服務(wù)架構(gòu)則是進(jìn)一步在探討一個(gè)應(yīng)用系統(tǒng)該如何設(shè)計(jì)才能夠更好的開發(fā)恼策、管理更加靈活高效鸦致。

微服務(wù)架構(gòu)的基本思想就是“圍繞業(yè)務(wù)領(lǐng)域組件來創(chuàng)建應(yīng)用，讓應(yīng)用可以獨(dú)立的開發(fā)涣楷、管理和加速”分唾。

二、微服務(wù)架構(gòu)的好處

我們總結(jié)了四個(gè)方面的優(yōu)點(diǎn)狮斗，分別如下：

是每個(gè)微服務(wù)組件都是簡單靈活的绽乔，能夠獨(dú)立部署。不再像以前一樣碳褒，應(yīng)用需要一個(gè)龐大的應(yīng)用服務(wù)器來支撐折砸。

可以由一個(gè)小團(tuán)隊(duì)負(fù)責(zé)更專注專業(yè)捍壤，相應(yīng)的也就更高效可靠。

微服務(wù)之間是松耦合的鞍爱，微服務(wù)內(nèi)部是高內(nèi)聚的，每個(gè)微服務(wù)很容易按需擴(kuò)展专酗。

微服務(wù)架構(gòu)與語言工具無關(guān)睹逃，自由選擇合適的語言和工具，高效的完成業(yè)務(wù)目標(biāo)即可祷肯。

看到這里沉填，大家會(huì)覺得微服務(wù)架構(gòu)挺不錯(cuò)，然而還會(huì)有一些疑問佑笋，什么樣的應(yīng)用算是一個(gè)微服務(wù)架構(gòu)的應(yīng)用?該怎樣設(shè)計(jì)一個(gè)微服務(wù)架構(gòu)的應(yīng)用?那我們來一起看看我們推薦的微服務(wù)應(yīng)用的設(shè)計(jì)原則翼闹。

三、微服務(wù)應(yīng)用4個(gè)設(shè)計(jì)原則

我們總結(jié)了四個(gè)原則推薦給大家：

AKF拆分原則

前后端分離

無狀態(tài)服務(wù)

Restful通信風(fēng)格

1.AKF拆分原則

AKF擴(kuò)展立方體(參考《The Art of Scalability》)蒋纬，是一個(gè)叫AKF的公司的技術(shù)專家抽象總結(jié)的應(yīng)用擴(kuò)展的三個(gè)維度猎荠。理論上按照這三個(gè)擴(kuò)展模式，可以將一個(gè)單體系統(tǒng)蜀备，進(jìn)行無限擴(kuò)展关摇。

X 軸 ：指的是水平復(fù)制，很好理解碾阁，就是講單體系統(tǒng)多運(yùn)行幾個(gè)實(shí)例输虱，做個(gè)集群加負(fù)載均衡的模式。

Z 軸 ：是基于類似的數(shù)據(jù)分區(qū)脂凶，比如一個(gè)互聯(lián)網(wǎng)打車應(yīng)用突然或了宪睹，用戶量激增，集群模式撐不住了蚕钦，那就按照用戶請(qǐng)求的地區(qū)進(jìn)行數(shù)據(jù)分區(qū)亭病，北京、上海嘶居、四川等多建幾個(gè)集群命贴。

Y 軸 ：就是我們所說的微服務(wù)的拆分模式，就是基于不同的業(yè)務(wù)拆分食听。

場景說明：比如打車應(yīng)用胸蛛，一個(gè)集群撐不住時(shí)，分了多個(gè)集群樱报，后來用戶激增還是不夠用葬项，經(jīng)過分析發(fā)現(xiàn)是乘客和車主訪問量很大，就將打車應(yīng)用拆成了三個(gè)乘客服務(wù)迹蛤、車主服務(wù)民珍、支付服務(wù)襟士。三個(gè)服務(wù)的業(yè)務(wù)特點(diǎn)各不相同，獨(dú)立維護(hù)嚷量，各自都可以再次按需擴(kuò)展陋桂。

2.前后端分離

前后端分離原則，簡單來講就是前端和后端的代碼分離也就是技術(shù)上做分離蝶溶，我們推薦的模式是最好直接采用物理分離的方式部署嗜历，進(jìn)一步促使進(jìn)行更徹底的分離。不要繼續(xù)以前的服務(wù)端模板技術(shù)抖所，比如JSP 梨州，把Java JS HTML CSS 都堆到一個(gè)頁面里，稍復(fù)雜的頁面就無法維護(hù)田轧。這種分離模式的方式有幾個(gè)好處：

前后端技術(shù)分離暴匠，可以由各自的專家來對(duì)各自的領(lǐng)域進(jìn)行優(yōu)化，這樣前端的用戶體驗(yàn)優(yōu)化效果會(huì)更好傻粘。

分離模式下剩盒，前后端交互界面更加清晰啤斗，就剩下了接口和模型，后端的接口簡潔明了，更容易維護(hù)宝穗。

前端多渠道集成場景更容易實(shí)現(xiàn)眠冈，后端服務(wù)無需變更洲尊，采用統(tǒng)一的數(shù)據(jù)和模型晓锻，可以支撐前端的web UI?移動(dòng)App等訪問。

3.無狀態(tài)服務(wù)

對(duì)于無狀態(tài)服務(wù)肩祥，首先說一下什么是狀態(tài)：如果一個(gè)數(shù)據(jù)需要被多個(gè)服務(wù)共享后室，才能完成一筆交易，那么這個(gè)數(shù)據(jù)被稱為狀態(tài)混狠。進(jìn)而依賴這個(gè)“狀態(tài)”數(shù)據(jù)的服務(wù)被稱為有狀態(tài)服務(wù)岸霹，反之稱為無狀態(tài)服務(wù)。

那么這個(gè)無狀態(tài)服務(wù)原則并不是說在微服務(wù)架構(gòu)里就不允許存在狀態(tài)将饺，表達(dá)的真實(shí)意思是要把有狀態(tài)的業(yè)務(wù)服務(wù)改變?yōu)闊o狀態(tài)的計(jì)算類服務(wù)贡避，那么狀態(tài)數(shù)據(jù)也就相應(yīng)的遷移到對(duì)應(yīng)的“有狀態(tài)數(shù)據(jù)服務(wù)”中。

場景說明：例如我們以前在本地內(nèi)存中建立的數(shù)據(jù)緩存予弧、Session緩存刮吧，到現(xiàn)在的微服務(wù)架構(gòu)中就應(yīng)該把這些數(shù)據(jù)遷移到分布式緩存中存儲(chǔ)，讓業(yè)務(wù)服務(wù)變成一個(gè)無狀態(tài)的計(jì)算節(jié)點(diǎn)掖蛤。遷移后杀捻，就可以做到按需動(dòng)態(tài)伸縮，微服務(wù)應(yīng)用在運(yùn)行時(shí)動(dòng)態(tài)增刪節(jié)點(diǎn)蚓庭，就不再需要考慮緩存數(shù)據(jù)如何同步的問題致讥。

4.Restful通信風(fēng)格

作為一個(gè)原則來講本來應(yīng)該是個(gè)“無狀態(tài)通信原則”仅仆，在這里我們直接推薦一個(gè)實(shí)踐優(yōu)選的Restful 通信風(fēng)格 ，因?yàn)樗泻芏嗪锰帲?/p>

無狀態(tài)協(xié)議HTTP垢袱，具備先天優(yōu)勢墓拜，擴(kuò)展能力很強(qiáng)。例如需要安全加密是请契，有現(xiàn)成的成熟方案HTTPS可用咳榜。

JSON 報(bào)文序列化，輕量簡單姚糊，人與機(jī)器均可讀，學(xué)習(xí)成本低授舟，搜索引擎友好救恨。

語言無關(guān)，各大熱門語言都提供成熟的Restful API框架释树，相對(duì)其他的一些RPC框架生態(tài)更完善肠槽。

當(dāng)然在有些特殊業(yè)務(wù)場景下，也需要采用其他的RPC框架奢啥，如thrift秸仙、avro-rpc、grpc桩盲。但絕大多數(shù)情況下Restful就足夠用了寂纪。

四、微服務(wù)架構(gòu)帶來的問題

做到了前面講的四個(gè)原則赌结，那么就可以說是構(gòu)建了一個(gè)微服務(wù)應(yīng)用捞蛋，感覺上也不復(fù)雜。但實(shí)際上微服務(wù)也不是個(gè)萬金油柬姚，也是有利有弊的拟杉，接下來我們來看看引入微服務(wù)架構(gòu)后帶來的問題有哪些。

依賴服務(wù)變更很難跟蹤量承，其他團(tuán)隊(duì)的服務(wù)接口文檔過期怎么辦?依賴的服務(wù)沒有準(zhǔn)備好搬设，如何驗(yàn)證我開發(fā)的功能。

部分模塊重復(fù)構(gòu)建撕捍，跨團(tuán)隊(duì)拿穴、跨系統(tǒng)、跨語言會(huì)有很多的重復(fù)建設(shè)忧风。

微服務(wù)放大了分布式架構(gòu)的系列問題贞言，如分布式事務(wù)怎么處理?依賴服務(wù)不穩(wěn)定怎么辦?

運(yùn)維復(fù)雜度陡增，如：部署物數(shù)量多阀蒂、監(jiān)控進(jìn)程多導(dǎo)致整體運(yùn)維復(fù)雜度提升该窗。

上面這些問題我們應(yīng)該都遇到過弟蚀，并且也會(huì)有一些解決方案，比如提供文檔管理酗失、服務(wù)治理义钉、服務(wù)模擬的工具和框架; 實(shí)現(xiàn)統(tǒng)一認(rèn)證、統(tǒng)一配置规肴、統(tǒng)一日志框架捶闸、分布式匯總分析; 采用全局事務(wù)方案、采用異步模擬同步;搭建持續(xù)集成平臺(tái)拖刃、統(tǒng)一監(jiān)控平臺(tái)等等删壮。

這些解決方案折騰到最后終于搞明白了，原來我們是需要一個(gè)微服務(wù)應(yīng)用平臺(tái)才能整體性的解決這些問題兑牡。

五央碟、微服務(wù)平臺(tái)的19個(gè)落地實(shí)踐

1.企業(yè)IT建設(shè)的三大基礎(chǔ)環(huán)境

我們先來宏觀的看一下，一個(gè)企業(yè)的IT建設(shè)非常重要的三大基礎(chǔ)環(huán)境：團(tuán)隊(duì)協(xié)作環(huán)境均函、個(gè)人基礎(chǔ)環(huán)境亿虽、IT基礎(chǔ)設(shè)施。

團(tuán)隊(duì)協(xié)作環(huán)境：主要是DevOps領(lǐng)域的范疇苞也，負(fù)責(zé)從需求到計(jì)劃任務(wù)洛勉，團(tuán)隊(duì)協(xié)作，再到質(zhì)量管理如迟、持續(xù)集成和發(fā)布收毫。

個(gè)人基礎(chǔ)環(huán)境：就是本文介紹的微服務(wù)應(yīng)用平臺(tái)，他的目標(biāo)主要就是要支撐微服務(wù)應(yīng)用的設(shè)計(jì)開發(fā)測試殷勘，運(yùn)行期的業(yè)務(wù)數(shù)據(jù)處理和應(yīng)用的管理監(jiān)控牛哺。

IT基礎(chǔ)設(shè)施：就是我們通常說的各種運(yùn)行環(huán)境支撐如IaaS (VM虛擬化)和CaaS (容器虛擬化)等實(shí)現(xiàn)方式。

2.微服務(wù)應(yīng)用平臺(tái)總體架構(gòu)

微服務(wù)應(yīng)用平臺(tái)的總體架構(gòu)劳吠，主要是從開發(fā)集成引润、微服務(wù)運(yùn)行容器與平臺(tái)、運(yùn)行時(shí)監(jiān)控治理和外部渠道接入等維度來劃分的痒玩。

開發(fā)集成：主要是搭建一個(gè)微服務(wù)平臺(tái)需要具備的一些工具和倉庫

運(yùn)行時(shí)：要有微服務(wù)平臺(tái)來提供一些基礎(chǔ)能力和分布式的支撐能力淳附，我們的微服務(wù)運(yùn)行容器則會(huì)運(yùn)行在這個(gè)平臺(tái)之上。

監(jiān)控治理：則是致力于在運(yùn)行時(shí)能夠?qū)κ芄艿奈⒎?wù)進(jìn)行統(tǒng)一的監(jiān)控蠢古、配置等能力奴曙。

服務(wù)網(wǎng)關(guān)： 則是負(fù)責(zé)與前端的WEB應(yīng)用 移動(dòng)APP 等渠道集成，對(duì)前端請(qǐng)求進(jìn)行認(rèn)真鑒權(quán)草讶，然后路由轉(zhuǎn)發(fā)洽糟。

3.微服務(wù)應(yīng)用平臺(tái)的運(yùn)行視圖

參考上圖，在運(yùn)行期，作為一個(gè)微服務(wù)架構(gòu)的平臺(tái)與業(yè)務(wù)系統(tǒng)坤溃，除了業(yè)務(wù)應(yīng)用本身外拍霜，還需要有接入服務(wù)、統(tǒng)一門戶薪介、基礎(chǔ)服務(wù)等平臺(tái)級(jí)服務(wù)來保障業(yè)務(wù)系統(tǒng)的可靠運(yùn)行祠饺。圖中的公共服務(wù)就是業(yè)務(wù)處理過程中需要用到的一些可選服務(wù)。

4.微服務(wù)平臺(tái)的設(shè)計(jì)目標(biāo)

微服務(wù)平臺(tái)的主要目標(biāo)主要就是要支撐微服務(wù)應(yīng)用的全生命周期管理汁政，從需求到設(shè)計(jì)開發(fā)測試道偷，運(yùn)行期的業(yè)務(wù)數(shù)據(jù)處理和應(yīng)用的管理監(jiān)控等，后續(xù)將從應(yīng)用生命周期的幾個(gè)重要階段切入记劈，結(jié)合前面提到的設(shè)計(jì)原則和問題勺鸦，介紹平臺(tái)提供的能力支撐情況。

5.微服務(wù)開發(fā)：前端目木、后端换途、混合

我們一起看一下我們正在開發(fā)中的微服務(wù)應(yīng)用平臺(tái)EOS8.0的一些開發(fā)工具截圖，了解一下開發(fā)期提供了哪些關(guān)鍵的能力支撐嘶窄。

前面的設(shè)計(jì)原則中提到了一個(gè)前后端分離的原則怀跛，那么我們的開發(fā)環(huán)境中距贷，目前支持創(chuàng)建前端項(xiàng)目柄冲、后端項(xiàng)目和混合項(xiàng)目。其中前端項(xiàng)目忠蝗、后端項(xiàng)目就對(duì)應(yīng)前后端分離的原則现横，利用平臺(tái)中集成的開發(fā)工具和框架可以做到前后端開發(fā)分離，利用持續(xù)集成工具可以方便的將前端阁最、后端項(xiàng)目編譯打包成可獨(dú)立運(yùn)行的程序戒祠。混合項(xiàng)目則是為了兼容傳統(tǒng)模式而保留的速种，為企業(yè)應(yīng)用向微服務(wù)架構(gòu)演進(jìn)提供過渡方案姜盈。

6.服務(wù)契約與API管理

對(duì)于前面提到的微服務(wù)帶來的依賴管理問題，我們可以通過平臺(tái)提供的API管理能力來解決配阵。說到API管理馏颂，那首先就用提到服務(wù)契約。平臺(tái)開發(fā)工具中提供了方便的服務(wù)發(fā)布能力棋傍，能夠快速的將業(yè)務(wù)功能對(duì)外發(fā)布救拉，生成服務(wù)的規(guī)格契約，當(dāng)然也可以先設(shè)計(jì)服務(wù)契約瘫拣，在根據(jù)契約來生成服務(wù)的默認(rèn)實(shí)現(xiàn)代碼亿絮。

這里強(qiáng)調(diào)一下，我們提到的服務(wù)契約是一個(gè)很重要的東西，他有點(diǎn)類似web service的wsdl描述派昧，主要描述服務(wù)接口的輸入輸出規(guī)格標(biāo)準(zhǔn)和其他一些服務(wù)調(diào)用集成相關(guān)的規(guī)格內(nèi)容黔姜。

7.服務(wù)契約與服務(wù)模擬

有了服務(wù)契約，我們就可以根據(jù)契約自動(dòng)生成服務(wù)的文檔和服務(wù)模擬測試環(huán)境斗锭，這樣地淀，開發(fā)者就可以方便的獲取到依賴服務(wù)變更的情況，能夠及時(shí)的根據(jù)依賴服務(wù)的變化調(diào)整自己的程序岖是，并且能夠方便的進(jìn)行模擬測試驗(yàn)證帮毁。

8.服務(wù)契約與服務(wù)編排

有了服務(wù)契約，那就有了服務(wù)接口的輸入輸出規(guī)格豺撑，那么restful的服務(wù)編排也就變得可行烈疚。在我們設(shè)計(jì)的契約標(biāo)準(zhǔn)中，還定義了調(diào)用集成相關(guān)的內(nèi)容聪轿，比如服務(wù)支持的事務(wù)模式等等爷肝。通過這些約定，我們就可以采用簡單圖形化的方式來對(duì)業(yè)務(wù)服務(wù)流程進(jìn)行編排陆错。編排能夠很大程度上簡化分布式服務(wù)調(diào)用的復(fù)雜度灯抛，如同步、異步音瓷、異步模擬同步对嚼、超時(shí)重試、事務(wù)補(bǔ)償?shù)壬鳎蟹?wù)編排引擎完成纵竖，不再完全依賴?yán)蠋煾档木幋a能力。

服務(wù)編排的作用和意義很大杏愤，可以快速的將已經(jīng)提供的微服務(wù)能力進(jìn)行組合發(fā)布靡砌，非常適合業(yè)務(wù)的快速創(chuàng)新。

但是大家要注意珊楼，邏輯流編排的是業(yè)務(wù)流程通殃，盡量能夠簡單明了，一眼看上去就明白業(yè)務(wù)含義厕宗。而業(yè)務(wù)規(guī)則推薦采用服務(wù)內(nèi)部進(jìn)行編碼實(shí)現(xiàn)画舌。千萬不要將我們的 “邏輯流” 圖形化服務(wù)編排完全取代程序編碼，這樣就會(huì)可能會(huì)走入另外一個(gè)極端媳瞪，比如設(shè)計(jì)出像蜘蛛網(wǎng)一樣的邏輯流圖骗炉，簡直就是災(zāi)難。

9.微服務(wù)容器

我們再來看一下微服務(wù)運(yùn)行容器的一個(gè)邏輯圖蛇受，大家可以看到句葵，我們要做微服務(wù)架構(gòu)的應(yīng)用，可靠高效的微服務(wù)應(yīng)用，實(shí)際上我們需要做的事情還是非常多的乍丈。如果沒有一個(gè)統(tǒng)一的微服務(wù)容器剂碴，這些能力在每個(gè)微服務(wù)組件中都需要建設(shè)一遍，而且會(huì)五花八門轻专，也很難集成到一起忆矛。有了統(tǒng)一的微服務(wù)運(yùn)行容器和一些公共的基礎(chǔ)服務(wù)，前面所提到的微服務(wù)架構(gòu)下部分組件重復(fù)建設(shè)的問題也迎刃而解请垛。

10.三方能力集成說明

我們的API管理契約文檔API模擬我們是集成了Swagger的工具鏈催训。微服務(wù)應(yīng)用平臺(tái)的基礎(chǔ)就是SpringCloud，從容器框架到注冊發(fā)現(xiàn)再到安全認(rèn)證這些基礎(chǔ)方案均采用了他的能力來支撐宗收。下面簡單看下我們集成的一些開源框架和工具漫拭。

SpringCloud在微服務(wù)平臺(tái)中的定位是基礎(chǔ)框架，本文重點(diǎn)是要介紹一個(gè)企業(yè)級(jí)的微服務(wù)平臺(tái)在落地過程中的一些設(shè)計(jì)原則和解決方案混稽。具體Spring Cloud相關(guān)的技術(shù)就不在文中多做介紹了采驻，大家可以在我們的公眾號(hào)里面查看相關(guān)文章。

11.服務(wù)注冊發(fā)現(xiàn)路由

接下來我們聊一下注冊發(fā)現(xiàn)匈勋，以前的單塊應(yīng)用之間互相調(diào)用時(shí)配置個(gè)IP就行了礼旅，但在微服務(wù)架構(gòu)下，服務(wù)提供者會(huì)有很多洽洁，手工配置IP地址又變成了一個(gè)不可行的事情痘系。那么服務(wù)自動(dòng)注冊發(fā)現(xiàn)的方案就解決了這個(gè)問題。

我們的服務(wù)注冊發(fā)現(xiàn)能力是依賴SpringCloud Eureka組件實(shí)現(xiàn)的诡挂。服務(wù)在啟動(dòng)的時(shí)候碎浇，會(huì)將自己要發(fā)布的服務(wù)注冊到服務(wù)注冊中心临谱，運(yùn)行時(shí)璃俗，如果需要調(diào)用其他微服務(wù)的接口，那么就要先到注冊中心獲取服務(wù)提供者的地址悉默，拿到地址后城豁，通過微服務(wù)容器內(nèi)部的簡單負(fù)載均衡期進(jìn)行路由用。

一般情況抄课，系統(tǒng)內(nèi)微服務(wù)的調(diào)用都通過這種客戶端負(fù)載的模式進(jìn)行唱星，否則就需要有很多的負(fù)載均衡進(jìn)程「ィ跨業(yè)務(wù)系統(tǒng)的服務(wù)調(diào)用间聊，也可以采用這種去中心化的路由方式。當(dāng)然采用SOA的模式抵拘，由中心化的服務(wù)網(wǎng)管來管理系統(tǒng)間的調(diào)用也是另一種選擇哎榴，要結(jié)合企業(yè)的IT現(xiàn)狀和需求來決定。

12.統(tǒng)一認(rèn)證鑒權(quán)

安全認(rèn)證方面，我們基于Spring Security結(jié)合Auth2再加上JWT(Json web token)做安全令牌尚蝌，實(shí)現(xiàn)統(tǒng)一的安全認(rèn)證與鑒權(quán)迎变，使得微服務(wù)之間能夠按需隔離和安全互通。后續(xù)在統(tǒng)一認(rèn)證和權(quán)限方面我們產(chǎn)品會(huì)陸續(xù)推出較完善并且擴(kuò)展性良好的微服務(wù)組件飘言，可以作為微服務(wù)平臺(tái)的公共的認(rèn)證和鑒權(quán)服務(wù)衣形。再啰嗦一句，認(rèn)證鑒權(quán)一定是個(gè)公共的服務(wù)姿鸿，而不是多個(gè)系統(tǒng)各自建設(shè)谆吴。

13.日志與流水設(shè)計(jì)

作為一個(gè)微服務(wù)應(yīng)用平臺(tái)除了提供支撐開發(fā)和運(yùn)行的技術(shù)組件和框架之外，我們還提供一些運(yùn)維友好的經(jīng)驗(yàn)總結(jié)苛预，我們一起來看一下我們推薦的日志與流水實(shí)現(xiàn)纪铺，先來看日志，平臺(tái)默認(rèn)回會(huì)提供的日志主要有三種碟渺，系統(tǒng)日志鲜锚，引擎日志還有跟蹤日志。有了這些日志苫拍，在出問題的時(shí)候能夠幫助我們獲取一些關(guān)鍵信息進(jìn)行問題定位芜繁。

要想做到出了問題能夠追根溯源，那么右邊的這些流水號(hào)的設(shè)計(jì)也是非常重要的绒极，日志與各種流水號(hào)配合骏令，能夠讓我們快速定位問題發(fā)生的具體時(shí)間地點(diǎn)以及相關(guān)信息，能夠快速還原業(yè)務(wù)交易全鏈路垄提。對(duì)這些日志與流水的細(xì)節(jié)處理榔袋，對(duì)于系統(tǒng)運(yùn)維問題定位有非常大的幫助，沒有這些有用的日志內(nèi)容铡俐，ELK日志收集套件搭建的再漂亮凰兑，收一對(duì)垃圾日志也是沒用的。通常開源框架只是提供個(gè)框架有開發(fā)人員自由發(fā)揮审丘，而設(shè)計(jì)一個(gè)平臺(tái)則一定要考慮直接提供統(tǒng)一規(guī)范的基礎(chǔ)能力吏够。

14.集中配置管理

微服務(wù)分布式環(huán)境下，一個(gè)系統(tǒng)拆分為很多個(gè)微服務(wù)滩报，一定要告別投產(chǎn)或運(yùn)維手工修改配置配置的方式锅知。需要采用集中配置管理的方式來提升運(yùn)維的效率。

配置文件主要有運(yùn)行前的靜態(tài)配置和運(yùn)行期的動(dòng)態(tài)配置兩種脓钾。靜態(tài)配置通常是在編譯部署包之前設(shè)置好售睹。動(dòng)態(tài)配置則是系統(tǒng)運(yùn)行過程中需要調(diào)整的系統(tǒng)變量或者業(yè)務(wù)參數(shù)。要想做到集中的配置管理可训，那么需要注意以下幾點(diǎn)昌妹。

是配置與介質(zhì)分離生真，這個(gè)就需要通過制定規(guī)范的方式來控制。千萬別把配置放在Jar包里捺宗。

是配置的方式要統(tǒng)一柱蟀，格式、讀寫方式蚜厉、變更熱更新的模式盡量統(tǒng)一长已，要采用統(tǒng)一的配置框架

就是需要運(yùn)行時(shí)需要有個(gè)配置中心來統(tǒng)一管理業(yè)務(wù)系統(tǒng)中的配置信息，這個(gè)就需要平臺(tái)來提供配置中心服務(wù)和配置管理門戶昼牛。

15.統(tǒng)一管理門戶

微服務(wù)架構(gòu)下术瓮，一個(gè)大的EAR、WAR應(yīng)用被拆為了多個(gè)小的可獨(dú)立運(yùn)行的微服務(wù)程序贰健，通常這些微服務(wù)程序都不再依賴應(yīng)用服務(wù)器胞四，不依賴傳統(tǒng)應(yīng)用服務(wù)器的話，應(yīng)用服務(wù)器提供管理控制臺(tái)也就沒得用了伶椿，所以微服務(wù)的運(yùn)行時(shí)管理需要有統(tǒng)一的管理門戶來支撐辜伟。我們規(guī)劃了的統(tǒng)一集中的微服務(wù)門戶，可以支撐 應(yīng)用開發(fā)脊另、業(yè)務(wù)處理导狡、應(yīng)用管理、系統(tǒng)監(jiān)控等偎痛。上圖是應(yīng)用管理頁面旱捧，就是對(duì)我們傳統(tǒng)意義上的業(yè)務(wù)系統(tǒng)進(jìn)行管理，點(diǎn)擊一個(gè)業(yè)務(wù)系統(tǒng)踩麦，我們就能夠看到系統(tǒng)下有哪些微服務(wù)枚赡，每個(gè)微服務(wù)有幾個(gè)節(jié)點(diǎn)實(shí)例再運(yùn)行，可以監(jiān)控微服務(wù)的子節(jié)點(diǎn)狀態(tài)谓谦，對(duì)微服務(wù)進(jìn)行配置管理和監(jiān)控贫橙。

16.分布式事務(wù)問題

微服務(wù)架構(gòu)的系統(tǒng)下，進(jìn)程成倍增多茁计，那么也分布式事務(wù)一致性的問題也就更加明顯料皇。我們這里說的事務(wù)一致性谓松，不是傳統(tǒng)說的基于數(shù)據(jù)庫實(shí)現(xiàn)的技術(shù)事務(wù)星压。微服務(wù)之間是獨(dú)立的、調(diào)用協(xié)議也是無狀態(tài)的鬼譬，因此數(shù)據(jù)庫事務(wù)方案在一開始就已經(jīng)不再我們考慮的范圍內(nèi)娜膘。我們要解決的是一定時(shí)間后的數(shù)據(jù)達(dá)到最終一致狀態(tài)，準(zhǔn)確的說就是采用傳統(tǒng)的業(yè)務(wù)補(bǔ)償與沖正方式优质。

推薦的事務(wù)一致性方案有三種：

可靠事件模式：即事件的發(fā)送和接收保障高可靠性竣贪，來實(shí)現(xiàn)事務(wù)的一致性军洼。

補(bǔ)償模式：Confirm Cancel ，如果確認(rèn)失敗演怎，則全部逆序取消匕争。

TCC模式：Try Confirm Cancel ，補(bǔ)償模式的一種特殊實(shí)現(xiàn) 通常轉(zhuǎn)賬類交易會(huì)采用這種模式爷耀。

曉晨的補(bǔ)充：還有 最大努力型甘桑、異步確保、2PC歹叮、3PC

17.分布式同步調(diào)用問題

微服務(wù)架構(gòu)下跑杭，相對(duì)于傳統(tǒng)部署方式，存在更多的分布式調(diào)用咆耿，那么“如何在不確定的環(huán)境中交付確定的服務(wù)”德谅，這句話可以簡單理解為，我所依賴的服務(wù)的可靠性是無法保證的情況下萨螺，我如何保證自己能夠正常的提供服務(wù)窄做，不被我依賴的其他服務(wù)拖垮?

我們推薦SEDA架構(gòu)來解決這個(gè)問題。

SEDA : staged event-driven architecture本質(zhì)上就是采用分布式事件驅(qū)動(dòng)的模式慰技，用異步模擬來同步浸策，無阻塞等待，再加上資源分配隔離結(jié)起來的一個(gè)解決方案惹盼。

18.持續(xù)集成與持續(xù)交付設(shè)計(jì)

在運(yùn)維方面庸汗，首先我們要解決的就是持續(xù)集成和持續(xù)交付，而微服務(wù)應(yīng)用平臺(tái)的職責(zé)范圍目前規(guī)劃是只做持續(xù)集成手报，能夠方便的用持續(xù)集成環(huán)境把程序編譯成介質(zhì)包和部署包蚯舱。(目前規(guī)劃持續(xù)部署由DevOps平臺(tái)提供相應(yīng)能力，微服務(wù)平臺(tái)可與DevOps平臺(tái)集成)

這里要厘清一個(gè)概念：介質(zhì)掩蛤，是源碼編譯后的產(chǎn)物枉昏，與環(huán)境無關(guān)，多環(huán)境下應(yīng)該是可以共用的揍鸟，如：jar兄裂、dockerfile;配置：則是環(huán)境相關(guān)的信息。配置+介質(zhì)=部署包阳藻。

獲取到部署包之后晰奖，微服務(wù)應(yīng)用平臺(tái)的職責(zé)就完成了，接下來就是運(yùn)維人員各顯神通來進(jìn)行上線部署操作腥泥。

19.微服務(wù)平臺(tái)與容器云匾南、DevOps的關(guān)系

就微服務(wù)應(yīng)用平臺(tái)本身來說，并不依賴DevOps和容器云蛔外，開發(fā)好的部署包可以運(yùn)行在物理機(jī)蛆楞、虛擬機(jī)或者是容器中溯乒。

然而當(dāng)微服務(wù)應(yīng)用平臺(tái)結(jié)合了DevOps和容器云之后，我們就會(huì)發(fā)現(xiàn)豹爹，持續(xù)集成和交付變成了一個(gè)非常簡單便捷并且又可靠的過程裆悄。

簡單幾步操作，整套開發(fā)臂聋、測試灯帮、預(yù)發(fā)或者生產(chǎn)環(huán)境就能夠搭建完成。整個(gè)過程的復(fù)雜度都由平臺(tái)給屏蔽掉了逻住，通過三大基礎(chǔ)環(huán)境的整合钟哥，我們能夠使分散的微服務(wù)組件更簡單方便的進(jìn)行統(tǒng)一管理和運(yùn)維交付。