單體到微服務架構服務演化過程

聊聊從單體到微服務架構服務演化過程

單體分層架構

在 Web 應用程式發展的早期，大部分工程是將所有的服務端功能模塊打包到單個巨石型（Monolith）應用中，譬如很多企業的 Java 應用程式打包為 war 包，最終會形成如下的架構：

巨石型應用易於搭建開發環境、易於測試、易於部署；其缺陷也非常明顯，無法進行局部改動與部署，編譯時間過長，回歸測試周期過長，開發效率降低等。集中式架構分為標準的三層：數據訪問層、服務層和 Web 層。

在 Web2.0 時代剛剛流行的時候，互聯網應用與企業級應用並沒有本質的區別，集中式架構分為標準的三層：數據訪問層、服務層和 Web 層。

• 數據訪問層用於定義數據訪問介面，實現對真實資料庫的訪問；
• 服務層用於對應用業務邏輯進行處理；
• Web 層用於處理異常、邏輯跳轉控制、頁面渲染模板等。

面向服務架構 - SOA

SOA（Service-Oriented Architecture） 面向服務架構，是在互聯網應用規模迅速增長，集中式架構已無法做到無限制地提升系統的吞吐量的背景下，產生的涉及模塊化開發、分散式擴展部署等相對寬泛的概念。

SOA 是一個組件模型，它將應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的介面和契約聯繫起來。SOA 中的介面獨立於實現服務的硬體平臺、操作系統和編程語言，採用中立的方式進行定義。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行交互。面向服務架構，它可以根據需求通過網路對鬆散耦合的粗粒度應用組件進行分散式部署、組合和使用。服務層是 SOA 的基礎，可以直接被應用調用，從而有效控制系統中與軟體代理交互的人為依賴性。

實施 SOA 的關鍵目標是實現企業 IT 資產的最大化作用。要實現這一目標，就要在實施 SOA 的過程中牢記以下特征：可從企業外部訪問、隨時可用、粗粒度的服務介面分級、鬆散耦合、可重用的服務、服務介面設計管理、標準化的服務介面、支持各種消息模式、精確定義的服務契約。

服務消費者（Service Consumer）可以通過發送消息來調用服務，這些消息由一個服務匯流排（Service Bus）轉換後發送給適當的服務實現。這種服務架構可以提供一個業務規則引（Business Rules Engine），該引擎容許業務規則被合併在一個服務里或多個服務里。這種架構也提供了一個服務管理基礎（Service Management Infrastructure），用來管理服務，類似審核，列表（billing），日誌等功能。此外，該架構給企業提供了靈活的業務流程，更好地處理控制請求（Regulatory Requirement），例如 Sarbanes Oxley（SOX），並且可以在不影響其他服務的情況下更改某項服務。

由於分散式系統十分複雜，因此產生了大量的用於簡化分散式系統開發的分散式中間件和分散式資料庫，服務化的架構設計理念也被越來越多的公司所認同。如下是 Dubbo 官方文檔公佈了一張有關 SOA 系統演化過程的圖片：

微服務架構 - Microservices

微服務（Microservices Architecture Pattern）由 Martin Fowler 在 2014 年提出的，是希望將某個單一的單體應用，轉化為多個可以獨立運行、獨立開發、獨立部署、獨立維護的服務或者應用的聚合，從而滿足業務快速變化及分散式多團隊並行開發的需求。如康威定律（Conway’s Law）所言，任何組織在設計一套系統（廣義概念）時，所交付的設計方案在結構上都與該組織的通信結構保持一致，微服務與微前端不僅僅是技術架構的變化，還包含了組織方式、溝通方式的變化。

對於微服務，不同背景的人也有不同的見解，對於熟悉 SOA 的開發者，微服務也可以認為是去除了 ESB 的 SOA 的一種實現方案；ESB 是 SOA 架構中的中心匯流排，設計圖形應該是星形的，而微服務是去中心化的分散式軟體架構。SOA 更多強調重用，而微服務偏向於重寫。SOA 偏向水平服務，微服務偏向垂直服務；SOA 偏向自上而下的設計，微服務偏向自下而上的設計。

