轉(zhuǎn)載微服務(wù)的4個設(shè)計原則和19個解決方案 - 平臺+

微服務(wù)架構(gòu)現(xiàn)在是談到企業(yè)應(yīng)用架構(gòu)時必聊的話題，微服務(wù)之所以火熱也是因為相對之前的應(yīng)用開發(fā)方式有很多優(yōu)點始鱼，如更靈活娜扇、更能適應(yīng)現(xiàn)在需求快速變更的大環(huán)境逗物。

本文將介紹微服務(wù)架構(gòu)的演進方库、優(yōu)缺點和微服務(wù)應(yīng)用的設(shè)計原則，然后著重介紹作為一個“微服務(wù)應(yīng)用平臺”需要提供哪些能力弯院、解決哪些問題才能更好的支撐企業(yè)應(yīng)用架構(gòu)辱士。

微服務(wù)平臺也是我目前正在參與的，還在研發(fā)過程中的平臺產(chǎn)品听绳，平臺是以SpringCloud為基礎(chǔ)识补，結(jié)合了普元多年來對企業(yè)應(yīng)用的理解和產(chǎn)品的設(shè)計經(jīng)驗，逐步孵化的一個微服務(wù)應(yīng)用平臺辫红。

目錄：

一凭涂、微服務(wù)架構(gòu)演進過程

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

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

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

五、微服務(wù)平臺的19個落地實踐

六名惩、總結(jié)展望

一澎胡、微服務(wù)架構(gòu)演進過程

近年來我們大家都體會到了互聯(lián)網(wǎng)、移動互聯(lián)帶來的好處，作為IT從業(yè)者攻谁，在生活中時刻感受互聯(lián)網(wǎng)好處的同時稚伍，在工作中可能感受的卻是來自自互聯(lián)網(wǎng)的一些壓力，那就是我們傳統(tǒng)企業(yè)的IT建設(shè)也是迫切需要轉(zhuǎn)型戚宦，需要面向外部客戶个曙，我們也需要應(yīng)對外部環(huán)境的快速變化、需要快速創(chuàng)新受楼，那么我們的IT架構(gòu)也需要向互聯(lián)網(wǎng)企業(yè)學習作出相應(yīng)的改進垦搬，來支撐企業(yè)的數(shù)字化轉(zhuǎn)型。

我們再看一下應(yīng)用架構(gòu)的演進過程艳汽，回憶一下微服務(wù)架構(gòu)是如何一步一步進化產(chǎn)生的猴贰，最早是應(yīng)用是單塊架構(gòu)，后來為了具備一定的擴展和可靠性河狐，就有了垂直架構(gòu)米绕，也就是加了個負載均衡，接下來是前幾年比較火的SOA馋艺，主要講了應(yīng)用系統(tǒng)之間如何集成和互通栅干，而到現(xiàn)在的微服務(wù)架構(gòu)則是進一步在探討一個應(yīng)用系統(tǒng)該如何設(shè)計才能夠更好的開發(fā)、管理更加靈活高效丈钙。

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

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

我們總結(jié)了四個方面的優(yōu)點芙扎，分別如下：

是每個微服務(wù)組件都是簡單靈活的星岗，能夠獨立部署。不再像以前一樣戒洼，應(yīng)用需要一個龐大的應(yīng)用服務(wù)器來支撐俏橘。

可以由一個小團隊負責更專注專業(yè)，相應(yīng)的也就更高效可靠圈浇。

微服務(wù)之間是松耦合的寥掐，微服務(wù)內(nèi)部是高內(nèi)聚的，每個微服務(wù)很容易按需擴展磷蜀。

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

看到這里污它，大家會覺得微服務(wù)架構(gòu)挺不錯，然而還會有一些疑問，什么樣的應(yīng)用算是一個微服務(wù)架構(gòu)的應(yīng)用衫贬？該怎樣設(shè)計一個微服務(wù)架構(gòu)的應(yīng)用德澈？那我們來一起看看我們推薦的微服務(wù)應(yīng)用的設(shè)計原則。

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

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

AKF拆分原則

前后端分離

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

Restful通信風格

1.AKF拆分原則

AKF擴展立方體（參考《The Art of Scalability》）梆造，是一個叫AKF的公司的技術(shù)專家抽象總結(jié)的應(yīng)用擴展的三個維度。理論上按照這三個擴展模式缝呕，可以將一個單體系統(tǒng)澳窑，進行無限擴展。

