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

原文：5 Best Practices for REST-Based Microservices

作者：Shamik Mitra

翻譯：Vincent

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

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

1.使用者代理：在請求頭裡面命名有意義的名字是非常重要的,如果出現了類似于系統運作緩慢,記憶體通路量驟增,甚至出現飙升的情況,那麼從該微服務發起的請求頭中，開發人員就可以很容易定位問題。在服務請求頭的User-Agent屬性提供邏輯名稱/{service id }，這就是一個最佳實踐。例：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的微服務時,需要考慮兩個方面：

1. 使用者體驗
2. 開發人員的視角

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