⑴ 微服務前端和後端的交互
前後的交互的方式主要考慮的是交互方式與傳輸安全考慮
關於交互方式：
常用的一般是tcp、udp和http
1）get、post、put、delete方式請求操作數據
2）傳輸數據一般是使用json（也有xml，當時現在很少了）
關於安全性的考慮，先講下我的設計思想（從內到外）：
1）參數簽名，使用某種自定義的規則，前後端對要請求的數據進行簽名操作，放入參數sign中，可以使用單項加密（如md5），或者是對稱加密演算法加密
2）使用非對稱演算法進行加密，在客戶端使用公鑰加密，伺服器端使用私鑰解密
3）在傳輸過程中使用https
4）在伺服器端收到數據後，使用私鑰進行解密，驗證數據完整性
5）參數簽名驗證
6）對比較重要的數據，如需要返回代表前後端交互的代表值，則需要將返回數據進行加密（根據場景使用加密演算法）
對於重要的數據，都是不能以明文數據進行傳輸的。對於不重要的數據，可進行加密或不進行加密處理
⑵ 微服務架構：基於微服務和Docker容器技術的PaaS雲平台架構設計
基於微服務架構和Docker容器技術的PaaS雲平台建設目標是給我們的開發人員提供一套服務快速開發、部署、運維管理、持續開發持續集成的流程。平台提供基礎設施、中間件、數據服務、雲伺服器等資源，開發人員只需要開發業務代碼並提交到平台代碼庫，做一些必要的配置，系統會自動構建、部署，實現應用的敏捷開發、快速迭代。在系統架構上，PaaS雲平台主要分為微服務架構、Docker容器技術、DveOps三部分，這篇文章重點介紹微服務架構的實施。
如果想學習Java工程化、高性能及分布式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java高級交流：854630135，群里有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。
實施微服務需要投入大量的技術力量來開發基礎設施，這對很多公司來說顯然是不現實的，別擔心，業界已經有非常優秀的開源框架供我們參考使用。目前業界比較成熟的微服務框架有Netflix、Spring Cloud和阿里的Dubbo等。Spring Cloud是基於Spring Boot的一整套實現微服務的框架，它提供了開發微服務所需的組件，跟Spring Boot一起使用的話開發微服務架構的雲服務會變的很方便。Spring Cloud包含很多子框架，其中Spring Cloud Netflix是其中的一套框架，在我們的微服務架構設計中，就使用了很多Spring Cloud Netflix框架的組件。Spring Cloud Netflix項目的時間還不長，相關的文檔資料很少，博主當時研究這套框架啃了很多英文文檔，簡直痛苦不堪。對於剛開始接觸這套框架的同學，要搭建一套微服務應用架構，可能會不知道如何下手，接下來介紹我們的微服務架構搭建過程以及 需要那些 框架或組件來支持微服務架構。
為了直接明了的展示微服務架構的組成及原理，畫了一張系統架構圖，如下：
從上圖可以看出，微服務訪問大致路徑為：外部請求 → 負載均衡 → 服務網關（GateWay）→ 微服務 → 數據服務/消息服務。服務網關和微服務都會用到服務注冊和發現來調用依賴的其他服務，各服務集群都能通過配置中心服務來獲得配置信息。
服務網關（GateWay）
網關是外界系統（如：客戶端瀏覽器、移動設備等）和企業內部系統之間的一道門，所有的客戶端請求通過網關訪問後台服務。為了應對高並發訪問，服務網關以集群形式部署，這就意味著需要做負載均衡，我們採用了亞馬遜EC2作為虛擬雲伺服器，採用ELB(Elastic Load Balancing)做負載均衡。EC2具有自動配置容量功能，當用戶流量達到尖峰，EC2可以自動增加更多的容量以維持虛擬主機的性能。ELB彈性負載均衡，在多個實例間自動分配應用的傳入流量。為了保證安全性，客戶端請求需要使用https加密保護，這就需要我們進行SSL卸載,使用Nginx對加密請求進行卸載處理。外部請求經過ELB負載均衡後路由到GateWay集群中的某個GateWay服務，由GateWay服務轉發到微服務。服務網關作為內部系統的邊界，它有以下基本能力：
1、動態路由：動態的將請求路由到所需要的後端服務集群。雖然內部是復雜的分布式微服務網狀結構，但是外部系統從網關看就像是一個整體服務，網關屏蔽了後端服務的復雜性。
2、限流和容錯：為每種類型的請求分配容量，當請求數量超過閥值時拋掉外部請求，限制流量，保護後台服務不被大流量沖垮；黨內部服務出現故障時直接在邊界創建一些響應，集中做容錯處理，而不是將請求轉發到內部集群，保證用戶良好的體驗。
3、身份認證和安全性控制：對每個外部請求進行用戶認證，拒絕沒有通過認證的請求，還能通過訪問模式分析，實現反爬蟲功能。
4、監控：網關可以收集有意義的數據和統計，為後台服務優化提供數據支持。
5、訪問日誌：網關可以收集訪問日誌信息，比如訪問的是哪個服務？處理過程（出現什麼異常）和結果？花費多少時間？通過分析日誌內容，對後台系統做進一步優化。
我們採用Spring Cloud Netflix框架的開源組件Zuul來實現網關服務。Zuul使用一系列不同類型的過濾器（Filter），通過重寫過濾器，使我們能夠靈活的實現網關（GateWay）的各種功能。
如果想學習Java工程化、高性能及分布式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java高級交流：854630135，群里有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。
服務注冊與發現
由於微服務架構是由一系列職責單一的細粒度服務構成的網狀結構，服務之間通過輕量機制進行通信，這就引入了服務注冊與發現的問題，服務的提供方要注冊報告服務地址，服務調用放要能發現目標服務。我們的微服務架構中使用了Eureka組件來實現服務的注冊與發現。所有的微服務（通過配置Eureka服務信息）到Eureka伺服器中進行注冊，並定時發送心跳進行 健康 檢查，Eureka默認配置是30秒發送一次心跳，表明服務仍然處於存活狀態，發送心跳的時間間隔可以通過Eureka的配置參數自行配置，Eureka伺服器在接收到服務實例的最後一次心跳後，需要等待90秒（默認配置90秒，可以通過配置參數進行修改）後，才認定服務已經死亡（即連續3次沒有接收到心跳），在Eureka自我保護模式關閉的情況下會清除該服務的注冊信息。所謂的自我保護模式是指，出現網路分區、Eureka在短時間內丟失過多的服務時，會進入自我保護模式，即一個服務長時間沒有發送心跳，Eureka也不會將其刪除。自我保護模式默認為開啟，可以通過配置參數將其設置為關閉狀態。
Eureka服務以集群的方式部署（在博主的另一篇文章中詳細介紹了Eureka集群的部署方式），集群內的所有Eureka節點會定時自動同步微服務的注冊信息，這樣就能保證所有的Eureka服務注冊信息保持一致。那麼在Eureka集群里，Eureka節點是如何發現其他節點的呢？我們通過DNS伺服器來建立所有Eureka節點的關聯，在部署Eureka集群之外還需要搭建DNS伺服器。
當網關服務轉發外部請求或者是後台微服務之間相互調用時，會去Eureka伺服器上查找目標服務的注冊信息，發現目標服務並進行調用，這樣就形成了服務注冊與發現的整個流程。Eureka的配置參數數量很多，多達上百個，博主會在另外的文章里詳細說明。
微服務部署
微服務是一系列職責單一、細粒度的服務，是將我們的業務進行拆分為獨立的服務單元，伸縮性好，耦合度低，不同的微服務可以用不同的語言開發，每一個服務處理的單一的業務。微服務可以劃分為前端服務（也叫邊緣服務）和後端服務（也叫中間服務），前端服務是對後端服務做必要的聚合和剪裁後暴露給外部不同的設備（PC、Phone等），所有的服務啟動時都會到Eureka伺服器進行注冊，服務之間會有錯綜復雜的依賴關系。當網關服務轉發外部請求調用前端服務時，通過查詢服務注冊表就可以發現目標服務進行調用，前端服務調用後端服務時也是同樣的道理，一次請求可能涉及到多個服務之間的相互調用。由於每個微服務都是以集群的形式部署，服務之間相互調用的時候需要做負載均衡，因此每個服務中都有一個LB組件用來實現負載均衡。
微服務以鏡像的形式，運行在Docker容器中。Docker容器技術讓我們的服務部署變得簡單、高效。傳統的部署方式，需要在每台伺服器上安裝運行環境，如果我們的伺服器數量龐大，在每台伺服器上安裝運行環境將是一項無比繁重的工作，一旦運行環境發生改變，就不得不重新安裝，這簡直是災難性的。而使用Docker容器技術，我們只需要將所需的基礎鏡像（jdk等）和微服務生成一個新的鏡像，將這個最終的鏡像部署在Docker容器中運行，這種方式簡單、高效，能夠快速部署服務。每個Docker容器中可以運行多個微服務，Docker容器以集群的方式部署，使用Docker Swarm對這些容器進行管理。我們創建一個鏡像倉庫用來存放所有的基礎鏡像以及生成的最終交付鏡像，在鏡像倉庫中對所有鏡像進行管理。
服務容錯
微服務之間存在錯綜復雜的依賴關系，一次請求可能會依賴多個後端服務，在實際生產中這些服務可能會產生故障或者延遲，在一個高流量的系統中，一旦某個服務產生延遲，可能會在短時間內耗盡系統資源，將整個系統拖垮，因此一個服務如果不能對其故障進行隔離和容錯，這本身就是災難性的。我們的微服務架構中使用了Hystrix組件來進行容錯處理。Hystrix是Netflix的一款開源組件，它通過熔斷模式、隔離模式、回退（fallback）和限流等機制對服務進行彈性容錯保護，保證系統的穩定性。
1、熔斷模式：熔斷模式原理類似於電路熔斷器，當電路發生短路時，熔斷器熔斷，保護電路避免遭受災難性損失。當服務異常或者大量延時，滿足熔斷條件時服務調用方會主動啟動熔斷，執行fallback邏輯直接返回，不會繼續調用服務進一步拖垮系統。熔斷器默認配置服務調用錯誤率閥值為50%，超過閥值將自動啟動熔斷模式。服務隔離一段時間以後，熔斷器會進入半熔斷狀態，即允許少量請求進行嘗試，如果仍然調用失敗，則回到熔斷狀態，如果調用成功，則關閉熔斷模式。
2、隔離模式：Hystrix默認採用線程隔離，不同的服務使用不同的線程池，彼此之間不受影響，當一個服務出現故障耗盡它的線程池資源，其他的服務正常運行不受影響，達到隔離的效果。例如我們通過andThreadPoolKey配置某個服務使用命名為TestThreadPool的線程池，實現與其他命名的線程池隔離。
3、回退（fallback）：fallback機制其實是一種服務故障時的容錯方式，原理類似Java中的異常處理。只需要繼承HystixCommand並重寫getFallBack()方法，在此方法中編寫處理邏輯，比如可以直接拋異常（快速失敗），可以返回空值或預設值，也可以返回備份數據等。當服務調用出現異常時，會轉向執行getFallBack()。有以下幾種情況會觸發fallback：
1）程序拋出非HystrixBadRequestExcepption異常，當拋出HystrixBadRequestExcepption異常時，調用程序可以捕獲異常，沒有觸發fallback，當拋出其他異常時，會觸發fallback；
2）程序運行超時；
3）熔斷啟動；
4）線程池已滿。
4、限流： 限流是指對服務的並發訪問量進行限制，設置單位時間內的並發數，超出限制的請求拒絕並fallback，防止後台服務被沖垮。
Hystix使用命令模式HystrixCommand包裝依賴調用邏輯，這樣相關的調用就自動處於Hystrix的彈性容錯保護之下。調用程序需要繼承HystrixCommand並將調用邏輯寫在run()中，使用execute()（同步阻塞）或queue()（非同步非阻塞）來觸發執行run()。
動態配置中心
微服務有很多依賴配置，某些配置參數在服務運行期間可能還要動態修改，比如：根據訪問流量動態調整熔斷閥值。傳統的實現信息配置的方法，比如放在xml、yml等配置文件中，和應用一起打包，每次修改都要重新提交代碼、打包構建、生成新的鏡像、重新啟動服務，效率太低，這樣顯然是不合理的，因此我們需要搭建一個動態配置中心服務支持微服務動態配置。我們使用Spring Cloud的configserver服務幫我們實現動態配置中心的搭建。我們開發的微服務代碼都存放在git伺服器私有倉庫裡面，所有需要動態配置的配置文件存放在git伺服器下的configserver（配置中心，也是一個微服務）服務中，部署到Docker容器中的微服務從git伺服器動態讀取配置文件的信息。當本地git倉庫修改代碼後push到git伺服器倉庫，git服務端hooks(post-receive，在服務端完成代碼更新後會自動調用)自動檢測是否有配置文件更新，如果有，git服務端通過消息隊列給配置中心（configserver，一個部署在容器中的微服務）發消息，通知配置中心刷新對應的配置文件。這樣微服務就能獲取到最新的配置文件信息，實現動態配置。
以上這些框架或組件是支撐實施微服務架構的核心，在實際生產中，我們還會用到很多其他的組件，比如日誌服務組件、消息服務組件等等，根據業務需要自行選擇使用。在我們的微服務架構實施案例中，參考使用了很多Spring Cloud Netflix框架的開源組件，主要包括Zuul（服務網關）、Eureka（服務注冊與發現）、Hystrix（服務容錯）、Ribbon（客戶端負載均衡）等。這些優秀的開源組件，為我們實施微服務架構提供了捷徑。
如果想學習Java工程化、高性能及分布式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java高級交流：854630135，群里有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。
⑶ 輕量、高效、功能強大的微前端框架-MicroApp
這幾年後端的微服務是比較火爆，我們公司目前只要是新項目，基本上都是基於微服務去架構的，那麼微前端是什麼呢？
微前端是借鑒了微服務的架構理念，核心在於將一個龐大的前端應用拆分成多個獨立靈活的小型應用，每個應用都可以獨立開發、獨立運行、獨立部署，再將這些小型應用融合為一個完整的應用，或者將原本運行已久、沒有關聯的幾個應用融合為一個應用。微前端既可以將多個項目融合為一，又可以減少項目之間的耦合，提升項目擴展性，相比一整塊的前端倉庫，微前端架構下的前端倉庫傾向於更小更靈活
以前我們為了把幾個獨立運行的小型應用合並成一個應用都是通過iframe的方式去實現的，如果不考慮體驗問題，iframe 幾乎是最完美的微前端解決方案了。
iframe 最大的特性就是提供了瀏覽器原生的硬隔離方案，不論是樣式隔離、js 隔離這類問題統統都能被完美解決。但他的最大問題也在於他的隔離性無法被突破，導致應用間上下文無法被共享，隨之帶來的開發體驗、產品體驗的問題
micro-app不是基於iframe架構的
micro-app提供了js沙箱、樣式隔離、元素隔離、預載入、數據通信、靜態資源補全等一系列完善的開箱即用功能
micro-app沒有任何依賴
為了保證各個業務之間獨立開發、獨立部署的能力，micro-app做了諸多兼容，在任何技術框架中都可以正常運行。
下面我講一下如何在Vue中使用micro-app
1、初始化一個基座應用
2、基座應用的文件修改
main.js修改
router.js修改
3、main-page.vue頁面
4、創建一個子應用
5、子應用的router.js文件修改
6、src目錄下新建 public-path.js
7、 main.js 引入public-path.js
到此這個簡單的微應用就搭好了
覺得效果不錯的請幫忙加個關注點個贊，經常分享前端實用開發技巧
⑷ 微服務下沒有服務網關前端如何調用後端服務
在微服務改造過程中，往往我們會遇到這樣的情況，在開發環境中沒有服務網關，前端需要連接多個獨立服務（獨立服務的意思是服務不是同一個ip+埠所提供的）。在開發時，我們可以直接寫死服務地址，來實現對後端服務的調用。但是，如若到生產環境，亦或是臨時將開發成果暴露至公網，這個方法顯然不行。那有沒有辦法零時頂替一下呢？
1.前端調用的後端服務地址抹去ip+埠（將寫死的地址去掉）
2.加上易辨別的前綴，用於Nginx轉發是匹配的url路徑
3.在nginx配置文件中添加該url路徑的代理地址
例如作者配置的圖片瀏覽服務的nginx代理：
⑸ 前後端分離微服務架構如何設計
前端
前端開發人員專注業務的頁面呈現，非常注重用戶體驗度，也是與各種角色打交道最多的。
比如：
一般前端工作包括六個部分：
後端
如果前後端職責劃分很清楚的話，後端更多開發工作在於業務介面設計、業務邏輯處理以及數據的持久化存儲，並提供詳細的介面設計文檔給前端開發人員使用。
一般後端工作包括五個部分：
1、與產品經理對接需求
2、業務 API 介面開發：根據根據需求文檔進行業務介面開發
4、介面對接：與前端開發人員介面對接
5、前後端聯調測試：包括頁面展示以及介面數據
6、bug修復
前端開發技術棧
h5 、 css 、 nodejs / vue / angular / react 、 webpack 、 hbuilder / vscode 等
後端開發技術棧
SpringCloud / Springboot 、 SpringMVC 、 ORM 框架、資料庫、緩存框架（ Redis ， Codis , Memcached 等），大數據框架（ Hadoop / Spark / hive / Hbase / Storm / ES / Kafka ）等等
技術選型
最好選擇成熟穩定，易上手、開發效率高的技術，因為實際項目開發時間是有限的，開發人員沒有多少精力放在學習和深度研究技術上。
數據格式
後端開發提供介面設計文檔，詳細寫明每個介面的請求地址、請求參數、響應參數等等；一般採用 REST 風格以 JSON 格式提供數據。
介面設計
一個介面設計的好壞，直接影響到前後端的一些溝通協調問題。
依筆者的經驗來看，如果後端介面不穩定，會導致前端開發人員反復修改頁面數據呈現。常常出現後端開發說這是前端問題，前端開發說是後端問題，來回扯皮，溝通效率低下。
介面容量問題
一個介面的業務容量大小，往往代表前後端工作量的大小。
如果一個介面的業務容量太小，前端需要分階段處理的事情就多，尤其是對多個介面 Ajax 非同步處理；
如果一個介面的業務容量太大，那麼業務耦合性高，萬一需求變更，後端程序改動大，不利於程序的擴展。
一、前後端分離的思想要轉變
不能老是按照傳統WEB（ js/h5/css/ 後端代碼放在一個工程）開發思維去看待前後端分離
二、溝通成本問題
以前傳統 WEB 開發，開發人員從需求到設計到開發基本上是一個人。
而前後端分離後，前端只負責頁面呈現，後端更注重業務邏輯處理以及數據的持久化，雙發都有自己的側重點，工作量上有私心。
三、組織結構問題
康威定律
第一定律： Communication dictates design （組織溝通方式會通過系統設計表達出來）
第二定律： There is never enough time to do something right, but there is always enough time to do it over （時間再多一件事情也不可能做得美，但總有時間做完一件事情）
第三定律 ： There is a homomorphism from the linear graph of a system to the linear graph of its design organization （線型系統和線型組織架構間有潛在的異質同態特性）
第四定律： The structures of large systems tend to disintegrate ring development, qualitatively more so than with small systems （大的系統組織總是比小系統更傾向於分解）
康威定律說明以下幾點
四、部署及監控運維
前後端分離後，拆分的服務會帶來線上部署以及如何監控運維的復雜性。
總體來說，前後分離所帶來的好處還是更明顯的。一個成熟的前後端分離的團隊，文檔化約定，前後端職責分離、介面約定都是做得比較好的
⑹ 微服務平台前後端是相同的平台嗎
微服務平台前後端不是相同的平台。根據查詢相關公開信息顯示，微服務的平台別部署在不同伺服器上，前後端分離一般是在開發的時候項目分開，部署的時候會把前端代碼編譯到後端的平台。微服務平台是指一種軟體開發技術。面向服務的體系結構SOA架構樣式的一種變體，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。
⑺ 前端微服務設計
近些年，前端發展呈百家爭鳴式發展，框架層出不窮，版本更是迭代不窮，難免會出現前端項目技術棧不統一、所用框架版本不統一的情況。
如若某些項目，沒有新的功能加入，又能線上穩定運行，但其技術棧卻用的是 vue1.0，為了將其結合到新應用中去而對其重構，成本會很高。然而，微服務可以幫我們解決這個問題。
在既不重寫原有系統的基礎之下，又可以抽出人力來開發新的業務。其不僅僅對於業務人員來說是一個相當吸引力的特性，對於技術人員來說，不重寫舊的業務，能在一些新技術上做挑戰，也是一件很有意思的事情。
除此之外，在這兩三年裡，移動應用出現了一種趨勢，用戶不想裝那麼多應用。而往往一家大的商業公司，會提供一系列的應用。這些應用也從某種程度上，反應了這家公司的組織架構。然而，在用戶的眼裡他們就是一家公司，他們就只應該有一個產品。相似的，這種趨勢也在桌面 Web 出現。聚合成為了一個技術趨勢，體現在前端的聚合就是微服務化架構。
理想的前端微服務化，應該是符合如下幾個特點：
路由分發式微前端，即通過設置路由，將不同的業務分發到不同的、獨立前端應用上。其通常可以通過 HTTP 伺服器的反向代理來實現，又或者是應用框架自帶的路由來解決。
就當前而言，通過路由分發式的微前端架構應該是採用最多、最易採用的 「微前端」 方案。但是這種方式看上去更像是多個前端應用的聚合，即我們只是將這些不同的前端應用拼湊到一起，使他們看起來像是一個完整的整體。但是，它們並不是一個完整的整體，每次用戶從 A 應用到 B 應用的時候，往往需要刷新一下頁面。
通常可通過 nginx 配置反向代理，來進行路由分發，從而實現前端微服務。
它適用於以下場景：
iframe 可以創建一個全新的獨立的宿主環境，這意味著我們的前端應用之間可以相互獨立運行。
採用 iframe 有幾個重要的前提：
即何時載入、卸載應用，如何監聽應用事件等。
不論是基於 Web Components 的 Angular，或者是 VirtualDOM 的 React 等，現有的前端框架都離不開基本的 HTML 元素 DOM。
那麼，我們只需要：
第一個問題，創建 DOM 是一個容易解決的問題。而第二個問題，則一點兒不容易，特別是移除 DOM 和相應應用的監聽。當我們擁有一個不同的技術棧時，我們就需要有針對性設計出一套這樣的邏輯。現有的框架有single-spa、qiankun、mooa等
常見的方式有：
其次，採用這種方式還有一個限制，那就是：規范！ 規范！ 規范！。在採用這種方案時，我們需要：
Web Components 組件可以擁有自己獨立的 Scripts 和 Styles，以及對應的用於單獨部署組件的域名。然而它並沒有想像中的那麼美好，要直接使用純 Web Components 來構建前端應用的難度有：
現有的微前端框架有single-spa、qiankun、mooa。其均是在前端框架之上設計通訊、載入機制來實現的。
⑻ 微服務架構下，進行前後端分離，前端怎麼寫
分離後的前端，不再是一個簡單的HTML文件，已經是一個獨立的應用系統。除了要考慮頁面的數據渲染展示，還要用工程化的思想來考慮前端的架構，前後端的交互和數據安全等事情。
RESTful介面交互
前後端分離之後，更多的是採用RESTful風格的介面與後端進行數據交互。
REST是「呈現狀態轉移（REpresentational State Transfer）」的縮寫，一種API的架構風格，在客戶端和服務端之間通過呈現狀態的轉移來驅動應用狀態的演進。
在 REST 樣式的 Web 服務中，每個資源都有一個地址。資源本身都是方法調用的目標，方法列表對所有資源都是一樣的。這些方法都是標准方法，包括 HTTP GET、POST、PUT、DELETE，還可能包括 HEADER 和 OPTIONS。
RESTful的API設計，使得後端通過介面向前端傳遞數據，數據的格式通常是JSON這種通用的格式。對前端來說，只要後端返回過來的是RESTful的數據就行，不管後端是用Java寫，還是用python或PHP，拜託對後端的依賴，做到前端系統的獨立。
工程化構建
Nodejs不止可以用來做前端伺服器，在開發階段，它也能發揮很大的作用。
前端生態的發展，是圍繞著Nodejs進行的。用npm來管理項目依賴，可以很好的維護和運行在Nodejs環境上。
打包工具grunt、gulp、webpack和rollup等，都是運行在nodejs上，再結合語法編譯、打包部署等插件，將應用輸入成一個完整的應用。
如果你使用了Angular、React或Vue框架，或者你使用瀏覽器暫時還不兼容的ES6語法，還需要在應用打包前用babel將語法編譯成瀏覽器可識別的ES5的語法。
SPA
SPA是單頁Web應用（single page web application，SPA）的簡寫，就是只有一張Web頁面的應用，是載入單個HTML 頁面並在用戶與應用程序交互時動態更新該頁面的Web應用程序。
像Angular、React或Vue就是為了SPA而設計的，結合前端路由庫（react-router、vue-router）和狀態熱存儲（rex、vuex）等，可以開發出一個媲美Native APP的Web APP，用戶體驗得到了很大的提升。
當然，SPA也不是完美的，也不是適合所有的web應用，需要結合項目和場景來選擇。
SPA有如下缺點：
初次載入耗時增加。可以通過代碼拆分、懶載入來提升性能，減少初次載入耗時。
SEO不友好，現在可以通過Prerender或Server render來解決一部分。
頁面的前進和後端需要開發者自己寫，不過現在一些路由庫已經幫助我們基本解決了。
對開發者要求高，由於做SPA需要了解一整套技術棧，所以，要考慮後期是否有合適的人選進行維護。