微服務架構的演變

文章目錄

• 微服務架構的演變
• 單體架構（Monolithic）
• SOA 架構（Service Oriented Architecture）
• 微服務架構（MicroServices）
• 架構的演進
• 微服務&分佈式關係
• 微服務&分佈式理解

微服務架構的演變

引言

• 微服務是一種服務間鬆耦合的、每一個服務之間高度自治而且使用輕量級協議進行通訊的可持續集成部署的分佈式架構體系
• 那麼，微服務架構又與其它架構有何區別?

單體架構（Monolithic）

• 單體架構是最簡單的軟件架構，經常使用於傳統的應用軟件開發以及傳統 Web 應用，適用於用戶業務不復雜、訪問量較小的時候，甚至能夠將應用服務、數據庫、文件服務器部署在一臺服務器上（相信不少人都這麼幹過，^_）

• (MVC)三層設計模型（表示層、業務邏輯處理層、數據訪問層）：

  • 表示層：一般理解爲用於和用戶交互的視圖層；
  • 業務邏輯處理層：用戶提交請求，通過業務邏輯層處理後，對用戶請求做出響應；
  • 數據庫訪問層：主要用於操做數據庫。

• 缺點：

  • 隨着業務愈來愈複雜，單體應用代碼量急劇膨脹，最終致使代碼可 讀性、可維護行和可擴展性得不到保證；
  • 隨着用戶訪問量增長，單體應用的併發能力有限；
  • 隨着系統代碼量的劇增，當修改應用程序或者新增需求時，測試難度成指數級增加；
  • 部署效率低下（即便是一個很小的改動，也須要將全部機器上的應用所有部署一遍）， 增長運維複雜度；
  • 技術選型單一。

留白

• 在某個陽光明媚、風和日麗的日子裏，使用單體架構發現很難推動需求的開發、以及日積月累的技術債，終於爆發了，不少企業開始作單體服務的拆分，拆分的方式通常有水平拆分和垂直拆分，逐漸演變出了SOA（Service Oriented Architecture）架構， SOA 一出世，便被賦予了重大使命…

SOA 架構（Service Oriented Architecture）

• SOA是個什麼鬼？

  • SOA 是一種粗粒度、鬆耦合服務架構，服務之間經過簡單、精肯定義接口進行通信，不涉及底層編程接口和通信模型。SOA 能夠看做是 B/S 模型、XML（標準通用標記語言的子集）/Web Service 技術以後的天然延伸。

• 你說了這麼多，但我仍是不知道SOA是個什麼鬼啊？你能說的通熟易懂點兒麼？

  • 單體服務若是至關於一個快餐店，老闆（堪稱全能）又要負責收銀結算，又要負責作漢堡，又要負責端盤子，又要負責打掃，用戶來了後，老闆從前到後負責到底（累死我的喲）。SOA 至關於老闆按需招聘了些許服務員，有職責分工，收銀員負責收銀，廚師負責作漢堡，保潔阿姨負責打掃（老闆沒事處處轉悠轉悠，曬曬太陽什麼的，解放本身，坐等數票票）等，全部服務員須要用同一種語言交流，方便工做協調。

• 有什麼優勢嗎？

  • 把模塊（即服務）拆分，使用接口通訊，下降模塊之間的耦合度；
  • 把項目拆分紅若干個子項目，不一樣的團隊負責不一樣的子項目；
  • 增長功能時只須要再增長一個子項目，調用其它系統的接口就能夠；
  • 能夠靈活的進行分佈式部署。

• 說了這麼多優勢，不可能一點缺點都沒有吧，不要王婆賣瓜自賣自詡哈…

  • 和單體架構相比，增長了系統複雜度，系統總體性能有較大影響;
  • 多服務數據通訊協議之間轉換過程複雜，容易形成 ESB（Enterprise Service Bus）性能瓶頸。

SOA架構圖

• ESB 架構

  • 簡單說下， ESB 就像一根管道，用來鏈接各個服務節點。ESB的存在是爲了集成基於不一樣協議的不一樣服務，ESB 作了消息的轉化、解釋以及路由的工做，以此來讓不一樣的服務互聯互通;
  • 舉個栗子: 當業務愈來愈複雜，調用關係亂成一團， ESB 現身梳理了梳理各類應用系統的複雜關係，調用關係就會清析不少（具體參照圖片）

ESB架構圖(簡)

總結

• balabala… 說了一坨亂七八糟的東西以後，咱們說一說SOA 到底解決了咱們的那些問題：
  • 系統間的集成【有序】
    • 站在系統角度， 首先要解決的是各個系統之間的通訊問題， 目的是將原先系統間散亂、無規劃的網狀結構，梳理成規整、可治理的星形結構，這步的實現每每須要引入一些概念和規範，好比 ESB、以及技術規範、服務管理規範
  • 系統的服務化【複用】
    • 站在功能角度， 提出問題： 那麼多業務就沒有通用的嗎？若是有，怎麼抽象出通用業務邏輯，目的是要把原先固有的業務功能抽象設計爲通用的業務服務、實現業務邏輯的快速複用;
  • 業務的服務化【高效】
    • 站在全局角度，前面兩步都是從技術層面來解決系統調用、系統功能複用的問題，咱們須要在業務層面，目的是封裝某一業務單元爲服務，

