接通知,某牛逼业务(后面简称nb)要做后台架构的分享,果断参加。
一是,就冲nb的名头,怎能放过;
二则,我负责的业务算是同类产品,类似于mini nb,想必有很多可借鉴的经验。
架构和接入
经典的三层架构:接入、逻辑、存储。
多种接入set负责适配不同接入模式,后端使用统一的逻辑层、存储层。
就近接入(GSLB+CDN)+可调度:通过GSLB把流量引导到最近接入点;逻辑层可根据规则,把用户重定向到其他节点
8G内存的服务器大概可做到100w并发长连接。
经验:
可调度的能力很重要,这意味着你可随意控制灰度的范围和节奏,也可把vip放在专有set里,以确保新代码稳定后再灰度到他们。
待思考问题:
1、采用长连接对并发、阻塞的处理?
2、多IDC间,用户数据漫游规则,怎样智能迁移?典型场景:用户A在北方求学,寒暑假回南方,怎么确保就近访问?
安全/会话
注:密码学老师请原谅我,公钥私钥PKI啥的全忘干净了,大概意思如下,同学们凑合着看
登录鉴权基于RSA(非对称加密算法,意思是用一个密钥来加密信息,但是用另外一个不同的密钥来解密。这里使用2048bit密钥),服务端生成SessionKey派发给客户端。
后续请求基于AES,相对轻量,损耗约在10%以内。RSA太吃机器了,以至于nb把登录鉴权的逻辑单独部署了集群。
连接与会话分离,重建连接可复用会话。好处:网络波动无需重走登录逻辑。
经验:
因为各种原因,用户的SessionKey一般2天就会失效。
如何确保用户身份的安全合法,不被伪造?(这个问题背景貌似是:接入层透传,到逻辑层才做解密和鉴权)确认身份后,才能收到通知。
数据
每个帐号都有独立的box,用于存储云端未读数据,先存储再通知,客户端拉取后删除云端数据。
如果是1vN组播数据,则所有组成员的box都会收到这份数据的copy。好处:确保读取逻辑简单,有未读就收走。坏处:多份copy对存储的浪费?
C/S数据同步
目的:将S存储的数据同步到C,还要省流量
关键:确定C/S间的数据差异(即:只同步需要同步的),同时减少网络交互
实现:S使用递增seq记录变更,C使用seq记录同步点
核心:一定、必须保证seq是递增的,否则就丢数据了(比如:C的seq>S的seq)。这里采用非连续的递增seq。
经验:
省流量怎么做?C每次pull request都带上了自己所持有的seq号。也就意味着,每次同步之后,C不需要给S汇报(确认)本轮更新的完成位置,因为下次req时,S看到C送上来的seq就知道上次C已经同步到哪个位置了。从而节省一次seq ack的开销。
对特殊用户染色,开启全量日志,方便跟踪。弊端是:无法追溯染色前的问题。
高可用
按需使用不同类型的存储:双机、三机
异步采集,离线统计,多级监控:本地agent从逻辑服务shm取出数据,上传到监控/日志中心,统计归并后输出告警or展示
多IDC、多园区的分布容灾
经验:
第三方拨测+业务定时注册续期,及时发现宕机节点,实现故障屏蔽。