微服務架構誕生的今世前生大揭秘

微服務架構介紹

• 微服務架構出現
• 微服務架構流派
• 云原生與微服務
• 總結
• 福利

近年來，微服務架構一直是互聯網技術圈的熱點之一，越來越多的互聯網應用都采用了微服務架構作為系統構建的基礎，很多新技術和理念如 Docker
、Kubernetes 、DevOps 、持續交付、Service Mesh 等也都在關注、支持和跟隨微服務架構的發展 ，
本章將會概要性地介紹微服務架構：包括微服務架構是如何演進的，微服務架構的主要流派，當前主流的云原生應用與微服務之間的關系等 ，

微服務架構的出現

從單體應用架構發展到 SOA 架構，再到微服務架構，應用架構經歷了多年的不斷演進 ， 微服務架構不是憑空產生的，而是技術發展的必然結果，分布式云平臺的應用環境使得微服務代替單體應用成為互聯網大型系統的架構選擇 ，目前，雖然微服務架構還沒有公認的技術標準和規范草案，但業界已經有了一些很有影響力的開源微服務架構解決方案，在進行微服務化開發或改造時可以進行相應的參考 ，

單體應用架構

與微服務架構對比的是傳統的單體應用 ，Web 應用程式發展的早期，大部分 Web 工程是將所有的功能模塊打包到一起部署和運行，例如 Java 應用程式打包為一個 war 包，其他語言（ Ruby 、Python 或者 C＋＋）撰寫的應用程式也有類似的做法 ， 單體應用的實作架構類似于圖1-1 中的電影售票系統 ，

這個電影售票系統采用分層架構，按照呼叫順序，從上到下為表示層、業務層、資料訪問（ DAO ）層、 DB 層 ， 表示層負責用戶體驗；業務層負責業務邏輯，包括電影、訂單和用戶 三個模塊；資料訪問層負責 DB 層的資料存取， 實作增刪改查的功能 ， 業務層定義了應用的業務邏輯，是整個應用的核心 ，

但是，隨著應用專案變得復雜 、開發團 隊不斷擴張之后，單體應用的不足和弊端將會變得很明顯，主要有如下不足：

• 可靠性：每個 bug 都可能會影響到整個應用的可靠性 ， 因為所有模塊都運行在一個行程中，任何一個模塊中 的一個 bug ，比如記憶體泄露，都可能拖垮整個行程 ，
• 復雜性高：單體應用巨大的代碼庫可能會令人望而生畏，特別是對團隊新成員來說 ， 應用難以理解和迭代，進而導致開發速度減慢 ， 由于沒有清晰的模塊邊界，模塊化會逐漸消失 ，
• 持續部署困難： 巨大的單體應用本身就是頻繁部署 的一大障礙，為了更新一個組件，必須重新部署整個應用 ， 這會中斷那些可能與更改無關的后臺任務（例如 Java 應用中的 Quartz 任務），同時可能引發其他問題 ， 另外，未被更新的組件有可能無法正常啟動 ， 重新部署會增加風險，進而阻礙頻繁更新 ，
• 擴展能力受限：單體架構只能進行一維擴展 ， 一方面，它可以通過運行多個應用服 務實體來增加業務容量，實作擴展 ，但另一方面，不同的應用組件有不同的資源需 求 ： 有的是 CPU 密集型的，有的是記憶體密集型的 ， 單體架構無法單獨擴展每個組件 ，
• 阻礙技術創新：
  單體應用往往使用統一的技術平臺或方案解決所有問題，團隊的每個成員都必須使用相同的開發語言和架構，想要引人新的框架或技術平臺非常困難 ，單體架構迫使團隊長期使用在開發初期選定的技術枝，比如選擇了 JVM 的語言， 此時以非 JVM 語言撰寫的組件就無法在該單體架構的應用中使用 ，

SOA 架構

面向服務的架構（ SOA ）是 Gartner 于 20 世紀 90 年代中期提出的 ，
2002 年 12 月，Gartner提出“面向服務的架構”是現代應用開發領域最重要的課題之一 ，
SOA 的核心主體是服務，其目標是通過服務的流程化來實作業務的靈活性 ，服務就像一堆“元器件”，這些元器件通過封裝形成標準服務，它們有相同的介面和語意表達規則 ，但服務要組裝成一個流程和應用，還需要有效的“管理”，包括如何注冊服務 、 如何發現服務、如何包裝服務的安全性和可靠性，這些就是 SOA 治理 ，SOA 治理是將 SOA 的一堆元器件進行有效組裝 ， 這是形成一個“產品”的關鍵，否則那些永遠是一堆元器件，而無法形成一個有機整體 ，

