這個服務器架構(gòu)不一定能用上，記錄在這里，算是一個小小的學習成果。
1. 技術(shù)選擇
- Cocos2d-x 3.x —— 客戶端框架。
- WebSockt —— 網(wǎng)絡協(xié)議。
- HTTP —— 網(wǎng)絡協(xié)議。
- OpenResty —— 基于 nginx+lua 實現(xiàn) WebSocket 或 HTTP 服務器。
- MySQL —— 數(shù)據(jù)庫支持。
- 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) 實現(xiàn)。
下圖表述了這種關(guān)系。虛線框內(nèi)代表邏輯服務器部署。
3. 開發(fā)者分離
共有 4 個開發(fā)者 dev1~dev4 ，他們需要獨立的服務器環(huán)境進行開發(fā)與測試。
按照常規(guī)，開發(fā)者可以在自己的開發(fā)計算機上建立服務器環(huán)境進行開發(fā)，待測試完畢后，合并代碼并部署到公用服務器上進行測試。
但 OpenResty 在 Windows 系統(tǒng)上編譯比較麻煩，于是我采取了上圖所示的部署方式：
在服務器上為每個開發(fā)者綁定一個獨立的 OpenResty 端口和 master 進程，使用獨立的端口號、配置文件和服務端代碼(lua files)，這樣能夠?qū)崿F(xiàn)完全隔離。
對于 Redis，也進行類似的操作，每個開發(fā)者綁定一個獨立的 Redis 配置文件和端口號。
HTTP 和 MySql 服務是共享的，不需要單獨分配。因為所有開發(fā)者都共享相同的用戶信息。
4. 部署工具
由于所有的代碼都在遠程服務器上，為了方便開發(fā)者管理服務器、更新自己的測試代碼，我使用 git 庫鉤子和腳本來實現(xiàn)了一套部署工具。
4.1 serverctrl
serverctrl 是一個專用于控制服務器的 git 倉庫。
下面的 OpenResty 服務器的和 redis 服務器的配置文件模版都保存在這個 git 庫中。
4.2 OpenResty 服務器
下面的例子是中，使用 [server] 代表服務器名稱，使用 [user] 代表開發(fā)者名稱（也是 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 每個服務器程序的文件夾結(jié)構(gòu)
每個 OpenResty 服務器程序?qū)嵗加型耆毩⒌囊惶着渲茫?/span>/opt/hhl/socketserver/dev1 為例，包含這樣幾個子文件夾：
- logs 存放 log 日志和 pid 文件；
- conf 其中只有一個 nginx.conf 配置文件，供當前的 OpenResty 服務器程序?qū)嵗褂茫?/span>
- src 服務器邏輯的 lua 文件。
4.2.3 配置文件模版
每個 OpenResty 服務器程序?qū)嵗际褂貌煌亩丝凇?prefix 和配置文件，完全獨立。
上面提到的 nginx.conf 配置文件的模版位于 serverctrl 的 git 倉庫中。模版文件為： nginx.[server].templ.conf ，用于替換模版的值文件為nginx.[server].sub.py 。
下面是 nginx.socketserver.templ.conf 的內(nèi)容：
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 的內(nèi)容：
{ '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 沒有采用分文件夾的方式，而是采用不同的配置文件來實現(xiàn)隔離。
配置文件名為： /opt/redis/etc/[port].conf 。
每個 Redis 服務器實例，使用不同的端口號和配置文件，完全獨立。
上面提到的配置文件的模版位于 serverctrl 的 git 倉庫中。模版文件為：redis.templ.conf ，用于替換模版的值文件為 redis.sub.py 。
下面是 redis.templ.py 的內(nèi)容：
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 的內(nèi)容：
{ 'master':{ 'PORT': 6379, 'BIND': '127.0.0.1 192.168.18.18', }, 'dev1':{ 'PORT': 6381, }, 'dev2':{ 'PORT': 6382, }, 'dev3':{ 'PORT': 6383, }, 'dev4':{ 'PORT': 6384, }, } 替換規(guī)則與 OpenResty 的相同。
5. git 鉤子，部署代碼與重啟服務
要將本地的代碼部署到服務器上，只需要通過 git 鉤子，在提交本地代碼的同時，更新服務器上的代碼即可。
同時，不是所有的開發(fā)者都有服務器的管理權(quán)限。我使用 git 鉤子提供了重啟服務的功能，讓所有開發(fā)者都可以實現(xiàn)對自己的 Redis、OpenResty 進程的控制。
我在這篇文章中作了描述：使用 git post-receive 鉤子部署服務端代碼 。
另外，由于存在 3 個服務器程序，涉及到許多通用代碼和庫。我將這些代碼放置在一個單獨的 git 項目中，不對所有的開發(fā)者可見，但提供開發(fā)者文檔。這樣一來，開發(fā)者在自己的服務器程序中，只需要關(guān)注邏輯相關(guān)的代碼，而不必在意底層庫是如何實現(xiàn)的。
6. log 日志系統(tǒng)
由于開發(fā)者沒有服務器權(quán)限，無法看到服務的出錯日志。為了解決這個問題，我將所有的錯誤日志使用 rsyslog 來管理，同時提供了基于 web 的查看系統(tǒng)。這樣一來，開發(fā)者們完全不必和服務器打交道了。
我在這篇文章中作了描述：rsyslog/Python/LogAnalyzer 記錄和查看日志 。
我基于 OpenResty 提供的 resty.logger.socket 實現(xiàn)了從服務端的 lua 代碼中將 log 提交到 rsyslog，這樣開發(fā)者調(diào)試代碼也可以使用這種方式。
詳情見這兩個實現(xiàn)：
（全文完）