dubbo官網上描述的架構的發展
dubbo官網上的圖和介紹
背景
1.單一應用架構
當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。此時，用於簡化增刪改查工作量的資料訪問框架(ORM,如Hibernate,mybatis)是關鍵。
ORM框架:
提供了資料庫中的表與持久化類的對映關係,ORM框架就能參照mapper檔案,將物件持久化到資料庫中的對應表
-
表===>類
-
記錄===>物件
-
欄位===>物件的屬性
2.垂直應用架構
當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，提升效率的方法之一是將應用拆成互不相干的幾個應用，以提升效率。此時，用於加速前端頁面開發的Web框架(MVC,Model View Controller)是關鍵。
MVC與三層架構的區別:
三層架構是一種架構模式,重視層次結構,每一個層完成同一型別的操作
mvc是一種設計模式,不存在明顯的層次結構,controller建立model與view的聯絡
它們就不是同一種類型的東西.不過可以同時存在,bs處理業務時可以使用三層架構
架構:一個藍圖,一種設計方案,將不同需求抽象為元件,描述這些元件的之間的通訊和呼叫 框架:它們互相協作提供了針對某個給定的問題領域中的應用程式所用到的一種可複用的體系結構。 設計模式:是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結，它強調的是一個設計問題的解決方法。 一個架構可能用到多個框架和設計模式;框架是針對共性抽象出來的半成品,可能包含多個設計模式;設計模式是為了解決單一問題經過總結給出的一套解決方案
三層架構基於業務邏輯來分
是一種系統架構,屬於巨集觀的解決方案,可以應用在任何語言\任何技術的應用程式,解決在業務操作過程中不同階段程式碼的封裝問題,為了使程式設計師
結構清晰,耦合度低,可維護性\擴充套件性高,哪個地方出了問題,就找哪層,不會影響整個系統
就是說要解耦合,不要都放在一起,又要考慮業務邏輯\又要關心資料的儲存\列印日誌\記錄時間,而是分成多層,每層都只專注自己想要做的事,方便程式碼複用.
如果程式需要,可以分為多層.大多數分為3層
UI:介面層(表現層),與使用者互動的介面,顯示資料,接收使用者輸入的資料
BLL:業務邏輯層,接收介面層傳遞的資料,根據不同的需求處理資料
DAL:資料訪問層(持久層),執行對資料的增刪改查,操作資料庫
MVC基於頁面來分
cs架構需要更新客戶端,很麻煩,但是體驗好;bs只需要電腦上有個瀏覽器
是一種設計模式,只是解決BS應用程式檢視層和各部分的耦合關係.如展示資料的html與業務程式碼分離,獨立到View中;與使用者互動的程式邏輯放在controller中;在view和controller傳遞資料使用專門封裝資料的實體類物件,統稱為Model
M:model模型層,負責業務邏輯和資料庫互動
V:view檢視層,展示資料和發起請求
C:controller控制層,接收請求,呼叫M處理拿到結果交給V
3.分散式服務架構
當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用於提高業務複用及整合的分散式服務框架(RPC)是關鍵。
分散式就是拆拆拆
由於一臺伺服器承受不住壓力,把一個業務拆分多個子業務，部署在不同的伺服器上，每個伺服器都完成不同的業務。通過rpc或webservice進行通訊，為了完成共同的任務而協調工作，利用更多的伺服器，處理更多的資料。但使用者訪問時,感覺是一個整體
當其中一個子業務崩了，這個業務就垮了
注意只有當使用一臺計算機無法處理日益增長的計算，儲存任務時，且提升硬體效能的代價高昂到得不償失、程式也不能進一步優化，才需要考慮分散式
拆分方式分為垂直拆分和水平(橫向)拆分
水平拆分:把檢視層+控制層部署在伺服器A,service和dao層部署在伺服器B,
A中只需要呼叫B中的service完成服務
垂直拆分:根據業務進行拆分,把一個專案拆分成多個專案,拆分後的專案仍然可以作為獨立的專案使用
RPC:
遠端過程呼叫,是一種程序間通訊方式,允許程式呼叫另一個地址空間的函式(說人話就是老闆隔空喊話,跨國指揮員工)
叢集：
同一個業務，部署在多個伺服器上
哪個伺服器壓力少，就交給誰處理
(分散式+叢集)先將一個業務拆分多個子業務，再將每個子業務叢集部署
4.流動計算架構
當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基於訪問壓力實時管理叢集容量，提高叢集利用率。此時，用於提高機器利用率的資源排程和治理中心(SOA)是關鍵。
SOA:
面向服務的架構（SOA）是一個元件模型，它將應用程式的不同功能單元（稱為服務）進行拆分，並通過這些服務之間定義良好的介面和協議聯絡起來。介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行互動。
他是一種設計方法，其中包含多個服務， 服務之間通過相互依賴最終提供一系列的功能。一個服務通常以獨立的形式存在與作業系統程序中。各個服務之間通過網路呼叫。
5.微服務架構
誕生:
隨著服務不斷的被拆分和分解,變得非常的細粒度.直到微服務架構的誕生
微服務架構是一種架構模式，
微服務是將模組拆分成一個獨立的服務單元通過介面來實現資料的互動
一個小服務只提供一個功能，做一件事,可以單獨部署執行。
每個服務都執行在獨立的程序中,服務與服務之間通過rpc完成溝通
每個服務可以圍繞業務,選擇適合的語言、工具進行構建
與SOA架構的區別:
微服務是真正的分散式的、去中心化的。把所有的“思考”邏輯包括路由、訊息解析等放在服務內部，去掉一個大一統的 ESB，服務間輕通訊，是比 SOA 更徹底的拆分。
微服務架構強調的重點是業務系統需要徹底的元件化和服務化，原有的單個業務系統會拆分為多個可以獨立開發，設計，執行和運維的小應用，這些小應用之間通過服務完成互動和整合。
| 功能 | SOA | 微服務 |
|---|---|---|
| 元件大小 | 大塊業務邏輯 | 單獨任務或小塊業務邏輯 |
| 耦合 | 通常鬆耦合 | 總是鬆耦合 |
| 公司架構 | 任何型別 | 小型、專注於功能交叉團隊 |
| 管理 | 著重中央管理 | 著重分散管理 |
| 目標 | 確保應用能夠互動操作 | 執行新功能、快速拓展開發團隊 |
微服務架構強調的重點是業務系統需要徹底的元件化和服務化，原有的單個業務系統會拆分為多個可以獨立開發，設計，執行和運維的小應用，這些小應用之間通過服務完成互動和整合。
與分散式的區別:
分散式架構和微服務都是將一個系統劃分為多個模組。分散式架構的目標是一臺機器承受不了訪問，不得不使用多臺機器完成部署。微服務的目標是讓各個模組拆分，某模組的升級或出現問題不會影響其它模組，可以在一臺機器上部署
帶來的問題:
服務之間依賴關係錯綜複雜，當呼叫某個服務失敗該找誰，多個消費者時如何確保服務質量，當服務升級後，如果出現意外，如果控制不影響其它服務
https://blog.csdn.net/weixin_53173799/article/details/113698377
客戶端如何訪問服務
服務之間如何通訊
這麼多服務,如何查詢
服務掛了怎麼辦
SpringCloud解決以上微服務架構的問題
負載均衡，閘道器路由：高可用、叢集部署，校驗、請求轉發、服務整合。
服務治理：服務註冊、發現。
容錯：避免雪崩。熔斷機制,服務降級
監控跟蹤：監控資源利用、服務響應、容器資源利用情況。
訊息匯流排：訊息佇列、非同步通訊。
配置管理：統一配置管理。
本文來自那麼簡潔的部落格園，作者：赤北，轉載請註明原文連結：https://www.cnblogs.com/cqhh/p/15108143.html