某科技网站技术详解.pptx

阿里巴巴网站技术介绍 ;;阿里巴巴（A）是一个服务于全球企业的（B2B）电子商务平台。用户遍布中国以及世界各地，为了更好的为这上千万的用户提供网络服务，我们建立了多个站点去为用户提供应用. 总体而言,我们的站点发展经历了以下三个阶段： 单站点 双站点 多站点;;网站部署的三个阶段;;状态数据都保存在数据库和存储，由数据库和存储提供分布式以及HA的解决方案。 应用都是无状态的（尽量用Cookie解决session的问题），非常便于扩展。;可用性的要求 单个IDC发生故障,例行维护,系统升级都会影响所有的用户，进而降低网站的可用时间。 用户体验的问题 网站是为全球用户提供服务的，物理距离产生的网络延时是不可避免的。 10000公里 = 延时30毫秒 电子商务网站的内容通常都是动态的，CDN只能解决大多数静态资源的问题(图片,css,js…)。; DNS负载均衡(IDC之间的负载均衡) 数据同步解决方案 应用拆分＆镜像;DNS负载均衡;数据同步1.0-方案选型;数据同步1.0-实现;第二阶段-双站点;CAP原理 写应用:符合ConsistencyAvailability 读应用:符合Partition toleranceAvailability, 结论:读应用更容易实现跨IDC的部署 问题 数据同步会放大数据不一致数据不完整的情况 .这会增加镜像站点应用的复杂性. ;应用拆分-注意事项;应用拆分示意图;部署结果; 解决了大多数读应用和少量写应用的用户体验问题. 实现了读应用的跨站点的HA.提高了读应用以及网站的整体可用性. 读应用的数据源尽量迁移到了Search engine和cache上为其性能和可扩展性带来了很大的收益. ;不完全的镜像 同步的延迟到导致应用之间数据不一致的问题，尤其在不同IDC之间存在应用的依赖时，这个问题会被放大。 数据的双向同步带来了一些不能解决的数据冲突，需要在设计的时候进行规避。;应用规模的日益复杂 同步数据量的增大 数据同步1.0的缺点逐渐凸显. 数据冲突的问题 不能拦截所有的数据变更 开始酝酿升级;起因;目 标;挑 战;变更数据的急剧增长导致同步的效率成为瓶颈. 结果： 站点之间的数据延迟不断加大 应用之间的数据不一致的情况逐渐加剧 ;数据同步的瓶颈并不在于网络 数据同步的瓶颈最终受制于为了满足数据一致性而对写入操作进行的排序;在数据库层面记录数据变更 基于Base原则 消息驱动 并行所有可以并行的内容. 有选择的侵入业务 简单的处理冲突的逻辑 Merge操作;HA方式;Sharding. 去中心化,缩小中心 Write Sticky:解决跨站点的Web Flow的问题 事后补偿 异步 ;提高对数据不一致窗口的容忍程度． 数据库记录中的文件路径的问题. 降低多点更新数据的冲突可能性 引用计数的问题;IDC之间的数据不能遵循ACID,只遵循Base的原则. 下面两个问题是提高用户体验的关键. 提高同步性能，缩小数据不一致性窗口 尽量保证目的端数据库的数据完整性. 单个 IDC内部的数据一致性优于跨IDC的数据环境 .所以。尽量把单个用户的操作行为限制在单个IDC中.;;集中的持久化技术已经不足以支撑应用的写入的吞吐量，其他的持久化技术开始引入 分布式数据库 其他分布式持久化方案的引入:KV-Engine, DFS.. 分布式事务.;;数据复制的节点增加. 硬件成本随之增大 一些特殊应用对同步实时性的要求提高. 随着分布式持久化技术的引入.单个IDC的数据持久化能力 得到极大的提升.但数据同步技术因为受制于数据一致性 的问题 ,逐渐成为了瓶颈. 设备数量的增长对自动化管理提出了新的要求. 多站点的发布,自动化测试以及应用监控. 跨站点的动态负载均衡; 数据同步方案的优化 有效地控制数据备份的数量. 在合适的场景下使用反向代理技术. 水平拆分优于垂直拆分. 应用监控平台 自动化发布和部署的平台.;优化数据变更的采集方式 根据数据的类型设定不同的通道和策略. 解决各种分布式数据源的数据一致性的问题.(分布式事务的场景) 纪录和尝试解决数据冲突的问题.;适用范围 数据总量比较大,访问相对集中的静态资源;例如图片信息. 访问量比较小的一些动态应用. 效果 降低同步数据量 降低存储设备的投入 减少因为同步延迟而造成的数据不一致.;;镜像的关键是数据同步的问题. 根据DQ的原则.将中心最小化.采用异步或者事后补偿的机制降低中心应用对其他应用的可用性的影响. 单个IDC的核心数据保证可以保证强一致性,多个IDC的核心业务数据只保证最终一致性. 在业务上解决数据冲突的问题并容忍一定程度的不一致. 采用数据Sharding技术,水平拆分优于垂