完整的 SOA 架構由五大部分組成：基礎設施服務 、 企業服務總線 、 關鍵服務組件、開發工具、管理工具等 ，

• 基礎設施： 為整個 SOA 組件和框架提供一個可靠的運行環境，以及服務組件容器，它的核心組件是應用服務器等基礎軟體支撐設施，提供運行期完整、可靠的軟體支撐 ，
• 企業服務總線： 提供可靠訊息傳輸、服務接入、協議轉換、資料格式轉換、基于內容的路由等功能，屏蔽了服務的物理位置、協議和資料格式 ，
• 關鍵服務組件：SOA 在各種業務服務組件的分類 ，
• 開發工具和管理工具： 提供完善的、可視化的服務開發和流程編排工具，包括服務的設計、開發 、 配置、部署、監控、重構等完整的 SOA專案開發生命周期 ，

微服務架構

微服務最早是由 Martin Fowler 與 Jam es Lewis 于 2014 年共同提出，需要了解細節的讀者可以閱覽 http s 😕/martinfow !er. com/arti cles/rn icroservices.h trn l ， 其實 Martin 先生并沒有給出明確的微服務定義，根據其描述，微服務的定義可以概括如下：微服務架構是一種使用一系列粒度較小 的服務來開發單個應用的方式；每個服務運行在自己的行程中；服務間采
用輕量級的方式進行通信（通常是 HTTPAPI) ；這些服務是基于業務邏輯和范圍，通過自動化部署的機制來獨立部署的，并且服務的集中管理應該是最低限度的，即每個服務可以采用不同的編程語言撰寫，使用不同的資料存盤技術 ，
如今，微服務架構已經不是一個新概念了，很多業界前沿互聯網公司的實踐表明，微服務是一種漸進式的演進架構，是企業應對業務復雜性，支持大規模持續創新行之有效的架構手段 ，

組成
微服務架構是一種比較復雜、內涵豐富的架構模式，它包含很多支撐“微”服務的具體組件和概念，其中一些常用的組件及其概念如下：

• 服務注冊與發現：
  服務提供方將己方呼叫地址注冊到服務注冊中心，讓服務呼叫方能夠方便地找到自己；服務呼叫方從服務注冊中心找到自己需要呼叫的服務的地址 ，
• 負載均衡：服務提供方一般以多實體的形式提供服務，負載均衡功能能夠讓服務呼叫方連接到合適的服務節點 ，并且，服務節點選擇的程序對服務呼叫方來說是透明的 ，
• 服務網關：服務網關是服務呼叫的唯一人口，可以在這個組件中實作用戶鑒權、動態路由、灰度發布、A/B 測驗、負載限流等功能 ，口配置中心：將本地化的配置資訊（ Properties 、 XML 、YAML等形式）注冊到配置中心，實作程式包在開發、測驗、生產環境中的無差別性，方便程式包的遷移 ，
• 集成框架：微服務組件都以職責單一的程式包對外提供服務，集成框架以配置的形式將所有微服務組件（特別是管理端組件）集成到統一的界面框架下，讓用戶能夠在統一的界面中使用系統 ，
• 呼叫鏈監控：記錄完成一次請求的先后銜接和呼叫關系，并將這種串行或并行的呼叫關系展示出來 ， 在系統出錯時，可以方便地找到出錯點 ，
• 支撐平臺：系統微服務化后，各個業務模塊經過拆分變得更加細化，系統的部署、運維、監控等都比單體應用架構更加復雜，這就需要將大部分的作業自動化 ， 現在，Docker 等工具可以給微服務架構的部署帶來較多的便利，例如持續集成、藍綠發布、健康檢查、性能健康等等 ，如果沒有合適的支撐平臺或工具，微服務架構就無法發揮它最大的功效 ，

