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