某科技网站技术详解.pptVIP

阿里巴巴网站技术介绍 网站镜像和同步技术? ?? 第一页，共四十二页。 纲要 一、前 言 二、网站部署的三个阶段 三、新的挑战 四、总结 第二页，共四十二页。 阿里巴巴（A）是一个服务于全球企业的（B2B）电子商务平台。用户遍布中国以及世界各地，为了更好的为这上千万的用户提供网络服务，我们建立了多个站点去为用户提供应用. 总体而言,我们的站点发展经历了以下三个阶段： 单站点 双站点 多站点 前 言 第三页，共四十二页。 纲 要 一、前 言 二、网站部署的三个阶段 三、新的挑战 四、阶段性总结 第四页，共四十二页。 网站部署的三个阶段 第五页，共四十二页。 应用都是无状态的 状态数据都保存在以下的设备中 数据库 存储 第一阶段-单站点 第六页，共四十二页。 状态数据都保存在数据库和存储，由数据库和存储提供分布式以及HA的解决方案。 应用都是无状态的（尽量用Cookie解决session的问题），非常便于扩展。 描述 缺 点　 部分地区用户的使用体验不佳 系统性能和扩展性不好 第一阶段-单站点 第七页，共四十二页。 可用性的要求 单个IDC发生故障,例行维护,系统升级都会影响所有的用户，进而降低网站的可用时间。 用户体验的问题 网站是为全球用户提供服务的，物理距离产生的网络延时是不可避免的。 10000公里 = 延时30毫秒 电子商务网站的内容通常都是动态的，CDN只能解决大多数静态资源的问题(图片,css,js…)。 驱动力 第二阶段-双站点 第八页，共四十二页。 DNS负载均衡(IDC之间的负载均衡) 数据同步解决方案 应用拆分＆镜像 需要解决的问题 第二阶段-双站点 第九页，共四十二页。 DNS负载均衡 第二阶段-双站点 第十页，共四十二页。 数据同步1.0-方案选型 数据库提供的方式 专业工具,例如shareplex 自主开发 同步效率 中 高 中 双向同步 不支持 支持 支持 关联的文件同步 不支持 不支持 支持 异构数据库 不支持 不支持 支持 冲突检测逻辑 不支持 不支持 支持 第二阶段-双站点 第十一页，共四十二页。 数据同步1.0-实现 基于AOP方式的SQL拦截 根据变更的数据找到关联的文件. 异步的进行SQL以及文件的复制. 第二阶段-双站点 第十二页，共四十二页。 第二阶段-双站点 数据同步1.0-缺点 数据同步1.0-优点 第十三页，共四十二页。 CAP原理 写应用:符合ConsistencyAvailability 读应用:符合Partition toleranceAvailability, 结论:读应用更容易实现跨IDC的部署 问题 数据同步会放大数据不一致数据不完整的情况 .这会增加镜像站点应用的复杂性. 应用拆分-分析 第二阶段-双站点 第十四页，共四十二页。 应用拆分-注意事项 第二阶段-双站点 被镜像的读应用需要从设计上避免数据完整性的问题. 设计业务流程的时候需要避免跨IDC的Web Flow. 第十五页，共四十二页。 应用拆分示意图 第二阶段-双站点 第十六页，共四十二页。 部署结果 第二阶段-双站点 第十七页，共四十二页。 解决了大多数读应用和少量写应用的用户体验问题. 实现了读应用的跨站点的HA.提高了读应用以及网站的整体可用性. 读应用的数据源尽量迁移到了Search engine和cache上为其性能和可扩展性带来了很大的收益. 收益 第二阶段-双站点 第十八页，共四十二页。 不完全的镜像 同步的延迟到导致应用之间数据不一致的问题，尤其在不同IDC之间存在应用的依赖时，这个问题会被放大。 数据的双向同步带来了一些不能解决的数据冲突，需要在设计的时候进行规避。 缺 陷 第二阶段-双站点 第十九页，共四十二页。 应用规模的日益复杂 同步数据量的增大 数据同步1.0的缺点逐渐凸显. 数据冲突的问题 不能拦截所有的数据变更 开始酝酿升级 后 记 第二阶段-双站点 第二十页，共四十二页。 起因 第三阶段-多站点 Disaster… 第二十一页，共四十二页。 目 标 第三阶段-多站点 第二十二页，共四十二页。 挑 战 第三阶段-多站点 多个IDC之间的数据同步 数据同步的吞吐量以及数据一致性的问题. 写应用的镜像数据拆分 第二十三页，共四十二页。 变更数据的急剧增长导致同步的效率成为瓶颈. 结果： 站点之间的数据延迟不断加大 应用之间的数据不一致的情况逐渐加剧 数据同步现状 第三阶段-多站点 第二十四页，共四十二页。 数据同步的瓶颈并不在于网络 数据同步的瓶颈最终受制于为了满足数据一致性而对写入操作进行的排序 数据同步瓶颈分析 第三阶段-多站点 第二十五页，共四十二页。 在数据库层面记录数据变更