eaby技术架构变迁

标签: eaby 技术 架构 | 发表时间:2014-05-13 07:44 | 作者:wyxhd2008
出处:http://blog.csdn.net


如果你对项目管理、系统架构有兴趣,请加微信订阅号“softjg”,加入这个PM、架构师的大家庭

 

最近在infoq上面看到 ebay介绍其系统架构变迁以及系统设计分享方面的讲座,其中陈述了ebay从1995年到2006年之间系统架构的变化过程。从这里,我们可以学习到许多宝贵的经验来设计一个大容量,高并发,分布式的系统。

ebay的系统架构的变迁主要经历了4个阶段,下面一幅图展现了ebay系统架构变迁的时间表

在ebay的V1版本,ebay采用的是FREEBSD + APACHE + PERL +DGBM,这是一个比较原始的模型,而且相对比较简单,操作系统,应用服务器,web服务器 以及 数据库服务器都是在同一台机器中,网络结构在物理上只有一层。整个网站有四个域名,每个域名对应不同的应用,每组应用对应一台服务器。

图表 1 ebayV1系统架构

随着业务量以及访问量的不断上升,ebay在1999年开始对架构进行升级,技术架构发生了较大的变化,这期间主要是从1999-2004年,而架构的版本号则从V2.0到V2.5 ,下面我们来看看Ebay V2.0技术架构

  • V2.0

² 开始采用ORACLE服务器,数据库服务器和web服务器分开,数据库独立部署到一台新的机器上面

² 程序逻辑上面已经开始分层,也就是我们常说的mvc3层结构:显示层、业务逻辑层、数据访问层,而在物理上面还是两层结构 web服务器 以及 数据库服务器

² 编程语言采用C++,那个时候java刚兴起,估计也没有其他好的语言选择了。

  • V2.1

² 每组应用对应多台服务器,而多台服务器组成一个 servler pool(服务池),通过一个负载均衡服务器来分别转发请求到不同的服务器

² 数据库部署到性能更加好的服务器上面

  • V2.2

² 增加了一台数据库服务器作为 备份服务器,防止失败

  • V2.3

这个版本只是对每个应用增加了更多的服务器,不断的进行server pool

  • V2.4

这个版本最大且最重要的改变就是对数据库进行垂直拆分,即把数据库按照不同的功能模块进行划分,例如交易库,会员库,帐务库

  • V2.5

这个版本在2.4的版本上面,对部分数据库进行读写分离,同时对Item(物品条目)数据库进行水平拆分,把Items按照不同的Categoty分配到不同的Categoty商品库里面,,这样大大的扩展了对Items数据库的访问性能。

图表 2 ebayV2系统架构

从上可以看出ebay V2的架构变迁,主要是通过服务器的添加,数据库的垂直拆分以及水平拆分,数据库的读写分离操作 来提高整个网站的性能。在web层,通过添加服务器来进行水平扩展,同时对应用服务功能进行垂直拆分,按照不同的业务功能划分到不同的系统。在数据库层面,进行了读写分离尝试,对数据库进行垂直拆分,同时把Items库按照Category进行水平拆分,这样做,分散了对产品库items的集中访问,不过需要在DAL层提供透明的访问机制,ebays这里貌似还并没有这个成熟的框架,同时不知道 分布式事务ebay在这个阶段是如何实现的。

  • V3

整个应用程序开发平台全部替换为j2ee平台,用java改写了整个网站。看来是一次比较大的工作。目的是为模块解耦 以及模块复用,从这里,我们可以看出java在开发复杂企业应用的优势。

V3版本在数据库层面上面做了更加优化的设计,ebay继续在数据库上面进行优化

垂直拆分数据库,按照 功能模块 拆分为更多的子库

水平拆分数据库,对同一类数据,按照key值的不同数据分配到不同的数据库中(具体水平分库的方式有多种,这里就不再介绍了。)在进行水平拆分数据库的时候,ebay也必须建立一套透明的DAL访问方式,必须提供透明的数据库访问机制以及透明的数据库路由功能,数据库的物理结构变更不会影响到代码的逻辑变动。

