十万同时在线用户,需要多少内存?——Newbe.Claptrap框架水平扩展实验
Newbe.Claptrap 项目是笔者正在构建以反应式
、Actor模式
和事件溯源
为理论基础的一套服务端开发框架。本篇我们将来了解一下框架在水平扩展方面的能力。
前情提要
时隔许久,今日我们再次见面。首先介绍一下过往的项目情况:
'第一次接触本框架的读者,可以先点击此处阅读本框架相关的基础理论和工作原理。'
今日主题
今天,我们来做一套实验预演,来验证 Newbe.Claptrap 框架,如何通过水平扩展的形式来适应逐渐增长的同时在线用户数。
由于此次实验涉及的内容很多,因此笔者将内容进行了归类,读者可以按照自己的兴趣阅读相关的章节:
业务需求说明
先看看今天要实现的业务场景:
- 用户通过 API 登录后生成一个 JWT token
- 用户调用 API 时验证 JWT token 的有效性
- 没有使用常规的 JWS 公私钥方式进行 JWT token 颁发,而是为每个用户单独使用 secret 进行哈希验证
- 验证看不同的在线用户需要消耗的内存情况
- 用户登录到生成 token 所消耗时间不得超过 200 ms
- tokn 的验证耗时不得超过 10 ms
吹牛先打草稿
笔者没有搜索到于“在线用户数”直接相关的理论定义,因此,为了避免各位的理解存在差异。笔者先按照自己的理解来点明:在线用户数到底意味着什么样的技术要求?
未在线用户若上线,不应该受到已在线用户数的影响
如果一个用户登录上线需要消耗 100 ms。那么不论当前在线的用户数是十人还是百万人。这个登录上线所消耗的时间都不会明显的超过 100 ms。
当然,有限的物理硬件肯定会使得,当在线用户数超过一个阈值(例如两百万)时,新用户登录上线会变慢甚至出错。
但是,增加物理机器就能提高这个阈值,我们就可以认为水平扩展设计是成功的。
对于任意一个已在线用户,得到的系统性能反馈应当相同
例如已在线的用户查询自己的订单详情,需要消耗 100 ms。那么当前任何一个用户进行订单查询的平均消耗都应该稳定在 100 ms。
当然,这里需要排除类似于“抢购”这种高集中性能问题。此处主要还是讨论日常稳定的容量增加。(我们以后会另外讨论“抢购”这种问题)
具体一点可以这样理解。假设我们做的是一个云笔记产品。
那么,如果增加物理机器就能增加同时使用云笔记产品的用户数,而且不牺牲任何一个用户的性能体验,我们就认为水平扩展设计是成功的。
在此次的实验中,若用户已经登录,则验证 JWT 有效性的时长大约为 0.5 ms。
调用时序关系
简要说明:
- 客户端发起登录请求将会逐层传达到 UserGrain 中
- UserGrain 将会在内部激活一个 Claptrap 来进行维持 UserGrain 中的状态数据。包括用户名、密码和用于 JWT 签名的 Secret。
- 随后的生成 JWT 生成和验证都将直接使用 UserGrain 中的数据。由于 UserGrain 中的数据是在一段时间内是“缓存”在内存中的。所以之后的 JWT 生成和验证将非常快速。实测约为 0.5 ms。
物理结构设计
如上图所示,便是此次进行测试的物理组件:
名称 | 说明 |
---|---|
WebAPI | 公开给外部调用 WebAPI 接口。提供登录和验证 token 的接口。 |
Orleans Cluster | 托管 Grain 的核心进程. |
Orleans Gateway | 于 Orleans Cluster 基本相同,但是 WebAPI 只能与 Gateway 进行通信 |
Orleans Dashboard | 于 Orleans Gateway 基本相同,但增加了 Dashboard 的展示,以查看整个 Orleans 集群的情况 |
Consul | 用于 Orleans 集群的集群发现和维护 |
Claptrap DB | 用于保存 Newbe.Claptrap 框架的事件和状态数据 |
Influx DB & Grafana | 用于监控 Newbe.Claptrap 相关的性能指标数据 |
此次实验的 Orleans 集群节点的数量实际上是 Cluster + Gateway + Dashboard 的总数。以上的划分实际上是由于功能设定的不同而进行的区分。
此次测试“水平扩展”特性的物理节点主要是 Orleans Cluster 和 Orleans Gateway 两个部分。将会分别测试以下这些情况的内存使用情况。
Orleans Dashboard | Orleans Gateway | Orleans Cluster |
---|---|---|
1 | 0 | 0 |
1 | 1 | 1 |
1 | 3 | 5 |
此次实验采用的是 Windows Docker Desktop 结合 WSL 2 进行的部署测试。
以上的物理结构实际上是按照最为此次实验最为复杂的情况设计的。实际上,如果业务场景足够简单,该物理结构可以进行裁剪。详细可以查看下文“常见问题解答”中的说明。