1、分布式系統中的相關概念

1.1、衡量網站的性能指標

• 響應時間：指執行一個請求從開始到最后收到響應數據所花費的總體時間。
• 并發數：指系統同時能處理的請求數量。
  • 并發連接數：指的是客戶端向服務器發起請求，并建立了TCP連接。每秒鐘服務器連接的總TCP數量
  • 請求數：也稱為QPS(Query Per Second) 指每秒多少請求
  • 并發用戶數：單位時間內有多少用戶
• 吞吐量：指單位時間內系統能處理的請求數量。
  • QPS：Query Per Second 每秒查詢數。
  • TPS：Transactions Per Second 每秒事務數。
  • 一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程?？蛻魴C在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數。
  • 一個頁面的一次訪問，只會形成一個TPS；但一次頁面請求，可能產生多次對服務器的請求，就會有多個QPS

 

1.2、集群和分布式

• 集群：可以簡單理解為多節點、同模塊。
• 分布式（Distributed）：分布式是指將任務、數據、服務等分散到多臺計算機上進行處理，而不是單純依賴于一臺計算機。它的目標是提高系統的性能、可靠性、可擴展性和容錯性。可以簡單理解為，分布式就是通過多個節點（計算機）共同協作來完成一個整體任務。（簡單理解就是多節點、多模塊）

 

2、架構演進

隨著互聯網的發展，互聯網企業的業務也在不斷的飛速發展，進而導致系統的架構也在不斷的發生著變化?？傮w來說，系統的架構大致經歷了：單體應用架構—>垂直應用架構—>分布式架構—>SOA架構—>微服務架構的演變。

 

2.1、單體應用架構（單機單體架構、集群單體架構）

2.2、垂直架構（拆分成多個單體架構）

2.3、分布式架構（重復模塊抽取為公共服務）

 

2.4、SOA架構（調度中心）

在分布式架構下，當部署的服務越來越多時，重復的代碼就會變得越來越多，不利于代碼的復用和系統維護。為此，我們需要增加一個統一的調度中心對集群進行實時管理，這就是SOA（Service-Oriented Architecture，面向服務的架構）架構。

這種架構的優點是通過注冊中心解決了各個服務之間服務依賴和調用關系的自動注冊與發現。

這種架構的缺點：服務之間的依賴與調用關系復雜，增加了測試和運維的成本。

 

2.5、微服務架構

微服務架構是在SOA架構的基礎上進行進一步的擴展和拆分。在微服務架構下，一個大的項目拆分為一個個小的可獨立部署的微服務，每個微服務都有自己的數據庫。微服務架構強調的一個重點是“業務需要徹底的組件化和服務化”，原有的單個業務系統會拆分為多個可以獨立開發、設計、運行的小應用，這些小應用之間通過服務完成交互和集成。

微服務架構特征：

• 單一職責：微服務拆分粒度更小，每一個服務都對應唯一的業務能力，做到單一職責，避免重復業務開發
• 面向服務：微服務對外暴露業務接口
• 自治：團隊獨立、技術獨立、數據獨立、部署獨立
• 隔離性強：服務調用做好隔離、容錯、降級，避免出現級聯問題

 

3、分布式和微服務架構的區別

總的來說，分布式主要是有多個服務器，而微服務主要注重服務的拆分，微服務并不一定是部署在多個服務器上，也可能只是在一個服務器上（基本很少見）。即分布式是多節點多模塊，而微服務有可能是單節點多模塊，但通常也是多節點多模塊的。

分布式服務顧名思義服務是分散部署在不同的機器上的，一個服務可能負責幾個功能，是一種面向SOA架構的，服務之間也是通過rpc來交互或者是webservice來交互的。

微服務與分布式的細微差別是，微服務的應用不一定是分散在多個服務器上也可以是同一個服務器。

分布式服務架構強調的是服務化以及服務的分散化，而微服務則更強調服務拆分的專業化和精細分工。分布式也可以理解為屬于微服務，但可能服務拆分沒那么細致，而微服務架構通常也是分布式的架構。

 

