一.前后端分離

1.為什么要前后端分離

在以前傳統的網站開發中，前端一般扮演的只是切圖的工作，只是簡單地將UI設計師提供的原型圖實現成靜態的HTML頁面，而具體的頁面交互邏輯，比如與后臺的數據交互工作等，可能都是由后臺的開發人員來實現的，或者是前端是緊緊的耦合后臺。比如，以前淘寶的Web基本上都是基于MVC框架webx，架構決定了前端只能依賴后端。所以他們的開發模式依然是，前端寫好靜態demo，后端翻譯成VM模版，這種模式的問題就不說了，被吐槽了很久。

而且更有可能后臺人員直接兼顧前端的工作，一邊實現API接口，一邊開發頁面，兩者互相切換著做，而且根據不同的url動態拼接頁面，這也導致后臺的開發壓力大大增加。前后端工作分配不均。不僅僅開發效率慢，而且代碼難以維護。而前后端分離的話，則可以很好的解決前后端分工不均的問題，將更多的交互邏輯分配給前端來處理，而后端則可以專注于其本職工作，比如提供API接口，進行權限控制以及進行運算工作。而前端開發人員則可以利用nodejs來搭建自己的本地服務器，直接在本地開發，然后通過一些插件來將api請求轉發到后臺，這樣就可以完全模擬線上的場景，并且與后臺解耦。前端可以獨立完成與用戶交互的整一個過程，兩者都可以同時開工，不互相依賴，開發效率更快，而且分工比較均衡。

• 前后端分離：前端和后端分離開發和部署（前端部署在不同的服務器），這樣可以減少tomcat的訪問壓力，例如：如果前后端部署在一個服務器中，客戶端發起一個請求一個服務器要同時處理相應靜態頁面響應和后端代碼的響應，這樣服務器就壓力很大，如多利用Nginx部署前后端分離，這樣同樣一個tomcat服務就就能同時處理更多的請求，就符合開發高可用。

• 優點：將靜態資源的訪問和對接口的訪問進行分離，tomcat服務器只負責數據服務的訪問。

二.集群負載均衡

在網站創立初期，我們一般都使用單臺機器對外提供集中式服務。隨著業務量的增大，我們一臺服務器不夠用，此時就會把多臺機器組成一個集群對外提供服務，但是，我們網站對外提供的訪問入口通常只有一個，比如 www.web.com。那么當用戶在瀏覽器輸入www.web.com進行訪問的時候，如何將用戶的請求分發到集群中不同的機器上呢，這就是負載均衡要做的事情。

負載均衡通常是指將請求"均勻"分攤到集群中多個服務器節點上執行，這里的均勻是指在一個比較大的統計范圍內是基本均勻的，并不是完全均勻。

負載均衡集群把很多客戶集中訪問的請求負載壓力盡可能平均的分攤到計算機集群中處理。客戶請求負載通常包括”應用程度處理負載”和”網絡流量負載”。這樣的系統非常適合向使用同一組應用程序為大量用戶提供服務。每個節點都可以承擔一定的訪問請求負載壓力，并且可以實現訪問請求在各節點之間動態分配，以實現負載均衡。

負載均衡運行時，一般通過一個或多個前端負載均衡器將客戶訪問請求分發到后端一組服務器上，從而達到整個系統的高性能和高可用性。這樣計算機集群有時也被稱為服務器群。一般高可用性集群和負載均衡集群會使用類似的技術，或同時具有高可用性與負載均衡的特點。

負載均衡集群的

分擔訪問流量（負載均衡） 保持業務的連續性（高可用性）

集群負載均衡就是使用多臺服務器構成一個數據庫整體，以應對多客戶請求，當客戶發送請求的時候后，服務器不知道哪臺服務器空閑，哪臺服務器忙碌，這時候就通過負載均衡將客戶請求根據服務器狀態分配到服務器，以達到高并發，高可用。

3.分布式

簡單而言只要服務不是在同一臺服務器上就屬于分布式
分布式就是把所有的功能、模塊拆分成不同的子項目，部署在多臺不同的服務器上，這些子項目相互協作共同對外提供服務。

