强制使用https这件事情，其实在整个互联网已经很久了。

本博之前也有短暂的启用过，但是后来由于各种原因终止了。

另一方面，我发现继续使用http好像也没有什么影响，所以也就没有什么动力去继续支持https。

直到最近发生了几件事情：

1. iPhone15上的joplin不再支持http接口的webdav同步，即使直接使用ip地址也不行。
2. 搜索引擎似乎不再收录http的网站，尤其是百度，已经找不到本博的内容了。
3. 之前另一个域名的付费https证书即将过期，但是续费的价格涨了不少（通配符域名一年200元左右）。

于是，我总算打算认真研究一下https证书的问题，究竟有没有免费的方案呢？

因为我总觉得，https作为互联网的基础功能，如果只有收费方案，与互联网最原始的开放、分享精神不符。

而借助于ChatGPT，我发现解决方案出奇的简单，提示词如下：

通过 Let's Encrypt 生成免费证书，给一下具体的解决方案和实施步骤。
要求如下：
1. 域名 vimer.cn 
2. 要求支持通配符 
3. 要求自动续期 
4. 操作系统是centos 7 
5. webserver是nginx 
6. 云平台是阿里云 
7. 尽量使用pip来安装相关库，因为我装了python

当然，提示词是经过我多番与AI的交互后优化的结果。

具体的解决方案就不贴出来了 ...

发现想抽时间写博客实在是太难了，不过我觉得今天这一篇还是很值得写一下的。

熟悉我的同学应该都知道，我之前做了一款《矩阵危机》的产品，使用的是帧同步的技术。

简单画一下V1架构图：

• Gateway

  网关服务器。

  负责客户端连接的接入，使用协议TCP。

  使用C++编写。

• KcpProxy

  Kcp协议的代理服务器。

  客户端默认使用Kcp连接服务器，如果失败会自动回退到Tcp。

  使用C++编写。

• RoomServer

  房间服务器。运行战斗逻辑，每个房间同时仅能运行一场战斗，帧率为15帧/秒。

  房间服务器与Gateway间通过Tcp连接，每个房间建立一个一条独立的连接。

  使用Python编写。

整个架构还是比较清晰的，但是里面有个极大的问题：性能

因为python的性能实在是太差了，对于RoomServer每秒15帧这种cpu密集型的业务场景完全不适合。

至于python的性能有多差，我当时做过一个简单的测试，同样的业务代码，c++是python性能的10倍左右。

可能直接说这个数字大家也没什么感觉，但是要知道换算成服务器的话，那就是10倍的服务器量，10倍的成本。

所以这也是要做架构升级的原因。

而升级的方案也有多种，其中一个方案如下：

其核心逻辑是将CPU密集的RoomServer放到Gateway中去，而额外多出来一组RoomController负责对Gateway和Room进行控制。

RoomController可以继续使用python实现。

这样的方案虽然解决了性能问题，但是却导致gateway的功能过于耦合，不是好的设计方案。

还有一个方案就是将RoomServer直接使用C++重写，每个Room开一个线程 ...

游戏内小红点算是一个极其常用的功能了，之前在德州里面也有过实现。
然而之前的实现实在是乱七八糟，所以这次也是将其做了彻底的重写，并把方案跟大家分享一下。

我们将游戏内小红点可以分为三类：

1. 服务器小红点-服务器自动清除

   比如，我们常见的每日任务，成长任务，活动等。
   以每日任务举例：
   当有任务奖励可以领取时，在每日任务按钮上就显示小红点。
   当任务奖励全部领取完毕后，小红点消失。

2. 服务器小红点-客户端告知服务器清除

   比如，信箱功能，新好友通知，好友申请通知。
   以信箱举例：
   有新邮件，则信箱按钮就显示小红点。
   打开信箱后，如果信箱内分标签页，则判断标签页下的邮件列表，如果有新邮件，则在标签上显示小红点。
   当标签页打开之后，标签页上小红点消失。 当所有标签页的小红点都消失后，信箱按钮上的小红点消失

3. 客户端小红点-客户端自己维护

   比如聊天功能。

   登录时，拉取所有未读消息，如果有消息的话，大厅聊天按钮需要显示小红点。
   之后，当收到新的好友消息的时候，大厅聊天按钮需要显示小红点。
   当点击聊天按钮进入具体的聊天页面时，每个有新消息的好友页签，需要显示小红点。
   当点击该页签时，小红点消失。
   当所有页签的小红点消失后，大厅聊天按钮的小红点消失。