4、框架

Dubbo 是 SOA 時代的產物，SpringCloud 是微服務時代的產物。

 

4.1、Dubbo

Dubbo框架是由阿里巴巴開發的開源式的分布式服務化治理框架，它會通過RPC請求方式訪問。Dubbo是在阿里巴巴的電商平臺中逐漸探索演進所形成的，經歷過復雜業務的高并發挑戰。

 

4.2、Spring Cloud

Spring Cloud不是一個單獨框架，它是一整個系列的框架合計，它是基于HTTP（s）的RETS服務構建服務體系的。Spring Cloud能夠幫助架構師構建一整套完整的微服務架構技術生態鏈。

SpringCloud是目前國內使用最廣泛的微服務框架。官網地址：https://spring.io/projects/spring-cloud。 SpringCloud集成了各種微服務功能組件，并基于SpringBoot實現了這些組件的自動裝配，從而提供了良好的開箱即用體驗：

springcloud 與 springboot的版本兼容關系：

 

4.3、微服務框架對比

 

5、RPC協議

RPC（Remote Procedure Call）是一種進程間通信方式，簡單地說就是能使應用像調用本地方法一樣的調用遠程的過程或服務，可以應用在分布式服務、分布式計算、遠程服務調用等許多場景。

 

5.1、常見的RPC協議

1）Dubbo 協議

• 簡介：阿里巴巴開源的高性能、輕量級的 Java RPC 框架 Dubbo 所使用的默認協議。
• 特點
  • 高效的網絡傳輸：基于 TCP 協議，采用單一長連接和 NIO 異步通訊方式，減少了頻繁建立和斷開連接的開銷，提升了系統的并發處理能力，適用于高并發、小數據量的服務調用場景。
  • 豐富的服務治理功能：支持服務注冊與發現、負載均衡、集群容錯等功能，方便構建復雜的分布式系統。
  • 高度可擴展：支持多種協議（如 Dubbo 協議、HTTP 協議等）、多種序列化方式和多種集群容錯策略，可以根據實際需求進行靈活配置。
• 應用場景：主要用于 Java 語言構建的分布式系統，特別是大型互聯網企業的微服務架構中。

2）Tars 協議

• 簡介：騰訊開源的高性能 RPC 框架 Tars 所使用的協議，提供了服務開發、部署、監控等一站式解決方案。
• 特點
  • 高性能：采用高效的網絡傳輸和序列化協議，具備良好的性能表現，能夠處理高并發的服務調用。
  • 自動化運維：框架提供了豐富的運維工具，支持服務的自動部署、監控、擴容等功能，降低了運維成本。
  • 多語言支持：支持多種編程語言，方便不同技術棧的團隊進行開發。
• 應用場景：適用于大型互聯網企業的分布式系統，特別是對性能和運維管理有較高要求的場景，如游戲、社交等領域的后端服務。

3）gRPC

• 簡介：由 Google 開源的高性能、通用的 RPC 框架，基于 HTTP/2 協議標準設計，使用 Protocol Buffers 作為接口描述語言。
• 特點
  • 高性能：HTTP/2 的二進制分幀、多路復用等特性，使得數據傳輸更高效，減少了網絡延遲。
  • 多語言支持：支持多種主流編程語言，如 Java、Python、Go、C++ 等，方便不同技術棧的服務間通信。
  • 強類型接口定義：使用 Protocol Buffers 定義服務接口和消息結構，保證了接口的規范性和一致性，同時生成的代碼具有高效的序列化和反序列化能力。
• 應用場景：適用于對性能要求高、跨語言的分布式系統，如微服務架構中的服務間通信，云原生應用等。

 

5.2、RPC協議和Dubbo、HTTP協議的關系

1）RPC 協議與 Dubbo 的關系：dubbo協議是RPC協議的具體實現

