更好地理解微服務架構，並舉例這種架構好處，以及Uber如何將它們的單體應用變成微型服務。
在這個文章中，您將深入瞭解架構概念，並使用Uber的案例研究來實現它們。
你將瞭解以下內容：
Microservice架構的定義
微服務體系結構的關鍵概念
微服務體系結構的優缺點
Uber微服務案例研究
您可以參考“什麼是微服務（https://www.edureka.co/blog/what-is-microservices/）”來了解微服務的基本原理和好處。
還沒有微服務/微服務體系結構的正確定義，但是您可以說，它是一個由執行不同操作的小型、單獨部署的服務組成的框架。
微服務關注單個業務領域，這些業務領域可以作為完全獨立的可部署服務實現，並在不同的技術堆棧上實現它們。
請參考上面的圖表來理解單體架構和微服務架構之間的區別。為了更好地理解這兩個體系結構之間的差異，您可以參考我以前的文章，看看什麼是微服務。
為了讓您更好地理解，讓我告訴您微服務體系結構的一些關鍵概念。
微服務體系結構的關鍵概念
在開始使用微服務構建自己的應用程序之前，您需要清楚應用程序的範圍和功能。
以下是在討論微服務時要遵循的一些指導方針。
1、作為一名開發人員，當您決定構建一個應用程序時，要將各個業務領域分離，並在功能上明確。
2、您設計的每個微服務應該只專注於應用程序的一個服務。
3、確保您每個服務都是單獨部署的。
4、確保微服務之間的通信是通過無狀態服務器完成的。
5、每個服務都可以被重構為更小的服務，擁有自己的微服務。
現在，您已經閱讀了設計微服務時的基本指導方針，讓我們瞭解微服務的體系結構。
微服務框架如何工作？
一個典型的微服務框架microservice architecture (MSA)應該具有以下的組件：
- 客戶端Clients
- 標識提供者Identity Providers
- API網關API Gateway
- 消息格式Messaging Formats
- 數據庫Databases
- 靜態內容Static Content
- 管理Management
- 服務發現Service Discovery
參考下圖：
我知道這個架構看起來有點複雜，但是讓我來簡單的說一下。
1.客戶端Clients
體系結構從不同類型的客戶端開始，不同的設備嘗試執行各種管理功能，如搜索、構建、配置等。
2. 身份提供者Identity Providers
然後，來自客戶機的這些請求被傳遞給身份提供者，身份提供者對客戶機的請求進行身份驗證，並將請求傳遞給API網關。然後，請求通過定義良好的API網關與內部服務通信。
3. API 網關（Gateway）
由於客戶端不直接調用服務，因此API網關作為客戶端向適當的微服務提出請求的入口點。
所有的服務都可以在客戶不知情的情況下進行更新。
服務還可以使用不支持web的消息傳遞協議。
API網關可以實現安全、負載均衡等橫切功能。
在接收到客戶端的請求後，內部體系結構由微服務組成，這些微服務通過消息相互通信來處理客戶端request.ts將請求轉發給適當的微服務。
4. 消息格式Messaging Formats
他們通過兩種類型信息進行交流：
- 同步消息:在客戶機等待服務響應的情況下，微服務通常使用REST(Representational State Transfer)，因為它依賴於無狀態、客戶機-服務器和HTTP協議。這個協議被用作一個分佈式環境，每個功能都用一個資源來表示，以執行操作。
- 異步消息: 在客戶端不需要等待服務響應的情況下，微服務通常傾向於使用AMQP、STOMP、MQTT等協議。這些協議用於這種類型的通信，因為定義了消息的性質，並且這些消息必須在實現之間可互操作。
您可能會想到的下一個問題是，使用微服務的應用程序如何處理它們的數據?
5. 數據處理
每個微服務都有一個私有數據庫來存儲它們的業務數據並實現各自的業務功能。此外，微服務的數據庫只能通過其服務API進行更新。
參考下圖：
微服務處理數據-微服務體系結構
微服務提供的服務支持不同技術堆棧的進程間通信。
6. 靜態內容
在微服務內部進行通信之後，它們將靜態內容部署到基於雲的存儲服務，該服務可以通過內容交付網絡(CDNs)將其直接交付給客戶端。
除了上述組件外，典型的微服務體系結構中還存在一些其他組件:
7. 管理組件
該組件負責平衡節點上的服務和識別故障。
8. 服務發現
作為微服務指南，在維護節點所在的服務列表時查找它們之間的通信路徑。
現在，讓我們看看這個體系結構的優缺點，以便更好地理解何時使用這個體系結構。
微服務體系結構的優缺點
參考下表：
讓我們通過比較優步公司之前的架構和現在的架構來了解更多關於微服務的內容。
Uber 樣例學習
Uber's 之前的架構設計
與許多初創公司一樣，優步的起步之路也是建立在單一城市的單一服務基礎上的。當時，擁有一個代碼庫似乎很乾淨，解決了優步的核心業務問題。然而，隨著Uber開始在全球擴張，它們在可擴展性和持續集成方面面臨著各種問題。
上圖描述了Uber以前的架構。
1、乘客和司機使用REST API進行連接通信。
2、其中有三個不同的適配器與API一起使用，用於執行諸如計費、付款、發送電子郵件/消息等操作，我們在預訂出租車時看到德這些操作。
3、一個MySQL數據庫，用來存儲所有數據。
所以，你在這裡注意到的所有的功能，如乘客管理、計費、通知功能、支付、旅行管理和司機管理都是在一個框架內實現的。
問題陳述
當優步開始在全球擴張時，這種框架帶來了各種挑戰。以下是一些突出的挑戰
1、所有的功能都必須重新構建、部署和反覆測試才能更新單個功能點。
2、在一個存儲庫中修復bug變得極其困難，因為開發人員必須一次又一次地修改代碼。
3、在全球範圍內同時擴展功能和引入新功能是非常困難的。
解決方案
為了避免此類問題，優步決定效仿亞馬遜(Amazon)、Netflix、推特(Twitter)等其他高速增長公司，技術改變架構。因此，Uber決定將其單體架構分解為多個代碼庫，形成一個微服務架構。
請參考下面的圖表，查看Uber微服務體系結構：
1、我們在這裡觀察到的主要變化是引入了API網關，所有司機和乘客通過該網關連接。從API網關用來連接所有的內部單元節點，如乘客管理、司機管理、出行管理等。
2、這些單元節點是獨立的可部署單元，用來執行不同的功能。
例如：如果您想在賬單微服務中更改任何內容，那麼只需部署賬單微服務，而不必部署其他服務。
3、現在所有的功能都被單獨地縮放了，也就是說，每個功能之間的相互依賴性都被刪除了。
例如，我們都知道，搜索出租車的人數要比預訂出租車和付款的人數要多。
這就會得到一個推論：在乘客管理微服務上工作的流程的數量超過了處理支付的流程的數量。
通過這種方式，優步受益於其架構從單一服務向微服務的轉變。
我希望您喜歡閱讀這篇文章，任何建議請您評論區留言。
閱讀更多 程序你好 的文章
