這個服務器架構不一定能用上,記錄在這里,算是一個小小的學習成果。
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,這樣開發者調試代碼也可以使用這種方式。
詳情見這兩個實現:
(全文完)