X 軸?：指的是水平復(fù)制供常，很好理解摊聋，就是講單體系統(tǒng)多運行幾個實例，做個集群加負載均衡的模式栈暇。

Z 軸?：是基于類似的數(shù)據(jù)分區(qū)麻裁，比如一個互聯(lián)網(wǎng)打車應(yīng)用突然或了，用戶量激增源祈，集群模式撐不住了煎源，那就按照用戶請求的地區(qū)進行數(shù)據(jù)分區(qū)，北京香缺、上海手销、四川等多建幾個集群。

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

場景說明：比如打車應(yīng)用，一個集群撐不住時祸轮，分了多個集群兽埃，后來用戶激增還是不夠用，經(jīng)過分析發(fā)現(xiàn)是乘客和車主訪問量很大适袜，就將打車應(yīng)用拆成了三個乘客服務(wù)柄错、車主服務(wù)、支付服務(wù)苦酱。三個服務(wù)的業(yè)務(wù)特點各不相同售貌，獨立維護，各自都可以再次按需擴展疫萤。

2.前后端分離

前后端分離原則颂跨，簡單來講就是前端和后端的代碼分離也就是技術(shù)上做分離，我們推薦的模式是最好直接采用物理分離的方式部署给僵，進一步促使進行更徹底的分離毫捣。不要繼續(xù)以前的服務(wù)端模板技術(shù)详拙，比如JSP ，把Java JS HTML CSS 都堆到一個頁面里蔓同，稍復(fù)雜的頁面就無法維護饶辙。這種分離模式的方式有幾個好處：

前后端技術(shù)分離，可以由各自的專家來對各自的領(lǐng)域進行優(yōu)化斑粱，這樣前端的用戶體驗優(yōu)化效果會更好弃揽。

分離模式下，前后端交互界面更加清晰则北，就剩下了接口和模型矿微，后端的接口簡潔明了，更容易維護尚揣。

前端多渠道集成場景更容易實現(xiàn)涌矢，后端服務(wù)無需變更，采用統(tǒng)一的數(shù)據(jù)和模型快骗，可以支撐前端的web UI\ 移動App等訪問娜庇。

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

對于無狀態(tài)服務(wù)，首先說一下什么是狀態(tài)：如果一個數(shù)據(jù)需要被多個服務(wù)共享方篮，才能完成一筆交易名秀，那么這個數(shù)據(jù)被稱為狀態(tài)。進而依賴這個“狀態(tài)”數(shù)據(jù)的服務(wù)被稱為有狀態(tài)服務(wù)藕溅，反之稱為無狀態(tài)服務(wù)匕得。

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

場景說明：例如我們以前在本地內(nèi)存中建立的數(shù)據(jù)緩存、Session緩存攒发，到現(xiàn)在的微服務(wù)架構(gòu)中就應(yīng)該把這些數(shù)據(jù)遷移到分布式緩存中存儲调塌，讓業(yè)務(wù)服務(wù)變成一個無狀態(tài)的計算節(jié)點晋南。遷移后惠猿，就可以做到按需動態(tài)伸縮，微服務(wù)應(yīng)用在運行時動態(tài)增刪節(jié)點负间，就不再需要考慮緩存數(shù)據(jù)如何同步的問題偶妖。

4.Restful通信風格

作為一個原則來講本來應(yīng)該是個“無狀態(tài)通信原則”，在這里我們直接推薦一個實踐優(yōu)選的Restful 通信風格 政溃，因為他有很多好處：

無狀態(tài)協(xié)議HTTP趾访，具備先天優(yōu)勢，擴展能力很強董虱。例如需要安全加密是扼鞋，有現(xiàn)成的成熟方案HTTPS可用申鱼。

JSON 報文序列化，輕量簡單云头，人與機器均可讀捐友，學習成本低，搜索引擎友好溃槐。

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

當然在有些特殊業(yè)務(wù)場景下猴鲫，也需要采用其他的RPC框架，如thrift谣殊、avro-rpc拂共、grpc。但絕大多數(shù)情況下Restful就足夠用了姻几。

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

做到了前面講的四個原則，那么就可以說是構(gòu)建了一個微服務(wù)應(yīng)用鲜棠，感覺上也不復(fù)雜肌厨。但實際上微服務(wù)也不是個萬金油，也是有利有弊的豁陆，接下來我們來看看引入微服務(wù)架構(gòu)后帶來的問題有哪些柑爸。

依賴服務(wù)變更很難跟蹤，其他團隊的服務(wù)接口文檔過期怎么辦盒音？依賴的服務(wù)沒有準備好表鳍，如何驗證我開發(fā)的功能。

