参加某nb业务的后台架构分享

接通知，某牛逼业务（后面简称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、多园区的分布容灾

经验：

第三方拨测+业务定时注册续期，及时发现宕机节点，实现故障屏蔽。