基於REST微服務的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.彈性實現

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

6.結論

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

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

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