在这里,ebay也在数据库层给出了最佳实践:

² 尽量减少数据库CPU的消耗,例如不使用存储过程,只使用少量的触发器

² 减少数据库层面的逻辑功能,例如数据转化,组合,这些都放在逻辑层

² 减少动态SQL,主要是SQL中参数的动态生成功能,这一点,公司的DBA也在强调

² 尽可能的缩短数据库的事务时间,尽可能早的结束事物

² 尽可能的采用异步更新数据库方式,分散数据库的压力,例如消耗数据库时间的操作要放在夜间处理。

² 不使用分布式事务,看来分布式事务的确不使用高并发性的系统

在应用逻辑层面,ebay把系统按照功能划分成许多不同的模块,每个模块作为一个子系统,同时通过水平扩展子系统服务器数量来提高整个系统的伸缩性。

下面看看ebay在应用层面给出的最佳实践

² 保持应用层子系统完全是无状态的,可以水平进行无限扩展以提高伸缩性,通过负载均衡服务器均等分配到各个子系统的实例池里面。

² 尽可能的使用缓存,缓存能够减少数据库的压力,使用空间来换时间

² 严格划分系统的各个层面,表现层,业务逻辑层,服务集成层,DAO层,基础设施层。

在应用层的设计上面,ebay通过不同的功能划分了很多domain,每个domain只负责自己的功能的业务逻辑,domain与domain之间是不会依赖的,同时还会提供common domain 提供各个 domain之间的交互以及依赖,见下图:

由于ebay的数据库按照逻辑划分了很多不同的字库,那么ebay必须提供透明的访问数据库的能力,举个例子:ebay把Items按照categoray分成了很多sub items库,假如需要查询出来某一个用户所购买的所有Items,那么必须要查询所有的sub items库,把数据库组合出来,那么DAL层必须屏蔽数据库的物理结构,一次性的把所有的sub items库中对应的数据查询出来。而这个访问,对应用来说是透明的。应用不需要关注到底items有多少个子库。

总结:在大规模,高并发系统的设计中,最常用的技术就是分层和缓存,把一个业务流程垂直分解成几个系统,每个系统提供不同类型的服务,一个业务流程通过不同的服务组装起来,这就是SOA设计的思路吧。每个系统可以进行水平集群,提供无状态的服务,可以水平无线扩展,数据库层面,主要就是用到垂直分库,水平分库,读写分离,热备份等技术,提高数据库的读写能力。在应用层可以考虑使用集中式缓存或者分布式缓存来减少数据库的访问压力。

如果你对项目管理、系统架构有兴趣,请加微信订阅号“softjg”,加入这个PM、架构师的大家庭

作者:wyxhd2008 发表于2014-5-12 23:44:01 原文链接
阅读:110 评论:0 查看评论

相关 [eaby 技术 架构] 推荐:

eaby技术架构变迁

- - CSDN博客架构设计推荐文章
如果你对项目管理、系统架构有兴趣,请加微信订阅号“softjg”,加入这个PM、架构师的大家庭. 最近在infoq上面看到 ebay介绍其系统架构变迁以及系统设计分享方面的讲座,其中陈述了ebay从1995年到2006年之间系统架构的变化过程. 从这里,我们可以学习到许多宝贵的经验来设计一个大容量,高并发,分布式的系统.

应用架构和技术架构

- - 人月神话的BLOG
在这里再谈下应用架构和技术架构的关系和边界问题,这里的说明和标准的TOGAF会有一些区别,仅为个人理解的一些点滴记录. 首先再说下应用架构,应用架构是和业务架构有强烈的映射关系的一个架构,应用架构要说明的是整体企业内部信息化建设和规划应该分为哪些应用系统去建设,应用系统间的集成关系是如何的. 即我们常说的应用架构和应用集成架构.

