原文地址：微服務架構概述
部落格地址：blog.720ui.com/
傳統的單體架構，使用三層架構，包括檢視表現層、業務邏輯層與資料訪問層，其劃分的目的是為了更好地規劃軟體系統的邏輯結構，便於開發與維護。單體架構將整個應用系統視為一個整體，部署在同一個 Web 容器。例如，一個 VR 資訊系統包含資訊模組、話題模組、日報模組、百科模組等多個模組，在單體架構中，所有的功能模組都在同一個應用系統中，並且共同使用一個資料庫。
單體架構的好處在於，所有的功能模組都在同一個應用系統中，非常容易開發與測試。但是，隨著系統規模的不斷擴大，業務需求的不斷迭代，系統功能的持續增加，傳統的單體架構面對的問題也越來越多，主要體現在幾個方面：
- 開發效率變低。所有的功能模組都在同一個應用系統中，團隊成員需要共同維護同一套工程程式碼，勢必增加了相應的溝通成本與協作成本。
- 維護成本增加。業務需求的不斷迭代與系統功能的持續增加，使得這個應用系統變得越來越龐大，越來越複雜。一方面，開發人員在開發功能與修復缺陷的成本變高，另一方面，新加入團隊的成員也需要花費巨大的精力去熟悉這個巨無霸的業務系統。
- 部署影響變大。系統規模的不斷擴大，帶來的另外一個後果就是構建時間變長。每次新功能版本釋出，或修復缺陷重新部署，這個過程將導致應用系統不可用，相當於系統當機，影響面較大。
- 可擴充套件性較差。應用系統作為一個業務強耦合的整體，無論是水平擴充套件還是垂直擴充套件，都存在擴充套件性問題。
- 技術選型成本高。單體架構技術選型相對而言比較單一，很難平滑替換新的技術。
隨著敏捷開發、持續交付、虛擬化技術、DevOps 理論的實踐，微服務架構應運而生，並逐漸使得應用架構朝著高可用性、可擴充套件性、可伸縮性發展的方向演進。ThoughtWorks 公司的首席科學家 Martin Fowler 對微服務進行了描述，他說到：“微服務是一種將單個應用劃分成許多小的服務來構建軟體的架構模式。每個服務執行在自己的程式中，服務與服務間採用輕量級的通訊機制互相溝通（通常是基於 HTTP 協議的 RESTful API）。每個服務都圍繞著具體業務和各自獨立的自動化部署機制構建而來。每個服務需要極少的集中管理，因此可以使用不同的程式語言以及不同的儲存技術。”。Martin Fowler 還列舉了微服務的九個特徵，包括通過服務實現元件化、圍繞業務能力進行組織、基於產品而不是專案、智慧端點與啞管道、去中心化治理、去中心化資料管理、基礎設施自動化、為故障而生、演進的設計。如果對Martin Fowler 的微服務描述感興趣，可以閱讀 martinfowler.com/articles/mi…
請讀者思考，微服務的拆分粒度多小，才能算是“微”?一般情況下，拆分粒度應該保證微服務具有業務的獨立性與完整性，因此微服務的拆分圍繞業務模組進行拆分。那麼，這裡將 VR 資訊系統進行服務拆分，分為資訊系統、話題系統、日報系統、百科系統四個微服務系統，每個微服務獨立使用一個資料庫。
微服務帶來的價值，主要體現在幾個方面：
- 每個微服務易於開發和維護，便於溝通與協作，很適合小團隊敏捷開發與持續交付。
- 每個微服務職責單一，高內聚、低耦合。同時，每個微服務能夠獨立開發、獨立執行、獨立部署。
- 每個微服務之間是獨立的，如果某個服務部署或者當機，只會影響到當前服務，而不會對整個業務系統產生影響。
- 每個微服務可以隨著系統規模的不斷擴大，面對海量使用者和高併發，獨立做水平擴充套件與垂直擴充套件。
- 每個微服務可以使用不同的程式語言以及不同的儲存技術，使得我們更容易嘗試新的技術。此外，對單個服務進行業務重構，也不會面臨很大的業務負擔與技術債卷。
微服務不是銀彈，它也帶來了一些技術的複雜度。因此，我們需要思考與解決分散式的複雜性、事務的一致性、服務的管理與運維、服務的自動化部署等解決方案。
總結下，隨著系統規模的不斷擴大，業務需求的不斷迭代，系統功能的持續增加，傳統的單體架構面對的問題也越來越多。並且網際網路產品需求變化快、使用者量大，傳統的單體架構顯得力不從心。而隨著敏捷開發、持續交付、虛擬化技術、DevOps 理論的實踐，微服務架構取代了傳統的單體架構，將單個應用劃分成許多小的服務，服務與服務間採用基於 HTTP 協議的 RESTful API 通訊。在收穫微服務帶來的價值的同時，需要解決微服務帶來的一些技術的複雜度問題。
（完）
更多精彩文章，盡在「服務端思維」微信公眾號！