部分模塊重復(fù)構(gòu)建祥诽，跨團隊譬圣、跨系統(tǒng)、跨語言會有很多的重復(fù)建設(shè)雄坪。

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

運維復(fù)雜度陡增绳姨，如：部署物數(shù)量多、監(jiān)控進程多導(dǎo)致整體運維復(fù)雜度提升阔挠。

上面這些問題我們應(yīng)該都遇到過飘庄，并且也會有一些解決方案，比如提供文檔管理购撼、服務(wù)治理跪削、服務(wù)模擬的工具和框架谴仙； 實現(xiàn)統(tǒng)一認證、統(tǒng)一配置碾盐、統(tǒng)一日志框架狞甚、分布式匯總分析； 采用全局事務(wù)方案廓旬、采用異步模擬同步哼审；搭建持續(xù)集成平臺、統(tǒng)一監(jiān)控平臺等等孕豹。

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

五励背、微服務(wù)平臺的19個落地實踐

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

我們先來宏觀的看一下春霍，一個企業(yè)的IT建設(shè)非常重要的三大基礎(chǔ)環(huán)境：團隊協(xié)作環(huán)境、個人基礎(chǔ)環(huán)境叶眉、IT基礎(chǔ)設(shè)施址儒。

團隊協(xié)作環(huán)境：主要是DevOps領(lǐng)域的范疇，負責從需求到計劃任務(wù)衅疙，團隊協(xié)作莲趣，再到質(zhì)量管理、持續(xù)集成和發(fā)布饱溢。

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

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

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

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

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

運行時：要有微服務(wù)平臺來提供一些基礎(chǔ)能力和分布式的支撐能力状植，我們的微服務(wù)運行容器則會運行在這個平臺之上浊竟。

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

服務(wù)網(wǎng)關(guān)： 則是負責與前端的WEB應(yīng)用 移動APP 等渠道集成圆仔，對前端請求進行認真鑒權(quán)旧噪，然后路由轉(zhuǎn)發(fā)。

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

參考上圖胖替，在運行期，作為一個微服務(wù)架構(gòu)的平臺與業(yè)務(wù)系統(tǒng)，除了業(yè)務(wù)應(yīng)用本身外帝簇，還需要有接入服務(wù)徘郭、統(tǒng)一門戶、基礎(chǔ)服務(wù)等平臺級服務(wù)來保障業(yè)務(wù)系統(tǒng)的可靠運行丧肴。圖中的公共服務(wù)就是業(yè)務(wù)處理過程中需要用到的一些可選服務(wù)残揉。

4.微服務(wù)平臺的設(shè)計目標

微服務(wù)平臺的主要目標主要就是要支撐微服務(wù)應(yīng)用的全生命周期管理，從需求到設(shè)計開發(fā)測試芋浮，運行期的業(yè)務(wù)數(shù)據(jù)處理和應(yīng)用的管理監(jiān)控等抱环，后續(xù)將從應(yīng)用生命周期的幾個重要階段切入，結(jié)合前面提到的設(shè)計原則和問題纸巷，介紹平臺提供的能力支撐情況镇草。

5.微服務(wù)開發(fā)：前端、后端瘤旨、混合

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

前面的設(shè)計原則中提到了一個前后端分離的原則存哲，那么我們的開發(fā)環(huán)境中因宇，目前支持創(chuàng)建前端項目、后端項目和混合項目祟偷。其中前端項目察滑、后端項目就對應(yīng)前后端分離的原則，利用平臺中集成的開發(fā)工具和框架可以做到前后端開發(fā)分離修肠，利用持續(xù)集成工具可以方便的將前端杭棵、后端項目編譯打包成可獨立運行的程序》沾停混合項目則是為了兼容傳統(tǒng)模式而保留的魂爪，為企業(yè)應(yīng)用向微服務(wù)架構(gòu)演進提供過渡方案。

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

對于前面提到的微服務(wù)帶來的依賴管理問題艰管，我們可以通過平臺提供的API管理能力來解決滓侍。說到API管理，那首先就用提到服務(wù)契約牲芋。平臺開發(fā)工具中提供了方便的服務(wù)發(fā)布能力撩笆，能夠快速的將業(yè)務(wù)功能對外發(fā)布，生成服務(wù)的規(guī)格契約缸浦，當然也可以先設(shè)計服務(wù)契約夕冲，在根據(jù)契約來生成服務(wù)的默認實現(xiàn)代碼。

