《淘宝系统架构概述.ppt》由会员分享，可在线阅读，更多相关《淘宝系统架构概述.ppt（37页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、系统架构概述Yes,We KAO更强，更高，更持久 了解什么是架构 了解Alibaba网站架构的历史 掌握Alibaba网站架构的现状 掌握网站架构设计的理念课程目标和内容 架构规定了软件的高层划分及各部分间的交互 架构不是软件，但架构决策体现于软件平台和框架之中 架构的优劣决定了业务应用系统的实施能力和发展空间 技术搭台，业务唱戏 架构搭台，应用唱戏 架构永远在随着业务的发展而变迁 拥抱变化！什么是架构？架构变迁更多用户更多数据更多功能硬件成本人力成本质量成本提高收益节约成本业务发展B2B架构演化过程1999史前2001石器时代2002中世纪2005工业革命未来星际时代？PerlWebMac
2、ropojojdbcVelocityEjbWebXSpringSOAOPEN API云计算 Perl，CGI Mysql Apache 服务器在美国，56KModem，远程开发、测试、部署1999-史前时代 Java服务器使用线程性能比cgi技术使用进程好 Java相比Perl，可维护性好，开发效率高 Java开始在国内流行史前-石器时代原因 开始使用Java 模板技术采用WebMacro 中间层采用Servlet技术，使用POJO封装业务逻辑和数据访问 使用BizObj对象封装基本业务逻辑和数据访问方法 其它业务对象继承BizObj方法，实现自己的业务逻辑和数据访问方法 使用JDBC访问数据
3、库 Servlet容器使用resin，Web服务器使用Apache2001底-石器时代-www系统2001底-石器时代(续)基于POJO的biz层基于WebMacro的模板技术表现层业务层BizObj业务逻辑方法数据访问方法OfferObj业务逻辑方法数据访问方法MemberObj业务逻辑方法数据访问方法CompanyObj业务逻辑方法数据访问方法基于pojo的Biz层Oracle数据库 LDAP数据存储 表现层仅仅使用模板技术，缺乏MVC框架，导致大量的servlet配置 业务逻辑层和数据访问层耦合，可维护性和可扩展性差 受到EJB风潮的影响石器时代-中世纪原因 表现层采用WebX 模板技术
4、Velocity 在Turbine基础上开发了自己的服务框架和一系列公共服务 通过一个delegate对象访问业务逻辑层 业务逻辑层使用EJB（SLSB，CMP，DAO等）通过一个faade对象供表现层delegate访问 Faade对象访问多个SLSB实现的controller对象实现业务逻辑 使用CMP实现单条记录的增加和删除 考虑性能，在CMP之外封装DAO对象通过JDBC访问数据库 EJB服务器使用Weblogic Web服务器使用Apache2002底-中世纪2002底-中世纪（续）搜索引擎 Oracle数据库 LDAP使用SLSB实现的业务逻辑对象Controlers基于Webx以
5、及Service框架的Web层框架CMP进行单条记录的增加删除，DAO对象查找表现层商业逻辑层数据访问层数据存储delegateFaade Turbine的发展缓慢 EJB配置复杂,可维护性差 重量级框架，业务侵入高 高度容器依赖，可测试性差 CMP性能差，导致DAO和CMP并存中世纪-工业革命原因 表现层使用WebX和Service 框架 Velocity模板技术 自有服务框架及多种公共服务：Form Service，Template Service，Mail Service，Rundata Service，Upload Service等 通过command模式和biz层交互 无状态Web应
6、用，基于cookie实现session，获取线性扩展性 业务逻辑层使用Alibaba Service框架，并且引入spring 框架 Spring容器和Alibaba Service框架无缝集成 AO，BO 使用分布式cache缓存对象 数据访问层 透明的事务处理 引入Hibernate和iBatis，以iBatis为主2005-工业革命2005-工业革命（续）搜索引擎 Oracle数据库 LDAP基于Spring以及Service框架的biz层框架基于Webx以及Service框架的Web层框架分布式Cache分布式Session基于Spring以及DAO设计模式的数据访问框架表现层商业逻辑
7、层数据访问层数据存储 数据库成为瓶颈-分布式数据库 应用耦合严重-SOA Pampas平台演化还在继续 中文站会员数超过2000万 中文站Offer已经超过1.5亿 中文站每天的用户PV已经超过1.6亿 中文站每天新发Offer超过100万 中文站每天重发Offer超过1500万 国际站略少，但是增长迅猛网站的现在中文站/国际站应用部署图网站镜像部署图(国际站)中供用户 网站运营海外卖家Load Balance(F5,Alteon)Apache JbossDatabaseSearch Engine ApacheJbossApacheJbossApacheStatic ResourceCache
8、Storage用户请求处理 流量随着用户量而增加 业务的变更频繁 用户行为的收集 产品角色的细分及调整 7 X 24的高可用性互联网的挑战单击此处编辑版标题样式流量激增处理用户请求RequestProcess ResponseRequestProcess ResponseRequestProcess Response应对的挑战 并发(垂直)用户数量的增加 使用资源的增加 响应(水平)处理性能的维持单击此处编辑版标题样式业务变更专业化细分之前offer list detailmember company personaltransaction no support专业化细分之后offer Clo
9、thing Retail Loanmember Trust Pass Special Markettransaction alipay paypal数据挖掘offer repostnew offerbid 行为数据的采集追踪埋点异步收集采集数据的分析数据仓库分析引擎运营团队决策风险行为的控制CTU系统安全团队单击此处编辑版标题样式网站产品的生命周期产 品需求整理架构 团队设计开 发团队实 施质 量 团队质检运 营团队 运作用 户 需求分析团队再细分用 户 需求分析 商 业 策划 市 场 策划 产 品需求分析 产 品 设计 网站运 营架构 团队 架构 师开 发团队 程序员 项目经理 用户体验质
10、量 团队 测试 流程控制运 营团队 产 品运 营 客 户 服 务角色专业化细分业务1业务2业务3避免宕机集群化服务化备份切换维护时间有限新产品发布在线发布叠加式发布用户透明过渡高可用性 架构是平衡的艺术 不要把简单问题复杂化，也不要把复杂问题简单化 系统架构需要考虑哪些业务要求和质量指标？怎样取得平衡？分解复杂度 自上而下，分离关注点（总体系统局部）分配复杂度 用合适的技术、合适的组织来解决问题架构设计理念更多用户更多数据更多功能更少硬件更少人力更少故障质量指标可用性安全性性能稳 定性可 维护 性分解 业务 应用 数据合并 联动的业务 高藕合的数据持 续发 展 插件式扩展能力 弱藕合,易于剥离
11、 局部可优化调整 可测试稳 定性 高可用性 负载均衡 线性扩展 可被监控架构的考虑要点业务划分系统细分应用优化架构考虑的方向会员管理跟单管理财务管理销售后台Offer 审批会员审批类目运营数据采集分析运营后台用户登录用户前台用户后台旺铺、广告社区、论坛网站前台搜索引擎阿里旺旺支付宝合作部门总体架构 分解：按不同的业务领域、用户群来分解 业务 业务 复 复 杂 杂 性 性 分配：将业务需求分配到各个 公司、部 公司、部 门 门、系、系 统 统、服、服 务 务 系统/服务可独立部署和维护，它们之间多采用分布式交互业务划分(总体架构)会 员 体系运营体系业务体系业务划分(总体架构)系统架构WebXV
12、elocitySpring MVC表现层IOC(Spring)SOA(Pampus)EJB业务逻辑层iBatisCMPJMS数据访问层安全容错管理监控日志Build工具系统架构 分解：按不同的技术层次来分解 技 技 术 术 复 复 杂 杂 性 性 分配：将技术需求分配到各个 中 中 间 间 件、容器、框架、工具 件、容器、框架、工具 组 组 件 件 容器/框架通过特定的技术模式来透明或半透明地解决技术问题网站 应用系 统BOPS系统资 源系 统系统细分应用优化DACSANNAS存储系统全文索引目录索引搜索引擎索引数据复制水平分割垂直分割数据库内容静态化数据库缓存对象缓存客户端缓存Cache局部调优（数据存取）分解：按数据的位置、读写、计算特性等分解 数据存取复 数据存取复 杂 杂 性 性 分配：将数据分配到各个 数据 数据 库 库、索引、索引 库 库、存、存 储 储 系 系 统 统、Cache Cache 不同的存储技术适合于不同的数据存取需求读 写应用优化 总体架构 考虑面向服务体系 系统架构 更加专业化、服务化的信息收集系统 更加全面化、自动化的配置管理 更加有效率的镜像同步、切换 局部应用优化 分布式文件系统 优化数据同步系统 读写分离展望未来 架构随着业务发展不断演进 架构发展要有方向有节奏总结Q&A