目錄
一、傳統架構：簡單單體模式
二、分布式架構：面向服務架構（SOA）
1、服務與SOA
2、SOA戰略
3、SOA的兩大基石：RPC和MQ
三、分布式架構：微服務架構（MSA）
什么是微服務
微服務的特點?
微服務的優點
微服務的缺點
四、SOA架構和微服務架構的區別和聯系
SOA架構特點：
微服務架構特點：
主要區別：
典型的企業級應用系統或者互聯網應用系統一般都是通過Web提供一組業務服務能力。這類系統包括：提供給用戶操作的、運行于瀏覽器中、具有UI的業務邏輯展示和輸入部分，運行于服務器端、用后端編程語言構建的業務邏輯處理部分，以及用于存儲業務數據的關系數據庫或其他類型的存儲軟件。
根據軟件系統在運行期的表現風格和部署結構，我們可以粗略地將其劃分為兩大類：
- 整個系統的所有功能單元，整體部署到同一個進程（所有代碼可以打包成1個或多個文件），我們可以稱之為“單體架構”（Monolithic Architecture）；
- 整個系統的功能單元分散到不同的進程，然后由多個進程共同提供不同的業務能力，我們稱之為“分布式架構”（Distributed Architecture）；
再結合軟件系統在整個生命周期的特點，我們可以進一步區分不同的架構風格。
對于單體架構，我們根據設計期和開發實現期的不同模式和劃分結構，可以分為：
- 簡單單體結構：代碼層面沒有拆分，所有的業務邏輯都在一個項目（project）里打包成一個二進制的編譯后文件，通過這個文件進行部署，并提供業務能力
- MVC模式：系統內每個模塊的功能組件按照不同的職責劃分為模型（Model）、視圖（View）、控制器（Controller）等角色，并以此來組織研發實現工作
- 前后端分離模式：將前后端代碼耦合的設計改為前端邏輯和后端邏輯獨立編寫實現的處理模式
- 組件模式：系統的每一個模塊拆分為一個子項目（subproject），每個模塊獨立編譯打包成一個組件，然后所有需要的組件一起再部署到同一個容器里；
- 類庫模式：A系統需要復用B系統的某些功能，這時可以直接把B系統的某些組件作為依賴庫，打包到A系統來使用
對于分布式架構，我們根據設計期的架構思想和運行期的不同結構，可以分為：
- 面向服務架構（Service Oriented Architecture，SOA）：以業務服務的角度和服務總線的方式（一般是WebService與ESB）考慮系統架構和企業IT治理
- 分布式服務架構（Distributed Service Architecture，DSA）：基于去中心化的分布式服務框架與技術，考慮系統架構和服務治理
- 微服務架構（MicroServices Architecture，MSA）：微服務架構可以看做是面向服務架構和分布式服務架構的拓展，使用更細粒度的服務（所以叫微服務）和一組設計準則來考慮大規模的復雜系統架構設計。
也有人把如上的各個架構風格總結為4個大的架構發展階段：
一、傳統架構：簡單單體模式
簡單單體模式是最簡單的架構風格，所有的代碼全都在一個項目中。這樣研發團隊的任何一個人都可以隨時修改任意的一段代碼，或者增加一些新的代碼。開發人員也可以只在自己的電腦上就可以隨時開發、調試、測試整個系統的功能。也不需要額外的一些依賴條件和準備步驟，我們就可以直接編譯打包整個系統代碼，創建一個可以發布的二進制版本。這種方式對于一個新團隊的創立初期，需要迅速開始從0到1，抓住時機實現產品最短時間推向市場，可以省去各種額外的設計，直接上手干活，爭取了時間，因而是非常有意義的。
但是這種簡單單體模式對于一個系統后期的穩定發展還是有很多壞處的：
- 簡單單體模式的系統存在代碼嚴重耦合的問題：代碼之間的相互引用，導致了系統內的對象之間相互依賴，關系混亂。修改其中的一處代碼，可能會引發一大片代碼的變化。對于經常需要修改維護的系統，很顯然會引發很大的問題。
- 簡單單體模式的系統變更對部署影響大：系統作為一個單體部署，每次發布的部署單元就是一個新版本的整個系統，系統內的任何業務邏輯調整都會導致整個系統的重新打包，部署、停機、再重啟，進而導致了系統的停機發布時間較長。每次發布上線都是生產系統的重大變更，這種部署模式大大提升了系統風險，降低了系統的可用性。
- 簡單單體模式的系統影響開發效率
- 簡單單體模式打包后的部署結構可能過于龐大：部署結構過于龐大，導致業務系統啟動很慢，進而也會影響系統的可用性。
- 擴展性受限：如果任何一個業務存在性能問題，那么都需要考慮多部署幾個完整的實例的集群，或者再加上負載均衡設備，才能保證整個系統的性能可以支撐用戶的使用。
二、分布式架構：面向服務架構（SOA）
1、服務與SOA
面向服務架構（SOA）是一種建設企業IT生態系統的架構指導思想。SOA的關注點是服務。服務最基本的業務功能單元，由平臺中立性的接口契約來定義。通過將業務系統服務化，可以將不同模塊解耦，各種異構系統間可以輕松實現服務調用、消息交換和資源共享。
各個系統的業務拆解為不同粒度和層次的模塊和服務，服務可以組裝到更大的粒度，不同來源的服務可以編排到同一個處理流程，實現非常復雜的集成場景和更加豐富的業務能力。而且系統的復用可以從以前的代碼級的粒度擴展到業務服務的粒度，能夠快速的對業務和集成需求的變更。SOA從更高的層次對真個系統機型了統一的設計和處理，對消息處理和服務調用進行監控，優化資源和配置，降低系統復雜度和綜合成本，為業務流程梳理和優化提供技術支撐。
在SOA體系下，應用軟件被劃分為具有不同功能的服務單元，并通過標準的軟件接口把這些服務聯系起來，以SOA架構實現的企業應用可以更靈活快速地響應企業業務變化，實現新舊軟件資產的整合和復用，降低軟件整體擁有成本。
2、SOA戰略
SOA的實施對整個IT生態環境都有重要的影響，作為一種重大的IT變革和技術決策，必然要自上而下的進行。必須獲得管理層的支持，由技術決策層面直接推動，并和技術部門、相關業務部門一起，根據目前各個IT業務系統的現狀，統一規劃SOA戰略和分階段目標，制定可行方案與計劃步驟，逐步推進實施。
3、SOA的兩大基石：RPC和MQ
SOA關注于系統的服務化，不同系統服務間的相互通信就成為了一個重要的話題。并且隨著RPC和MQ技術的發展，這兩種技術逐漸成為SOA的兩大基石，也是分布式技術體系里的重要基礎設施。
RPC
RPC，即 Remote Procedure Call（遠程過程調用），是一個計算機通信協議。 該協議允許運行于一臺計算機的程序調用另一臺計算機的子程序，而程序員無需額外地為這個交互作用編程。說得通俗一點就是：A計算機提供一個服務，B計算機可以像調用本地服務那樣調用A計算機的服務。
RPC的調用關系里，我們把提供具體的調用方法的系統叫服務提供者（Provider），調用服務的系統稱為服務消費者（Consumer）。把對象轉換為以便于網絡傳輸的二進制或文本數據的過程，叫做序列化（Serialization）；二進制或文本數據再還原為對象的過程，叫做反序列化（Deserialization）。 我們可以看到，典型的RPC處理機制包括兩部分：
- 通信協議，可以是基于tcp的，也可以是基于http的。
- 數據格式，一般是一套序列化+反序列化機制。
MQ
MQ（Message Queue，消息隊列） 異步的遠程調用，如果能同時存在很多個請求，該如何處理呢？進一步地，由于不能立即拿到處理結果，假若需要考慮失敗策略，重試次數等，應該怎么設計呢？ 如果有N個不同系統相互之間都有RPC調用，這時候整個系統環境就是一個很大的網狀結構，依賴關系有N*(N-1)/2個。任何一個系統出問題，都會影響剩下N-1個系統，怎么降低這種耦合呢？
基于這些問題，我們發展出來了消息隊列（MQ）技術，所有的處理請求先作為一個消息發送到MQ（一般我們叫做broker），接著處理消息的系統從MQ拿到消息并進行處理。這樣就實現了各個系統間的解耦，同時可以把失敗策略、重試等作為一個機制，對各個應用透明，直接在MQ與各調用方的應用接口層面實現即可。
一般來說，我們把發送消息的系統稱為消息生產者（message producer），接受處理消息的系統稱為消息消費者（message consumer）。
三、分布式架構：微服務架構（MSA）
什么是微服務
The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.?
通過Martin Flowler的這段微服務描述，可以抽象出以下幾個關鍵點：
- 由一些獨立的服務共同組成應用系統
- 每個服務單獨布署、獨立跑在自己的進程中
- 每個服務都是獨立的業務
- 分布式管理
通過幾個關鍵點可以看出微服務重在獨立布署和獨立業務，而所謂的微服務，并不是越小越好，而是通過團隊規模和業務復雜度由粗到細的劃分過程，所遵循的原則是松耦合和高內聚。
微服務的特點?
- 單一職責：微服務中每一個服務都對應唯一的業務能力，做到單一職責
- 微：微服務的服務拆分粒度很小，例如一個用戶管理就可以作為一個服務。每個服務雖小，但“五臟俱全”
- 面向服務：面向服務是說每個服務都要對外暴露服務接口API。并不關心服務的技術實現，做到與平臺和語言無關，也不限定用什么技術實現，只要提供Rest的接口即可
- 自治：自治是說服務間互相獨立，互不干擾
- 團隊獨立：每個服務都是一個獨立的開發團隊，人數不能過多
- 技術獨立：因為是面向服務，提供Rest接口，使用什么技術沒有別人干涉
- 前后端分離：采用前后端分離開發，提供統一Rest接口，后端不用再為PC、移動段開發不同接口
- 數據庫分離：每個服務都使用自己的數據源
- 部署獨立：服務間雖然有調用，但要做到服務重啟不影響其它服務。有利于持續集成和持續交付。每個服務都是獨立的組件，可復用，可替換，降低耦合，易維護
?
微服務的優點
1.每個微服務都很小，這樣能聚焦一個指定的業務功能或業務需求。微服務架構模式給采用單體式編碼方式很難實現的功能提供了模塊化的解決方案，由此，單個服務很容易開發、理解和維護。
2.微服務能夠被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
3.微服務是松耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的，可以加快部署速度。UI團隊可以采用AB測試，快速的部署變化。微服務架構模式使得持續化部署成為可能
4.微服務能使用不同的語言開發。
5.微服務易于被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現價值。
6.微服務允許你利用融合最新技術。
7.微服務只是業務邏輯的代碼，不會和HTML,CSS 或其他界面組件混合。
微服務的缺點
1.微服務架構可能帶來過多的操作（服務拆分）
2.需要DevOps技巧?
3.可能雙倍的努力。
4.分布式系統可能復雜難以管理。開發者需要在RPC或者消息傳遞之間選擇并完成進程間通訊機制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當然這并不是什么難事，但相對于單體式應用中通過語言層級的方法或者進程調用，微服務下這種技術顯得更復雜一些。
5.因為分布部署跟蹤問題難。
6.當服務數量增加，管理復雜性增加
7.分區的數據庫架構。商業交易中同時給多個業務分主體更新消息很普遍。這種交易對于單體式應用來說很容易，因為只有一個數據庫。在微服務架構應用中，需要更新不同服務所使用的不同的數據庫。使用分布式交易并不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴展性的NoSQL數據庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發者提出了更高的要求和挑戰。
四、SOA架構和微服務架構的區別和聯系
SOA架構特點：
- 系統集成：站在系統的角度，解決企業系統間的通信問題，把原先散亂、無規劃的系統間的網狀結構，梳理成 規整、可治理的系統間星形結構，這一步往往需要引入 一些產品，比如 ESB[企業服務總線(Enterprise Service Bus)]、以及技術規范、服務管理規范； 這一步解決的核心問題是【有序】
- 系統的服務化：站在功能的角度，把業務邏輯抽象成 可復用、可組裝的服務，通過服務的編排實現業務的 快速再生，目的：把原先固有的業務功能轉變為通用 的業務服務，實現業務邏輯的快速復用；這一步解決 的核心問題是【復用】
- 業務的服務化：站在企業的角度，把企業職能抽象成 可復用、可組裝的服務；把原先職能化的企業架構轉變為服務化的企業架構，進一步提升企業的對外服務能力；
- “前面兩步都是從技術層面來解決系統調用、系統功能復用的問題”。第三步，則是以業務驅動把一個業務單元封裝成一項服務。這一步解決的核心問題是【高效】
微服務架構特點：
1.通過服務實現組件化：開發者不再需要協調其它服務部署對本服務的影響。
2.按業務能力來劃分服務和開發團隊：開發者可以自由選擇開發技術，提供 API 服務
3.去中心化
- 每個微服務有自己私有的數據庫持久化業務數據
- 每個微服務只能訪問自己的數據庫，而不能訪問其它服務的數據庫
- 某些業務場景下，需要在一個事務中更新多個數據庫。這種情況也不能直接訪問其它微服務的數據庫，而是通過對于微服務進行操作。
- 數據的去中心化，進一步降低了微服務之間的耦合度，不同服務可以采用不同的數據庫技術（SQL、NoSQL等）。在復雜的業務場景下，如果包含多個微服務，通常在客戶端或者中間層（網關）處理。
4.基礎設施自動化（devops、自動化部署）
傳統的Java EE部署架構，通過展現層打包WARs，業務層劃分到JARs最后部署為EAR一個大包，而微服務則打開了這個黑盒子，把應用拆分成為一個一個的單個服務，應用Docker技術，不依賴任何服務器和數據模型，是一個全棧應用，可以通過自動化方式獨立部署，每個服務運行在自己的進程中，通過輕量的通訊機制聯系，經常是基于HTTP資源API，這些服務基于業務能力構建，能實現集中化管理（因為服務太多啦，不集中管理就無法DevOps啦）。
?
主要區別：
---------------------
作者：devillyd2018
來源：CSDN
原文：https://blog.csdn.net/devillyd2018/article/details/118032720
版權聲明：本文為作者原創文章，轉載請附上博文鏈接！
內容解析By：CSDN,CNBLOG博客文章一鍵轉載插件
)
