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

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 的：

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

（全文完）

本文鏈接：http://zengrong.net/post/2228.htm