• RPC 是抽象概念和技術范疇：RPC 是一種允許程序調用位于不同地址空間（通常是不同計算機）中過程或方法的技術，它提供了一種機制，讓調用者可以像調用本地方法一樣調用遠程方法，屏蔽了底層網絡通信、數據傳輸等復雜細節。RPC 是一個廣泛的概念，涵蓋了各種實現方式和協議。
• Dubbo 協議是具體實現：Dubbo 協議是 Apache Dubbo 框架所使用的默認協議，它是為了滿足分布式系統中服務之間高效通信而設計的具體 RPC 協議。Dubbo 協議在實現 RPC 功能的基礎上，結合了 Dubbo 框架的特點和需求，進行了針對性的優化和擴展

 

2）RPC 協議與 HTTP 協議的關系：兩者有明顯區別，沒太大關系

• HTTP 協議可作為 RPC 的傳輸層協議：RPC 需要一種方式在網絡中傳輸請求和響應數據，HTTP 協議可以充當這個傳輸層協議?；?HTTP 協議的 RPC 實現具有良好的跨平臺和跨語言特性，因為 HTTP 協議是一種通用的網絡協議，幾乎所有的編程語言和平臺都支持。例如 JSON - RPC 就是一種基于 HTTP 協議的輕量級 RPC 協議，它使用 JSON 格式來編碼請求和響應數據，簡單易用，適合快速開發和集成。
• RPC 對 HTTP 協議的擴展：雖然 HTTP 協議提供了基本的請求 - 響應機制，但在一些復雜的分布式系統中，可能需要更多的功能，如服務發現、負載均衡、容錯等。RPC 協議在使用 HTTP 作為傳輸層的基礎上，會對這些功能進行擴展。例如，一些基于 HTTP 的 RPC 框架會在 HTTP 請求頭中添加額外的元數據來實現服務發現和負載均衡等功能。

 

3）Dubbo 與 HTTP 協議的關系：兩者有明顯區別，沒太大關系

• Dubbo 框架支持 HTTP 協議：Dubbo 框架除了默認的 Dubbo 協議外，還支持 HTTP 協議。當使用 HTTP 協議時，Dubbo 服務可以更好地與其他遵循 HTTP 協議的系統進行交互，或者部署在一些需要通過防火墻的環境中。例如，當 Dubbo 服務需要與前端的 Web 應用進行交互時，使用 HTTP 協議可以方便地實現數據傳輸。
• 應用場景和性能特點不同：Dubbo 協議基于 TCP 協議，采用單一長連接和 NIO 異步通訊，在高并發、小數據量的服務調用場景中性能表現較好；而 HTTP 協議是一種無狀態的協議，基于請求 - 響應模型，更適合于對跨平臺、跨語言和兼容性要求較高的場景。在實際應用中，可以根據具體的業務需求選擇使用 Dubbo 協議還是 HTTP 協議。

 

5.3、RESTful API和 RPC 協議

RESTful API 和 RPC（遠程過程調用）協議都是用于實現不同軟件系統之間通信的技術手段，但它們在多個方面存在差異。兩者有明顯區別，沒太大關系。

• RESTful API：基于 HTTP 協議，利用 HTTP 的狀態碼、請求頭和響應頭來傳遞額外的信息。例如，使用 200 狀態碼表示請求成功，404 狀態碼表示資源不存在；通過Content - Type頭指定響應數據的格式。
• RPC 協議：可以基于多種傳輸協議，如 TCP、UDP 或 HTTP。不同的 RPC 協議有自己的規范和消息格式，例如 gRPC 基于 HTTP/2 協議，定義了自己的請求和響應消息結構。

 

6、序列化和反序列化

• 什么是序列化？序列化就是將數據結構或對象轉換成二進制串的過程，也就是編碼的過程
• 什么是反序列化？將在序列化過程中所生成的二進制串轉換成數據結構或對象的過程
• 為什么需要序列化？轉換為二進制串才好進行網絡傳輸嘛
• 為什么需要反序列化？將二進制串轉換成對象才好進行后續處理嘛