接下里我们说一下具体的实现。

首先，所有服务器小红点的状态，在用户登录的时候，就应该返回。
所以我们在登录协议里面增加了一个red_points字段 ...

其实第一次创业在技术上还是有不少历史问题的，所以在第二次创业就趁机做了很多弥补，下面详细说一下。

一.运行环境升级

直接列在这里

centos 6.5 x64  -> centos 7.5 x64
mysql 5.5       -> mysql 5.7
redis 2         -> redis 4
python 2.7      -> python 3.7
django 1.6      -> django 2.1
protobuf 2      -> protobuf 3

老版本有很多的问题，比如mysql5.5的性能问题，redis的dump性能问题，python2的中文处理问题，django1.x系列无法自动migrate，protobuf 2的default混乱问题 ...

一. 前言

2016年6月17日凌晨5点钟，我们完成了服务器端V3版本的重构，切换的过程十分平滑且没有对线上用户产生任何影响。

这也正式标志着，我们的游戏服务器进入了一个全新的阶段。

我们上一次的重构是在 2014年12月23日，现在看看，时间过的真快啊。

而熟悉我的人应该知道，我特意为上一次重构写过一篇《游戏服务器端架构升级之路》，其中详细的讲述了我们游戏服务器从农业时代跨越到工业时代的历程。

而这次V3版本的重构，我将其定义为第二次工业革命。也许它没有那么的强大和完美，但是他切实的解决了现存的大部分问题。

二. 背景

之前的文章已经说过，V2版本的服务器的几个优点：

1. 支持服务器代码热更新而不影响外网服务
2. 架构模式足够简单：push-pull

但是，其简单的架构也存在一些缺点：

1. 业务模块之间容易互相影响

   比如两个游戏玩法 A 和 B，内部使用的逻辑、存储服务器都完全不同，但是在worker层却是共用的。

   所以一旦玩法A的服务器出现问题导致处理变慢，那么worker就会被堵住，而玩法B也会跟着遭殃。

   同时，即时在一个业务模块内，也存在请求处理优先级的问题，比如拉取牌局记录和跟注，要尽量避免跟注这种核心逻辑受到影响。

2. 限制了游戏逻辑的实现方式

   V2的多worker的模式，导致worker必须限制为无状态的，因为worker可能处理任何一个请求，而一个请求也可能被分配到任何一个worker上。

   这一点是之前解决服务器热重启的关键，但同时也限制了我们代码逻辑多样性的实现。

   比如我们的游戏桌子数据是存储在redis中，所有人对桌子的写操作可能同时分配到多个worker上，而为了避免写冲突，我们不得不通过redis来实现分布式锁 ...

之前在文章里面有提到过，很多事情，并没有绝对的对错，只是度的问题。而度的衡量又取决于时、势二字。所以当形势逼人的时候，基本就是这件事情非做不可的时候了。

先说下背景，公司的服务器一直用的阿里云，包括mysql、redis也都是买了ECS自己搭建的。这里面有几个原因:

1. 创业的时候，阿里云只提供mysql的存储，redis的存储还没提供。
2. 没钱，即时现在去看redis的存储价格也是贵的吓人。

这样自己来搞存储有好处也有坏处。 好处：

1. 完全可控，比如连接数限制，内存限制，存储限制。还有数据备份的灵活性等等。
2. 强迫团队服务器研发要有存储运维能力。
3. 省钱

坏处：

1. 冷备、热备方案不完善。
2. 存储运维的成本较高，需要长时间积累。

ok，问题就是这样，接下来再来说一下我们之前的冷备和热备方案。 可以说极其简陋：

1. mysql、redis每天10点冷备，备份到本地磁盘和阿里云OSS
2. redis使用rdb落地，每60秒至少有1次写就会触发落地。

这样做的问题其实挺多的，主要几个:

1. mysql dump的时候会导致游戏卡顿，即使加了 --single-transaction 参数 也仅仅是缓解
2. 冷备频率过低，真出现问题数据已经太久
3. 没有热备，风险较大

针对这些问题，我们先做了mysql备份的优化 ...

