首先我们项目的定位是一个图片,音频为主体的分享应用,于是服务器对于大资源的存储有了常规数据库,nginx静态资源存储和对象存储服务的选型问题.常规数据库(如mysql)的业务存储不可避免的遇到服务器带宽问题和单点问题.于是我们选择了COS服务进行大对象存储,同时对于生成目录等用户关键信息进行云Redis存储并选择双机备份.项目开发,压测结束Redis只占用了2M内存空间,COS服务+CDN溯源提供了优秀的读写带宽和数据保持.
其次一开始我们两位后台开发同学对于架构的选型的第一目的其实是以”复杂装逼”为先,但是实际搭建过程中发现需要意识到每个组件选型的原因,因为每个组件的选型对于访问压力和安全都有可能有灾难性的错误,在具体架构图的体现上可能是”一粒老鼠屎”.因此我们转而明确我们需要什么样的服务器.阅读往年KM经验总结得到互联网服务器的核心在于可用容灾,简单点说要先解决每个服务的单点问题.举个项目过程中的接口例子:
我们COS的上传服务是客户端先向服务器请求一个临时Token而后利用这个临时Token存储,读取资源.由于COS不能设计给CVM的回调函数,于是基本设计是通过两条请求分离1. 取token和路径, 2. 校验,存Redis数据库当中.在这个流程中一开始我们的单机设计是在本地对于key做一个缓存,然后再确认请求中读取缓存;通过超时删除策略清理缓存池.这样的策略当接入多机时候需要cookie/session保持对单机的服务连接,接入弹性伸缩时候就完全不可用了.因此重构代码,将缓存信息存储到Redis里面,而后读取其中信息.这样配置了服务的开机自启之后就可以有效的进行弹性伸缩的业务可用性保证.总而言之服务器应该作为无状态服务,对于每个请求原子化操作.
进一步服务的解耦是在这次mini项目中理解的部分.对于python的sdk/api/算法实现,我们服务端最初解决的策略有二:
相对应的,遇到了以下问题:
于是我们分离核心模块与算法模块到内部服务器,类似外网负载均衡业务,接入内网负载均衡服务,内网弹性伸缩组通过内网ip调用算法弹性伸缩组,这样golang的代码看起来优雅(没有wrap和hack)许多,也进一步保证了安全性.另外可以对于不同服务设计不同弹性伸缩策略(业务服务设计CPU监控,图像算法服务设计内存监控)来进行伸缩组操作.
另外值得一提有三点:
扫码关注腾讯云开发者
领取腾讯云代金券
Copyright © 2013 - 2025 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号:粤B2-20090059 深公网安备号 44030502008569
腾讯云计算(北京)有限责任公司 京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287
Copyright © 2013 - 2025 Tencent Cloud.
All Rights Reserved. 腾讯云 版权所有