《企業級容器云架構開發指南》—2.2.3　完整微服務系統包含的功能

2.2.3　完整微服務系統包含的功能

一個完整的微服務系統應該包含哪些功能？其實微服務的關鍵不僅僅是微服務本身，而是系統要提供一套基礎架構，這種架構使得微服務可以獨立地部署、運行、升級，不僅如此，這個系統架構還讓各個微服務之間在結構上實現“松耦合”，在功能上則表現為一個統一的整體。這種所謂的“統一的整體”表現出來的是統一風格的界面、統一的權限管理、統一的安全策略、統一的上線過程、統一的日志和審計方法、統一的調度方式、統一的訪問入口等。

從圖2-18我們可以看出，一個完整的微服務系統應該包括一個基座，要有日志和審計、監控和告警、消息（輕量級MQ或HTTP）、注冊發現、負載均衡、事件調度，只有把這些基座都完成了，才可以在上面部署一個個的業務微服務。基座之上，我們要考慮外部和服務之間如何暴露API，外部請求只能通過服務網關來訪問微服務，所有關于微服務相應的流控、安全、訪問健全管理都會在這個網關上完成。

圖2-18　完整的微服務所包含的功能

我們對外暴露了很多API，那么外部如何找到關于這些API的定義？API的每個動作都會有什么樣的輸入和輸出？配合API網關，會有一個統一的文檔框架，這個文檔框架應該是開源的，也是一個工具集，大家可以不再去找擁有這些微服務的個人，而是直接找公司的主體，一般運營商都會對外有一個開放的門戶，其中會定義對外開放了哪些能力，通過文檔框架可找到開放了哪些能力。

一個基座、一個訪問控制是整體微服務的根基。同時要有集成自動化、測試自動化、部署自動化，要有一個自動化流水線，這是為微服務團隊的開發和集成部署服務的。另外，配合配置管理、代碼管理、灰度發布，也要有相應的工具集。一般來講，一個生產系統差不多會有3～4套環境，即一套開發環境、一套上線環境和一套對外真正的生產環境，有時還會有對外的性能測試環境。如果3～4套環境部署在不同的機房和不同的IDC里面，而每一次的配置如果是通過人工去完成的，那么為了一次性能測試，可以想象我們可能需要好幾天時間來提前準備環境、測試和數據。但如果我們將配置預先寫好，底層也是基于容器化的資源管理，那么為某一種測試建立一套環境就會簡單很多，也無須用3～4天的時間預先準備一個環境，配置實際上主要是為了在這種多環境下實時部署。

無論是敏捷還是DevOps，我們認為最大的好處是上線和停機，7×24小時，一天做100個版本，但不能忽視其根本——灰度發布，我們必須先把環境進行分區，當想發布新版本的時候，會把請求路由到其中一個區，升級另外的分區，升級完成后再把請求升級到新分區，所以至少要有一個基本的灰度發布分區。總體來說，我們最終希望實現的完整的微服務系統需要先有一個框，然后再解構原來單體的功能，最后再部署微服務，這是一個有先后順序的過程。

OpenStack 云計算

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。