服務端指南 服務端概述 | 微服務架構概述

原文地址：微服務架構概述
博客地址：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 通訊。在收穫微服務帶來的價值的同時，須要解決微服務帶來的一些技術的複雜度問題。

（完）

更多精彩文章，盡在「服務端思惟」微信公衆號！