從一個案例來看，如何在做架構(gòu)設(shè)計時利用微服務(wù)的思想來幫我們解決問題。

?

背景介紹

公司對產(chǎn)品服務(wù)的管理目前還停留在物理機(jī)的那種理念，雖然阿里云、AWS、騰訊云、OpenStack等云平臺用的不亦樂乎，但仍然停留在針對hostname和ip的管理上。如果想發(fā)布一個新版本，需要將設(shè)計到的所有機(jī)器的ip整理到一起，然后借助Ansible將產(chǎn)品更新上去。

這種現(xiàn)狀的形成，并不只是技術(shù)上的落后，還有成本上的限制，畢竟包年付費模式要比按需付費便宜一大半。但是給運維團(tuán)隊帶來的困擾也很大，畢竟遇到高峰期還是需要多備一套擴(kuò)容組來扛流量，運維工程師除了要維護(hù)“靜態(tài)的”云實例，還要維護(hù)這部分“動態(tài)的”云實例，運維成本很大。產(chǎn)品迭代后，包年的實例通過Ansible更新好后，運維工程師還要登陸到云平臺上，選中一個更新后的實例，導(dǎo)出鏡像，再將這個鏡像更新到伸縮組的伸縮規(guī)則，這樣才能保證伸縮組擴(kuò)容出來的新實例運行的是新版本的應(yīng)用。

?

需求下發(fā)：

開發(fā)一個系統(tǒng)可以直接從Ansible那邊傳來IP和伸縮組ID后，我的系統(tǒng)要把阿里云中伸縮組的鏡像更新為該IP對應(yīng)實例的鏡像。

?

設(shè)計階段：

產(chǎn)品的定位和擴(kuò)展性

如果單單只實現(xiàn)這一點功能，可以寫個python或者SpringMCV項目，調(diào)用阿里云的SDK就可以搞定。當(dāng)我分析公司現(xiàn)有的資源和軟件產(chǎn)品時發(fā)現(xiàn)，目前并沒有一款這種對接云平臺的輔助系統(tǒng)，所以我們可以把項目的定位抬高一些，做成對接所有云平臺，甚至是對接運維所有輔助系統(tǒng)的這么一個項目。

最終選定用SpringFramework微服務(wù)架構(gòu)來開發(fā)，雖然前期投入比較大，但是會帶來很多優(yōu)點：

1，?每個邏輯節(jié)點可以配置多個物理節(jié)點達(dá)到高可用性。?

2，?自動的服務(wù)發(fā)現(xiàn)和注冊機(jī)制?

3，?節(jié)點間松耦合，新增和修改擴(kuò)展靈活?

4，?統(tǒng)一的API網(wǎng)關(guān)，提供轉(zhuǎn)發(fā)和過濾功能?

5，?可以添加Spring Config（統(tǒng)一配置中心）、Spring Bus（配置熱修改）、Spring Sleuth（日志追蹤）等輔助節(jié)點滿足大批量節(jié)點管理?

?

現(xiàn)階段：?

開發(fā)了4個節(jié)點：服務(wù)注冊中心（Register）、對外服務(wù)網(wǎng)關(guān)（Gateway）、云總控（CloudCenter）、云分控（AliyunClient），架構(gòu)圖如下：

?

其中注冊中心是基礎(chǔ)運維研發(fā)關(guān)心的節(jié)點，用來觀察服務(wù)節(jié)點的健康狀況；Gateway是對外提供服務(wù)的入口，采用Restful協(xié)議，可定制安全規(guī)則（目前采用IP白名單）；其它節(jié)點為內(nèi)部服務(wù)節(jié)點，不對外暴漏，不允許直接訪問。

?

再階段：

后續(xù)與云平臺相關(guān)的新功能，與阿里云有關(guān)的可以繼續(xù)修改阿里云分控節(jié)點的代碼，如果涉及到其它平臺，新添加節(jié)點。?

這樣設(shè)計的優(yōu)點：1 某個云平臺API升級、SDK更新等不會影響到其它節(jié)點代碼的可用性；2 每個云平臺根據(jù)自己的壓力單獨擴(kuò)展資源。

?

終極形態(tài)：

對接更多的系統(tǒng)，擴(kuò)展更多的組件

除開與云平臺相關(guān)的功能，后續(xù)如果有其它模塊需要開發(fā)的部分，也可以放到該項目中來。隨著項目復(fù)雜度的增加，物理節(jié)點達(dá)到一定規(guī)模后，靠基礎(chǔ)運維人工管理整套系統(tǒng)將會變的非常困難，需要引入Spring Cloud輔助工具。

