低代碼平臺如何藉助Nginx實現網關服務

摘要：本文由葡萄城技術團隊於OSCHINA原創並首發。轉載請註明出處：葡萄城官網，葡萄城爲開發者提供專業的開發工具、解決方案和服務，賦能開發者。

前言

在典型的系統部署架構中，應用服務器是一種軟件或硬件系統，它承載着應用程序的核心邏輯。它接收客戶端的請求並處理相應的業務邏輯、數據操作等任務。應用服務器通常被用於支持 Web 應用程序、移動應用程序和企業應用程序等。在應用服務器之上通常是網關服務器，在其下方是數據庫服務。有趣的是，在低代碼平臺中，同樣也存在應用服務器，今天小編將以葡萄城公司的企業級低代碼開發平臺——活字格爲例給大家介紹網關服務器對於低代碼平臺的輔助作用。

使用Nginx實現的應用場景

在本文中，將以網關服務器Nginx爲例，展示網關服務的四個場景：

跨域訪問：讓多個應用共享同一個服務器的端口。
靜態資源：通過微信公衆平臺等驗證。
IP黑白名單：滿足更高的安全防護要求。
訪問日誌：詳細記錄並分析系統響應能力。

1.跨域訪問：讓多個應用共享同一個服務器的同一個端口

將同一個系統的多個模塊拆分成若干個應用，不論是開發管理還是系統運維都是很值得推薦的實踐模式。但如果一個應用的前端頁面需要調用另一個應用的服務端命令時，會遇到跨域訪問的問題。爲了解決這個問題，我們需要將這些跨應用調用的功能全部挪到服務端命令中：A應用的前端頁面調用A應用的服務端命令，在該服務端命令中調用B應用的WebAPI。這種做法平添了開發A應用服務端命令的工作量，後期維護時也會有額外的工作和風險。

在編碼開發時，通常是通過網關將所有應用統一到同一個地址和端口中，來避免這種跨域訪問的問題。而在低代碼開發中，解決的方式也是一樣的。

在服務器上架設一臺Nginx服務器，將多個應用作爲Nginx的upstream。具體的配置方法如下：

（1）修改Nginx配置，在http節點下方爲管理控制檯和每個應用配置一個upstream節點，包含機器名和端口號。在測試環境中，Nginx安裝在應用服務器上，所以這裏可以直接用localhost。常規情況下，Nginx需要部署到和應用服務器在同一個局域網內的另外一臺服務器上，此時，需要將localhost替換爲該服務器的內網IP。

提示：爲應用服務器添加upstream而不是直接在location中跳轉，可以提升配置文件的可讀性。

upstream us-server{
     server localhost:22345;
   }

   upstream red-server{
     server localhost:9101;
   }

   upstream green-server{
     server localhost:9102;
   }

（2）在http→server節點中監聽80端口或其他指定的端口號。

listen    80;

（3）在http→server節點中，爲管理控制檯和每個應用分別配置一個location節點，包含URL的匹配規則和對應的upstream。最常用的規則是從頭開始匹配，即^~意味着以後面的字符串開頭，如location ^~ /red/匹配到的是所有以/red/開頭的location（URL中端口號後面的部分）。

 location ^~ /UserService/ {
       proxy_pass http://us-server/UserService/;
       proxy_redirect default;   
     }
 
 location ^~ /red/ {
   proxy_pass http://red-server/red/;
   proxy_redirect default;
 }
 
 location ^~ /green/ {
   proxy_pass http://green-server/green/;
   proxy_redirect default;
 }

（4）在活字格管理控制檯上，將應用的“域名”（應用管理→應用→常規設置→設置域名）修改爲Nginx監聽的端口，確保頁面的外部導航正常運行。應用的配置中，需要包含應用名。

管理控制檯的“域名”也需要設置（設置→安全設置→設置管理控制檯站點的域名），控制檯的配置不包含應用名。

擴展場景：
如果您的IT安全策略要求只能開放80/443端口，但需要訪問到多個應用時，也可以用這個方案，實現端口統一化。

2.靜態資源：通過微信公衆平臺等驗證

在對接微信公衆平臺等第三方系統時，對方通常會提出基於文件的域名驗證機制，如微信公衆平臺的JS接口域名驗證需要將特定文件放到域名的根目錄。

此時，可以使用網關的靜態資源服務器能力，完成驗證工作。

在【1.跨域訪問】的基礎上繼續配置Nginx文件，具體的操作方法如下：

（1）：在域名管理的界面上，通過ICP備案的域名指向Nginx服務器的外網地址。

（2）：將需要對外提供訪問的靜態文件存放到Nginx服務器上Nginx靜態資源根目錄中，如/etc/Nginx/html（安裝方式和版本不同，根目錄還可能是/usr/share/Nginx/html或/var/www/html，默認情況下，Nginx根目錄中有index.html和50x.html兩個文件）。Nginx將根目錄中的文件以Web靜態資源的形式提供給外部使用。具體而言就是接收到URL爲 /xxx.yyy 的請求時，將根目錄中的xxx.yyy文件內容作爲響應來返回。

3.IP黑白名單：滿足更高的安全防護要求

對於一些高安全要求的應用場景，通常會要求做黑白名單，如僅允許特定的IP訪問、或不允許某個特定的IP訪問。這些工作推薦在網關上執行，將風險攔截在應用服務器之外。
因爲活字格內置的管理控制檯中包含了應用管理、用戶角色管理等敏感操作，很多企業要求爲該應用啓用白名單控制，僅允許公司IT運維團隊專用的IP地址訪問。接下來，我們在【二、跨域訪問】的基礎上繼續完善Nginx配置來實現白名單。具體的操作方法如下：

修改Nginx配置中http→server節點中找到管理控制檯對應的location，在下面追加以下內容，將內網的10.32.209.252和外網的113.132.178.118添加到白名單。

 location ^~ /UserService/ {
       proxy_pass http://us-server/UserService/;
       proxy_redirect default;  
       allow 10.32.209.252;
       allow 113.132.178.118;
       deny all; 
     }

重要提示：
網關層面的白名單層次高於系統防火牆，兩者不是取代關係。您依然需要使用防火牆的策略來避免暴露不必要的端口，以降低安全風險。

4.訪問日誌：詳細記錄並分析系統響應能力

當需要評估系統的響應性能、可用性等參數，尋找改進方向時，您需要通過第三方來記錄應用的訪問日誌，然後將其接入主流的日誌處理和分析工具鏈（日誌分析是一個“高技術含量”的領域，已經有成熟的方案，如ELK）進行後續處理。

好消息是，Nginx內置了日誌機制，只需要做非常簡單的配置，就可以得到想要的日誌，然後再按照ELK的幫助文檔，就能搞定自己的日誌分析平臺了。繼續在【3.IP黑白名單】的基礎上繼續完善Nginx配置和日誌配置。具體的操作方法如下：

（1）：修改Nginx配置中http節點，添加一個名爲json的日誌模板，便於filebeats抓取。

log_format json escape=json '{"time_local": "$time_local", '
              '"remote_addr": "$remote_addr", '
              '"request_uri": "$request_uri", '
              '"status": $status, '
              '"upstream_time": "$upstream_response_time"}';

（2）：修改http→server節點，追加訪問日誌的配置，指定文件路徑和剛纔定義的名爲json的模板access_log /var/log/Nginx/access.log json;