微服務是什么？有什么優缺點？

這篇文章的知識點包括：微服務的概念、微服務的優缺點、微服務的架構以及微服務的使用示例，閱讀完整文相信大家對微服務會有一定的認識。

什么是微服務

• 微服務 (Microservices) 是一種軟件架構風格，將應用程序構造為圍繞業務的小型自治服務的集合

• 微服務以專注于單一責任與功能的小型功能區塊 (Small Building Blocks) 為基礎。每個服務都是獨立的，并實現單個業務功能

• 微服務利用模塊化的方式組合出復雜的大型應用程序，各功能區塊使用與語言無關的 API 集相互通信

• 微服務運用了以業務功能為主導的設計概念，應用程序在設計時就能先以業務功能或流程設計先行分割，將各個業務功能都獨立實現成一個能自主運行的個體服務，然后再利用相同的協議將所有應用程序需要的服務都組合起來，形成一個應用程序

微服務例子1

• 以購物車應用程序為例，當打開購物車應用程序時，您看到的只是一個網站。但是，在后臺，購物車應用程序具有用于接受付款服務，客戶服務等

• 假設此應用程序的開發人員使用了單體框架，架構如下圖
  

• 如圖，在單體架構中，所有功能都放在一個代碼庫中，并在一個基礎數據庫下

• 現在，假設市場上出現了一個新品牌，并且開發人員希望將即將到來的品牌的所有詳細信息放入此應用程序中

• 此時，不僅需要處理新品牌的服務，而且還必須重新構建整個系統并相應地進行部署。為了避免此類挑戰，開發人員決定將其應用程序從單體架構轉換為微服務

• 開發人員為搜索，推薦，客戶服務等創建了單獨的微服務

• 此微服務架構不僅可以幫助開發人員克服以前的架構所面臨的所有挑戰，而且還可以輕松地構建，部署和擴展購物車應用程序

微服務例子2

• 以旅游行業應用程序為例
  
  

• 整體服務包括了旅客關系管理、付款、消息通知等服務

• 傳統的單體常常采用如上圖所示的整體式架構，并采取MVC的設計模式

• 三層架構（MVC）的具體內容如下

• 表示層（view）： 用戶使用應用程序時，看到的、聽見的、輸入的或者交互的部分。

• 業務邏輯層（controller）： 根據用戶輸入的信息，進行邏輯計算或者業務處理的部分。

• 數據訪問層（model）： 關注有效地操作原始數據的部分，如將數據存儲到存儲介質（如數據庫、文件系統）及

• 從存儲介質中讀取數據等。

• 雖然現在程序被分成了三層，但只是邏輯上的分層，并不是物理上的分層。也就是說，對不同層的代碼而言，經過編譯、打包和部署后，所有的代碼最終還是運行在同一個進程中
  單體架構在規模比較小的情況下工作情況良好，但是隨著系統規模的擴大，它暴露出來的問題也越來越多，主要有以下幾點：

• 復雜性逐漸變高

• 比如有的項目有幾十萬行代碼，各個模塊之間區別比較模糊，邏輯比較混亂，代碼越多復雜性越高，越難解決遇到的問題

• 技術債務逐漸上升

• 公司的人員流動是再正常不過的事情，有的員工在離職之前，疏于代碼質量的自我管束，導致留下來很多坑，由于單體項目代碼量龐大的驚人，留下的坑很難被發覺，這就給新來的員工帶來很大的煩惱，人員流動越大所留下的坑越多，也就是所謂的技術債務越來越多

• 維護成本大

• 當應用程序的功能越來越多、團隊越來越大時，溝通成本、管理成本顯著增加。當出現 bug 時，可能引起 bug 的原因組合越來越多，導致分析、定位和修復的成本增加；并且在對全局功能缺乏深度理解的情況下，容易在修復bug 時引入新的 bug

• 持續交付周期長

• 構建和部署時間會隨著功能的增多而增加，任何細微的修改都會觸發部署流水線。新人培養周期長：新成員了解背景、熟悉業務和配置環境的時間越來越長

• 技術選型成本高

• 單塊架構傾向于采用統一的技術平臺或方案來解決所有問題，如果后續想引入新的技術或框架，成本和風險都很大

• 可擴展性差

• 隨著功能的增加，垂直擴展的成本將會越來越大；而對于水平擴展而言，因為所有代碼都運行在同一個進程，沒辦法做到針對應用程序的部分功能做獨立的擴展