這里強調(diào)一下裂逐，我們提到的服務(wù)契約是一個很重要的東西歹鱼，他有點類似web service的wsdl描述，主要描述服務(wù)接口的輸入輸出規(guī)格標準和其他一些服務(wù)調(diào)用集成相關(guān)的規(guī)格內(nèi)容卜高。

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

有了服務(wù)契約弥姻，我們就可以根據(jù)契約自動生成服務(wù)的文檔和服務(wù)模擬測試環(huán)境南片，這樣，開發(fā)者就可以方便的獲取到依賴服務(wù)變更的情況庭敦，能夠及時的根據(jù)依賴服務(wù)的變化調(diào)整自己的程序疼进，并且能夠方便的進行模擬測試驗證。

根據(jù)契約生成模擬服務(wù)也就是我們常說的服務(wù)擋板秧廉，這樣即使依賴的其他服務(wù)還無法提供功能伞广，我們也可以通過擋板來進行聯(lián)調(diào)測試。

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

有了服務(wù)契約疼电，那就有了服務(wù)接口的輸入輸出規(guī)格赔癌，那么restful的服務(wù)編排也就變得可行。在我們設(shè)計的契約標準中澜沟，還定義了調(diào)用集成相關(guān)的內(nèi)容灾票，比如服務(wù)支持的事務(wù)模式等等。通過這些約定茫虽，我們就可以采用簡單圖形化的方式來對業(yè)務(wù)服務(wù)流程進行編排刊苍。編排能夠很大程度上簡化分布式服務(wù)調(diào)用的復(fù)雜度，如同步濒析、異步正什、異步模擬同步、超時重試号杏、事務(wù)補償?shù)扔さ蟹?wù)編排引擎完成，不再完全依賴老師傅的編碼能力盾致。

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

但是大家要注意罩驻，邏輯流編排的是業(yè)務(wù)流程，盡量能夠簡單明了护赊，一眼看上去就明白業(yè)務(wù)含義惠遏。而業(yè)務(wù)規(guī)則推薦采用服務(wù)內(nèi)部進行編碼實現(xiàn)。千萬不要將我們的 “邏輯流” 圖形化服務(wù)編排完全取代程序編碼骏啰，這樣就會可能會走入另外一個極端节吮，比如設(shè)計出像蜘蛛網(wǎng)一樣的邏輯流圖，簡直就是災(zāi)難判耕。

9.微服務(wù)容器

我們再來看一下微服務(wù)運行容器的一個邏輯圖透绩，大家可以看到，我們要做微服務(wù)架構(gòu)的應(yīng)用，可靠高效的微服務(wù)應(yīng)用渺贤，實際上我們需要做的事情還是非常多的雏胃。如果沒有一個統(tǒng)一的微服務(wù)容器请毛，這些能力在每個微服務(wù)組件中都需要建設(shè)一遍志鞍，而且會五花八門，也很難集成到一起方仿。有了統(tǒng)一的微服務(wù)運行容器和一些公共的基礎(chǔ)服務(wù)固棚，前面所提到的微服務(wù)架構(gòu)下部分組件重復(fù)建設(shè)的問題也迎刃而解。

10.三方能力集成說明

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

SpringCloud在微服務(wù)平臺中的定位是基礎(chǔ)框架呜师，本文重點是要介紹一個企業(yè)級的微服務(wù)平臺在落地過程中的一些設(shè)計原則和解決方案。具體Spring Cloud相關(guān)的技術(shù)就不在文中多做介紹了贾节，大家可以在我們的公眾號里面查看相關(guān)文章汁汗。

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

接下來我們聊一下注冊發(fā)現(xiàn)，以前的單塊應(yīng)用之間互相調(diào)用時配置個IP就行了栗涂，但在微服務(wù)架構(gòu)下知牌，服務(wù)提供者會有很多，手工配置IP地址又變成了一個不可行的事情斤程。那么服務(wù)自動注冊發(fā)現(xiàn)的方案就解決了這個問題角寸。

我們的服務(wù)注冊發(fā)現(xiàn)能力是依賴SpringCloud Eureka組件實現(xiàn)的。服務(wù)在啟動的時候忿墅，會將自己要發(fā)布的服務(wù)注冊到服務(wù)注冊中心扁藕，運行時，如果需要調(diào)用其他微服務(wù)的接口疚脐，那么就要先到注冊中心獲取服務(wù)提供者的地址纹磺，拿到地址后，通過微服務(wù)容器內(nèi)部的簡單負載均衡期進行路由用亮曹。