其实打算做游戏内热更新也是几个月之前的事情了，在方案经历了数次变迁之后，最近才终于应用到了外网的bugfix中。
但是就目前数据来看，热更新由于要下载资源，会使新用户的进入门槛变高，所以留存收到了一定影响，基本降低了10个点。
当然，也可能是热更新的功能存在bug。

好了，我们还是进入正题吧!

方案一

最早的时候，我们想用一种类似打patch的方式来更新。
即将lua代码和资源打成一个zip包，而每个zip包只要代码或者资源发生变化，都会有一个自增的小版本号（大版本号为打在apk或者ipa里的版本号）。
不同的zip包之间diff就可以生成一个patch文件，而为了开发的简单，这个patch列表只会将文件路径列出来，之后客户端要去完整的下载新的文件覆盖。

然而这个方案有很多的问题。

1. 小版本号不好维护 因为代码和资源会不停的修改，而如果人工来维护小版本号，会极其复杂。如果通过机器来维护也是个很麻烦的工程

2. patch包太多 如果我们将小版本号的patch包先生成好放到服务器上，那么如果我们有100个小版本，就会有非常多 1->100, 2->100, 3->100 ... 这种格式的patch包。 并且如果小版本号继续增长，patch包的增长基本会失控。

3. 消耗大量流量，速度缓慢 也许有同学会说，不如只有 1->2, 2->3, 3->4 这样的单个小版本之间的升级patch，客户端自己挨个下载就好。

   但是这样客户端如果是个很小的版本号，就不会不停的重复下载，导致迟迟进入不了游戏，并且流量也大量消耗。

综上所述，方案一有太多的弊端。
这也是为什么我们做完了之后迟迟不敢上线的原因 ...

最近在grahite上看到响应时间变得很长，虽说之前没有特意去优化性能，但是感觉也不应该这么差才对。

我们的服务器框架用的就是我之前开源的 maple，每个命令字都对应一个入口函数，如下：

@app.route(2)
def login(request):
    logger.error("login: %s", request.gw_box)
    uid = request.box.get_json()["uid"]
    request.login_client(uid)
    time.sleep(1)
    request.write_to_client(dict(
        ret=0,
        body="login %s" % uid
    ))

所以只要找到一种方法分析这个函数对应的内部调用情况就可以了。

很方便的，python内置了cProfile类来完成我们想要的功能，我给封装成为一个装饰器，用起来更方便一些，当然在django和flask中也可以直接用。

def monitor_profile(func):
    import cProfile
    import functools
    @functools.wraps(func ...

这几天的心情非常好，主要原因是我们把服务器端的架构升级到了 2.0，这样最大的一个好处就是：

Server重启完全不会影响外网服务

所以，也是想趁此机会，服务器端整个发展的历程，跟大家分享一下，干货比较多，框架代码也会全部开源：）

一. 农业时代

创业最重要的就是一个“快”字，所以最开始的时候，所有的架构都以快速出模型为前提。

而常看我博客的朋友应该知道我对python情有独钟，所以自然的，python成为了我开发服务端框架的语言。

python自带的多线程tcp服务器框架非常简单：ThreadingTCPServer，即每个链接一个线程的模式：

import SocketServer

class RequestHandler(SocketServer.BaseRequestHandler):
    def handle(self):
        f = self.request.makefile('r')

        while True:
            message = f.readline()
            if not message:
                print 'client closed'
                break
            print "message, len: %s, content ...

发现自己经常会一篇文章写了（一）之后，很久都不写（二），搞得最后自己都快要忘记了，所以这次赶紧把统一支付的文章给补上。

上次的文章中将统一支付的v1版本已经讲解ok了，但是还剩下两个问题：

• 服务器端没有办法做分布式
• 客户端对支付sdk进行插件式管理十分困难

我们一个个来说

一. 解决服务器端分布式的问题

解决这个问题的核心思路比较简单：

之前我们是把event的通知放在进程内存中，现在我们做成网络通信

由于支付的请求量本身不属于高并发，所以就放弃了打算直接写通知server的想法，转而看一下有没有什么简单的解决方案。

而由于自己之前redis的使用经历，恰好知道redis有一个pubsub模式，很适合做这种监听和通知的工作。

python的实现示例代码如下：

import time
import config
from share.vals import rds
from share.utils import safe_str
from gevent.timeout import Timeout
from urllib import quote, unquote

class RedisPubSub(object):
    """
    用redis订阅/发布消息
    """
    # 订阅频道
    sub_key ...