2020年微服務技術現況調查

Published in

Gemini Open Cloud 雙子星雲端

8 min readDec 20, 2020

在前一篇我們介紹了微服務架構的演進故事，這一篇就讓我們來看看，2020年的今天，微服務技術的發展現況。本篇介紹的主要內容，來自於Linux.com的報導《The state of the art of microservices in 2020》，我們會做重點翻譯，並附上我們的看法。

The state of the art of microservices in 2020 - Linux.com

"The microservice architectural style is an approach to developing a single application as a suite of small services…

www.linux.com

「微服務架構風格是一種將單個應用程式開發為一組小型服務的方法，每個小型服務都在自己的程序中運行，並以輕量的機制（通常是HTTP API）進行通訊。這些服務圍繞著業務功能而建構，並且可以由全自動地獨立部署。這些服務幾乎沒有集中管理，而且可以用不同的程式語言撰寫，並且使用不同的資料儲存技術。」 — — James Lewis and Martin Fowler (2014) [6]

簡介

在2020年，全球雲端微服務市場預期將以22.5％的速度成長，而美國市場的成長預計將達到27.4% [5]。趨勢是，開發人員將從本地託管的應用程式轉移到雲端。因此，這將幫助企業將停機時間極小化、優化資源、並降低基礎架構成本。專家還預測，到了2022年，有90%的應用程式將使用微服務架構來開發[5]。

我們的看法是：雖不敢預測微服務在本地市場的成長率，但我們也親眼見到愈來愈多的企業正在轉型到微服務架構，而跨多家公有雲、異地多集群、混合雲的部署也是愈來愈高。

微服務是什麼？

微服務是一種架構模式，該模式中的應用是基於許多小型互連服務的。根據羅伯特．C．馬丁（Robert C. Martin）的觀點，微服務應基於單一責任原則，該原則是「收集由於相同原因而發生變化的事物，並且分離由於不同原因而發生變化的事物」[2]。微服務架構還可延伸為可以獨立開發、部署和維護的鬆散耦合服務 [2]。

遠離單體架構

微服務常被拿來與傳統的單體架構 (monolithic architecture) 相比。在單體架構中，程式組件是相互連接且相互依賴的，而不是鬆散耦合的。緊密耦合的架構，也就是單體架構中，需要每個組件都存在，才能夠執行或編譯。除此之外，如果需要更新組件，整個程式需要重寫。

筆者：在我過去曾經看過，工程師把一個古老的README文字檔刪除後，整個程式就無法編譯，真的是這樣啊⋯⋯

微服務架構就不是這樣！因為每個模組都是獨立的，所以可以在不影響其他部份的情況下做變更。因此，就能減少了牽一髮而動全身的風險。

如果您公司內的單體架構應用，已經太過複雜而難以升級、太過昂貴而難維護，把它拆解成一個個獨立運作的小組件，應是這個問題的解決方案。

世界各地的開發者如何建構他們的微服務

微服務以提高可擴展性與性能而聞名。但是，這些是世界各地的開發者建構其微服務的主要原因嗎？在2020年微服務現狀研究專案[1]中，來自歐洲、北美、中南美洲、中東、東南亞、澳洲和紐西蘭的660位微服務專家，列出了微服務成熟度相關的問題的平均評分[1] ：

如上表，多數專家喜歡用微服務來解決擴展性的問題，但維護與除錯仍是挑戰。

雖然微服務的部署選擇很多，最多數(49%)的專家選擇了AWS，其次(34%)是他們自用的伺服器(on-prem)。同時，最多數(65%) 人採用Kubernetes做為服務探索(service discovery)。

調查報告也揭露了，大部份的微服務使用HTTP做為通訊，其次為事件(Event)和gRPC。

大部份人使用微服務持續整合(CI)。87%的人使用GitLab CI, Jenkins, or GitHub Actions。

最後，大多數的受訪者認為，微服務架構將成為複雜系統或後端開發的標準。

微服務的成功案例

許多公司已經從單體架構轉移到微服務架構。

Amazon

在「微服務」一詞流行之前的2001年，Amazon 就決定轉向微服務，將其單體應用拆解為小型、獨立、基於特定服務的應用[3][9]，以滿足其快速增長用戶群的可擴展性需求，此一轉變也讓Amazon Web Service 成為最早支援微服務架構的方案之一。

Netflix

2008年，Netflix經歷了一次重大的資料庫損壞，三天無法運送DVD給訂戶[10]，這讓他們意識到，單點故障(single point of failure)的風險，並開始考慮轉移至雲端。2009年，Netflix開始重構為微服務，克服了規模的挑戰與服務的中斷，也透過雲端服務以降低成本。時至今日，Netflix每天向190國家的1.39億用戶播放2.5億小時的內容。

Uber

為了快速開發和啟動新功能、快速修復錯誤，Uber 決定改用微服務，把應用程式分解為基於雲的微服務。Uber為每個功能創建了一個微服務，例如乘客管理和行程管理。轉向微服務給Uber帶來了很多好處，各團隊關注於他們需要擴展的服務，更新服務又不中斷其他服務，實現了更可靠的容錯能力，進而促進了快速擴展[11]。

我們的想法

我們十分同意，微服務架構終將成為多種核心應用系統的主流，只不過，這條轉型之路充滿了多種挑戰！

該如何在維持既有單體系統的運作下，發展新的微服務應用系統？
該如何在整個企業的應用系統中，管理單個微服務和共同管理部署大量微服務？
如何管理基於微服務API的整體業務應用性能？
如何管理一個微服務跨越既有公共雲和私有雲的混合雲環境？
如何管理容器，例如Docker，還有我們的微服務運行的主機？
該如何使用微服務架構來協助業務的拓展？

在過去幾年，我們Gemini Open Cloud協助了多個企業與組織，重構了既有的企業應用，轉型為微服務系統架構，透過了我們的API Gateway、OpenStack和Kubernetes的資源管理，提高了開發速度與品質，創造和試驗新的方案，進而促進了快速拓展。請追踪關注這個部落格，我們將持續分享 Gemini Open Cloud 在多雲管理、資源管理、微服務架構上的各種思考和答案！