一般情況橄杨，系統(tǒng)內(nèi)微服務(wù)的調(diào)用都通過這種客戶端負載的模式進行，否則就需要有很多的負載均衡進程照卦∈浇茫跨業(yè)務(wù)系統(tǒng)的服務(wù)調(diào)用，也可以采用這種去中心化的路由方式役耕。當然采用SOA的模式采转，由中心化的服務(wù)網(wǎng)管來管理系統(tǒng)間的調(diào)用也是另一種選擇，要結(jié)合企業(yè)的IT現(xiàn)狀和需求來決定。

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

安全認證方面故慈，我們基于Spring Security結(jié)合Auth2再加上JWT（Json web token）做安全令牌板熊，實現(xiàn)統(tǒng)一的安全認證與鑒權(quán)，使得微服務(wù)之間能夠按需隔離和安全互通察绷。后續(xù)在統(tǒng)一認證和權(quán)限方面我們產(chǎn)品會陸續(xù)推出較完善并且擴展性良好的微服務(wù)組件干签，可以作為微服務(wù)平臺的公共的認證和鑒權(quán)服務(wù)。再啰嗦一句拆撼，認證鑒權(quán)一定是個公共的服務(wù)容劳，而不是多個系統(tǒng)各自建設(shè)。

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

作為一個微服務(wù)應(yīng)用平臺除了提供支撐開發(fā)和運行的技術(shù)組件和框架之外闸度，我們還提供一些運維友好的經(jīng)驗總結(jié)竭贩，我們一起來看一下我們推薦的日志與流水實現(xiàn)，先來看日志莺禁，平臺默認回會提供的日志主要有三種留量，系統(tǒng)日志，引擎日志還有跟蹤日志哟冬。有了這些日志楼熄，在出問題的時候能夠幫助我們獲取一些關(guān)鍵信息進行問題定位。

要想做到出了問題能夠追根溯源柒傻，那么右邊的這些流水號的設(shè)計也是非常重要的孝赫，日志與各種流水號配合，能夠讓我們快速定位問題發(fā)生的具體時間地點以及相關(guān)信息红符，能夠快速還原業(yè)務(wù)交易全鏈路青柄。對這些日志與流水的細節(jié)處理，對于系統(tǒng)運維問題定位有非常大的幫助预侯，沒有這些有用的日志內(nèi)容致开，ELK日志收集套件搭建的再漂亮，收一對垃圾日志也是沒用的萎馅。通常開源框架只是提供個框架有開發(fā)人員自由發(fā)揮双戳，而設(shè)計一個平臺則一定要考慮直接提供統(tǒng)一規(guī)范的基礎(chǔ)能力。

14.集中配置管理

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

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

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

是配置的方式要統(tǒng)一，格式亚脆、讀寫方式做院、變更熱更新的模式盡量統(tǒng)一，要采用統(tǒng)一的配置框架

就是需要運行時需要有個配置中心來統(tǒng)一管理業(yè)務(wù)系統(tǒng)中的配置信息型酥，這個就需要平臺來提供配置中心服務(wù)和配置管理門戶山憨。

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

微服務(wù)架構(gòu)下查乒，一個大的EAR弥喉、WAR應(yīng)用被拆為了多個小的可獨立運行的微服務(wù)程序，通常這些微服務(wù)程序都不再依賴應(yīng)用服務(wù)器玛迄，不依賴傳統(tǒng)應(yīng)用服務(wù)器的話由境，應(yīng)用服務(wù)器提供管理控制臺也就沒得用了，所以微服務(wù)的運行時管理需要有統(tǒng)一的管理門戶來支撐蓖议。我們規(guī)劃了的統(tǒng)一集中的微服務(wù)門戶虏杰，可以支撐 應(yīng)用開發(fā)、業(yè)務(wù)處理勒虾、應(yīng)用管理纺阔、系統(tǒng)監(jiān)控等。上圖是應(yīng)用管理頁面修然，就是對我們傳統(tǒng)意義上的業(yè)務(wù)系統(tǒng)進行管理笛钝，點擊一個業(yè)務(wù)系統(tǒng)，我們就能夠看到系統(tǒng)下有哪些微服務(wù)愕宋，每個微服務(wù)有幾個節(jié)點實例再運行玻靡，可以監(jiān)控微服務(wù)的子節(jié)點狀態(tài)，對微服務(wù)進行配置管理和監(jiān)控中贝。

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

