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

原文：5 best practices for rest-based microservices

翻譯：vincent

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的微服務時,需要考慮兩個方面：

使用者體驗

開發人員的視角

基於spring boot的rest微服務框架

週末在家研究spring boot，參考github上的一些開源專案，整了乙個rest微服務框架，取之於民，用之於民，在github上開源了，位址如下 主要特性如下 資料訪問 資料庫初始化指令碼 見src mybatis generator ddl.sql 資料實體 生成 採用mybatis gen...

基於spring boot的rest微服務框架

週末在家研究spring boot，參考github上的一些開源專案，整了乙個rest微服務框架，取之於民，用之於民，在github上開源了，位址如下 主要特性如下 資料訪問 資料庫初始化指令碼 見src mybatis generator ddl.sql 資料實體 生成 採用mybatis gen...

基於SpringCloud的微服務架構實戰案例專案

基於springcloud體系實現，簡單購物流程實現，滿足基本功能 註冊 登入 商品列表展示 商品詳情展示 訂單建立 詳情檢視 訂單支付 庫存更新等等。每個業務服務採用獨立的mysql資料庫，初期考慮用到如下元件 服務註冊 發現 eureka 配置管理 spring config spring se...