56, 2023-04-16周总结
- FileStorage存储方式修改
- GameManageCenter和AccountCenter部署
- 国内业务服务器请求流量突然增加
- 转小程序的一些问题
- 新项目框架搭建
- 线上问题
FileStorage存储方式修改
FileStorage是之前做的一个简易存储服务，客户端通过请求将存档发送到服务器存储，同时也可以通过请求将存档拉取到本地。
之前也因为存档频率的不合理，导致这个服务把机器打爆了，这个之前的总结里面提到过。
因为当时做的比较简单，存档只支持了文件存储，但随着用户量的增加，磁盘不断的被占满，成本随着也不断的上升。所以后续考虑使用云服务提供的对象存储来落地存储文件，以减少成本。
改的第一步就是要把磁盘上的文件上传到对象，结果发现上传的文件数量达到了千万级别。根据累计用户算了下文件量不应该那么大，哪里出问题了。把怀疑的方向提供给同事，结果发现《巨星崛起》的教练模式存档有问题，一个教练可以产生几千个存档文件，而且大部分文件后面都没有用，导致产生了很多无用文件。怪不得磁盘使用量升的那么快。
另外一个发现上传过程中每天不断再收费，看了下资源包都是够的，查了下收费文档，发现调用上传api也要计费，0.01元/万次，我们几千万个文件，也要些钱了。
GameManageCenter和AccountCenter部署
上周改了Web框架，这周把这两个基于新框架重写了下，同时在内网部署，3D项目服务端暂时没时间接入，改到下周接。
国内业务服务器请求流量突然增加
国内某台机器入流量突然增加很多，导致触发报警了，但只能分析出来流量到了nginx这边，不知道是哪个请求导致的。挨个看了下access log，感觉流量都不大，不知道什么原因导致的。
意识到了按请求做监控的重要性，这块之前没做好。后续利用云服务提供的一些功能慢慢把这一块搭建起来。例如后续的http业务都走腾讯云的api网关，利用api网关上面的监控和报警来监控流量和rt情况。
转小程序的一些问题
小程序目前在转换中，目前遇到比较大的问题是同步改成异步导致的bug。因为小程序的特殊性，所以资源尽量都已异步的方式加载，另一方面的原因是有些资源管理器同步加载在小程序上会有问题，比如我们用的YooAsset在小程序上是用不了同步加载的，表现感觉像死锁了。
因为之前代码都是以同步为前提的，改成异步会有很多莫名的bug出现需要一一解决。所以如果游戏要考虑转小程序，那就要预先规范好资源加载方式，比如现在3D项目就明确规定资源加载只能用异步。
新项目框架搭建
准备启动新项目，正好客户端框架搭建差不多了，用新框架搭建了这个新项目，同时做了一些前期结构上的搭建，包括启动，强更，热更，加载流程等。搭建过程中也发现底层框架的一些问题，一起跟着迭代改进。
另外也在内部利用verdacci搭建了一个npm server，这样客户端框架的发布和应用就可以走Unity的Package Manager了。
比较麻烦的一点是我们同时有项目用了Unity2020和Unity2021，其他库都还好，就是Newtonsoft.Json2020用的是2.0.x版本（对应的是12.x版本的Newtonsoft.Json），2021用的是3.0.x（对应的是13.x版本的Newtonsoft.Json）。
所以要维护两个分支分别去维护2020和2021版本的框架。
线上问题
周末晚上又出现线上问题，用户登录不上，上机器看了下，所有的asp.net进程全部挂掉，同时守护进程supervisor也挂了（这个挂了就很奇怪了）。
一时没找到原因，就重新启动了supervisor，结果asp.net拉不起来，报Failed to create CoreCLR, HRESULT: 0x80004005，又奇怪dotnet环境一开始就搭建好的，为啥突然出现这个，感觉整个机器都在出现奇怪的问题。
查了下这个报错，最后通过加环境变量：COMPlus_EnableDiagnostics=0解决这个报错，后面一起都顺利启动了，游戏也能正常进了，但还是疑惑为啥出现这个问题。
第二天再处理其他事情的时候，发现创建不了文件了，报磁盘满了，但是df发现磁盘使用率只有82%，唯一可能的原因就是我们的磁盘存储的文件量太碎（因为FileStorage存储的千万级别的小文件）导致统计不准了。周末出现问题的原因应该也是这个导致。