1、分布式系統中的相關概念
1.1、衡量網站的性能指標
- 響應時間：指執行一個請求從開始到最后收到響應數據所花費的總體時間。
- 並發數：指系統同時能處理的請求數量。
- 並發連接數：指的是客戶端向服務器發起請求，並建立了TCP連接。每秒鍾服務器連接的總TCP數量
- 請求數：也稱為QPS(Query Per Second) 指每秒多少請求
- 並發用戶數：單位時間內有多少用戶
- 吞吐量：指單位時間內系統能處理的請求數量。
- QPS：Query Per Second 每秒查詢數。
- TPS：Transactions Per Second 每秒事務數。
- 一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數。
- 一個頁面的一次訪問，只會形成一個TPS；但一次頁面請求，可能產生多次對服務器的請求，就會有多個QPS
1.2、集群和分布式
- 集群：很多“人”一起 ，干一樣的事。（一個業務系統，部署在多台服務器上）
- 分布式：很多“人”一起，干不一樣的事。這些不一樣的事，合起來是一件大事。（一個大的業務系統，拆分為小的業務模塊，分別部署在不同的機器上）
2、架構演進
隨着互聯網的發展，互聯網企業的業務也在不斷的飛速發展，進而導致系統的架構也在不斷的發生着變化。總體來說，系統的架構大致經歷了：單體應用架構—>垂直應用架構—>分布式架構—>SOA架構—>微服務架構的演變。
2.1、單體應用架構（單機單體架構、集群單體架構）
在企業發展的初期，一般公司的網站流量都比較小，只需要一個應用，將所有的功能代碼打包成一個服務，部署到服務器上就能支撐公司的業務。這樣也能夠減少開發、部署和維護的成本。比如，大家都很熟悉的電商系統，里面涉及的業務主要有：用戶管理、商品管理、訂單管理、支付管理、庫存管理、物流管理等等模塊，初期我們會將所有模塊寫到一個Web項目中，然后統一部署到一個Web服務器中。
優點： 簡單：開發部署都很方便，小型項目首選
缺點： 項目啟動慢 可靠性差 可伸縮性差 擴展性和可維護性差 性能低
2.2、垂直架構（拆分成多個單體架構）
垂直架構是指將單體架構中的多個模塊拆分為多個獨立的項目，形成多個獨立的單體架構。
垂直架構根據業務屬性將一個大的單體應用拆分成多個模塊或子系統，子系統之間沒有直接關聯。 垂直架構相較於單體架構而言，進行了部分解耦，但是不夠徹底，在各個子系統相互依賴的代碼和模塊中，存在模塊功能重復開發和重復代碼拷貝的情況。
垂直架構存在的問題： 重復功能太多。
2.3、分布式架構（重復模塊抽取為公共服務）
將系統演變為垂直應用架構之后，當垂直應用越來越多時，重復編寫的業務代碼就會越來越多。此時，我們需要將重復的代碼抽象出來，形成統一的服務，供其他系統或者業務模塊調用，這就是分布式架構。
分布式架構是指在垂直架構的基礎上，將公共業務模塊抽取出來，作為獨立的服務，供其他調用者消費，以實現服務的共享和重用。
這種架構的優點如下：
- 將重復的業務代碼抽象出來，形成公共的訪問服務，提高了代碼的復用性。
- 可以有針對性地對系統和服務進行性能優化，以提升整體的訪問性能。
這種架構的缺點如下：
- 服務之間直接調用，服務提供方地址等信息一旦產生變更，所有消費方都需要變更。
- 系統之間的調用關系變得復雜，系統之間的依賴關系變得復雜，系統維護成本高。
在分布式架構中，我們會將系統整體拆分為服務層和表現層。服務層封裝了具體的業務邏輯供表現層調用，表現層則負責處理與頁面的交互操作。分布式系統架構如下圖示例：
RPC：Remote Procedure Call 遠程過程調用。有非常多的協議和技術來都實現了RPC的過程。比如：HTTP REST風格，Java RMI規范、WebService SOAP協議、Hession等等。
2.4、SOA架構（調度中心）
在分布式架構下，當部署的服務越來越多時，重復的代碼就會變得越來越多，不利於代碼的復用和系統維護。為此，我們需要增加一個統一的調度中心對集群進行實時管理，這就是SOA（Service-Oriented Architecture，面向服務的架構）架構。
這種架構的優點是通過注冊中心解決了各個服務之間服務依賴和調用關系的自動注冊與發現。
這種架構的缺點：服務之間的依賴與調用關系復雜，增加了測試和運維的成本。
2.5、微服務架構
微服務架構是在SOA架構的基礎上進行進一步的擴展和拆分。在微服務架構下，一個大的項目拆分為一個個小的可獨立部署的微服務，每個微服務都有自己的數據庫。微服務架構強調的一個重點是“業務需要徹底的組件化和服務化”，原有的單個業務系統會拆分為多個可以獨立開發、設計、運行的小應用，這些小應用之間通過服務完成交互和集成。
微服務架構特征：
- 單一職責：微服務拆分粒度更小，每一個服務都對應唯一的業務能力，做到單一職責，避免重復業務開發
- 面向服務：微服務對外暴露業務接口
- 自治：團隊獨立、技術獨立、數據獨立、部署獨立
- 隔離性強：服務調用做好隔離、容錯、降級，避免出現級聯問題
優點：服務徹底拆分，各服務獨立打包、獨立部署和獨立升級。每個微服務負責的業務比較清晰，利於后期擴展和維護。微服務之間可以采用REST和RPC協議進行通信。
缺點：架構非常復雜，運維、監控、部署難度提高。開發的成本比較高。涉及到各服務的容錯性問題。涉及到數據的一致性問題。涉及到分布式事務問題
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、微服務框架對比
