淘宝系统架构概述.ppt

淘宝系统架构概述.ppt

《淘宝系统架构概述.ppt》由会员分享，可在线阅读，更多相关《淘宝系统架构概述.ppt（37页珍藏版）》请在冰点文库上搜索。

系统架构概述,了解什么是架构了解Alibaba网站架构的历史掌握Alibaba网站架构的现状掌握网站架构设计的理念,课程目标和内容,架构规定了软件的高层划分及各部分间的交互架构不是软件，但架构决策体现于软件平台和框架之中架构的优劣决定了业务应用系统的实施能力和发展空间技术搭台，业务唱戏架构搭台，应用唱戏架构永远在随着业务的发展而变迁拥抱变化！

什么是架构？

B2B架构演化过程,1999史前,2001石器时代,2002中世纪,2005工业革命,未来星际时代？

Perl,WebMacropojojdbc,VelocityEjb,WebXSpring,SOAOPENAPI云计算,Perl，CGIMysqlApache服务器在美国，56KModem，远程开发、测试、部署,1999-史前时代,Java服务器使用线程性能比cgi技术使用进程好Java相比Perl，可维护性好，开发效率高Java开始在国内流行,史前-石器时代原因,开始使用Java模板技术采用WebMacro中间层采用Servlet技术，使用POJO封装业务逻辑和数据访问使用BizObj对象封装基本业务逻辑和数据访问方法其它业务对象继承BizObj方法，实现自己的业务逻辑和数据访问方法使用JDBC访问数据库Servlet容器使用resin，Web服务器使用Apache,2001底-石器时代-www系统,2001底-石器时代（续）,基于POJO的biz层,基于WebMacro的模板技术,表现层,业务层,Oracle数据库,LDAP,数据存储,表现层仅仅使用模板技术，缺乏MVC框架，导致大量的servlet配置业务逻辑层和数据访问层耦合，可维护性和可扩展性差受到EJB风潮的影响,石器时代-中世纪原因,表现层采用WebX模板技术Velocity在Turbine基础上开发了自己的服务框架和一系列公共服务通过一个delegate对象访问业务逻辑层业务逻辑层使用EJB（SLSB，CMP，DAO等）通过一个faade对象供表现层delegate访问Faade对象访问多个SLSB实现的controller对象实现业务逻辑使用CMP实现单条记录的增加和删除考虑性能，在CMP之外封装DAO对象通过JDBC访问数据库EJB服务器使用WeblogicWeb服务器使用Apache,2002底-中世纪,2002底-中世纪（续）,搜索引擎,Oracle数据库,LDAP,使用SLSB实现的业务逻辑对象Controlers,基于Webx以及Service框架的Web层框架,CMP进行单条记录的增加删除，DAO对象查找,表现层,商业逻辑层,数据访问层,数据存储,delegate,Faade,Turbine的发展缓慢EJB配置复杂,可维护性差重量级框架，业务侵入高高度容器依赖，可测试性差CMP性能差，导致DAO和CMP并存,中世纪-工业革命原因,表现层使用WebX和Service框架Velocity模板技术自有服务框架及多种公共服务：

FormService，TemplateService，MailService，RundataService，UploadService等通过command模式和biz层交互无状态Web应用，基于cookie实现session，获取线性扩展性业务逻辑层使用AlibabaService框架，并且引入spring框架Spring容器和AlibabaService框架无缝集成AO，BO使用分布式cache缓存对象数据访问层透明的事务处理引入Hibernate和iBatis，以iBatis为主,2005-工业革命,2005-工业革命（续）,搜索引擎,Oracle数据库,LDAP,基于Spring以及Service框架的biz层框架,基于Webx以及Service框架的Web层框架,分布式Cache,分布式Session,基于Spring以及DAO设计模式的数据访问框架,表现层,商业逻辑层,数据访问层,数据存储,数据库成为瓶颈-分布式数据库应用耦合严重-SOAPampas平台,演化还在继续,中文站会员数超过2000万中文站Offer已经超过1.5亿中文站每天的用户PV已经超过1.6亿中文站每天新发Offer超过100万中文站每天重发Offer超过1500万国际站略少，但是增长迅猛,网站的现在,中文站/国际站应用部署图,网站镜像部署图（国际站）,中供用户,网站运营,海外卖家,LoadBalance（F5,Alteon）,Apache,Jboss,Database,SearchEngine,Apache,Jboss,Apache,Jboss,Apache,StaticResource,Cache,Storage,用户请求处理,流量随着用户量而增加业务的变更频繁用户行为的收集产品角色的细分及调整7X24的高可用性,互联网的挑战,流量激增,处理用户请求,应对的挑战,并发（垂直）用户数量的增加使用资源的增加响应（水平）处理性能的维持,业务变更,专业化细分之前,专业化细分之后,数据挖掘,行为数据的采集追踪埋点异步收集采集数据的分析数据仓库分析引擎运营团队决策风险行为的控制CTU系统安全团队,网站产品的生命周期,团队再细分,角色专业化细分,避免宕机集群化服务化备份切换维护时间有限新产品发布在线发布叠加式发布用户透明过渡,高可用性,架构是平衡的艺术不要把简单问题复杂化，也不要把复杂问题简单化系统架构需要考虑哪些业务要求和质量指标？

怎样取得平衡？

分解复杂度自上而下，分离关注点（总体系统局部）分配复杂度用合适的技术、合适的组织来解决问题,架构设计理念,架构的考虑要点,架构考虑的方向,总体架构分解：

按不同的业务领域、用户群来分解业务复杂性分配：

将业务需求分配到各个公司、部门、系统、服务系统/服务可独立部署和维护，它们之间多采用分布式交互,业务划分（总体架构）,业务划分（总体架构）,系统架构,系统架构分解：

按不同的技术层次来分解技术复杂性分配：

将技术需求分配到各个中间件、容器、框架、工具组件容器/框架通过特定的技术模式来透明或半透明地解决技术问题,系统细分,应用优化,局部调优（数据存取）分解：

按数据的位置、读写、计算特性等分解数据存取复杂性分配：

将数据分配到各个数据库、索引库、存储系统、Cache不同的存储技术适合于不同的数据存取需求,应用优化,总体架构考虑面向服务体系系统架构更加专业化、服务化的信息收集系统更加全面化、自动化的配置管理更加有效率的镜像同步、切换局部应用优化分布式文件系统优化数据同步系统读写分离,展望未来,架构随着业务发展不断演进架构发展要有方向有节奏,总结,End,