1.1、衡量網(wǎng)站的性能指標

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

1.2、集群和分布式

• 集群：很多“人”一起 ，干一樣的事。（一個業(yè)務系統(tǒng)，部署在多臺服務器上）
• 分布式：很多“人”一起，干不一樣的事。這些不一樣的事，合起來是一件大事。（一個大的業(yè)務系統(tǒng)，拆分為小的業(yè)務模塊，分別部署在不同的機器上）

2、架構演進

隨著互聯(lián)網(wǎng)的發(fā)展，互聯(lián)網(wǎng)企業(yè)的業(yè)務也在不斷的飛速發(fā)展，進而導致系統(tǒng)的架構也在不斷的發(fā)生著變化?？傮w來說，系統(tǒng)的架構大致經(jīng)歷了：單體應用架構—>垂直應用架構—>分布式架構—>SOA架構—>微服務架構的演變。

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

在企業(yè)發(fā)展的初期，一般公司的網(wǎng)站流量都比較小，只需要一個應用，將所有的功能代碼打包成一個服務，部署到服務器上就能支撐公司的業(yè)務。這樣也能夠減少開發(fā)、部署和維護的成本。比如，大家都很熟悉的電商系統(tǒng)，里面涉及的業(yè)務主要有：用戶管理、商品管理、訂單管理、支付管理、庫存管理、物流管理等等模塊，初期我們會將所有模塊寫到一個Web項目中，然后統(tǒng)一部署到一個Web服務器中。

優(yōu)點： 簡單：開發(fā)部署都很方便，小型項目首選

缺點： 項目啟動慢 可靠性差 可伸縮性差 擴展性和可維護性差 性能低

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

垂直架構是指將單體架構中的多個模塊拆分為多個獨立的項目，形成多個獨立的單體架構。

垂直架構根據(jù)業(yè)務屬性將一個大的單體應用拆分成多個模塊或子系統(tǒng)，子系統(tǒng)之間沒有直接關聯(lián)。 垂直架構相較于單體架構而言，進行了部分解耦，但是不夠徹底，在各個子系統(tǒng)相互依賴的代碼和模塊中，存在模塊功能重復開發(fā)和重復代碼拷貝的情況。

垂直架構存在的問題： 重復功能太多。

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

將系統(tǒng)演變?yōu)榇怪睉眉軜嬛?，當垂直應用越來越多時，重復編寫的業(yè)務代碼就會越來越多。此時，我們需要將重復的代碼抽象出來，形成統(tǒng)一的服務，供其他系統(tǒng)或者業(yè)務模塊調(diào)用，這就是分布式架構。

分布式架構是指在垂直架構的基礎上，將公共業(yè)務模塊抽取出來，作為獨立的服務，供其他調(diào)用者消費，以實現(xiàn)服務的共享和重用。

這種架構的優(yōu)點如下：

1. 將重復的業(yè)務代碼抽象出來，形成公共的訪問服務，提高了代碼的復用性。
2. 可以有針對性地對系統(tǒng)和服務進行性能優(yōu)化，以提升整體的訪問性能。

這種架構的缺點如下：

1. 服務之間直接調(diào)用，服務提供方地址等信息一旦產(chǎn)生變更，所有消費方都需要變更。
2. 系統(tǒng)之間的調(diào)用關系變得復雜，系統(tǒng)之間的依賴關系變得復雜，系統(tǒng)維護成本高。

在分布式架構中，我們會將系統(tǒng)整體拆分為服務層和表現(xiàn)層。服務層封裝了具體的業(yè)務邏輯供表現(xiàn)層調(diào)用，表現(xiàn)層則負責處理與頁面的交互操作。分布式系統(tǒng)架構如下圖示例：

RPC：Remote Procedure Call 遠程過程調(diào)用。有非常多的協(xié)議和技術來都實現(xiàn)了RPC的過程。比如：HTTP REST風格，Java RMI規(guī)范、WebService SOAP協(xié)議、Hession等等。

2.4、SOA架構（調(diào)度中心）

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

這種架構的優(yōu)點是通過注冊中心解決了各個服務之間服務依賴和調(diào)用關系的自動注冊與發(fā)現(xiàn)。

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

2.5、微服務架構

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

微服務架構特征：

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

優(yōu)點：服務徹底拆分，各服務獨立打包、獨立部署和獨立升級。每個微服務負責的業(yè)務比較清晰，利于后期擴展和維護。微服務之間可以采用REST和RPC協(xié)議進行通信。

缺點：架構非常復雜，運維、監(jiān)控、部署難度提高。開發(fā)的成本比較高。涉及到各服務的容錯性問題。涉及到數(shù)據(jù)的一致性問題。涉及到分布式事務問題

3、分布式和微服務架構的區(qū)別

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

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

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

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

4、框架

Dubbo 是 SOA 時代的產(chǎn)物，SpringCloud 是微服務時代的產(chǎn)物。

4.1、Dubbo

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

4.2、Spring Cloud

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

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

springcloud 與 springboot的版本兼容關系：

4.3、微服務框架對比

文章來源地址http://www.zghlxwxcb.cn/news/detail-859183.html

到了這里，關于分布式系統(tǒng)架構中的相關概念的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！