基於 OpenResty 的服務器架構設計

這個服務器架構不必定能用上，記錄在這裏，算是一個小小的學習成果。

1. 技術選擇

• Cocos2d-x 3.x —— 客戶端框架。
• WebSockt —— 網絡協議。
• HTTP —— 網絡協議。
• OpenResty —— 基於 nginx+lua 實現 WebSocket 或 HTTP 服務器。
• MySQL —— 數據庫支持。
• Redis —— NoSQL 支持。

2. 邏輯服務器

有兩個不一樣的客戶端須要提供服務。data_tester 和 client 。它們都須要 WebSocket 服務， client 還須要 HTTP 服務。

dtserver 爲 data_tester 提供 WebSocket 服務。

socketserver 爲 client 提供 WebSocket 服務，httpserver 爲 client 提供 HTTP 服務。

dtserver/socketserver/httpserver 均使用 OpenResty(with lua) 實現。

下圖表述了這種關係。虛線框內表明邏輯服務器部署。

3. 開發者分離

共有 4 個開發者 dev1~dev4 ，他們須要獨立的服務器環境進行開發與測試。

按照常規，開發者能夠在本身的開發計算機上創建服務器環境進行開發，待測試完畢後，合併代碼並部署到公用服務器上進行測試。

但 OpenResty 在 Windows 系統上編譯比較麻煩，因而我採起了上圖所示的部署方式：

在服務器上爲每一個開發者綁定一個獨立的 OpenResty 端口和 master 進程，使用獨立的端口號、配置文件和服務端代碼(lua files)，這樣可以實現徹底隔離。

對於 Redis，也進行相似的操做，每一個開發者綁定一個獨立的 Redis 配置文件和端口號。

HTTP 和 MySql 服務是共享的，不須要單獨分配。由於全部開發者都共享相同的用戶信息。

4. 部署工具

因爲全部的代碼都在遠程服務器上，爲了方便開發者管理服務器、更新本身的測試代碼，我使用 git 庫鉤子和腳原本實現了一套部署工具。

4.1 serverctrl

serverctrl 是一個專用於控制服務器的 git 倉庫。

下面的 OpenResty 服務器的和 redis 服務器的配置文件模版都保存在這個 git 庫中。

4.2 OpenResty 服務器

下面的例子是中，使用 [server] 表明服務器名稱，使用 [user] 表明開發者名稱（也是 git 庫的分支名稱）。

4.2.1 支持的服務器

OpenResty 服務器程序部署在 /opt/hhl 文件夾中，下面幾個服務器都是基於 OpenResty 的：

服務器	服務器路徑
socketserver	/opt/hhl/socketserver/[user]
dtserver	/opt/hhl/dtserver/[user]
httpserver	/opt/hhl/httpserver/[user]

4.2.2 每一個服務器程序的文件夾結構

每一個 OpenResty 服務器程序實例，都有徹底獨立的一套配置，以 /opt/hhl/socketserver/dev1 爲例，包含這樣幾個子文件夾：

• logs 存放 log 日誌和 pid 文件；
• conf 其中只有一個 nginx.conf 配置文件，供當前的 OpenResty 服務器程序實例使用；
• src 服務器邏輯的 lua 文件。

4.2.3 配置文件模版

每一個 OpenResty 服務器程序實例都使用不一樣的端口、 prefix 和配置文件，徹底獨立。

上面提到的 nginx.conf 配置文件的模版位於 serverctrl 的 git 倉庫中。模版文件爲： nginx.[server].templ.conf ，用於替換模版的值文件爲 nginx.[server].sub.py 。

下面是 nginx.socketserver.templ.conf 的內容：

worker_processes  $WORKER_PROCESSES;
error_log  logs/error.log  debug;
events {
  worker_connections  1024;
}
http {
  lua_package_path "/opt/hhl/socketserver/$USER_NAME/src/?.lua;;";
  lua_code_cache $LUA_CODE_CACHE;
  server {
    listen	   $LISTEN;
    server_name  $SERVER_NAME;
    location /hhl {
      content_by_lua_file  src/main.lua;
    }
  }
}