Instagram的技术架构

- - 标点符
Instagram 被 Facebook 以10亿美金收购. 而在被Facebook收购前的一个月,整个团队才7名员工. 2011年: 3 位工程师. 2012年: 5 位工程师. 坚持 DRY(Don’t Repeat Yourself)原则. 使用通知/信号机制实现解耦. 我们大部分工作使用Python来完成,只有逼不得已的时候,才会用C.

业务架构、信息架构、技术架构三位一体

- -
        客户天天打电话要修改产品功能,简单的一个需求可能要做一个月. 产品越改越笨重,为了赶工期bug越来越多.         产品从初级版到现在已经四个年头,相关的程序员来去换了三批,在补丁上打补丁是常有的事,很多功能只是开了个头,换个项目经理就被遗忘. 我们总是害怕客户在这个产品上提出新的需求,只要客户还用得过去,能不改就不改.

架构面向服务的技术

- - 博客园_新闻
在其新作 《架构面向服务的技术》中,Philip Wik 总结了使用面向服务的技术搭建解决方案的三大阻力:. 如何在恰当的细节和抽象层次上为复杂的事物建模. 服务技术架构(Service Technology Architecture,后简称 STA)的基础元件是什么. 如何提升 STA 解决方案的速度和质量.

简记 YouPorn 的技术架构

- - 博客园_旁观者-郑昀
传说中占据整个互联网每秒流量2%、100Gb/s、300K queries/s的 YouPorn,关于它的 HAProxy->Varnish->Nginx->PHP-FPM->Symfony2->Doctrine->HAProxy->Redis, 郑昀简要记录几点:. 2012年2月开始,YouPorn 的主数据库正式切换为 Redis,取代了之前的 MySQL;.

Poppen.de的技术架构分享

- - 企业架构 - ITeye博客
网址:  http://www.javabloger.com/article/couchdb-erlang-rabbitmq-red5-linux-poppen-architecture.html. Poppen.de是一个德国的 交友/ 聊天/ 视频 的SNS网站, 部分内容. NSFW,网站采用了很多我们熟悉的技术,像Nginx ,MySQL,CouchDB,Erlang,Memcached的,RabbitMQ(消息服务器),采用了Graphite作为网站的系统监控,Red5作为视频服务,Tsung作为压力测试工具,选择的技术种类较多,还采用.

[原]技术架构组工作职责

- - KimmKing的技术博客
落地本部门的技术规划,负责本部门IT整体规划技术部分,指导重要项目的设计实现. 规范本部门的所有技术应用和开发内容,保障系统开发的有序、标准、一致性. 发展基础技术平台和完善通用组件,实现部门技术积累和IT资源高效复用. 解决各项目的技术难点、框架选型,保障项目开发的速度、效率、质量. 协助运维、安全和测试组的部分技术性工作,保障各组工作的顺利开展和技术积累.

技术架构组工作职责

- - zzm
落地本部门的技术规划,负责本部门IT整体规划技术部分,指导重要项目的设计实现. 规范本部门的所有技术应用和开发内容,保障系统开发的有序、标准、一致性. 发展基础技术平台和完善通用组件,实现部门技术积累和IT资源高效复用. 解决各项目的技术难点、框架选型,保障项目开发的速度、效率、质量. 协助运维、安全和测试组的部分技术性工作,保障各组工作的顺利开展和技术积累.

《大型网站技术架构》 笔记 - 架构篇

- - 码蜂笔记
第四章 瞬时响应:网站的高性能架构. 性能测试是性能优化的前提和基础,也是性能优化结果的检查和度量标准. 性能测试的指标有:响应时间、并发数、吞吐量、性能计数器. 网站性能优化的目的,除了改善用户体验的响应时间,还要尽量提升系统吞吐量,最大限度利用服务器资源. 4.2 Web 前端性能优化. 主要手段有优化浏览器访问、使用反向代理、CDN加速等.