優點
微服務架構模式有很多優勢可以有效解決單體應用擴大之后出現的大部分問題 ， 首先，通過將巨大單體式應用分解為多個服務的方法解決了復雜性 問題 ， 在功能不變的情況下，應用分解為多個可管理的模塊或服務 ， 每個服務都有一個用 RPC 或者訊息驅動 API 定義清楚的邊界 ， 微服務架構模式為采用單體式編碼方式很難實作的功能提供了模塊化的解決方案 ， 由此，單個服務變得很容易開發、理解和維護 ，
其次，微服務架構模式使得團隊并行開發得以推進，每個服務都可以由專門開發團隊來開發 ， 不同團隊的開發者可以自由選擇開發技術，提供 API 服務 ， 這種自由意味著開發者不需要被迫使用之前采用的過 時技術，他們可以選擇最新 的技術 ， 甚至于，因為服務都是相對簡單的，即使用新技術重寫以前的代碼也不是很困難的事情 ，
再次，微服務架構模式中每個微服務獨立都是部署的 ， 理想情況下，開發不需要協調其他服務部署對本服務的影響 ， 這種改變可以加快部署速度 ，ur 團隊可以采用 AB 測驗，快速地部署變化 ， 微服務架構模式使得持續化部署成為可能 ，最后 ， 微服務架構模式使得每個服務易于獨立擴展 ，

挑戰
微服務的一些想法是好的，但在實踐中也會呈現出其復雜性，具體如下 ：

• 運維要求較高 ， 更多的服務意味著需要更多的運維投入 ， 在單體架構中只需要保證一個應用的正常運行即可·而在微服務中，需要保證幾十甚至幾百個服務的正常運行與協作，這帶來了巨大的挑戰 ，
• 復雜性 ， 使用微服務構建的是分布式系統 ， 對于一個分布式系統來說，系統容錯 、網路延遲 、 分布式事務等都會帶來巨大的挑戰
• 介面調整成本高 ， 微服務之間通過介面進行通信 ， 如果修改某個微服務的 API ，可能所有使用了該介面 的微服務都需要做調整 ，
• 重復勞動
  很多服務可能都會使用到相同的功能，而這個功能并沒有達到分解為一個微服務的程度，這個時候，可能各個服務都會開發這－功能，導致代碼重復 ，
• 可測驗性的挑戰 ， 在動態環境下，服務間的互動會產生非常微妙的行為，難以進行可視化及全面測驗 ，

微服務架構的流派

常見的微服務架構方案有四種，分別是 ZeroC IceGrid 、 基于訊息 佇列 、Docker Swarm和 Spring Cloud ， 下面分別介紹這四種方案 ，
ZeroC IceGrid
ZeroC IceGrid 是基于 RPC 框架 Ice 發展而來的一種微服務架構，
Ice 不僅僅是一個 RPC框架，它還為網路應用程式提供了 一些補充服務 ，
Ice 是一個全面的 RPC 框架， 支持 C＋＋、C＃、Java 、JavaScript 、Python 等語言 ，IceGrid 具有定位、部署和管理 Ice 服務器的功能，具有良好的性能與分布式能力.

基于訊息佇列
在微服務架構的定義中講到，各個微服務之間使用“輕量級”的通信機制 ， 所謂輕量級，是指通信協議與語言無關 、 與平臺無關 ， 微服務之間的通信方式有兩種：同步和異步 ，同步方式有 RPC ,REST 等；除了標準的基于 同步通信方式的微服務架構外 ，還有基于訊息佇列異步方式通信的微服務架構 ，

Docker Swarm
Swarm 專案是 Docker 公司發布的三劍客中的一員，用來提供容器集群服務 ，目的 是更好地幫助用戶管理多個 Docker Eng ine ，方便用戶使用 ， 通過把多個 Docker Engine 聚集在一起，形成一個大的 Docker Engine ，對外提供容器的集群服務 ， 同時這個集群對外提供Swarm API ，用戶可以像使用 Docker Eng in e 一樣使用 Docker 集群 ，

Spring Cloud

Spring Cloud 是一個基于 Spring Boot 實作的 云應用開發工具，是一系 列框架的集合，當添加這些工具庫到應用后會增強應用的行為 ，Spring Boot 秉持約定優于配置的思想，因此可以利用這些組件基本的默認行為來快速入 門 ，并在需要的時候可以配置或擴展，以創建自定義解決方案 ，
Spring C l oud 利用 Spring Boot 的開發便利性，巧妙地簡化了分布式系統基礎設施的開發，如服務發現注冊、配置中心、訊息總線、負載均衡、斷路器、資料監控等，都可以基于 Spring Boot 組件進行開發，做到 一鍵啟動和部署 ，Spring Cloud 并沒有重復制造輪子，它只是將目前比較成熟、經得起實際考驗、優秀的開源服務框架組合起來，通 過 SpringBoot 進行封裝 ， 屏蔽掉復雜的配置和實作原理 ， 最終給開發者留了 一套簡單易懂、易部署和易維護的分布式系統開發工具包 ，

