一.前后端分離

1.為什么要前后端分離

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

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

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

• 優(yōu)點：將靜態(tài)資源的訪問和對接口的訪問進行分離，tomcat服務(wù)器只負(fù)責(zé)數(shù)據(jù)服務(wù)的訪問。

二.集群負(fù)載均衡

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

負(fù)載均衡通常是指將請求"均勻"分?jǐn)偟郊褐卸鄠€服務(wù)器節(jié)點上執(zhí)行，這里的均勻是指在一個比較大的統(tǒng)計范圍內(nèi)是基本均勻的，并不是完全均勻。

負(fù)載均衡集群把很多客戶集中訪問的請求負(fù)載壓力盡可能平均的分?jǐn)偟接嬎銠C集群中處理。客戶請求負(fù)載通常包括”應(yīng)用程度處理負(fù)載”和”網(wǎng)絡(luò)流量負(fù)載”。這樣的系統(tǒng)非常適合向使用同一組應(yīng)用程序為大量用戶提供服務(wù)。每個節(jié)點都可以承擔(dān)一定的訪問請求負(fù)載壓力，并且可以實現(xiàn)訪問請求在各節(jié)點之間動態(tài)分配，以實現(xiàn)負(fù)載均衡。

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

負(fù)載均衡集群的

分擔(dān)訪問流量（負(fù)載均衡） 保持業(yè)務(wù)的連續(xù)性（高可用性）

集群負(fù)載均衡就是使用多臺服務(wù)器構(gòu)成一個數(shù)據(jù)庫整體，以應(yīng)對多客戶請求，當(dāng)客戶發(fā)送請求的時候后，服務(wù)器不知道哪臺服務(wù)器空閑，哪臺服務(wù)器忙碌，這時候就通過負(fù)載均衡將客戶請求根據(jù)服務(wù)器狀態(tài)分配到服務(wù)器，以達到高并發(fā)，高可用。

3.分布式

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

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

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

4.微服務(wù)

• 微服務(wù)架構(gòu)：將原來在一個應(yīng)用中開發(fā)的多個模塊進行拆分，單獨開發(fā)和部署
• 保證可用性、性能

分布式強調(diào)系統(tǒng)的拆分，微服務(wù)也是強調(diào)系統(tǒng)的拆分，微服務(wù)架構(gòu)屬于分布式架構(gòu)的范疇；

并且到目前為止，微服務(wù)并沒有一個統(tǒng)一的標(biāo)準(zhǔn)的定義，那么微服務(wù)究竟是什么？

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

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

中文翻譯版本：

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

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

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

5.經(jīng)典面試題

經(jīng)典面試：分布式和微服務(wù)有什么區(qū)別？

分布式，就是將巨大的一個系統(tǒng)劃分為多個模塊，這一點和微服務(wù)是一樣的，都是要把系統(tǒng)進行拆分，部署到不同機器上，因為一臺機器可能承受不了這么大的訪問壓力，或者說要支撐這么大的訪問壓力需要采購一臺性能超級好的服務(wù)器，其財務(wù)成本非常高，有這些預(yù)算完全可以采購很多臺普通的服務(wù)器了，分布式系統(tǒng)各個模塊通過接口進行數(shù)據(jù)交互，其實分布式也是一種微服務(wù)，因為都是把模塊拆分變?yōu)楠毩⒌膯卧?#xff0c;提供接口來調(diào)用，那么它們本質(zhì)的區(qū)別是什么？它們的本質(zhì)的區(qū)別體現(xiàn)在“目標(biāo)”上， 何為目標(biāo)，就是你采用分布式架構(gòu)或者采用微服務(wù)架構(gòu)，你最終是為了什么，要達到什么目的？分布式架構(gòu)的目標(biāo)是什么？ 就是訪問量很大一臺機器承受不了，或者是成本問題，不得不使用多臺機器來完成服務(wù)的部署？而微服務(wù)的目標(biāo)是什么？只是讓各個模塊拆分開來，不會被互相影響，比如模塊的升級或者出現(xiàn)BUG或者是重構(gòu)等等都不要影響到其他模塊，微服務(wù)它是可以在一臺機器上部署；但是：分布式也是微服務(wù)的一種，微服務(wù)也屬于分布式；

面試：微服務(wù)與Spring-Cloud的關(guān)系或區(qū)別？

微服務(wù)只是一種項目的架構(gòu)方式、架構(gòu)理念，或者說是一種概念，就如同我們的MVC架構(gòu)一樣， 那么Spring Cloud便是對這種架構(gòu)方式的技術(shù)落地實現(xiàn)；

面試：微服務(wù)一定要使用Spring Cloud嗎？

微服務(wù)只是一種項目的架構(gòu)方式、架構(gòu)理念，所以任何技術(shù)都可以實現(xiàn)這種架構(gòu)理念，只是微服務(wù)架構(gòu)里面有很多問題需要我們?nèi)ソ鉀Q，比如：負(fù)載均衡，服務(wù)的注冊與發(fā)現(xiàn)，服務(wù)調(diào)用，服務(wù)路由，服務(wù)熔斷等等一系列問題，如果你自己從0開始實現(xiàn)微服務(wù)的架構(gòu)理念，那頭發(fā)都掉光了，所以Spring Cloud 幫我們做了這些事情，Spring Cloud將處理這些問題的的技術(shù)全部打包好了，我們只需要開箱即用；

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。