微服務(wù)架構(gòu)的系統(tǒng)下囤捻，進程成倍增多，那么也分布式事務(wù)一致性的問題也就更加明顯邻寿。我們這里說的事務(wù)一致性蝎土，不是傳統(tǒng)說的基于數(shù)據(jù)庫實現(xiàn)的技術(shù)事務(wù)。微服務(wù)之間是獨立的绣否、調(diào)用協(xié)議也是無狀態(tài)的誊涯，因此數(shù)據(jù)庫事務(wù)方案在一開始就已經(jīng)不再我們考慮的范圍內(nèi)。我們要解決的是一定時間后的數(shù)據(jù)達到最終一致狀態(tài)枝秤，準確的說就是采用傳統(tǒng)的業(yè)務(wù)補償與沖正方式醋拧。

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

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

補償模式：Confirm Cancel 丹壕，如果確認失敗庆械，則全部逆序取消。

TCC模式：Try Confirm Cancel 菌赖，補償模式的一種特殊實現(xiàn) 通常轉(zhuǎn)賬類交易會采用這種模式缭乘。

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

微服務(wù)架構(gòu)下，相對于傳統(tǒng)部署方式琉用，存在更多的分布式調(diào)用堕绩，那么“如何在不確定的環(huán)境中交付確定的服務(wù)”，這句話可以簡單理解為邑时，我所依賴的服務(wù)的可靠性是無法保證的情況下奴紧，我如何保證自己能夠正常的提供服務(wù)，不被我依賴的其他服務(wù)拖垮晶丘？

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

SEDA : staged event-driven architecture本質(zhì)上就是采用分布式事件驅(qū)動的模式，用異步模擬來同步浅浮，無阻塞等待沫浆，再加上資源分配隔離結(jié)起來的一個解決方案。

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

在運維方面滚秩，首先我們要解決的就是持續(xù)集成和持續(xù)交付专执，而微服務(wù)應(yīng)用平臺的職責范圍目前規(guī)劃是只做持續(xù)集成，能夠方便的用持續(xù)集成環(huán)境把程序編譯成介質(zhì)包和部署包郁油。（目前規(guī)劃持續(xù)部署由DevOps平臺提供相應(yīng)能力本股，微服務(wù)平臺可與DevOps平臺集成）

這里要厘清一個概念：介質(zhì)，是源碼編譯后的產(chǎn)物已艰，與環(huán)境無關(guān)痊末，多環(huán)境下應(yīng)該是可以共用的，如：jar哩掺、dockerfile凿叠；配置：則是環(huán)境相關(guān)的信息。配置+介質(zhì)=部署包嚼吞。

獲取到部署包之后盒件，微服務(wù)應(yīng)用平臺的職責就完成了，接下來就是運維人員各顯神通來進行上線部署操作舱禽。

19.微服務(wù)平臺與容器云炒刁、DevOps的關(guān)系

就微服務(wù)應(yīng)用平臺本身來說，并不依賴DevOps和容器云誊稚，開發(fā)好的部署包可以運行在物理機翔始、虛擬機或者是容器中罗心。

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

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

六强窖、總結(jié)展望

我們再來回顧一下凸椿，三大基礎(chǔ)環(huán)境的關(guān)系。微服務(wù)應(yīng)用平臺負責應(yīng)用開發(fā)毕骡、運行以及管理削饵；DevOps負責項目管理岩瘦、計劃管理未巫、CI、CD和團隊溝通協(xié)作等启昧；容器云平臺則負責基礎(chǔ)設(shè)置管理叙凡，屏蔽環(huán)境的復(fù)雜度。

這三大基礎(chǔ)環(huán)境的建設(shè)情況密末，直接反應(yīng)出了企業(yè)IT能力水平握爷。這三大基礎(chǔ)環(huán)境是技術(shù)人員和企業(yè)都希望擁有的，是企業(yè)贏得競爭严里、驅(qū)動業(yè)務(wù)創(chuàng)新的基礎(chǔ)新啼，是企業(yè)加速數(shù)字化轉(zhuǎn)型的必由之路。

最后刹碾，我們一起看一下普元正在研發(fā)的新一代The Platform平臺燥撞。

上圖紅框中的內(nèi)容是與我們今天分享的微服務(wù)應(yīng)用平臺相關(guān)的部分。整個The Platform平臺是我們站在企業(yè)整體架構(gòu)規(guī)劃的角度迷帜，從多個維度入手物舒，目標是為企業(yè)搭建一個持續(xù)發(fā)展的IT生態(tài)環(huán)境，加速企業(yè)的數(shù)字化型戏锹。