?

API核心步驟

1 DescribeInstances：通過基準(zhǔn)實例的內(nèi)網(wǎng)ip查詢對應(yīng)實例id

2 CreateImage：使用實例id創(chuàng)建一個新鏡像，記錄鏡像id

3 DescribeImages：通過鏡像id查詢鏡像狀態(tài)及progress，直到available為止

4 DescribeScalingGroups：通過伸縮組id查詢到生效中的伸縮配置，記錄ID

5 ModifyScalingConfiguration：修改伸縮配置，指向新的鏡像

?

提高用戶體驗體驗

阿里云基于實例制作鏡像的過程幾分鐘至幾小時時間不等，用戶通過RESTFul的POST請求通過Json體傳入實例IP和伸縮組ID后，將會陷入漫長的等待過程，所以操作請求和狀態(tài)返回需要設(shè)計成異步形式避免等待。

異步又有兩種可選的實現(xiàn)方式：1，后端任務(wù)完成后通過Queue通知客戶；2，提供狀態(tài)和進(jìn)度的查詢接口供客戶端調(diào)用。兩種方式各有利弊，對于請求者來說前者是被動的等待，不知道中間狀態(tài)，甚至不知道死活；后者需要請求者通過get不斷來輪詢，但是可以拿到任務(wù)的進(jìn)度。

所以，最終的設(shè)計是當(dāng)收到任務(wù)請求后，經(jīng)過簡單校驗直接轉(zhuǎn)交后臺處理，同時將查詢進(jìn)度的url通過http的response返回給請求端。

客戶對自己的鏡像可以有自定義的命名規(guī)則，方便后期維護(hù)和在云平臺的查詢，所以添加一個可選參數(shù)，讓客戶可定制鏡像名稱的前綴。

?

細(xì)節(jié)考慮

1 異步任務(wù)線程池

因為任務(wù)是異步執(zhí)行的，而且前面也說過，一次任務(wù)的執(zhí)行從十幾分鐘到幾小時不等，如果不做控制很有可能線程數(shù)爆掉，所以處于安全和效率的考慮，需要增加任務(wù)的線程池。如果線程池扛不住并發(fā)數(shù)，只能擴(kuò)展物理節(jié)點。

?

2 任務(wù)狀態(tài)緩存

因為無法控制客戶端調(diào)用狀態(tài)查詢接口的頻率，如果完全透傳給阿里云會嚴(yán)重影響我自己系統(tǒng)的性能。所以在設(shè)計中增加一層緩存，客戶端接口只查詢緩存中的狀態(tài)，緩存層每1min調(diào)用一次阿里云的鏡像狀態(tài)接口更新一次緩存中的狀態(tài)。

?

3 阿里云API容錯機(jī)制

這個是上線后遇到的問題，由于網(wǎng)絡(luò)的問題從我的系統(tǒng)到阿里云的服務(wù)并不能保證100%的問題，所以當(dāng)輪詢制作鏡像任務(wù)狀態(tài)時有極小概率會失敗，但其實在阿里云端制作鏡像的任務(wù)仍在運行中，但是在我的系統(tǒng)里卻認(rèn)為以失敗結(jié)束了。

所以對于特定的API需要增加容錯機(jī)制，連續(xù)3次API調(diào)用失敗后才認(rèn)為真正失敗。

?

部分源碼分享：

https://github.com/yejingtao/ci-register.git

https://github.com/yejingtao/ci-gateway.git

https://github.com/yejingtao/ci-cloudcenter.git

https://github.com/yejingtao/ci-aliclient.git

注意：因為我使用的JVM本地緩存，所以當(dāng)前的服務(wù)需要java -jar部署到一臺機(jī)器上，后續(xù)我會把本地緩存改造為共享緩存。

?

總結(jié)：

微服務(wù)開發(fā)是一個循序漸進(jìn)的過程，只要開始把架構(gòu)搭建好，隨著功能一點點的添加，跟搭積木一樣可以慢慢構(gòu)建出一個龐大的系統(tǒng)，而且添加新功能模塊對現(xiàn)有功能沖擊很小。

原文鏈接：https://blog.csdn.net/yejingtao703/article/details/84961510

總結(jié)

以上是生活随笔為你收集整理的微服务设计简单实践---从一个简单需求学习微服务思想的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。