七彩石前身后世.ppt

七彩石的前身后世 讲师：魏建强 大型应用之路1 2 3 4 将来之抉择5 某网站架构之过去&抉择 某网站架构之重构&现在 将来注意要点 大型应用类型 高可靠应用 § 如银行，证券交易，支付宝 高性能应用 § 如电话公司 高可用应用 § 19楼，新浪等 计算机世界的变化 莫尔定律的终结 § 按照莫尔定律，2004年应该出现10G的CPU 超线程和多核技术的使用 § 程序不再顺序执行 硬件发展趋势决定软件发展趋势 § Google的map-reduce & Yahoo的hadoop,云计算 并行时代的到来 过去&抉择 www.19lou.com 原逻辑结构 某网站原数据结构 DB5: 用户、权限 全局配置中心 完全帖子库 冗余数据 BBS1BBS10 论坛 存取帖子 列表和内 容 存取帖子 配置中心 用户中心 其他应用 根据fid不规则打散 Disuz!原体系结构 代码混乱，结构复杂 单点问题众多 维护成本巨大 扩展困难 系统不稳定 质量不可靠 安全工作艰巨 抉择一 Scale out(平行 扩展) 通过简单增加性价比 较好的硬件投入，使系 统提高负载增量，这个 增量是值相对稳定的。 典型例子如 google,facebook 哪条路？ Scale UP(向上 扩展) 购买计算能力更强， 处理能力更高，吞吐量 更大的硬件，大幅度提 高系统的负载能力 典型例子如Taobao，阿 里巴巴 Scale Up & Scale Out Scale Up & Scale Out Scale out优缺点： § 节省硬件成本，以可控的成本解决问题； § 技术相对复杂，大型站点如Google、Yahoo和Amazon.com，都自 行研发大量相关技术； § 需要对原先使用的软件进行大量的重写工作。 Scale up优缺点： § 现有程序不需修改（实际淘宝做了大量的修改） § 成本巨大 § 硬件有极限，达到最大极限的时候，成本巨大，难以想象 三叉口三叉口 新论坛新论坛 新论坛新论坛+ +维护维护 重构之七彩石重构之七彩石 抉择二 重构&抉择 项目规划 高层应用 基于服务的分层体系结构 物理逻辑分离 服务逻辑分离 Final Release 第三阶段 第二阶段 第一阶段 第一阶段目标 第二阶段目标 第二阶段实际结果 现有数据模型 UserDBConfigure DB (DB5) BBS1 Love BB BBS4 Ent fun 论坛 存取帖 子列表 和内容 配置中心 冗余数据 其他应用 分逻辑 存储 第三阶段目标 第三阶段 2008-11-28 全站去除分库表的db5支持 db5改论坛配置服务器 搜索引擎发布 RB1 RB2 RB3 RB4 第三阶段发布第三阶段发布 2008-10-31 帖子显示方式重构 置顶以及千斤鼎重构 增加指定置顶功能 帖子操作类型(推荐首页等) 2008-11-21 数据重分布 全站分库支持 2008-10-15 数据库字段重构 2008-10-17 新表fid插入支持 2008-10-18 新表导入fid数据 部署图 原时间表 3 1 应用逻辑分离 阶段一 物理逻辑分离 第二阶段 分层体系结构 第三阶段 2008.032008年4月中旬2008年7月中旬 2 实际进程 第一期第一期 2008.07 完成大部分慢查询的修改 2008.04 完成用户分离 第二期第二期 2008.11 去除db5单点，去除bbs1-10的单点 2008.09 数据重分布 2008.08 完成主要服务的分离，如帖子服务 第三期第三期 2008.底 解决图片服务器单点问题 2008.12 基于服务体系新产品的实践品牌天堂 将来将来 2009年 在七彩石搭建的基础架构上，新产品 搜索等等领域，尽情发挥吧 重构之外 软件技能的提升 新产品架构的合理性 编码过程规范化 敏捷管理的实施 软件过程的条理化 品质管理 支撑更大Team的基础管理结构和管理模式 安全提升 将来注意要点 面临的挑战 研发投入不足 产品开发流程的规范 质量保障体系的建立 安全体系的建立 新应用类型的架构 数据结构分布 用户中心（全站类） ： § 用户session数据 § 用户个人信息 § 好友关系 § 警告数据 组件数据结构（全站类） § 短消息 § 表情系统 § 用户主题相关(我的*系列) 论坛配置中心 § 论坛权限配置数据 § 论坛表 § 论坛全局配置数据 频道 § 22个楼层数据库实例 § 1个城市站数据库实例 应用分离-数据库篇 采取应用分离式容量扩展模式 § 短信息、表情系统、我的XX分离到全局组件 数据库，即这些应用将针对全 站应用。 § 22个楼层数据库，根据需要，购买新的服务器 ，放到各自独立的服务器 § 城市站数据库实例，根据需要，将各个城市站 导成独立数据库实例 § 假如，某个楼层容量大到无法用单台数据库支 撑，对单楼层进行数据分片 增强cache-数据库篇 采取cache进行容量扩展模式 § 论坛权限需要重构，加载cache（产品上，需 要跟进） § 论坛全局配置可以完全缓存起来，也需要重构 ，分层之。 § 帖子内容页缓存和帖子列表页缓存，应该采用 命中率更高的缓存策略 § 基本去除论坛的文件缓存 数据分片-数据库篇 HASH是一种廉价的方式 热度均匀需要达到 设计时候考虑产品需要，提供冗余度 高度依赖cache 读写分离-数据库篇 读写分离 § 在读上进行Load balance § 多做几个从库，但从库不宜过多，进行读负载 均衡 优点：较为常见的扩展模式，技术成熟 缺点：不能克服数据量过大的问题，从库的数量有 限，容量有限制。 § 如果已经过渡依赖读写分离 可以多层级联，但是实现成本高，维护成本高 AH方案 不需要考虑，太复杂了 有更好的解决方案 § 日PV有8000万的时候，就应该着手做了 § 需要大量的研发高手 存储篇 性价比选择要有标准 § 这个是重中之重 § 需要开发出一种简易计算模型 虚拟文件系统的建立 § 用软件替代昂贵的商业解决方案 § 数据分片，热度均匀的技术准备 需要分应用 § 从数据库、缓存、到存储都需要分应用，隔离 故障 § 均匀热度 服务器选择篇 定量 § 什么样的服务器，能支持什么样的应用流量 § 什么时候需要购买 定性 § 软件扩展还是硬件扩展 § 硬件扩展的话，未来性价比 § 预算怎么来定 § 买什么样的服务器 定价 性价比选择 § 需要考虑带宽、机柜、维护等成本因素 § 也需要开发一个计算模型 目前底子 实质支撑论坛程序的服务器 § 9台Dell 1950 web服务器 § 4台论坛数据库 § 1台Forumconfig库 § 1台用户库 论坛流量在1300万强 § 以Web论144万/台 § 以数据库论217万/台 § 综合论：90万/台上下 实际容量当在现有数字的 2倍以上 路很远，很艰辛，但我们从没停止脚步