以下為 Spring C loud 的核心功能 ：

• 分布式／版本化配置
• 服務注冊和發現
• 服務路由
• 服務和服務之間的呼叫
• 負載均衡
• 斷路器
• 分布式訊息傳遞
  還有很多基礎的功能沒有列出，每個功能對應 S pring C loud 中的 一 個組件，包括Spring Cloud Confi g 、S p ri ng Cloud Netflix (Eureka 、Hys tri x 、Zuul 、Archaius …）、SpringCloud Bus 等組件 ，

云原生與微服務

提及云原生，首先需要了解一下 CNCF ，即云原生計算基金會，
2 015 年由谷歌牽頭成立，基金會成員目前已有一百多個企業與機構，包括亞馬遜、微軟、思科等巨頭 ，目 前CNCF 所托管的應用已達 14 個，知名的專案有 Kubernetes 、Prometheus 、Envoy 等 ，

云原生
CNCF 憲章中給出了云原生應用的三大特征，概括如下 ：

• 窯器化封裝：以容器為基礎，提高整體開發水平，形成代碼和組件重用，簡化云原生應用程式的維護 ， 在容器中運行應用程式和行程，并作為應用程式部署 的獨立單元，實作高水平資源隔離 ，
• 動態管理：通過集中式的編排調度系統來動態管理和調度 ，
• 面向微服務 ：明確服務間的依賴，互相解耦，

云原生包含了 一組應用的模式，用于幫助企業快速、持續、可靠、規模化地交忖業務軟體 ， 如圖1-7 所示， 云原生 由微服務架構、DevOps 和以容器為代表的敏捷基礎架構組成 ，

總結

單體模式開發速度很快，但是隨著五聯網用戶的高速增長，已經變得不適應如此大用戶量的應用 ， 架構的演進從單體到 SOA ，再到微服務架構，技術的發展遵循一定的規律，使得移動互聯網的發展在技術上得到了支持 ， 微服務架構是 SOA 思想的一種具體實踐 ， 微服務架構將早期的單體應用從資料存盤開始垂直拆分成多個不同的服務，每個服務都能獨立部署，獨立維護，獨立擴展，服務與服務間通過諸如 RESTful的方式互相呼叫 ，

微服務架構并不能解決所有問題，所以一定要慎重考慮何時采用微服務，只有業務復雜到一定程度的時候才適合采用微服務架構 ， 微服務的理念和框架，使得它對團隊的要求比較高，需要團隊所有成員都要認可微服務的理念和治理框架，否則執行程序中會有很多問題 ，

后續
后續將為大家詳細講解springcloud每個技術組件的使用及原理，請大家保持關注

五分鐘熟悉 SpringCloud整體架構

五分鐘學會 Spring Cloud Eureka：服務注冊與發現（小白必看，一看就會教程）

五分鐘學會 Spring Cloud Ribbon：負載均衡的服務呼叫（小白必看，一看就會教程）

五分鐘學會 Spring Cloud Hystrix：服務容錯保護（小白必看，一看就會系列教程）

五分鐘學會 Spring Cloud Zuul：API網關服務（小白必看，一看就會教程）

五分鐘學會 Spring Cloud Config：外部集中化配置管理（小白必看，一看就會教程）

五分鐘學會 Spring Cloud Sleuth：分布式請求鏈路跟蹤（小白必看，一看就會教程）

五分鐘學會 Spring Cloud Consul：服務治理與配置中心（小白必看，你看就會教程）

五分鐘學會 Spring Boot Admin：微服務應用監控（小白必看，一看就會教程）

五分鐘學會 Spring Cloud Alibaba：Nacos 作為注冊中心和配置中心使用（小白必看，一看就會教程）

五分鐘學會 Spring Cloud Alibaba：Sentinel實作熔斷與限流（小白必看，一看就會教程）

五分鐘學會 Spring Cloud Bus：訊息總線（小白必看，一看就會教程）

粉絲福利

微信搜一搜「 碼上代碼」回復【面試資料】，【技術書籍】有我準備的一線大廠面試資料和簡歷模板和java必看技術書籍

大家好，感謝各位人才
能看到這里的都是您已是佼佼者
我會持續為大家做技術分享
預知下篇如何
請點贊、收藏和評論，我們下期見！