微服務與微前端原理和軟體工程，面向對象設計中的原理同樣相通，都是遵循單一職責(Single Responsibility)、關註分離(Separation of Concerns)、模塊化(Modularity)與分而治之(Divide & Conquer)等基本的原則。從巨石型應用到微服務的衍化也並非一蹴而就，如下圖也演示了簡單的漸進式替代過程：

雲原生架構 - Cloud Native

雲原生是通過構建團隊、文化和技術，利用自動化和架構來管理系統的複雜性和解放生產力。— Joe Beda，Heotio CTO，聯合創始人

Pivotal 是雲原生應用的提出者，並推出了 Pivotal Cloud Foundry 雲原生應用平臺和 Spring 開源 Java 開發框架，成為雲原生應用架構中先驅者和探路者。早在 2015 年 Pivotal 公司的 Matt Stine 寫了一本叫做遷移到雲原生應用架構的小冊子，其中探討了雲原生應用架構的幾個主要特征：符合 12 Factors 應用、面向微服務架構、自服務敏捷架構、基於 API 的協作以及抗脆弱性。2015 年 Google 主導成立了雲原生計算基金會（CNCF），起初 CNCF 對雲原生（Cloud Native）的定義包含以下三個方面：應用容器化、面向微服務架構、應用支持容器的編排調度。

雲原生應用程式簡單地定義為從頭開始為雲計算架構而構建應用程式；這意味著，如果我們將應用程式設計為預期將部署在分散式、可擴展的基礎架構上，我們的應用程式就是雲原生的。隨著公共雲將承載越來越多的算力，未來雲計算將是主流的 IT 能力交付方式，CNCF 也對雲原生進行了重新定義：雲原生技術有利於各組織在公有雲、私有雲和混合雲等新型動態環境中，構建和運行可彈性擴展的應用；雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。

• Codeless 對應的是服務開發，實現了源代碼托管，你只需要關註你的代碼實現，而不需要關心你的代碼在哪，因為在整個開發過程中你都不會感受到代碼庫和代碼分支的存在。
• Applicationless 對應的是服務發佈，在服務化框架下，你的服務發佈不再需要申請應用，也不需要關註你的應用在哪。
• Serverless 對應的則是服務運維，有了 Serverless 化能力，你不再需要關註你的機器資源，Servlerless 會幫你搞定機器資源的彈性擴縮容 這些技術組合搭配，能夠構建容錯性好、易於管理和便於觀察的松耦合系統；再結合可靠的自動化手段，雲原生技術能夠使工程師輕鬆地對系統作出頻繁和可預測的重大變更。由此可見，雲原生是保障系統能力靈動性地有效抓手；雲原生技術有利於各組織在公有雲、私有雲和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。微服務架構非常適合雲原生應用程式；但是，雲原生同樣存在著一定的限制，如果你的雲原生應用程式部署在 AWS 等公有雲上，則雲原生 API 不是跨雲平臺的。

雲原生應用的關鍵屬性包括了：使用輕量級的容器打包、使用最合適的語言和框架開發、以松耦合的微服務方式設計、以 API 為中心的交互和協作、無狀態和有狀態服務在架構上界限清晰、不依賴於底層操作系統和伺服器、部署在自服務、彈性的雲基礎設施上、通過敏捷的 DevOps 流程管理、自動化能力、通過定義和策略驅動的資源分配。雲原生是分散式應用當下重要的發展路徑，其終態應當是 Distributionless，所有與分散式相關的問題由雲平臺解，分散式應用的開發會跟傳統應用的開發一樣方便，甚至更加便捷。

作者|頂尖架構師棧

本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/Service-Evolution-Process-from-Monomer-to-Microservice-Architecture.html