微服務架構

• 將上面的整體架構改造為如上圖所示的微服務

• 來自不同設備的不同客戶端嘗試使用不同的服務，例如搜索，構建，配置和其他管理功能

• 所有服務均根據其功能進行分離，并進一步分離為單個微服務

• 這些微服務具有自己的負載均衡和執行環境以執行其功能,并在其自己的數據庫中捕獲數據

• 微服務之間通過無狀態服務器(REST、GRPC或消息總線)進行通信

• 微服務借助服務發現來了解其通信路徑并執行自動化，監控等操作功能

• 微服務執行的所有功能通過API網關傳達給客戶端

微服務特點

• 解耦

• 系統中的服務在很大程度上是解耦的。因此，整個應用程序可以輕松構建，更改和擴展

• 組件化

• 微服務被視為獨立的組件，可以輕松替換和升級

• 專注業務功能

• 業務功能–微服務非常簡單，專注于單一功能

• 獨立自主

• 開發人員和團隊可以彼此獨立地工作，從而提高了速度

• 持續交付

• 通過自動化的構建、測試和部署，允許頻繁發布軟件

• 分散治理

• 重點是使用正確的工具完成正確的工作。這意味著沒有標準化模式或任何技術模式。開發人員可以自由選擇最有用的工具來解決他們的問題

• 敏捷開發

• 微服務支持敏捷開發。任何新功能都可以快速開發并丟棄

微服務的優點

• 單一職責

• 微服務架構中的每個服務，都是具有業務邏輯的，符合高內聚、低耦合原則以及單一職責原則的單元，不同的服務通過“管道”的方式靈活組合，從而構建出龐大的系統

• 輕量級通信

• 服務之間通過輕量級的通信機制實現互通互聯，而所謂的輕量級，通常指語言無關、平臺無關的交互方式

• 對于輕量級通信的格式而言，我們熟悉的 XML 和 JSON，它們是語言無關、平臺無關的；對于通信的協議而言，通常基于 HTTP，能讓服務間的通信變得標準化、無狀態化。目前大家熟悉的 REST（Representational StateTransfer）、GRPC是實現服務間互相協作的輕量級通信機制之一。使用輕量級通信機制，可以讓團隊選擇更適合的語言、工具或者平臺來開發服務本身

• 提高容錯性（fault isolation），一個服務的內存泄露并不會讓整個系統癱瘓

• 獨立性

• 服務獨立測試、部署、升級、發布

• 在單塊架構中所有功能都在同一個代碼庫，功能的開發不具有獨立性；當不同小組完成多個功能后，需要經過集成和回歸測試，測試過程也不具有獨立性；當測試完成后，應用被構建成一個包，如果某個功能存在 bug，將導致整個部署失敗或者回滾

• 新技術的應用，系統不會被長期限制在某個技術棧上

• 可以根據市場需求，靈活多變的組合出新的業務場景

• 降低代碼耦合度

• 服務實例水平擴展，服務單一職責，功能獨立。保證可靠性與性能，提升資源利用

• 由于微服務是以業務功能導向的實現，因此不會受到應用程序的干擾，微服務的管理員可以視運算資源的需要來配置微服務到不同的運算資源內，或是布建新的運算資源并將它配置進去

• 提升開發交流，每個服務足夠內聚，足夠小，代碼容易理解

• 進程隔離、故障隔離

• 單塊架構中，整個系統運行在同一個進程中，當應用進行部署時，必須停掉當前正在運行的應用，部署完成后再重啟進程，無法做到獨立部署 有時候我們會將重復的代碼抽取出來封裝成組件，在單塊架構中，組件通常的形態叫做共享庫（如 jar 包或者DLL），但是當程序運行時，所有組件最終也會被加載到同一進程中運行。

  • 在微服務架構中，應用程序由多個服務組成，每個服務都是高度自治的獨立業務實體，可以運行在獨立的進程中，不同的服務能非常容易地部署到不同的主機上

• 即使應用程序的一項服務不起作用，系統仍然可以繼續運行

• 數據分區，數據獨立，可靠性保證

微服務的缺點

• 微服務提高了系統的復雜度

• 開發人員要處理分布式系統的復雜性

• 服務之間的分布式事務問題

• 服務的注冊與發現問題

• 數據隔離再來的報表處理問題

• 不同服務實例的管理困難，持續自動化部署的要求

• 運維要求較高

