整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
少粉絲和客戶朋友對于前后端分離怎么部署這個問題有很大的探索欲望。我們都知道，現在前后分離已經是發展趨勢和潮流了，不少企業和客戶都希望前后端分離，這樣就能術業有專攻，前后端工程師能分出精力來專注于做好自己的事情，從而提升效率。本文將分享給大家的是前后端分離如何部署的知識，滿滿的都是干貨，希望您能有所收獲。
一、前后端分離怎么部署？分享具體步驟
（一）一起部署：
1.先將前端打包成靜態文件：npm run build
2.將dist目錄下所有的文件拷貝到后端的static中（resource下的static）
3.在后端框架攔截器中將之前拷貝的所有文件都放行
4.注意修改配置文件里面mysql、redis以及其他的url
5.打包后端在項目父路徑（idea后面帶ROOT）的lifecycle中點擊package
6.找到target中的jar并上傳到linux（建議放到一個項目專屬文件夾中）
7.切換到項目文件夾執行命令 ：nohup java -jar +jar包名稱（有幾個執行幾遍）
8.訪問瀏覽器輸入Linux的地址+端口號+index.html
（二）前后端分離部署(使用nginx)
1.先將前端打包成靜態文件：npm run build
2.將dist目錄拷貝到Linux的文件夾下
3.找到Linux的配置文件
4.將nginx配置文件的指向地址修改為jar包的地址（后端）
5.訪問靜態資源（第一步拷貝的前端資源）下面修改為項目的文件夾到dist
6.將后端代碼打包成jar放入項目目錄
7.切換到項目文件夾執行命令 ：nohup java -jar +jar包名稱
8.啟動nginx: …/sbin/nginx
9.訪問瀏覽器輸入Linux的地址+index.html
二、看看IBPS微服務架構前后端分離框架特點
正是由于前后端分離的需求越來越被重視，因此IBPS低代碼開發平臺服務商順勢而為，探索出另一條全新的前后端分離模式。那么，該平臺前后端分離框架的特點究竟是什么？一起來探尋。
（一）前端解決方案特點
采用Webpack的模塊打包機制；
基于vue構建用戶界面的漸進式框架，采用Vue全家桶（vue-router、vuex、vue-cli、axios）；
基于vue的Element UI組件庫和Vux的前端解決方案；
Easy mock 模擬后端數據結構；
同一套代碼多端使用，即PC端、移動端可使用同一套前端代碼；
控件組件化；
表單靜態化，只需生成的代碼其他系統可調用。
（二）后端解決方案特點
采用Spring Cloud的微服務，通過服務注冊中心Eureka向外提供注冊及訪問服務；
支持使用客戶自己的注冊中心（基于Eureka)，公司主動去注冊；
穩定的網關服務zuul。提供統一服務調用入口，更精準的對服務進行權限、流量等控制；
同時支持resful接口方式調用公司服務，無需注冊中心及網關也可正常使用；
支持集群、分布式服務；
支持多種組件服務，如：消息服務、文件服務、定時任務等基礎服務。
經過上文的長篇介紹后，大家知道前后端分離怎么部署了嗎？
如果需要體驗，可以從這里登錄：https://cloud.bpmhome.cn:280/
（部分資料來源于網絡，如有侵權，請聯系我們刪除）
作者：山人行 來源：https://www.cnblogs.com/shanrengo/p/6397734.html
言：分離模式
對前后端分離研究了一段時間，恰逢公司有一個大項目決定嘗試使用前后端分離模式進行，便參與其中。該項目從2016年初立項至今，平平穩穩得度過，但也涌現出越來越多的問題，絕對不是說前后端分離模式不好，而是很多公司在嘗試前后端分離的時候沒有做好充分得準備。
網上對前后端分離介紹的文章已經屢見不鮮，接下來本人用一點粗淺的言語也談談這塊，獻丑了。
為什么要分離？
如果只問“前后端分離的意義大么？”這是廢話，因為從軟件架構的角度 Web 的前后端從一開始不就一直是分離的么，而且 browser、server 可能將永遠分離下去。
為了了解這個問題，我們有必要先了解一下 Web的研發模式演變，關于這個題材，下面這篇博文說得不錯，這邊就不做搬運工了。
https://github.com/lifesinger/blog/issues/184
我們不能“為了分離而分離”，而應該“為了真正理解web開發、為了更好完成需求而分離”。
前后端分離的誤區？
1、前端人員配備是否充足？
由于所在公司以往項目采用傳統開發風格，即以后端MVC為主的開發模式，前端人員僅僅提供靜態html頁面，其余工作皆由后端開發人員完成。采用前后端分離模式可以減后臺負擔，加快研發效率，當然，前提是前端能做好的話。以往只需要提供靜態頁面的前端人員，在前后端分離模式中要負責項目的view+controller部分，即除了靜態頁面，還需要負責頁面的所有交互代碼、以及nodejs與視圖層以及后端API的交互工作，無疑增加了前端人員的學習成本，在沒有足夠知識和人才儲備的情況下，只能讓前端人員加班加點。結果是大量前端人員離職（PS：做這么多事，工資總得加吧！）
2、前后端職責分配？
很多公司認為采用前后端分離之后，前后端只需要通過指定API進行交互即可，前端負責頁面渲染，Nodejs負責路由分配，后端提供API。忽視了大量關鍵工作，職責分配和細節處理沒有相應文檔規定，緩存機制、圖片上傳下載、數據校驗、語言國際化等等并沒有出具相應信息。另外，大量忽視了nodejs層的作用，僅僅把nodejs當成一個路由中轉，這一方面也是對nodejs技術的不熟悉導致的，其實nodejs能負責很多事，除了復雜業務邏輯處理和數據操作由Java 負責，大量工作完全可以在nodejs層處理。（PS：還是基礎不夠導致的！）
3、后端API是否Restful風格？
很多公司采用了前后端分離模式后，后端API仍然采用以往的傳統風格，這是不合理的，Restful風格的API應該是前后端分離的最佳實踐。ResultFul推薦每個URL能操作具體的資源,而且能準確描述服務器對資源的處理動作，通常服務器對資源支持get/post/put/delete/等，用來實現資源的增刪改查。前后端分離的話，這些api-url是對接的橋梁，采用resultFul接口地址含義才更清晰、見名知意。（PS：用了Spring4.x 竟然還不用rest風格，說不過去啊）
4、前后端協作模式？
前后端分離后，無論是API接口的對接還是測試工作，都涉及到前后端人員的溝通，很多公司采用前后端分離后，前后端協作模式配合力度底，互相等待，開發效率低下，反而不如傳統的開發模式。例如：當后端 API 沒有編寫完成時，前端無法進行調試，這就導致了前端會被后端阻塞的情況。其實像這種互相等待的模式需要改進， Mock Server 可能可以解決一些問題。
如何前后端分離？
怎么做前后端分離？大方向就是
后端專注于：后端控制層（Restful API） & 服務層 & 數據訪問層；
前端專注于：前端控制層（Nodejs） & 視圖層
本人認為的前后端分離模式應該是這樣，當然這不一定正確：
1、項目設計階段，前后端架構負責人將項目整體進行分析，討論并確定API風格、職責分配、開發協助模式，確定人員配備；設計確定后，前后端人員共同制定開發接口。
2、項目開發階段，前后端分離是各自分工，協同敏捷開發，后端提供Restful API，并給出詳細文檔說明，前端人員進行頁面渲染前臺的任務是發送API請(GET,PUT,POST,DELETE等)獲取數據（json，xml）后渲染頁面。
3、項目測試階段，API完成之前，前端人員會使用mock server進行模擬測試，后端人員采用junit進行API單元測試，不用互相等待；API完成之后，前后端再對接測試一下就可以了，當然并不是所有的接口都可以提前定義，有一些是在開發過程中進行調整的。
4、項目部署階段，利用nginx 做反向代理，即Java + nodejs + nginx 方式進行。
編后語
從經典的JSP+Servlet+JavaBean的MVC時代，到SSM（Spring + SpringMVC + Mybatis）和SSH（Spring + Struts + Hibernate）的Java 框架時代，再到前端框架（KnockoutJS、AngularJS、vueJS、ReactJS）為主的MV*時代，然后是Nodejs引領的全棧時代，技術和架構一直都在進步。雖然“基于NodeJS的全棧式開發”模式很讓人興奮，但是把基于Node的全棧開發變成一個穩定，讓大家都能接受的東西還有很多路要走。創新之路不會止步，無論是前后端分離模式還是其他模式，都是為了更方便得解決需求，但它們都只是一個“中轉站”。
走過的“中轉站”可能越來越多，但是不要漸行漸遠才是。
注于Java領域優質技術，歡迎關注
作 者：Cherry300
來 源：jianshu.com/p/c86cee16b418
前后端分離已成為互聯網項目開發的業界標準使用方式，通過nginx+tomcat的方式（也可以中間加一個nodejs）有效的進行解耦，并且前后端分離會為以后的大型分布式架構、彈性計算架構、微服務架構、多端化服務（多種客戶端，例如：瀏覽器，車載終端，安卓，IOS等等）打下堅實的基礎。這個步驟是系統架構從猿進化成人的必經之路。
核心思想是前端html頁面通過ajax調用后端的restuful api接口并使用json數據進行交互。
在互聯網架構中，名詞解釋：
Web服務器：一般指像nginx，apache這類的服務器，他們一般只能解析靜態資源。
應用服務器：一般指像tomcat，jetty，resin這類的服務器可以解析動態資源也可以解析靜態資源，但解析靜態資源的能力沒有web服務器好。
一般都是只有web服務器才能被外網訪問，應用服務器只能內網訪問。
以前的JavaWeb項目大多數都是java程序員又當爹又當媽，又搞前端，又搞后端。
隨著時代的發展，漸漸的許多大中小公司開始把前后端的界限分的越來越明確，前端工程師只管前端的事情，后端工程師只管后端的事情。正所謂術業有專攻，一個人如果什么都會，那么他畢竟什么都不精。
大中型公司需要專業人才，小公司需要全才，但是對于個人職業發展來說，我建議是分開。
1、對于后端java工程師：
把精力放在java基礎，設計模式，jvm原理，spring+springmvc原理及源碼，linux，mysql事務隔離與鎖機制，mongodb，http/tcp，多線程，分布式架構，彈性計算架構，微服務架構，java性能優化，以及相關的項目管理等等。
后端追求的是：三高（高并發，高可用，高性能），安全，存儲，業務等等。
2、對于前端工程師：
把精力放在html5，css3，jquery，angularjs，bootstrap，reactjs，vuejs，webpack，less/sass，gulp，nodejs，Google V8引擎，javascript多線程，模塊化，面向切面編程，設計模式，瀏覽器兼容性，性能優化等等。
前端追求的是：頁面表現，速度流暢，兼容性，用戶體驗等等。
術業有專攻，這樣你的核心競爭力才會越來越高，正所謂你往生活中投入什么，生活就會反饋給你什么。并且兩端的發展都越來越高深，你想什么都會，那你畢竟什么都不精。
通過將team分成前后端team，讓兩邊的工程師更加專注各自的領域，獨立治理，然后構建出一個全棧式的精益求精的team。
幾曾何時，我們的JavaWeb項目都是使用了若干后臺框架，springmvc/struts + spring + spring jdbc/hibernate/mybatis 等等。
大多數項目在java后端都是分了三層，控制層，業務層，持久層。控制層負責接收參數，調用相關業務層，封裝數據，以及路由&渲染到jsp頁面。然后jsp頁面上使用各種標簽或者手寫java表達式將后臺的數據展現出來，玩的是MVC那套思路。
我們先看這種情況：需求定完了，代碼寫完了，測試測完了，然后呢？要發布了吧？你需要用maven或者eclipse等工具把你的代碼打成一個war包，然后把這個war包發布到你的生產環境下的web容器里，對吧？
發布完了之后，你要啟動你的web容器，開始提供服務，這時候你通過配置域名，dns等等相關，你的網站就可以訪問了（假設你是個網站）。那我們來看，你的前后端代碼是不是全都在那個war包里？包括你的js，css，圖片，各種第三方的庫，對吧？
好，下面在瀏覽器中輸入你的網站域名（www.xxx.com），之后發生了什么？（這個問題也是很多公司的面試題）我撿干的說了啊，基礎不好的童鞋請自己去搜。
瀏覽器在通過域名通過dns服務器找到你的服務器外網ip,將http請求發送到你的服務器，在tcp3次握手之后（http下面是tcp/ip），通過tcp協議開始傳輸數據，你的服務器得到請求后，開始提供服務，接收參數，之后返回你的應答給瀏覽器，瀏覽器再通過content-type來解析你返回的內容，呈現給用戶。
那么我們來看，我們先假設你的首頁中有100張圖片，此時，用戶的看似一次http請求，其實并不是一次，用戶在第一次訪問的時候，瀏覽器中不會有緩存，你的100張圖片，瀏覽器要連著請求100次http請求（有人會跟我說http長連短連的問題，不在這里討論），你的服務器接收這些請求，都需要耗費內存去創建socket來玩tcp傳輸（消耗你服務器上的計四、JSP的痛點
以前的javaWeb項目大多數使用jsp作為頁面層展示數據給用戶，因為流量不高，因此也沒有那么苛刻的性能要求，但現在是大數據時代，對于互聯網項目的性能要求是越來越高，因此原始的前后端耦合在一起的架構模式已經逐漸不能滿足我們，因此我們需要需找一種解耦的方式，來大幅度提升我們的負載能力。
1、動態資源和靜態資源全部耦合在一起，服務器壓力大，因為服務器會收到各種http請求，例如css的http請求，js的，圖片的等等。一旦服務器出現狀況，前后臺一起玩完，用戶體驗極差。
2、UI出好設計圖后，前端工程師只負責將設計圖切成html，需要由java工程師來將html套成jsp頁面，出錯率較高（因為頁面中經常會出現大量的js代碼），修改問題時需要雙方協同開發，效率低下。
3、jsp必須要在支持java的web服務器里運行（例如tomcat，jetty，resin等），無法使用nginx等（nginx據說單實例http并發高達5w，這個優勢要用上），性能提不上來。
4、第一次請求jsp，必須要在web服務器中編譯成servlet，第一次運行會較慢。
5、每次請求jsp都是訪問servlet再用輸出流輸出的html頁面，效率沒有直接使用html高（是每次喲，親~）。
6、jsp內有較多標簽和表達式，前端工程師在修改頁面時會捉襟見肘，遇到很多痛點。
7、如果jsp中的內容很多，頁面響應會很慢，因為是同步加載。
8、需要前端工程師使用java的ide（例如eclipse），以及需要配置各種后端的開發環境，你們有考慮過前端工程師的感受嗎。
基于上述的一些痛點，我們應該把整個項目的開發權重往前移，實現前后端真正的解耦！
以前老的方式是：
1、產品經歷/領導/客戶提出需求
2、UI做出設計圖
3、前端工程師做html頁面
4、后端工程師將html頁面套成jsp頁面（前后端強依賴，后端必須要等前端的html做好才能套jsp。如果html發生變更，就更痛了，開發效率低）
5、集成出現問題
6、前端返工
7、后端返工
8、二次集成
9、集成成功
10、交付
新的方式是：
1、產品經歷/領導/客戶提出需求
2、UI做出設計圖
3、前后端約定接口&數據&參數
4、前后端并行開發（無強依賴，可前后端并行開發，如果需求變求變更，只要接口&參數不變，就不用兩邊都修改代碼，開發效率高）
5、前后端集成
6、前端頁面調整
7、集成成功
8、交付
以前老的方式是：
1、客戶端請求
2、服務端的servlet或controller接收請求（后端控制路由與渲染頁面，整個項目開發的權重大部分在后端）
3、調用service,dao代碼完成業務邏輯
4、返回jsp
5、jsp展現一些動態的代碼
新的方式是：
1、瀏覽器發送請求
2、直接到達html頁面（前端控制路由與渲染頁面，整個項目開發的權重前移）
3、html頁面負責調用服務端接口產生數據（通過ajax等等，后臺返回json格式數據，json數據格式因為簡潔高效而取代xml）
4、填充html，展現動態效果，在頁面上進行解析并操作DOM。
總結一下新的方式的請求步驟：
大量并發瀏覽器請求--->web服務器集群(nginx)--->應用服務器集群(tomcat)--->文件/數據庫/緩存/消息隊列服務器集群
同時又可以玩分模塊，還可以按業務拆成一個個的小集群，為后面的架構升級做準備。
1、可以實現真正的前后端解耦，前端服務器使用nginx。前端/WEB服務器放的是css，js，圖片等等一系列靜態資源（甚至你還可以css，js，圖片等資源放到特定的文件服務器，例如阿里云的oss，并使用cdn加速），前端服務器負責控制頁面引用&跳轉&路由，前端頁面異步調用后端的接口，后端/應用服務器使用tomcat（把tomcat想象成一個數據提供者），加快整體響應速度。（這里需要使用一些前端工程化的框架比如nodejs，react，router，react，redux，webpack）
2、發現bug，可以快速定位是誰的問題，不會出現互相踢皮球的現象。頁面邏輯，跳轉錯誤，瀏覽器兼容性問題，腳本錯誤，頁面樣式等問題，全部由前端工程師來負責。接口數據出錯，數據沒有提交成功，應答超時等問題，全部由后端工程師來解決。雙方互不干擾，前端與后端是相親相愛的一家人。
3、在大并發情況下，我可以同時水平擴展前后端服務器，比如淘寶的一個首頁就需要2000+臺前端服務器做集群來抗住日均多少億+的日均pv。（去參加阿里的技術峰會，聽他們說他們的web容器都是自己寫的，就算他單實例抗10萬http并發，2000臺是2億http并發，并且他們還可以根據預知洪峰來無限拓展，很恐怖，就一個首頁。。。）
4、減少后端服務器的并發/負載壓力。除了接口以外的其他所有http請求全部轉移到前端nginx上，接口的請求調用tomcat，參考nginx反向代理tomcat。且除了第一次頁面請求外，瀏覽器會大量調用本地緩存。
5、即使后端服務暫時超時或者宕機了，前端頁面也會正常訪問，只不過數據刷不出來而已。
6、也許你也需要有微信相關的輕應用，那樣你的接口完全可以共用，如果也有app相關的服務，那么只要通過一些代碼重構，也可以大量復用接口，提升效率。（多端應用）
7、頁面顯示的東西再多也不怕，因為是異步加載。
8、nginx支持頁面熱部署，不用重啟服務器，前端升級更無縫。
9、增加代碼的維護性&易讀性（前后端耦在一起的代碼讀起來相當費勁）。
10、提升開發效率，因為可以前后端并行開發，而不是像以前的強依賴。
11、在nginx中部署證書，外網使用https訪問，并且只開放443和80端口，其他端口一律關閉（防止黑客端口掃描），內網使用http，性能和安全都有保障。
12、前端大量的組件代碼得以復用，組件化，提升開發效率，抽出來！
1、在開需求會議的時候，前后端工程師必須全部參加，并且需要制定好接口文檔，后端工程師要寫好測試用例（2個維度），不要讓前端工程師充當你的專職測試，推薦使用chrome的插件postman或soapui或jmeter，service層的測試用例拿junit寫。ps：前端也可以玩單元測試嗎？
2、上述的接口并不是java里的interface，說白了調用接口就是調用你controler里的方法。
3、加重了前端團隊的工作量，減輕了后端團隊的工作量，提高了性能和可擴展性。
4、我們需要一些前端的框架來解決類似于頁面嵌套，分頁，頁面跳轉控制等功能。（上面提到的那些前端框架）。
5、如果你的項目很小，或者是一個單純的內網項目，那你大可放心，不用任何架構而言，但是如果你的項目是外網項目，呵呵噠。
6、 以前還有人在使用類似于velocity/freemarker等模板框架來生成靜態頁面，仁者見仁智者見智。
7、這篇文章主要的目的是說jsp在大型外網java web項目中被淘汰掉，可沒說jsp可以完全不學，對于一些學生朋友來說，jsp/servlet等相關的java web基礎還是要掌握牢的，不然你以為springmvc這種框架是基于什么來寫的？
8、如果頁面上有一些權限等等相關的校驗，那么這些相關的數據也可以通過ajax從接口里拿。
9、對于既可以前端做也可以后端做的邏輯，我建議是放到前端，為什么？因為你的邏輯需要計算資源進行計算，如果放到后端去run邏輯，則會消耗帶寬&內存&cpu等等計算資源，你要記住一點就是服務端的計算資源是有限的，而如果放到前端，使用的是客戶端的計算資源，這樣你的服務端負載就會下降（高并發場景）。類似于數據校驗這種，前后端都需要做！
10、前端需要有機制應對后端請求超時以及后端服務宕機的情況，友好的展示給用戶。
1、其實對于js，css，圖片這類的靜態資源可以考慮放到類似于阿里云的oss這類文件服務器上（如果是普通的服務器&操作系統，存儲在到達pb級的文件后，或者單個文件夾內的文件數量達到3-5萬，io會有很嚴重的性能問題），再在oss上配cdn（全國子節點加速），這樣你頁面打開的速度像飛一樣， 無論你在全國的哪個地方，并且你的nginx的負載會進一步降低。
2、如果你要玩輕量級微服務架構，要使用nodejs做網關，用nodejs的好處還有利于seo優化，因為nginx只是向瀏覽器返回頁面靜態資源，而國內的搜索引擎爬蟲只會抓取靜態數據，不會解析頁面中的js，這使得應用得不到良好的搜索引擎支持。同時因為nginx不會進行頁面的組裝渲染，需要把靜態頁面返回到瀏覽器，然后完成渲染工作，這加重了瀏覽器的渲染負擔。瀏覽器發起的請求經過nginx進行分發，URL請求統一分發到nodejs，在nodejs中進行頁面組裝渲染；API請求則直接發送到后端服務器，完成響應。
3、如果遇到跨域問題，spring4的CORS可以完美解決，但一般使用nginx反向代理都不會有跨域問題，除非你把前端服務和后端服務分成兩個域名。JSONP的方式也被淘汰掉了。
4、如果想玩多端應用，注意要去掉tomcat原生的session機制，要使用token機制，使用緩存（因為是分布式系統），做單點，對于token機制的安全性問題，可以搜一下jwt。
5、前端項目中可以加入mock測試（構造虛擬測試對象來模擬后端，可以獨立開發和測試），后端需要有詳細的測試用例，保證服務的可用性與穩定性。
前后端分離并非僅僅只是一種開發模式，而是一種架構模式（前后端分離架構）。千萬不要以為只有在擼代碼的時候把前端和后端分開就是前后端分離了，需要區分前后端項目。前端項目與后端項目是兩個項目，放在兩個不同的服務器，需要獨立部署，兩個不同的工程，兩個不同的代碼庫，不同的開發人員。
前后端工程師需要約定交互接口，實現并行開發，開發結束后需要進行獨立部署，前端通過ajax來調用http請求調用后端的restful api。前端只需要關注頁面的樣式與動態數據的解析&渲染，而后端專注于具體業務邏輯。
4、如果想玩多端應用，注意要去掉tomcat原生的session機制，要使用token機制，使用緩存（因為是分布式系統），做單點，對于token機制的安全性問題，可以搜一下jwt。
最近無意中發現了一個巨牛的人工智能教程，忍不住分享一下給大家。教程不僅是零基礎，通俗易懂，而且非常風趣幽默，像看小說一樣！覺得太牛了，所以分享給大家。點下面鏈接可以跳轉到教程。
https://www.captainbed.net/suga
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