微服務架構（MicroServices）

• 微服務的概念是 Martin Flower 在2014年寫的一篇論文《MicroServices》中提出來的，其主要特色是：

  • 每一個服務按照業務劃分；
  • 服務之間經過輕量級 API 調用；
  • 可使用不一樣語言開發；
  • 可使用不一樣的數據存儲技術；
  • 可獨立部署，服務之間互相不影響；
  • 可針對用戶訪問流量大的服務單獨擴展，從而可以節約資源；
  • 管理自動化。

• 主要挑戰：

  • 微服務粒度大小難以劃分，須要設計人員對業務有很好的掌握；
  • 分佈式複雜性，主要體如今分佈式事務、網絡延遲、系統容錯等問題解決難度較大；
  • 微服務之間通訊成本較高，對微服務之間網絡穩定性、通訊速度要求較高；
  • 因爲微服務數量較大，運維人員運維、部署有較大的挑戰

• 微服務架構和 SOA 架構很是相似,微服務只是的 SOA 昇華，只不過微服務架構強調的是「業務須要完全的組件化及服務化」，原單個業務系統會被拆分爲多個能夠獨立開發、設計、部署運行的小應用。這些小應用間經過服務化完成交互和集成。 組件表示的就是一個能夠獨立更換和升級的單元，就像 PC 中的 CPU、內存、顯卡、硬盤同樣，獨立且能夠更換升級而不影響其餘單元。若咱們把 PC 中的各個組件以服務的方式構 建，那麼這臺 PC 只須要維護主板（能夠理解爲ESB）和一些必要的外部設備就能夠。CPU、內存、硬盤等都是以組件方式提供服務，例如PC 須要調用 CPU 作計算處理，只需知道 CPU 這個組件的地址就能夠了。

綜上，按照咱們本身的理解，能夠抽檢出幾個關鍵詞來表達對微服務的理解與開展

鬆耦合

DDD（領域驅動設計）的思想進行設計領域模型，服務間儘可能減小同步的調用，多使用消息的方式讓服務間的領域事件來進行解耦

輕量級協議

更傾向於使用 Restful 風格的 API，輕量級的協議能夠很好地支持跨語言開發的服務，而且Restful 風格的API 便於理解

高度自治和持續集成

微服務能夠很好得和容器技術結合，容器技術比微服務出現得晚，可是容器技術的出現讓微服務的實施更加簡
    便，目前 Docker 已經成爲不少微服務實踐的基礎容器， 由於容器的特點，因此一臺機器上能夠部署幾十個、
    幾百個不一樣的微服務。若是某個微服務流量壓力比其餘微服務大，能夠在不增長機器的狀況下，在一臺機器上
    多分配一些該微服務的容器實例。同時，由於 Docker 的容器編排社區日漸成熟，相似 Mesos、Kubernetes 及 
    Docker 官方提供的 Swarm 均可以做爲持續集成部署的技術選擇

架構的演進

• 方向
  • 輕量級、靈活，甚至於 Serverless（無服務）架構
  • 單體 ——> 分層 ——> 面向服務 ——> 微服務 ——> Serverless（無服務）

微服務&分佈式關係

• 微服務架構屬於分佈式系統嗎？那必須得是啊…
• 做爲一個微服務，給其餘人使用，不得保證高可用啊，而後分佈式就自個兒蹦出來了…
• 微服務的分佈式不只僅是容器應用層面的分佈式，其爲了高度自治，底層的存儲體系也應該互相獨立，而且也不是全部的微服務都須要持久化的存儲服務

微服務&分佈式理解

• 怎樣理解微服務中的分佈式？以公司來舉例說明，一個公司內，多個部門，各司其職，相互配合，各自佔據一塊區域，有些東西呢，只有該部門的人能使用，而有些呢，全部人都會使用，有些呢，本身部門沒有，其它部門卻擁有，既有專屬資源，又有共享資源，同時共享資源還得考慮各類使用要求什麼的，大抵是這樣子
• 微服務的分佈式不只僅是容器應用層面的分佈式，其爲了高度自治，底層的存儲體系也應該互相獨立，而且也不是全部的微服務都須要持久化的存儲服務
• 微服務中的分佈式場景除了服務自己須要有服務發現、負載均衡，微服務依賴的底層存儲也會有分佈式的場景：爲了高可用性和性能須要處理數據庫的複製、分區，而且在存儲的分庫狀況下，微服務須要能保證分佈式事務的一致性。

---

若有錯誤，請留言或及時聯繫，感謝閱讀 – end –