直白一點：就是有很多項目，有很多war包，這些項目相互協作完成需要的功能，不是一個war能完成的，一個war包完成不了。

比如：
Shop項目：單體應用
Shop項目：拆分–> (user-center, order-center, trade-center) 分布式應用

4.微服務

• 微服務架構：將原來在一個應用中開發的多個模塊進行拆分，單獨開發和部署
• 保證可用性、性能

分布式強調系統的拆分，微服務也是強調系統的拆分，微服務架構屬于分布式架構的范疇；

并且到目前為止，微服務并沒有一個統一的標準的定義，那么微服務究竟是什么？

微服務一詞源于 Martin Fowler（馬丁.福勒）的名為 Microservices 的博文，可以在他的官方博客上找到這篇文章：

http://martinfowler.com/articles/microservices.html

中文翻譯版本：

https://www.martinfowler.cn/articles/microservices.html

簡單地說， 微服務是系統架構上的一種設計風格， 它的主旨是將一個原本獨立的系統拆分成多個小型服務，這些小型服務都在各自獨立的進程中運行，服務之間通過基于 HTTP 的 RESTful API 進行通信協作； （dubbo -->dubbo協議 ） RESTful API (controller --> 調用 congtroller被拆分后的每一個小型服務都專注于完成系統中的某一項業務功能，職責單一， 并且每個服務都是一個獨立的項目，可以進行獨立的測試、開發和部署等；由于各個獨立的服務之間使用的是基于 HTTP 的 JSON 作為數據通信協作的基礎，所以這些微服務也可以使用不同的語言來開發；

比如：項目里面有User模塊和Order模塊，但是User模塊和Order模塊并沒有直接關系，僅僅只是一些數據需要交互，那么就可以把這2個模塊單獨分開來，當user需要調用order的時候，order是一個服務方，但是order需要調用user的時候，user又是服務方了， 所以，它們并不在乎誰是服務方誰是調用方，他們都是2個獨立的服務，這就是微服務的概念；

5.經典面試題

經典面試：分布式和微服務有什么區別？

分布式，就是將巨大的一個系統劃分為多個模塊，這一點和微服務是一樣的，都是要把系統進行拆分，部署到不同機器上，因為一臺機器可能承受不了這么大的訪問壓力，或者說要支撐這么大的訪問壓力需要采購一臺性能超級好的服務器，其財務成本非常高，有這些預算完全可以采購很多臺普通的服務器了，分布式系統各個模塊通過接口進行數據交互，其實分布式也是一種微服務，因為都是把模塊拆分變為獨立的單元，提供接口來調用，那么它們本質的區別是什么？它們的本質的區別體現在“目標”上， 何為目標，就是你采用分布式架構或者采用微服務架構，你最終是為了什么，要達到什么目的？分布式架構的目標是什么？ 就是訪問量很大一臺機器承受不了，或者是成本問題，不得不使用多臺機器來完成服務的部署？而微服務的目標是什么？只是讓各個模塊拆分開來，不會被互相影響，比如模塊的升級或者出現BUG或者是重構等等都不要影響到其他模塊，微服務它是可以在一臺機器上部署；但是：分布式也是微服務的一種，微服務也屬于分布式；

面試：微服務與Spring-Cloud的關系或區別？

微服務只是一種項目的架構方式、架構理念，或者說是一種概念，就如同我們的MVC架構一樣， 那么Spring Cloud便是對這種架構方式的技術落地實現；

面試：微服務一定要使用Spring Cloud嗎？

微服務只是一種項目的架構方式、架構理念，所以任何技術都可以實現這種架構理念，只是微服務架構里面有很多問題需要我們去解決，比如：負載均衡，服務的注冊與發現，服務調用，服務路由，服務熔斷等等一系列問題，如果你自己從0開始實現微服務的架構理念，那頭發都掉光了，所以Spring Cloud 幫我們做了這些事情，Spring Cloud將處理這些問題的的技術全部打包好了，我們只需要開箱即用；

總結

以上是生活随笔為你收集整理的前后端分离 集群负载均衡 分布式 微服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。