微服務架構的演進故事

在軟體吃掉世界的時代，大型複雜軟體系統也衍生了許多開發、維護、規格化的問題，而在今天，微服務 (Microservices) 的架構成為最時尚的新寵，似乎軟體系統的複雜性問題都將迎刃而解，不過，在開始談微服務之前，讓我們先來回顧這些年來，軟體架構演變的歷史，看看我們是如何走到今天的吧！

在90年代，企業應用系統是大一統的單體 (Monolithic) 架構，所有的服務都打包在一起，集中在單個應用程序中，用戶界面、資料存取、資料儲存層都是緊密耦合，因為當時的應用系統，注定要部署到一個巨大而且是垂直擴展的機器上，例如Mainframe大型主機。想當年，「敏捷開發」一詞還沒問世，添加程式功能和修正錯誤相當困難，也無力於改用更好框架與技術，可靠性也低。

接著，我們有了Client-Server的架構，應用程式漸漸從Mainframe大型主機遷移到更為靈活的client端和伺服器上，然後的虛擬化技術，能夠在一個實體伺服器的多個虛擬機器上運行我們的應用程式，因此，我們開始將應用程式拆解成多層，化為數個可被單獨部署的服務。這種服務部署方式，隨著「服務導向架構」(Service-Oriented Architecture) 的倡導而愈來愈普及，應用服務開始有了不同的角色；但是在這個階段，雖然虛擬機的單價已經比實體的伺服器便宜許多，但是相關的成本仍然很高，因此企業應用能夠使用的虛擬機器數目仍然有限，不易進一步地拆解服務。

然後，雲端運算開始進入企業的IT基礎架構中，我們能夠用更小的虛擬機，更靈活地大量擴展，進而滿足我們的負載，讓我們可以再進一步地分解應用程式。此時我們發現，雲端基礎架構上的虛擬機器，其啟動速度仍然不夠快，大多是以秒級或者是分鐘級的啟動速度，這使我們意識到，我們還需要更小的部署粒度，以更快速回應工作負載的需求。

在過去幾年中，像Docker這樣的容器化技術引入企業基礎架構後，大大地鼓舞了我們將應用程式分解為微服務(Microservices)，再搭配上敏捷與DevOps的開發方法，似乎軟體架構的複雜問題都將解決！微服務是一種非常小的服務，它具有明確定義而且開放的服務界面，可以單做一件事，並且把它做得很好。這種架構上的典範轉移為我們帶來了非常多的好處，像是：

• 獨立性，保證了軟體系統可被拆解而平行開發，可以更頻繁地進行迭代開發並部署。
• 可擴展性，透過增加計算資源，提升整個微服務集群的服務能力。
• 隔離性，任何一個微服務的錯誤都只會影響自己，避開了牽一髮而動全身的痛。

讓我們舉個例子來看看，微服務架構對於管理面的影響：

如果我們公司在做一個電商系統，某個團隊負責開發「我的帳戶」微服務，讓用戶查詢變更自己的資料，只要我們維護好它的API界面協議，就可以自由地增加這個服務的功能，而不會無意間破壞了整個系統的其他相關部份，像是「購物車」微服務或「身份驗證」微服務，而在過去，部署的粒度很大，相關功能很可能會被「我的帳戶」微服務的變更而影響的。既然「我的帳戶」微服務可以自由部署而不影響其他元件，換句話說，開發「我的帳戶」微服務的團隊可以與其他元件分開部署，並可以按照不同的發佈時間表來進行部署。

不僅如此，由於每個微服務都與其他應用程式元件分開部署，這也意味著我們的每個微服務都是可以各自獨立擴展的。舉例來說，「身份驗證」微服務比「我的帳戶」微服務承受了更大的工作負載，為了更好地回應用戶要求，有更好的服務能力，我們可以為「身份驗證」微服務部署更多的容器。

微服務架構鼓勵我們平行開發、經常部署，這有助於我們實現長期以來一直追求的敏捷開發精神，快速地提供價值予我們的客戶。然而，微服務架構下，可能會有數百甚至數千個微服務，這為微服務的管理、部署以及性能方面，都帶來了新的挑戰，因此，如何正確地應用微服務架構，成為軟體業界思考的重要難題。好比說：

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

請追踪關注這個部落格，我們將持續分享 Gemini Open Cloud 在多雲管理、資源管理、微服務架構上的各種思考和答案！

作者簡介

Jonathan 於軟體業服務多年，待過上千人的軟體公司，也曾經在新創團隊中打拼，管理過各種產品開發專案，例如企業級的資安軟體、軟硬整合的一體機、還有軟體定義儲存。熟悉企業IT環境與應用，現為雙子星雲端的產品負責人。

除了熱愛的產品與專案管理工作，Jonathan 也曾以「喲哪桑」的筆名在網路媒體發表一系列軟體專案與產品管理的文章，同時也是台灣敏捷社群與Agile Tour的志工，曾在多場社群活動和IT論壇擔任主講人。