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