架構是邏輯上的設計模式，而框架則是具體的實現。一個架構模式上，可能會使用到多個框架。
一、架構的演變
架構的演變是根據業務量的急速擴張對技術要求不斷的加深而產生的。如果細粒度的劃分可以有很多路線，我一般將演變過程大體上分爲這幾類：
單體架構 -----> 分佈式架構 -----> SOA(面向服務架構) ------> 微服務
1.傳統的三層架構
在傳統的架構中，SSH,SSM，主要分爲web 控制層，業務邏輯層，數據庫訪問層，單點項目，項目沒有拆分，所有的開發任務全部寫在一個項目中，耦合度比價高，如果程序中的一個功能出現了問題，所導致的就是整個服務掛掉。
2.SOA 架構
因爲傳統項目的耦合度比較高，所以架構的發展逐步面向服務化，將共同的業務邏輯抽取出來，形成一個服務，可以供其他服務所調用，服務和服務之間的調用通過RPC遠程調用（底層就是httpclient技術）。
SOA 架構中通常使用xml 實現通訊，xml 比較重，佔寬帶，相對冗餘，在高併發情況下，很受影響。底層是使用webservice 技術，ESB 消息總站。
3.微服務架構
Springcloud 就是微服務架構，是由SOA 架構發展而來，沒有ESB 總站的傳輸方式，採用http + json 輕量級的傳輸方式。
微服務的架構比SOA更加的輕量級。
微服務架構中，服務的獨立性更加的強，可以有獨立數據庫，獨立的緩存、數據庫、消息隊列等資源，保障服務與服務之間更加的不受影響。
微服務架構中，服務化的粒度更加的精細，所以，更加適合敏捷開發。
二、一些常用的框架介紹
根據框架在體系的不同作用，主要可以分爲：
服務治理（註冊中心）：Dubbo (阿里巴巴)、Dubbox(噹噹網在Dubbo繼續開發的)、Eureka（已經閉源了）、consul
分佈式配置中心：disconf（百度）、Netfix的Archaius、360的QConf、SpringCloud Config、攜程的阿波羅等
分佈式任務調度平臺：xxl-job
服務跟蹤：hyra（京東)、springcloud的sleuth等
從市面上目前的使用情況來看，dubbo以及springcloud活躍度是很高的，所以針對性的介紹一下以及它們之間的異同。
1.什麼是dubbo,原理是什麼？
Dubbo是一款高性能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向接口的遠程方法調用，智能容錯和負載均衡，以及服務自動註冊和發現。
主要核心部件:
- Remoting:網絡通信框架，實現了 sync-over-async 和 request-response 消息機制；
- RPC: 一個遠程過程調用的抽象，支持負載均衡、容災和集羣功能；
- Registry: 服務目錄框架用於服務的註冊和服務事件發佈和訂閱。
工作原理:
dubbo官網的架構設計提供了一張整體的框架圖，10個層級看起來挺嚇人的。但是其核心總結起來就是：Microkernel + Plugin（微內核+插件）。
- Provider 暴露服務方稱之爲“服務提供者”。
- Consumer 調用遠程服務方稱之爲“服務消費者”。
- Registry 服務註冊與發現的中心目錄服務稱之爲“服務註冊中心”。
- Monitor 統計服務的調用次數和調用時間的日誌服務稱之爲“服務監控中心”。
(1) 連通性：
1.註冊中心負責服務地址的註冊與查找，相當於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小；
2.監控中心負責統計各服務調用次數，調用時間等，統計先在內存彙總後每分鐘一次發送到監控中心服務器，並以報表展示；
3.服務提供者向註冊中心註冊其提供的服務，並彙報調用時間到監控中心，此時間不包含網絡開銷；
4.服務消費者向註冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，同時彙報調用時間到監控中心，此時間包含網絡開銷；
5.註冊中心，服務提供者，服務消費者三者之間均爲長連接，監控中心除外；
6.註冊中心通過長連接感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者；
7.註冊中心和監控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表；
8.註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者。
(2) 健壯性：
1.監控中心宕掉不影響使用，只是丟失部分採樣數據；
2.數據庫宕掉後，註冊中心仍能通過緩存提供服務列表查詢，但不能註冊新服務；
3.註冊中心對等集羣，任意一臺宕掉後，將自動切換到另一臺；
4.註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地緩存通訊；
5.服務提供者無狀態，任意一臺宕掉後，不影響使用；
6.服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復。
(3) 伸縮性：
1.註冊中心爲對等集羣，可動態增加機器部署實例，所有客戶端將自動發現新的註冊中心；
2.服務提供者無狀態，可動態增加機器部署實例，註冊中心將推送新的服務提供者信息給消費者。
2.什麼是springcloud，原理是什麼？
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，都可以用Spring Boot的開發風格做到一鍵啓動和部署。Spring Cloud並沒有重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。
SpringCloud的組成
Spring Cloud由衆多子項目組成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分佈式系統及微服務常用的工具，如配置管理、服務發現、斷路器、智能路由、微代理、控制總線、一次性token、全局鎖、選主、分佈式會話和集羣狀態等，滿足了構建微服務所需的所有解決方案。
下面對其核心五大部件做一個簡單介紹：
（1）服務發現——Netflix Eureka
一個RESTful服務，用來定位運行在AWS地區（Region）中的中間層服務。由兩個組件組成：Eureka服務器和Eureka客戶端。Eureka服務器用作服務註冊服務器。Eureka客戶端是一個java客戶端，用來簡化與服務器的交互、作爲輪詢負載均衡器，並提供服務的故障切換支持。Netflix在其生產環境中使用的是另外的客戶端，它提供基於流量、資源利用率以及出錯狀態的加權負載均衡。
（2）客服端負載均衡——Netflix Ribbon
Ribbon，主要提供客戶側的軟件負載均衡算法。
Ribbon客戶端組件提供一系列完善的配置選項，比如連接超時、重試、重試算法等。Ribbon內置可插拔、可定製的負載均衡組件。下面是用到的一些負載均衡策略：
- 簡單輪詢負載均衡
- 加權響應時間負載均衡
- 區域感知輪詢負載均衡
- 隨機負載均衡
Ribbon中還包括以下功能：
- 易於與服務發現組件（比如Netflix的Eureka）集成
- 使用Archaius完成運行時配置
- 使用JMX暴露運維指標，使用Servo發佈
- 多種可插拔的序列化選擇
- 異步和批處理操作（即將推出）
- 自動SLA框架（即將推出）
- 系統管理/指標控制檯（即將推出）
（3）斷路器——Netflix Hystrix
斷路器可以防止一個應用程序多次試圖執行一個操作，即很可能失敗，允許它繼續而不等待故障恢復或者浪費 CPU 週期，而它確定該故障是持久的。斷路器模式也使應用程序能夠檢測故障是否已經解決。如果問題似乎已經得到糾正，應用程序可以嘗試調用操作。
斷路器增加了穩定性和靈活性，以一個系統，提供穩定性，而系統從故障中恢復，並儘量減少此故障的對性能的影響。它可以幫助快速地拒絕對一個操作，即很可能失敗，而不是等待操作超時（或者不返回）的請求，以保持系統的響應時間。如果斷路器提高每次改變狀態的時間的事件，該信息可以被用來監測由斷路器保護系統的部件的健康狀況，或以提醒管理員當斷路器跳閘，以在打開狀態。
（4）服務網關——Netflix Zuul
類似nginx，反向代理的功能，不過netflix自己增加了一些配合其他組件的特性。
（5）分佈式配置——Spring Cloud Config
這個還是靜態的，得配合Spring Cloud Bus實現動態的配置更新。
3.SpringCloud和Dubbo的區別
最大區別：SpringCloud拋棄了Dubbo的RPC通信，採用的是基於HTTP的REST方式。總體來說，兩者各有優勢。雖說後者服務調用的功能，但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的依賴，這在強調快速演化的微服務環境下，顯得更加合適。
這也相當於品牌機與組裝機的區別。很明顯SpringCloud比dubbo的功能更強大，覆蓋面更廣，而且能夠與SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring項目完美融合，這些對於微服務至關重要。使用Dubbo構建的微服務架構就像組裝電腦、各環節我們選擇自由度高，但是最總可能會因爲內存質量而影響整體，但對於高手這也就不是問題。而SpringCloud就像品牌機，在Spring Source的整合下，做了大量的兼容性測試，保證了機器擁有更高的穩定性。