從Uber微服務看最佳實踐如何煉成？_Kubernetes中文社群
Uber成長非常迅速，工程師團隊快速擴充，據說Uber有2000名工程師，8000個程式碼倉庫，部署了1000多個微服務。微服務架構是Uber應對技術團隊快速增長，功能快速上線很出色的解決方案。本文偏向微服務的入門篇，以Uber微服務為例，進行了深入淺出的講解。
微服務特性
對於微服務沒有適當的定義，你可以說它是一個框架，由小型的、獨立的可部署的服務組成，執行不同的操作。
微服務專注於單個業務領域，可以作為完全獨立的可部署服務，並在不同的技術棧上實現它們。
單體架構和微服務架構區別
在使用微服務構建自己的應用程式之前，需要清楚地瞭解應用程式的範圍和功能。
微服務特性
- 解耦 – 系統內的服務在很大程度上是解耦的。因此，整個應用程式可以輕鬆構建，更改和縮放
- 元件化 – 微服務被視為獨立的元件，可以輕鬆替換和升級
- 業務能力 – 微服務非常簡單，專注於單一功能
- 自治 – 開發人員和團隊可以獨立工作，從而提高速度
- 持續交付 – 通過軟體建立，測試和批准的系統自動化，允許軟體的頻繁釋出
- 責任 – 微服務不像專案那樣專注於應用程式。相反，他們將應用程式視為他們負責的產品
- 分散治理 – 重點在於使用正確的工具來完成正確的作業。這意味著沒有標準化模式或任何技術模式。開發人員可以自由選擇最有用的工具來解決他們的問題
- 敏捷 – 微服務支援敏捷開發。任何新功能都可以快速開發並再次丟棄
- 獨立開發 – 所有微服務都可以根據各自的功能輕鬆開發
- 獨立部署 – 基於各自的服務，可以單獨部署在任何應用程式中
- 故障隔離 – 即使應用程式的一項服務不起作用，系統仍會繼續執行
- 混合技術堆疊 – 可以使用不同的語言和技術來構建同一應用程式的不同服務
- 細粒度縮放 – 各個元件可根據需要進行擴充套件，無需將所有元件擴充套件到一起
在當今世界，複雜性已經滲透到產品中。微服務架構能夠更好地保持團隊的規模和功能。
以下是微服務設計的最佳實踐:
現在，讓我們來看一個用例來更好地理解微服務。
當開啟購物車應用程式時，你看到的只是一個網站。但是，在幕後，購物車應用程式有接受支付服務、顧客服務等等。
假設開發人員已經在一個整體框架中進行了建立。如下圖:
購物車應用程式的整體框架
所有功能都放在一個程式碼庫中，並在一個底層資料庫下。
現在，假設市場上出現了一個新品牌，開發人員希望將這個品牌的所有細節都放在這個應用程式中。
他們不僅要重新為新標籤提供服務，還必須重新構建完整的系統並進行相應部署。
為了應對這種挑戰，開發人員決定將其應用程式從單體架構轉移到微服務。如下圖：
購物車應用程式的微服務架構
這意味著開發人員不必建立Web微服務，邏輯微服務或資料庫微服務。相反，他們為搜尋，推薦，客戶服務等建立單獨的微服務。
這種應用架構不僅有助於開發人員克服以前架構面臨的挑戰，還有助於輕鬆構建，部署和擴充套件購物車應用程式。
- 作為開發人員，決定構建應用程式時，要將各個域分離，並在功能上明確。
- 設計的每一個微服務都只專注於應用中的一個服務。
- 確保設計的應用程式使每個服務都可以單獨部署。
- 確保微服務之間的通訊是通過無狀態伺服器完成的。
- 每一項服務都可以被推進到更小的服務中，擁有自己的微服務。
在設計微服務時，已經瞭解了基本的指導方針，現在來了解一下微服務的架構。
一個典型的微服務架構(MSA)應該包括以下元件：
2.身份提供者
3.API閘道器
4.訊息格式
5.資料庫
6.靜態內容
7.管理
8.服務發現
如下圖：
微服務架構
這個架構看起來有點複雜，讓我們來簡化一下。
1、客戶端
架構始於不同型別的客戶端，從不同的設備嘗試執行各種管理功能，如搜尋、構建、配置等。
2、身份提供者
這些來自客戶端的請求將傳遞給身份提供者，這些提供者對客戶端的請求進行身份驗證，並將請求傳遞給API閘道器。然後，請求通過定義良好的API閘道器與內部服務通訊。
3、API閘道器
由於客戶端不直接呼叫服務，因此API閘道器作為客戶端將請求轉發到適當的微服務的切入點。
使用API閘道器的優點包括:
•所有服務都可以在客戶端不知情的情況下進行更新。
•服務也可以使用非網路友好的訊息傳遞協議。
•API閘道器可執行跨切割功能，如提供安全性、負載均衡等。
在接收到客戶端的請求後，內部架構由微服務組成，這些微服務通過訊息相互通訊來處理客戶端請求。
4、訊息格式
有兩種型別的訊息通過它們進行通訊：
•同步訊息：在客戶端等待服務響應的情況下，微服務通常傾向於使用REST (Representational State Transfer)，因為它依賴於無狀態、客戶端伺服器和HTTP協議。這個協議被用作一個分散式環境，每個功能都用一個資源來表示，以執行操作。
•非同步訊息：在客戶端不等待服務響應的情況下，微服務通常傾向於使用AMQP、STOMP、MQTT等協議。這些協議在這種型別的通訊中使用，因為訊息的性質被定義，這些訊息在實現之間可以互操作。
下一個問題是，使用微服務的應用程式如何處理資料?
5、資料處理
每個微服務都擁有一個專有資料庫來捕獲它們的資料並實現相應的業務功能。此外，微服務的資料庫只通過其服務API進行更新。參考下圖：
微服務處理資料演示
微服務提供的服務被轉發到任何支援不同技術棧的程序間通訊的遠端服務。
6、靜態內容
在微服務內部進行通訊後，將靜態內容部署到基於雲的儲存服務，通過內容交付網路（CDN）直接將其交付給客戶端。
除了上述元件，還有一些其他元件出現在典型的微服務架構中。
7、管理
該元件負責平衡節點上的服務和故障識別。
8、服務發現
用作微服務的指南，以找到它們之間的通訊路由，由它維護節點所在的服務列表。
現在來看看這個架構的優缺點，以更好地理解何時使用這種架構。
| 微服務架構的優點 | 微服務架構的缺點 |
| 自由使用不同的技術 | 增加故障排除難題 |
| 每個微服務都關注單一業務能力 | 由於遠端呼叫而增加延遲 |
| 支援單獨的可部署單元 | 增加配置和其他運營工作量 |
| 允許頻繁的軟體釋出 | 難以保持交易安全 |
| 確保每項服務的安全性 | 很難跟蹤各種服務邊界的資料 |
| 並行開發和部署多個服務 | 服務之間很難移動程式碼 |
下面來比較一下UBER之前和現在的架構。
Uber之前的架構
像許多初創公司一樣，UBER在開始之初在單一城市運營，為單一產品打造了單體架構。當時有一個程式碼庫似乎被清理了，並解決了UBER的核心業務問題。然而，隨著UBER在全球範圍內擴張，它們在可擴充套件性和持續整合方面面臨各種各樣的問題。
UBER的單體架構
上圖描述了UBER之前的架構。
- 與乘客和司機連線的REST API。
- 三種不同的介面卡與API一起使用，當預定出租車時，執行諸如賬單、付款、傳送電子郵件/訊息等操作。
- MySQL資料庫儲存所有資料。
因此，可以發現這裡所有的特性，比如乘客管理、計費、通知功能、支付、行程管理和驅動管理都是在一個框架內完成的。
問題陳述
當Uber開始在世界範圍擴張時，這種框架引入了各種各樣的挑戰。以下是一些突出的挑戰。
- 所有的功能都必須重新構建、部署和測試，以更新單一功能。
- 在單個儲存庫中修復bug變得非常困難，因為開發人員不得不一次又一次地修改程式碼。
- 在全球範圍內引入新功能的同時，要將這些特性進行擴充套件是相當困難的。
解決方案
為了避免此類問題，Uber決定改變自己的架構，效仿亞馬遜(Amazon)、Netflix、Twitter等其他超級增長公司。因此，Uber決定將其整體架構拆分為多個程式碼庫，以形成一個微服務架構。
參考下面的圖表，看看Uber的微服務架構。
Uber的微服務架構
- 我們在這裡看到的主要變化是引入了API閘道器，所有的司機和乘客都是通過這個閘道器連線的。從API閘道器，所有的內部點都連線在一起，如乘客管理、司機管理、行程管理等。
- 每個單元是單獨的可部署單元，執行單獨的功能。例如：如果你想在賬單微服務中更改任何內容，那麼只需部署賬單微服務，而不必部署其他服務。
- 所有的功能都是單獨擴充套件的，即每個特徵之間的相互依賴被移除。
例如，我們都知道，搜尋計程車的人數比預訂出租車和付款的人要多。這就得到了一個推論：在乘客管理微服務上工作的流程的數量超過了處理支付的流程的數量。
通過這種方式，Uber將其架構從單一業務轉移到微服務中獲益。