由於最近在計劃工作的變動，想要好好規劃自己的未來，在這段時間內自己會休息一段時間。就在工作交接的空檔，對自己維護的專案以及近年來對工作做一些整理總結，發現了自己的框架在設計中對看門狗有兩種不同的方式，因此把它分享出來，希望對接觸它的人有所幫助，當然其中不乏紕漏，希望大家指正！記憶之中似乎以前也稍微寫過類似的文章，不過沒有這次總結來的完善。（這兩天狗狗幣很瘋狂，手動狗頭）
看門狗
顧名思義，它就和字面意思一樣是用來看家護院的，保護某個東西不被侵犯。在遊戲伺服器設計中，它就是用來保護遊戲伺服器不受到攻擊。還記得曾經玩過一個“看門狗”的遊戲，對此有過形象的解釋，如果狗狗被帶壞，那麼我們所要保護的東西就很危險了。
最近接近無業之時，整理自己過去工作和專案用到的設計，利用plain framework和skynet兩種框架分別實現兩種不同的效果，其各有優劣，因此在這篇文章中做相應的總結分析。
plain-simple在以下簡稱PF，skynet-simple簡稱SS
plain-simple
簡介
目前有三個示例的應用：看門狗、邏輯伺服器、客戶端，主要的邏輯放在LUA指令碼處理。這個示例並沒有完整的給出遊戲伺服器的具體邏輯，比如玩家模組、地圖模組等等。
其看門狗的實現方式大致圖如下：
１、PF中利用了路由和轉發的方式來實現看門狗，即只有當看門狗認證成功後資料才能由客戶端轉發到相應的伺服器
部分實現的程式碼
在伺服器（logic server）可以使用以下程式碼進行路由請求：
pf_net::packet::RoutingRequest routing_request;
routing_request.set_destination(destination); // 請求路由的目標服務
routing_request.set_aim_name(aim_name); // 請求路由的連線名
routing_request.set_aim_id(aim_id); // 請求路由的連線ID
result = connection->send(&routing_request);
在伺服器（logic server）使用連線的路由介面傳輸資料到客戶端（framework/core/src/connection/basic.cc）：
bool Basic::routing(const std::string &_name, packet::Interface *packet, const std::string &service) { if (routing_list_[_name] != 1 || is_null(packet)) return false; packet::Routing routing_packet; routing_packet.set_destination(service); // 需要路由的目標服務 routing_packet.set_aim_name(_name); // 需要路由的目標連線名 routing_packet.set_packet_size(packet->size()); // 路由的網路包大小 return send(&routing_packet) && send(packet); }
在看門狗（gateway）收到客戶端發上來的資訊呼叫連線的轉發介面（framework/core/src/connection/basic.cc）：
bool Basic::forward(packet::Interface *packet) { if (is_null(packet)) return false; std::string aim_name = params_["routing"].data; if (aim_name == "") return false; std::string service = params_["routing_service"].data; if (service == "") service = "default"; auto listener = ENGINE_POINTER->get_listener(service); if (is_null(listener)) return false; auto connection = listener->get(aim_name); if (is_null(connection) || connection->is_disconnect()) return false; packet::Forward forward_packet; forward_packet.set_original(name()); forward_packet.set_packet_size(packet->size()); return connection->send(&forward_packet) && connection->send(packet); }
2、怎樣實現多客戶端進入多伺服器進行操作（跨服）？直接利用看門狗進行轉發，還是透過客戶端所在主邏輯伺服器再進行分發處理？
3、丟失連線時的處理：PF中如果路由中的連線一旦發生丟失，這隻狗會“汪汪”兩聲，而這兩聲分別表現在看門口對自己的提醒和對另一方的提醒。比如客戶端這時正通過看門狗路由到伺服器上，客戶端這時突然消失離開，這時候看門狗能看警覺地對自己叫了一聲（如果開啟指令碼服務，則會呼叫指令碼的連結丟失函式），同時對著伺服器叫了一聲（如果開啟了指令碼，則呼叫丟失函式）。但有個地方不同的是：客戶端消失的時候，看門狗和伺服器的連線仍然存在，只是清除了相應的路由資訊；假如是伺服器突然消失，狗也同樣對自己和客叫兩聲，但這時候看門狗由於失去的路由便判定路由失敗直接斷開自己和客戶端的連線（客戶端以後可以優化，比如在丟失連線三十秒內看門狗連線伺服器）。
部分實現程式碼如下（路徑在PF專案的framework/core/src/connection/basic.cc）：
連線斷線時處理（客戶端離開了狗狗，狗狗叫了兩聲）：
void Basic::disconnect() { using namespace pf_basic::type; //Notice routing original. std::string aim_name = params_["routing"].data; if (aim_name != "") { std::string service = params_["routing_service"].data; manager::Listener *listener = ENGINE_POINTER->get_service(service); if (is_null(listener)) return; auto connection = listener->get(aim_name); if (!is_null(connection) && name_ != "") { packet::RoutingLost packet; packet.set_aim_name(name_); connection->send(&packet); // 通知伺服器 } } auto script = ENGINE_POINTER->get_script(); if (!is_null(script) && GLOBALS["default.script.netlost"] != "") { auto func = GLOBALS["default.script.netlost"].data; variable_array_t params; params.emplace_back(this->name()); params.emplace_back(this->get_id()); variable_array_t results; // 提醒自己 script->call(func, params, results); } clear(); }
心跳中定時監測路由的處理（這隻狗狗四處張望，看看是不是伺服器突然人間蒸發）：
bool Basic::heartbeat(uint32_t, uint32_t) { using namespace pf_basic; auto now = TIME_MANAGER_POINTER->get_ctime(); if (is_disconnect()) return false; if (safe_encrypt_time_ != 0 && !is_safe_encrypt()) { now = TIME_MANAGER_POINTER->get_ctime(); if (safe_encrypt_time_ + NET_ENCRYPT_CONNECTION_TIMEOUT < now) { io_cwarn("[%s] Connection with safe encrypt timeout!", NET_MODULENAME); return false; } } // Routing check also can put it in input. std::string aim_name = params_["routing"].data; if (aim_name != "") { auto last_check = params_["routing_check"].get<uint32_t>(); if (now - last_check >= 3) { std::string service = params_["routing_service"].data; manager::Listener *listener = ENGINE_POINTER->get_service(service); if (is_null(listener)) return false; auto connection = listener->get(aim_name); if (is_null(connection) || connection->is_disconnect()) { io_cwarn("[%s] routing(%s|%s) lost!", NET_MODULENAME, service.c_str(), aim_name.c_str()); return false; } params_["routing_check"] = now; } } return true; }
下面由兩張圖來體現，看門狗在丟失伺服器和客戶端時的不同做派。
1）客戶端丟失
2）伺服器丟失
4、PF模式的好處：可以隱藏所有伺服器，客戶端無法直接連線到伺服器上，使得有人想要惡意攻擊伺服器變得困難。看門狗在一定程度上可以過濾很多垃圾資料，如遭受攻擊的防禦策略可以放在看門狗身上。守門上看門狗作用不差，就算是被人打趴下也不會讓自己保護的東西受到直接攻擊，除非攻擊者讓看門狗瘋掉反過來破壞。（就算同一個IP上同時放伺服器和看門狗，伺服器的埠仍舊可以不用暴露，攻擊者自然也無法直接攻擊）
5、PF模式的劣勢：由於看門狗和伺服器之間只有一條連線，在客戶端數量很大的情況下，也許會造成訊息堵塞。這要看看門狗和伺服器之間的管道有多大，一般情況下是比較足夠的，當然這裡可以優化，比如增加看門狗到伺服器之間的管道數量（增加手下傳輸狗狗的數量，只要人手夠多就不相信忙不過來）。
skynet-simple
簡介
最近兩年的專案中都是使用skynet作為開發，源於雲風前輩的多年經驗和無私奉獻，相信很多做遊戲的對這個框架並不模式，其服務模式的優點在這裡就不仔細探討了。由於大部分邏輯在LUA層，因此開發很容易上手。
在這個示例中，匯聚了經手的幾個上線專案的一些核心實現（小型測試客戶端、登入伺服器、遊戲世界服），幾乎不用怎麼修改就能夠直接用於正式開發（用於商業風險自負，除非你自己經過很多測試，再次狗頭！）
它的配置由lumen-api和vue-admin共同實現，我這裡不描述這兩個工具（相當於平臺前後端），其配置檔案為json格式。
實現結構圖如下：
1、SS模式中的看門狗（這裡就是登陸伺服器）：就真的只起到看門的作用，客戶端需要先讓看門狗進行驗證，然後直接連線到伺服器上。伺服器收到客戶端連線請求，拿著客戶端認證的看門狗ID，讓對應的看門狗進行辨認，如果確認無誤則客戶端和伺服器可以正常連線（也可以視為可以進入伺服器，如遊戲裡就表現為可以進入遊戲世界）。但看門狗認證的憑證是有時效的，就像現在許多驗證碼一樣（1秒鐘足夠麼，手動狗頭！）。
如下程式碼中，SS模式就定時檢測時效的憑證並進行清除（service/login/auth_mgr.lua）：
local function clear_timeout() local now = skynet.now() local clears = {} for k, v in pairs(tokens) do if v.time + 30000 < now then -- 5min clear table.insert(clears, k) end end local _ = next(clears) and log:dump(clears, 'clear_timeout') for _, key in ipairs(clears) do tokens[key] = nil end end
2、SS模式得利於設計中的叢集模式（cluster），這種模式可以靈活的讓自己成為一個節點進行服務。
下面看看SS中節點的配置：
{ "login_1": "xx.101.1xx.1xx:10001" }
3、SS模式丟失連線：skynet中連線丟失可以自身做一些封裝處理，自身框架中並沒有統一的處理，它似乎並沒有像PF模式那樣汪汪兩聲。
下圖為plain-simple三個部分測試：登入伺服器（看門狗）、遊戲伺服器、機器人（迷你客戶端）
4、SS模式的優勢：連線比較清晰，我就是要直連！
直連處理時，客戶端清楚自己連線的是誰，伺服器也同時也知道誰連到了自己，並且這些連線都可以直接進行處理（可以直接明白的斷開各自的連線，資料也是沒被轉發的，因此不會有轉發導致資料丟失的風險）。
客戶端->（認證）看門狗
客戶端->（拿認證）伺服器
客戶端登入到登入伺服器（看門狗）程式碼（lualib/robot/init.lua）：
-- Auto signup and signin(connect login server). function login_account(self) skynet.sleep(100) local cfg = setting.get('login') local host = cfg.ip local port = cfg.port local account = self.account local uid = account.uid local fd = socket.open(host, port) log:debug('login account: %s %d', host, port) if not fd then return self:login_account() -- loop end log:info('login_account open fd[%d]', fd) self.fd = fd -- Dispatch. skynet.fork(function() local _ <close> = self:ref_guard() local ok, err = xpcall(client.dispatch, trace.traceback, self) if not ok then log:warn(err) end end) -- Try signin. local r = self:signin() if not r then if not self:signup() then socket.close(fd) return self:login_account() end -- Try signin again. if not self:signin() then socket.close(fd) return self:login_account() end end socket.close(fd) self.logined = true return true end
客戶端登入到遊戲伺服器（看門狗）程式碼（lualib/robot/init.lua）：
-- Auth game and enter(connect game server). -- @return bool function login_game(self) skynet.sleep(100) local pid = self.pid local sid = self.sid local cfg = setting.get('world') local game_host = cfg.ip local game_port = cfg.port local fd = socket.open(game_host, game_port) if not fd then return false end log:info('login game open fd: %d', fd) self.fd = fd skynet.fork(function() local _ <close> = self:ref_guard() local ok, err = pcall(client.dispatch, self) if not ok then log:warn('login game dispatch error %s', err or -1) end end) local r = self:auth_game() -- 驗證 if not r then return self:login_game() -- 進入遊戲世界 end return r end
5、SS模式的劣勢：暴露了伺服器，容易造成直接的攻擊（當然你的伺服器要有價值，否則攻擊者不會花費精力來做這個事）。當前可以利用其它方式來彌補這個劣勢，則伺服器端自身需要有防禦策略（家裡得放只看家狗）。
思考
伺服器叢集的模式在erlang中便利、容錯、效能等方面的優勢，使得國內伺服器開發還是有不少使用這個語言。skynet的模式差不多也是參考了 erlang的模式，使得我們可以比較容易使用高效能併發程式設計。在PF的設計中，我也曾經考慮過使用該模式來進行設計，對於解決跨服的資料交換問題可以提供一個不錯的方案。
1、賬號驗證該放在何處？
一般來說直接將賬號的驗證放在看門狗處，客戶端可以根據不同SDK到平臺驗證。客戶端傳送到看門狗這邊的引數一致，畢竟賬號驗證一般都只需要token以及賬號就行，看門狗可以連線到自己的平臺（或者別的平臺提供的統一GET/POST介面進行驗證）。當看門狗驗證成功後，進行到邏輯服的處理。
2、跨服（組）應該如何實現？
叢集的方式使用起來比較方便，在skynet中可以使用叢集伺服器（cluster.send/call）介面輕鬆跨節點。
那麼PF中的跨服，應當如何實現？
現階段可以使用PF框架中的路由來實現跨服處理，跨服的核心也就是資料的轉發。但這裡存在一個問題，當玩家從自己的伺服器進入一個公共跨服伺服器時，這裡的資料應當如何轉發？由於這裡有看門狗，如果玩家的路由始終不變，也就是看門狗並沒有連線跨服的情況下，那麼資料流的形式會是下圖中的（1、2、3），如果跨服直連看門狗的話資料流的形式就是下圖的（1、4）：
我們可以看到如果看門狗是PF這種設計的話，在跨服的時候未免就會多進行一次轉發，這次轉發帶來的不確定性也是PF看門狗模式的劣勢之一。因此我想到了（1、4）這種模式，那麼跨服也要連線到遊戲服所處的看門狗，遊戲服和跨服都要經過看門狗處理，但這樣感覺上讓遊戲服和跨服做了一次無意義的操作，畢竟它們都在門內，何必使用這個狗再傳遞？（感覺陷入了某個怪圈是不是，狗頭保命）
個人覺得跨服不要直連看門狗要好點，雖然多了一步的轉發操作，但內部轉發應該能反應過來，這樣跨服和遊戲服就不用隔著一道牆來交換資料，這樣資料的交換比較便利。
如果想到更好的解決辦法，我將在這篇文章中更新。