XX方案机密XX系统方案修订历史版本修订日期修订人修订内容0.62012.4.15罗玏起草0.72012.4.18罗玏增加对各相关表的备注0.80.91.01.11.41.51.62.02.12.5目录TOC\o"2-3"\h\z\t"标题1,1"HYPERLINK\l"_Toc375295276"1.概述PAGEREF_Toc375295276\h3HYPERLINK\l"_Toc375295277"1.1.约定PAGEREF_Toc375295277\h3HYPERLINK\l"_Toc375295278"2.系统架构设计PAGEREF_Toc375295278\h3概述本文为企业经营、会员管理等应用产品的通用管理后台系统的设计方案，因目前未有较好名称，故先暂命名为通用会员管理系统。本文的阅读对象为前后台设计、开发人员，需求分析及产品设计人员等。约定系统中的所有图片，包括商家照片、客户头像等，均以文件的形式保存在后台的文件路径下，数据库对应表中保存图像的原名及文件路径据D.V.B团队以及Cmshelp团队做CMS系统评测时的结果看来，MySQL单表一般在2千万条记录（4G）下能够良好运行，经过数据库的优化后5千万条记录（10G）下运行良好。因此，本系统后台数据库在单表百万量级前选择mysql。未来企业信息纪录，企业客户信息纪录，都会放在MySQL数据库里面，通过MySQL数据库的负载均衡分布在多台服务器上。未来发布的优惠信息，以及订单信息等动态信心，应该在年底移植到NoSQL数据库上面。产品信息可能也需要放在NoSQL数据库上。当年放在MySQL上面没有问题，1000家企业，每家100个产品才10万条记录。为避免读取数据库中时间后格式转换的麻烦，系统中使用到的日期及时间信息大部分将以yyyy-MM-dd、yyyy-MM-ddhh:mm:ss的字符串形式保存在数据库对应字段根据城市对数据库进行物理级别上的划分。APP一旦建立起来，基本上访问的数据就是自己家的，访问别的企业数据可能性较小，所以按照城市划分不会对APP造成影响，反而会利用地理优势提高访问性能。方案大体为深圳的APP首先访问深圳这边的数据库主机，北京的APP首先访问北京的数据库主机，上海的APP首先访问上海的数据库主机。应用主机的分地放置是趋势，但数据库是否需要从物理上划分，需要进一步商议，需要考虑未来商业模式的演变过程中，数据库的分离是否会有影响系统架构设计考虑未来业务逻辑会需要很大扩展、产品的需要快速更新、用户体验需要持续优化，在设计系统架构时，进行了以下规划：逻辑层以业务进行划分，尽量将业务逻辑解耦开，使得后续增加新业务逻辑时只需要部署新的业务逻辑代码就能快速满足需要，而且不会对已有业务产生影响。将后台管理逻辑与用户业务逻辑进行拆分，使得开发分工更加明细，而且相互独立不会干扰。将推送功能单独列出来，是为了强化推送的效率，保证推送的消息能够及时有序的下发。数据层上采用主从双写备份的方式实现容灾，能够实现即是主崩溃掉系统也不受影响，缺点是存储增加一倍。将图片与数据拆分，为图片单独设计一个图片存储服务器，优化操作系统性能，使得图片存储和传输最优。将数据按照不同库表拆分，比如产品库、促销广告库、公共库各占一个主机，根据每个库的不同特点，配置不同规格性能主机：公共库要求支持的链接多，但是数据量比较少，需要配置CPU多，硬盘空间小的主机；促销广告库的广告信息多，增长快，需要配置大内存大硬盘的主机，而且可能经常扩展硬盘。公共库可能针对全国各个区域，产品库、促销广告库可能只针对某个城市。