• 對于單體架構來講，我們只需要維護好這一個項目就可以了，但是對于微服務架構來講，由于項目是由多個微服務構成的，每個模塊出現問題都會造成整個項目運行出現異常，想要知道是哪個模塊造成的問題往往是不容易的，因為我們無法一步一步通過debug的方式來跟蹤，這就對運維人員提出了很高的要求

• 分布式的復雜性

• 對于單體架構來講，我們可以不使用分布式，但是對于微服務架構來說，分布式幾乎是必會用的技術，由于分布式本身的復雜性，導致微服務架構也變得復雜起來

• 接口調整成本高

• 比如，用戶微服務是要被訂單微服務和電影微服務所調用的，一旦用戶微服務的接口發生大的變動，那么所有依賴它的微服務都要做相應的調整，由于微服務可能非常多，那么調整接口所造成的成本將會明顯提高

微服務的溝通

溝通與事件廣播

微服務的規劃與單體式應用程序十分不同，微服務中每個服務都需要避免與其他服務有所牽連，且都要能夠自主，并在其他服務發生錯誤時不受干擾
倘若真有溝通，也應采用異步溝通的方式來避免緊密的相依性問題。要達到此目的，則可用下列兩種方式：

• 事件存儲中心（Event Store）
  這可以讓你在服務集群中廣播事件，并且在每個服務中監聽這些事件并作處理，這令服務之間沒有緊密的相依性，而這些發生的事件都會被保存在事件存儲中心里。這意味著當微服務重新上線、部署時可以重播（Replay）所有的事件。這也造就了微服務的數據庫隨時都可以被刪除、摧毀，且不需要從其他服務中獲取數據

• 消息隊列（Message Queue）

• 能夠在服務集群中廣播消息，并傳遞到每個服務中

• 比較有名的消息中間件如：NSQ、RabbitMQ、Nats、Kafka

• A 服務上廣播一個事件，此事件可以順帶一些數據。B 服務可以監聽這個事件并在接收到之后有所處理。這些過程都是異步處理的

• A 服務并不需要等到 B 服務處理完該事件后才能繼續，而這也代表 A 服務無法獲取 B 服務的處理結果

• 與事件存儲中心不同的是：消息隊列并不會保存事件。一旦事件被消化（接收）后就會從隊列中消失

服務發現

• 單個微服務在上線的時候，會向服務注冊中心注冊自己的 IP 位置、服務內容

• 當服務需要調用另一個服務的時候，會去詢問服務探索中心該服務的 IP 位置，得到位置后即可直接向目標服務發起調用

• 這么做的用意是可以統一集中所有服務的位置，就不會分散于每個微服務中

• 服務發現中心可以每隔一段時間就向微服務進行健康檢查（TCP 調用、HTTP 調用、Ping）

• 倘若該服務在時間內沒有回應，則將其從服務中心移除，避免其他微服務對一個無回應的服務進行調用

• 即便微服務重新在其他ip上部署，其他服務也是無感知的

• 比較常用的服務發現有：etcd，consul，普遍都采用了raft等分布式算法

微服務其他需要考慮的因素

• 網絡延遲

• 分布式事務

• 限流

• 例如一個服務掛掉后，上游服務或者用戶一般會習慣性地重試訪問。這導致一旦服務恢復正常，很可能因為瞬間網絡流量過大又立刻掛掉

• 因此服務需要能夠自我保護——限流。限流策略有很多，最簡單的比如當單位時間內請求數過多時，丟棄多余的請求。另外，也可以考慮分區限流。僅拒絕來自產生大量請求的服務的請求

• 熔斷

• 當一個服務因為各種原因停止響應時，調用方通常會等待一段時間，然后超時或者收到錯誤返回

• 如果調用鏈路比較長，可能會導致請求堆積，整條鏈路占用大量資源一直在等待下游響應。所以當多次訪問一個服務失敗時，應熔斷，標記該服務已停止工作，直接返回錯誤。直至該服務恢復正常后再重新建立連接

• 服務降級

• 當Service A調用Service B，失敗多次達到一定閥值，Service A不會再去調Service B，而會去執行本地的降級方法

• 降級服務其實就是犧牲掉一些邏輯處理，或者停止部分依賴服務的請求。以保障服務可以提供關鍵能力

• 權限控制

• API網關

• 分布式追蹤

• 分布式日志記錄

• 配置中心

• 關微服務就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果喜歡這篇文章，不如把它分享出去讓更多的人看到。