常见互联网业务模型与架构浅析[未完]

[写在前面]

Q3和老大讨论下半年技术学习方向时，老大建议应该多关注常见的互联网业务模型，并尝试分析各种业务的架构模型。确实，一个好的软件开发人员要成为一名优秀的架构师，必须开拓自己的视野和胸怀，这次谈话让我产生的写这篇文章的想法。

本文先列出常见的互联网业务，并逐一进行架构分析，分析过程我力求与业界领域的技术人员求证，但因个人理解难免有所偏差，欢迎大家指正！

[常见互联网业务模型]

1. SNS GAME-农牧场

2. 小型UGC业务-微博

3. 大型UGC业务-邮箱、相册、日志

4. 门户网站

5. 休闲游戏大厅

6. MMOG大型网游

7. 流媒体服务-音乐、视频

8. 电子银行-支付宝

[架构设计]

架构设计通常是数据和行为驱动的，数据的重要性通常分为下面的级别。

一、数据的重要性分级

1. 需要严格保证实时一致性， 用户重要数据

如电子银行、游戏中的道具数据等，这类数据的数据量一般不大，需要做热备、异地容灾备份。

2. 无须严格实时的一致性，用户次重要数据，追求最终的一致性

如游戏中的经验值，此类数据的数据量一般比较大，如果全量做热备成本比较高，因此可采用增量热备的方式，同时做隔日冷备，用于回档（具体实现见SNSGAME中的详述）。

3. 用户不是很关心的，可丢失的数据

如游戏中的一些消息，通知，或者一些提示等，无须备份。

二、数据的访问特征

1. 读多与写

常见与UGC业务，用户写成本比较高，因此量比较少，比如用户发表的日志、上传照片等，但部分数据读量很大，如一些热点图片、热点新闻和一些首页数据等。

2. 写多与读

常见与游戏，用户写操作成本低，十分频繁，如国内较火的游戏农场，每一次用户点击都是一次写请求。

3. 读写都较多

4. 读写都较少

架构师需要问自己下面一些问题：

[SNSGAME]

SNSGAME的特点是用户操作集中、读写量很高，因此，需要对数据的重要级别进行区分，进而选择存储方式。

1. 核心数据-经验、金币、等级

这类数据读写量很大，因此，db前面部署cache，保证用户的请求都落在cache时，同时，异步更新DB，为保证数据的最终一致性， 对未更新的数据，做增量cache，这样即使cache数据丢失，那么增量cache+db，就是一致性的数据。

2. 重要数据-道具、装备

这类数据需要用户支付RMB或者投入大量精力获得，因些要保证严格的一致性，但这类数据的读写量比较低，数据量少，因此，不需要做cache，直接用DB即可，同时，做好热备或者保证冷备。

3. 不重要数据-消息、提示

这类数据通常由用户操作触发，写量也比较高，同时数据不是很关键，只需要保存最近一个时间段的数据即可，通常直接用cache，保证请求响应速度。

[UGC业务]

UGC是用户产生内容的简称，UGC业务里最核心的问题就是分布式存储。