微服務架構：微服務架構是一種軟件架構風格，將一個復雜的應用拆分為多個服務模塊，每個模塊負責單一的業務功能對外服務，並且可以單獨編譯部署。每個模塊單獨部署，模塊之間無法直接通信，所以需要借助RPC（遠程過程通信協議）或者通過HTTP協議讓模塊之間進行通信。dubbo 是一套微服務系統的協調者。運用dubbo時將dubbo的jar引入項目中然后項目初始化的時候就會將當前系統需要發布的服務以及當前系統的IP和端口號發送給注冊中心；以及描述當前系統所需要的服務，然后向注冊中心請求這些服務所在的IP和端口號。
分布式：將以一個業務拆分為多個子業務，部署在不同的服務器上。分布式和微服務是一樣的。
集群：分布式是以縮短單個任務的執行時間來提升效率，集群是通過單位時間內執行的效率來提高效率的，集群的每台服務器上部署的是同樣的服務，他是有組織性的，一台服務器崩了，其他服務器可以頂上來。而分布式的每個節點都完成不同的功能，如果一個節點崩了則此服務器的服務無法訪問，所以最好就是分布式+集群部署。
負載均衡：負載均衡其實就是集群的前置。集群部署完后，需要一台服務器充當調度者角色，用戶的所有請求首先被此調度者服務器接收，然后根據每台服務器的負載情況分發請求。
<HTTP重定向實現負載均衡>當用戶請求某個服務時，請求首先被調度者服務器截獲，然后根據某種策略選擇集群中的一台服務器，將其的IP地址封裝在HTTP響應信息的location字段中，並將響應消息狀態碼設置為302，然后將響應信息返回給瀏覽器。
http狀態返回代碼 1xx（臨時響應） 表示臨時響應並需要請求者繼續執行操作的狀態代碼。
http狀態返回代碼 2xx （成功） 表示成功處理了請求的狀態代碼。
http狀態返回代碼 3xx （重定向） 表示要完成請求，需要進一步操作。 通常，這些狀態代碼用來重定向。
http狀態返回代碼 4xx（請求錯誤） 這些狀態代碼表示請求可能出錯，妨礙了服務器的處理。
http狀態返回代碼 5xx（服務器錯誤） 這些狀態代碼表示服務器在嘗試處理請求時發生內部錯誤。 這些錯誤可能是服務器本身的錯誤，而不是請求出錯。詳情<https://www.cnblogs.com/dekui/p/7801289.html>
<DNS負載均衡>我們提交的請求不會直接發送給想要訪問的網站，而是首先發送給域名服務器，會將其解析為IP地址然后返回，如果一個域名指向了多個IP地址每次域名解析時，DNS只要選一個IP返回即可。本地計算機就是有一個DNS域名解析器，首先現在本地查找，如果找不到再向遠程DNS服務器發送需要解析的域名。
<反向代理負載均衡>反向代理服務器位於實際服務器之間的服務器，所有請求首先經過反向代理服務器，服務器根據請求要么直接返回結果，要峨眉將請求交給其他后端服務器。