基於REST微服務的5個最佳實踐

關鍵時刻，第一時間送達！

作者丨Shamik Mitra

譯者丨Vincent

譯者註：微服務現在已經很流行了，作者在本文介紹了5個最佳實踐。如果想以後調整盡量少，那麼在設計架構時遵循這些最佳實踐，微服務體系結構將會更加適合開發人員的需求。以下為譯文。

如果想讓微服務架構開發變得友好，而且可以讓開發者管理起來輕鬆一些，跟蹤誤差更容易，那麼只要遵循本文中討論的5個最佳實踐就可以了。

1.用戶代理：在請求頭裡面命名有意義的名字是非常重要的,如果出現了類似於系統運行緩慢,內存訪問量驟增,甚至出現飆升的情況,那麼從該微服務發起的請求頭中，開發人員就可以很容易定位問題。在服務請求頭的User-Agent屬性提供邏輯名稱/，這就是一個最佳實踐。例：User-Agent：EmployeeSearchService

2.API版本控制：在基於REST的架構中，微服務之間是通過API互相訪問對方資源。在微服務裡面，API就充當著介面的角色。在編寫API時，頭腦一定得清晰，確保這樣API不會經常變更，這件事非常重要，因為其它的微服務會調用改API,所以API方法簽名只要發生調整，代碼也就需要跟著進行調整。但是改變是不可避免的,因為我們不知道未來會發生什麼，這真的是很諷刺的一件事,所以今天的商業策略可能在幾天以後就要被淘汰掉,因此API也就必須進行修改。

作為一名架構師,面臨的最大挑戰就是如何應對這些變化。答案就是版本維護。對於那些重大的變化,你可以在更新API版本的同時，給消費者發起通知,告知它已經有了新版本,這樣他們就可以在既定期限內遷移到新版本。在這個時間內,作為API提供者,就必須維護兩個版本,然後不斷發送重要通知給消費者，讓他們的代碼庫調用新版本,在這之後，就不再需要維護舊版本了。

3.相關ID：很多人都知道在微服務的架構中，業務功能是分布在多個微服務裡面,所以從客戶端內部發出的某個請求會扇出許多單獨的請求，最大的原因就是有可能某個微服務變慢了，或者down掉了。但作為一名開發人員需要知道在微服務森林如何定位出哪個微服務變慢了,所以我們需要在邏輯上對請求進行分組。為客戶端請求生成一個隨機的UUID，然後將該UUID傳遞到每個內部請求中，因此在日誌裡面就可以通過UUID進行追蹤，然後找到相應的調用軌跡。

4.ELK實現：微服務是用來自動定量的,所以在某個複雜的業務領域中是很難管理微服務的日誌文件。假設在某個系統中包含了50個微服務,每個每個服務有10個實例;那將會生成50 * 10 = 500個日誌文件。作為開發人員,不可能登錄到每個實例，然後收集日誌，再去調查問題,所以我們需要一個集中的機制,這樣所有的日誌都可以導出,然後在日誌中再做一些智能搜索,比如找出錯誤或某個特定的異常,再或者還可以通過主機以及相關ID等進行搜索。ELK提供了這一功能,E代表ElasticSearch,L是Logstash,K是Kibana。ElasticSearch會轉儲日誌，也提供了模糊搜索的功能,Logstash用於從不同來源收集日誌，然後對它們進行轉換,Kibana是一個圖形用戶界面,開發人員可以搜索他們需要的日誌。或者還可以使用Splunk或其他開源框架分析日誌。

5.彈性實現：如上面所描述的那樣,在微服務架構中,想要完成某個業務功能可能會涉及很多的微服務。最常見的情形就是某個微服務掛掉了,導致整個流程都停止了。針對於這種情況,彈性就顯得至關重要了,每個服務都應該實現彈性，從而為最終用戶提供無縫體驗。當某個服務在一定時間裡沒有響應,應該配置一個後備路徑,這樣用戶就不需要等待響應,但是會立即得到一個內部錯誤的提示。其實從本質上來說這就是一個響應設計。

結論

在構建基於REST的微服務時,需要考慮兩個方面：

用戶體驗

開發人員的視角

用戶不喜歡等待,他/她需要一個很明確的信息，不是指技術信息，而是指當內部出現某個問題時，可以告訴他/她發生了什麼,他/她就可以正常聯繫服務台。另一方面,為微服務提供支持的時候,我們需要知道的所有重要信息都在日誌中,事件發生後，需要基於日誌進行分析。在開發的時候如果總能站在支持的角度進行思考，這樣你就可以跟蹤流程，從日誌文件中也可以獲取到足夠的信息。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 CSDN 的精彩文章: