從Uber微服務看最佳實踐如何煉成？

微服務特性

對於微服務沒有適當的定義，你能夠說它是一個框架，由小型的、獨立的可部署的服務組成，執行不一樣的操做。

微服務專一於單個業務領域，能夠做爲徹底獨立的可部署服務，並在不一樣的技術棧上實現它們。

在使用微服務構建本身的應用程序以前，須要清楚地瞭解應用程序的範圍和功能。

• 解耦 - 系統內的服務在很大程度上是解耦的。所以，整個應用程序能夠輕鬆構建，更改和縮放
• 組件化 - 微服務被視爲獨立的組件，能夠輕鬆替換和升級
• 業務能力 - 微服務很是簡單，專一於單一功能
• 自治 - 開發人員和團隊能夠獨立工做，從而提升速度
• 持續交付 - 經過軟件建立，測試和批准的系統自動化，容許軟件的頻繁發佈
• 責任 - 微服務不像項目那樣專一於應用程序。相反，他們將應用程序視爲他們負責的產品
• 分散治理 -重點在於使用正確的工具來完成正確的做業。這意味着沒有標準化模式或任何技術模式。開發人員能夠自由選擇最有用的工具來解決他們的問題
• 敏捷 - 微服務支持敏捷開發。任何新功能均可以快速開發並再次丟棄

微服務優點

• 獨立開發 - 全部微服務均可以根據各自的功能輕鬆開發
• 獨立部署 - 基於各自的服務，能夠單獨部署在任何應用程序中
• 故障隔離 - 即便應用程序的一項服務不起做用，系統仍會繼續運行
• 混合技術堆棧 - 可使用不一樣的語言和技術來構建同一應用程序的不一樣服務
• 細粒度縮放 - 各個組件可根據須要進行擴展，無需將全部組件擴展到一塊兒

微服務設計最佳實踐

在當今世界，複雜性已經滲透到產品中。微服務架構可以更好地保持團隊的規模和功能。

如下是微服務設計的最佳實踐:

如今，讓咱們來看一個用例來更好地理解微服務。

案例：購物車應用程序

當打開購物車應用程序時，你看到的只是一個網站。可是，在幕後，購物車應用程序有接受支付服務、顧客服務等等。

假設開發人員已經在一個總體框架中進行了建立。以下圖:

全部功能都放在一個代碼庫中，並在一個底層數據庫下。

如今，假設市場上出現了一個新品牌，開發人員但願將這個品牌的全部細節都放在這個應用程序中。

他們不只要從新爲新標籤提供服務，還必須從新構建完整的系統並進行相應部署。

爲了應對這種挑戰，開發人員決定將其應用程序從單體架構轉移到微服務。以下圖：

這意味着開發人員沒必要建立Web微服務，邏輯微服務或數據庫微服務。相反，他們爲搜索，推薦，客戶服務等建立單獨的微服務。

這種應用架構不只有助於開發人員克服之前架構面臨的挑戰，還有助於輕鬆構建，部署和擴展購物車應用程序。

推薦一個交流學習羣：478030634 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

微服務設計指南

• 做爲開發人員，決定構建應用程序時，要將各個域分離，並在功能上明確。
• 設計的每個微服務都只專一於應用中的一個服務。
• 確保設計的應用程序使每一個服務均可以單獨部署。
• 確保微服務之間的通訊是經過無狀態服務器完成的。
• 每一項服務均可以被推動到更小的服務中，擁有本身的微服務。

在設計微服務時，已經瞭解了基本的指導方針，如今來了解一下微服務的架構。

推薦一個交流學習羣：478030634 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

微服務架構是如何工做的 ?

一個典型的微服務架構(MSA)應該包括如下組件：

1. 客戶端
2. 身份提供者
3. API網關
4. 消息格式
5. 數據庫
6. 靜態內容
7. 管理
8. 服務發現

以下圖：

這個架構看起來有點複雜，讓咱們來簡化一下。

一、客戶端

架構始於不一樣類型的客戶端，從不一樣的設備嘗試執行各類管理功能，如搜索、構建、配置等。

二、身份提供者

這些來自客戶端的請求將傳遞給身份提供者，這些提供者對客戶端的請求進行身份驗證，並將請求傳遞給API網關。而後，請求經過定義良好的API網關與內部服務通訊。

三、API網關

因爲客戶端不直接調用服務，所以API網關做爲客戶端將請求轉發到適當的微服務的切入點。

使用API網關的優勢包括:

全部服務均可以在客戶端不知情的狀況下進行更新。
服務也可使用非網絡友好的消息傳遞協議。
API網關可執行跨切割功能，如提供安全性、負載均衡等。
在接收到客戶端的請求後，內部架構由微服務組成，這些微服務經過消息相互通訊來處理客戶端請求。

四、消息格式

有兩種類型的消息經過它們進行通訊：

同步消息：在客戶端等待服務響應的狀況下，微服務一般傾向於使用REST (Representational State Transfer)，由於它依賴於無狀態、客戶端服務器和HTTP協議。這個協議被用做一個分佈式環境，每一個功能都用一個資源來表示，以執行操做。
異步消息：在客戶端不等待服務響應的狀況下，微服務一般傾向於使用AMQP、STOMP、MQTT等協議。這些協議在這種類型的通訊中使用，由於消息的性質被定義，這些消息在實現之間能夠互操做。
下一個問題是，使用微服務的應用程序如何處理數據?

五、數據處理

每一個微服務都擁有一個專有數據庫來捕獲它們的數據並實現相應的業務功能。此外，微服務的數據庫只經過其服務API進行更新。參考下圖：

微服務提供的服務被轉發到任何支持不一樣技術棧的進程間通訊的遠程服務。

六、靜態內容

在微服務內部進行通訊後，將靜態內容部署到基於雲的存儲服務，經過內容交付網絡（CDN）直接將其交付給客戶端。

除了上述組件，還有一些其餘組件出如今典型的微服務架構中。

七、管理

該組件負責平衡節點上的服務和故障識別。

八、服務發現

用做微服務的指南，以找到它們之間的通訊路由，由它維護節點所在的服務列表。

如今來看看這個架構的優缺點，以更好地理解什麼時候使用這種架構。

微服務架構優缺點

下面來比較一下UBER以前和如今的架構。

Uber微服務案例

Uber以前的架構

像許多初創公司同樣，UBER在開始之初在單一城市運營，爲單一產品打造了單體架構。當時有一個代碼庫彷佛被清理了，並解決了UBER的核心業務問題。然而，隨着UBER在全球範圍內擴張，它們在可擴展性和持續集成方面面臨各類各樣的問題。

上圖描述了UBER以前的架構。

• 與乘客和司機鏈接的REST API。
• 三種不一樣的適配器與API一塊兒使用，當預約出租車時，執行諸如帳單、付款、發送電子郵件/消息等操做。
• MySQL數據庫存儲全部數據。

所以，能夠發現這裏全部的特性，好比乘客管理、計費、通知功能、支付、行程管理和驅動管理都是在一個框架內完成的。

問題陳述

當Uber開始在世界範圍擴張時，這種框架引入了各類各樣的挑戰。如下是一些突出的挑戰。

• 全部的功能都必須從新構建、部署和測試，以更新單一功能。
• 在單個存儲庫中修復bug變得很是困難，由於開發人員不得不一次又一次地修改代碼。
• 在全球範圍內引入新功能的同時，要將這些特性進行擴展是至關困難的。

解決方案

爲了不此類問題，Uber決定改變本身的架構，效仿亞馬遜(Amazon)、Netflix、Twitter等其餘超級增加公司。所以，Uber決定將其總體架構拆分爲多個代碼庫，以造成一個微服務架構。

參考下面的圖表，看看Uber的微服務架構。

• 咱們在這裏看到的主要變化是引入了API網關，全部的司機和乘客都是經過這個網關鏈接的。從API網關，全部的內部點都鏈接在一塊兒，如乘客管理、司機管理、行程管理等。
• 每一個單元是單獨的可部署單元，執行單獨的功能。例如：若是你想在帳單微服務中更改任何內容，那麼只需部署帳單微服務，而沒必要部署其餘服務。
• 全部的功能都是單獨擴展的，即每一個特徵之間的相互依賴被移除。

例如，咱們都知道，搜索出租車的人數比預訂出租車和付款的人要多。這就獲得了一個推論：在乘客管理微服務上工做的流程的數量超過了處理支付的流程的數量。

經過這種方式，Uber將其架構從單一業務轉移到微服務中獲益。