從Uber微服務看最佳實踐如何煉成？
導讀：Uber成長非常迅速，工程師團隊快速擴充，據說Uber有2000名工程師，8000個代碼倉庫，部署了1000多個微服務。微服務架構是Uber應對技術團隊快速增長，功能快速上線很出色的解決方案。本文偏向微服務的入門篇，以Uber微服務為例，進行了深入淺出的講解。
微服務特性
對於微服務沒有適當的定義，你可以說它是一個框架，由小型的、獨立的可部署的服務組成，執行不同的操作。
微服務專註於單個業務領域，可以作為完全獨立的可部署服務，並在不同的技術棧上實現它們。
單體架構和微服務架構區別
在使用微服務構建自己的應用程序之前，需要清楚地了解應用程序的範圍和功能。
微服務特性
- 解耦 - 系統內的服務在很大程度上是解耦的。因此，整個應用程序可以輕松構建，更改和縮放
- 組件化 - 微服務被視為獨立的組件，可以輕松替換和升級
- 業務能力 - 微服務非常簡單，專註於單一功能
- 自治 - 開發人員和團隊可以獨立工作，從而提高速度
- 持續交付 - 通過軟件創建，測試和批準的系統自動化，允許軟件的頻繁發布
- 責任 - 微服務不像項目那樣專註於應用程序。相反，他們將應用程序視為他們負責的產品
- 分散治理 - 重點在於使用正確的工具來完成正確的作業。這意味著沒有標準化模式或任何技術模式。開發人員可以自由選擇最有用的工具來解決他們的問題
- 敏捷 - 微服務支持敏捷開發。任何新功能都可以快速開發並再次丟棄
微服務優勢
- 獨立開發 - 所有微服務都可以根據各自的功能輕松開發
- 獨立部署 - 基於各自的服務，可以單獨部署在任何應用程序中
- 故障隔離 - 即使應用程序的一項服務不起作用，系統仍會繼續運行
- 混合技術堆棧 - 可以使用不同的語言和技術來構建同一應用程序的不同服務
- 細粒度縮放 - 各個組件可根據需要進行擴展，無需將所有組件擴展到一起
微服務設計最佳實踐
在當今世界，復雜性已經滲透到產品中。微服務架構能夠更好地保持團隊的規模和功能。
以下是微服務設計的最佳實踐:
現在，讓我們來看一個用例來更好地理解微服務。
案例：購物車應用程序
當打開購物車應用程序時，你看到的只是一個網站。但是，在幕後，購物車應用程序有接受支付服務、顧客服務等等。
假設開發人員已經在一個整體框架中進行了創建。如下圖:
購物車應用程序的整體框架
所有功能都放在一個代碼庫中，並在一個底層數據庫下。
現在，假設市場上出現了一個新品牌，開發人員希望將這個品牌的所有細節都放在這個應用程序中。
他們不僅要重新為新標簽提供服務，還必須重新構建完整的系統並進行相應部署。
為了應對這種挑戰，開發人員決定將其應用程序從單體架構轉移到微服務。如下圖：
購物車應用程序的微服務架構
這意味著開發人員不必創建Web微服務，邏輯微服務或數據庫微服務。相反，他們為搜索，推薦，客戶服務等創建單獨的微服務。
這種應用架構不僅有助於開發人員克服以前架構面臨的挑戰，還有助於輕松構建，部署和擴展購物車應用程序。
微服務設計指南
- 作為開發人員，決定構建應用程序時，要將各個域分離，並在功能上明確。
- 設計的每一個微服務都只專註於應用中的一個服務。
- 確保設計的應用程序使每個服務都可以單獨部署。
- 確保微服務之間的通信是通過無狀態服務器完成的。
- 每一項服務都可以被推進到更小的服務中，擁有自己的微服務。
在設計微服務時，已經了解了基本的指導方針，現在來了解一下微服務的架構。
微服務架構是如何工作的 ?
一個典型的微服務架構(MSA)應該包括以下組件：
- 客戶端
- 身份提供者
- API網關
- 消息格式
- 數據庫
- 靜態內容
- 管理
- 服務發現
如下圖：
微服務架構
這個架構看起來有點復雜，讓我們來簡化一下。
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的單體架構
上圖描述了UBER之前的架構。
- 與乘客和司機連接的REST API。
- 三種不同的適配器與API一起使用，當預定出租車時，執行諸如賬單、付款、發送電子郵件/消息等操作。
- MySQL數據庫存儲所有數據。
因此，可以發現這裏所有的特性，比如乘客管理、計費、通知功能、支付、行程管理和驅動管理都是在一個框架內完成的。
問題陳述
當Uber開始在世界範圍擴張時，這種框架引入了各種各樣的挑戰。以下是一些突出的挑戰。
- 所有的功能都必須重新構建、部署和測試，以更新單一功能。
- 在單個存儲庫中修復bug變得非常困難，因為開發人員不得不一次又一次地修改代碼。
- 在全球範圍內引入新功能的同時，要將這些特性進行擴展是相當困難的。
解決方案
為了避免此類問題，Uber決定改變自己的架構，效仿亞馬遜(Amazon)、Netflix、Twitter等其他超級增長公司。因此，Uber決定將其整體架構拆分為多個代碼庫，以形成一個微服務架構。
參考下面的圖表，看看Uber的微服務架構。
Uber的微服務架構
- 我們在這裏看到的主要變化是引入了API網關，所有的司機和乘客都是通過這個網關連接的。從API網關，所有的內部點都連接在一起，如乘客管理、司機管理、行程管理等。
- 每個單元是單獨的可部署單元，執行單獨的功能。例如：如果你想在賬單微服務中更改任何內容，那麽只需部署賬單微服務，而不必部署其他服務。
- 所有的功能都是單獨擴展的，即每個特征之間的相互依賴被移除。
例如，我們都知道，搜索出租車的人數比預訂出租車和付款的人要多。這就得到了一個推論：在乘客管理微服務上工作的流程的數量超過了處理支付的流程的數量。
通過這種方式，Uber將其架構從單一業務轉移到微服務中獲益。
原文鏈接：
- 1、What Is Microservices – Introduction To MicroserviceArchitecture
- 2、Microservice Architecture – Learn, Build and Deploy Microservices
原文鏈接：https://mp.weixin.qq.com/s/-xaC4icfGh1T047-oBCDlQ
版權歸作者所有，轉載請註明出處
從Uber微服務看最佳實踐如何煉成？