系統應用架構演變（轉載）

0.      ORM應用

就是全部的都寫在一塊兒 ，這裏就不作解釋了吧，

1.      傳統的垂直應用的架構：

就是咱們如今企業中最經常使用的MVC架構，它有一個主要的特色就是技術單一，開發上手快，測試，部署都是比較簡單的

MVC的三層結構：

a．  最前端的是V(view),主要是用於前端頁面展現，使用jsp,js,html+css等

b．  中間爲調度控制層（Control）,主要是用於前端web請求的分發，而後調度後臺的邏輯執行，能夠經過struts2或者spring mvc來實現

c．  第三層爲應用模型層（Model），模型是應用程序上的字體部分，模型表明了業務邏輯和業務數據

標準的MVC模式並不包含數據訪問層，在開發中咱們有一些架構能夠解決這個問題，好比使用了咱們的ORM(對象關係映射框架)來實現與數據庫的訪問，可使用mybatis和hebernate,這倆個框架都不一樣程度的封裝了JDBC

這種垂直架構面臨的挑戰：

1.      複雜應用開發的維護成本很高，部署效率低

2.      團隊合做弱，多個項目的或者同一個項目的公共模塊重複開發，增長了代碼量的冗餘

3.      系統可靠性下降，隨業務的不斷增長，訪問量增大，網絡流量增大，數據庫鏈接增多，這都是將要面臨的問題

4.      維護困難：業務代碼不斷加大，功能不斷加多，在這種垂直的架構中沒法對已有的服務拆分，改一個地方，其它地方會有影響

2.      RPC架構

RPC架構可讓遠程過程（服務）調用更加簡單、透明，RPC框架負責屏蔽底層的傳輸方式（TCP或者是UDP）、序列化方式（XML、JSON、二進制）和一些通訊的細節，開發者不須要關心具體的通訊細節和調用過程

RPC架構的核心技術：

1.      遠程服務提供者須要以某種形式提供服務調用相關的信息，包括但不侷限於服務接口定義、數據結構，或者中間態的服務定義文件，服務調用者須要經過必定的途徑獲取遠程服務調用相關信息。

2.      遠程代理對象：服務調用者調用的服務實際是遠程服務的本地代理，對於咱們的java來講其實就是jdk的動態代理，經過動態代理的攔截機制，將本地調用封裝成遠程服務調用

3.      通訊：RPC框架與具體的協議無關

4.      序列化

RPC架構面臨的挑戰：

隨着服務愈來愈多的時候，服務間依賴關係變得錯綜複雜，服務的調用量愈來愈大，服務的容量問題就會暴露出來了，某個服務在那個機器上，何時該增長節點，這都是問題

將業務服務化後，隨之而來的就是服務治理的問題，目前業界開源的RPC框架的服務治理能力都不是很健全，當應用大規模服務化後會面臨許多服務治理方面的挑戰，須要解決這些問題，必須經過服務框架+服務治理來完成，但憑RPC框架就比較吃力了

3.      SOA服務化架構

SOA是一種粗粒度，鬆耦合的以服務爲中心的架構，接口間經過定義明確的協議和接口進行通訊。它能夠更加從容地應對複雜企業系統集成和需求的快速變化

SOA面向服務的通常原則總結以下

1.      服務和複用

2.      服務共享一個標準的契約：好比說一個接口

3.      服務間是鬆耦合的

4.      服務是底層邏輯的抽象：只有經服務契約所暴露的服務對外部可見，契約外的底層邏輯實現是不可見的

5.      服務是能夠組合的：多個服務能夠被編排組合成一個新的服務

6.      服務是自治的不依賴其它服務

7.      服務是能夠被自動發現的:服務發佈上線後，容許被其它消費者自動發現

SOA架構面臨的挑戰：

SOA架構解決了應用服務化的問題，隨着服務化實踐的不斷深刻，服務規模愈來愈大，服務治理面臨的挑戰也是愈來愈多

4.      微服務架構例如dubbo/springcloud

微服務架構是一種服務化架構風格，經過將功能分散到各個離散的服務中以實現對解決方案的解耦

微服務的主要特徵以下：

1.      原子服務，專一於作一件事情，與面向對象中的「單一職責原則」相似，實現高內聚，低耦合

2.      高密度部署：重要的服務能夠獨立進程部署，非核心服務能夠獨立打包，合設到統一進程中去，服務被高密度部署

3.      敏捷交付：服務由小研發團隊負責設計、開發、測試、部署、線上治理運維整個服務的生命週期

4.      微治理：服務足夠小，功能單一，能夠獨立打包、部署、升級。不依賴其它的服務，實現了局部自治

這就是咱們應用架構的演進，從耦合到微服務，便於管理和服務的治理