下面是 nginx.socketserver.sub.py 的內容：

{
  'master':{
    'WORKER_PROCESSES' : 1,
    'LUA_CODE_CACHE':'off',
    'LISTEN':'1080',
    'SERVER_NAME':'localhost',
  },
  'dev1':{
    'LISTEN':'1081',
  },
  'dev2':{
    'LISTEN':'1082',
  },
  'dev3':{
    'LISTEN':'1083',
  },
  'dev4':{
    'LISTEN':'1084',
  },
}

從上面的配置能夠看出，master 是配置文件基準值，下面的屬性會替換掉 master 中的同名值，而後寫入配置文件。

4.3 Redis 服務器

下面的例子是中，使用 [port] 表明 redis 服務器程序使用的端口號。

redis 服務器程序部署在 /opt/redis 文件夾中，與 OpenResty 不一樣，Redis 沒有采用分文件夾的方式，而是採用不一樣的配置文件來實現隔離。

配置文件名爲： /opt/redis/etc/[port].conf 。

每一個 Redis 服務器實例，使用不一樣的端口號和配置文件，徹底獨立。

上面提到的配置文件的模版位於 serverctrl 的 git 倉庫中。模版文件爲： redis.templ.conf ，用於替換模版的值文件爲 redis.sub.py 。

下面是 redis.templ.py 的內容：

include /opt/redis/etc/redis.conf

daemonize yes
pidfile /opt/redis/var/$PORT.pid
port $PORT
bind $BIND
tcp-keepalive 0
loglevel notice
logfile $PORT.log
databases 16
dbfilename $PORT.rdb
dir /opt/redis/var/
appendonly no
appendfilename "$PORT.aof"
syslog-enabled yes
syslog-ident redis-$PORT
syslog-facility local5

下面是 redis.sub.py 的內容：

{
  'master':{
    'PORT': 6379,
    'BIND': '127.0.0.1 192.168.18.18',
  },
  'dev1':{
    'PORT': 6381,
  },
  'dev2':{
    'PORT': 6382,
  },
  'dev3':{
    'PORT': 6383,
  },
  'dev4':{
    'PORT': 6384,
  },
}

替換規則與 OpenResty 的相同。

5. git 鉤子，部署代碼與重啓服務

要將本地的代碼部署到服務器上，只須要經過 git 鉤子，在提交本地代碼的同時，更新服務器上的代碼便可。

同時，不是全部的開發者都有服務器的管理權限。我使用 git 鉤子提供了重啓服務的功能，讓全部開發者均可以實現對本身的 Redis、OpenResty 進程的控制。

我在這篇文章中做了描述： 使用 git post-receive 鉤子部署服務端代碼 。

另外，因爲存在 3 個服務器程序，涉及到許多通用代碼和庫。我將這些代碼放置在一個單獨的 git 項目中，不對全部的開發者可見，但提供開發者文檔。這樣一來，開發者在本身的服務器程序中，只須要關注邏輯相關的代碼，而沒必要在乎底層庫是如何實現的。

6. log 日誌系統

因爲開發者沒有服務器權限，沒法看到服務的出錯日誌。爲了解決這個問題，我將全部的錯誤日誌使用 rsyslog 來管理，同時提供了基於 web 的查看系統。這樣一來，開發者們徹底沒必要和服務器打交道了。

我在這篇文章中做了描述： rsyslog/Python/LogAnalyzer 記錄和查看日誌 。

我基於 OpenResty 提供的 resty.logger.socket 實現了從服務端的 lua 代碼中將 log 提交到 rsyslog，這樣開發者調試代碼也可使用這種方式。

詳情見這兩個實現：

• SyslogHandler
• RestyAdapter

（全文完）

• 本文來自：Linux學習教程網