解析：eBay的网站架构以及技术特点

ebay的技术架构变化ebay的系统架构变化主要经历了四个阶段。下图显示了ebayV1版ebay的ebay系统架构变化时间表。ebay使用FREEBSD APACHE PERL DGBM，这是一个相对原始的模型，相对简单，操作系统，应用服务器，web服务器和数据库服务器都在同一台机器中，网络结构在物理上只有一层。整个网站有四个域名，每个域名对应不同的应用程序，每组应用程序对应一个服务器。随着业务量和访问量的不断增加，ebayV1系统架构在1999年开始升级，技术架构发生了很大变化。在此期间，主要从1999年到2004年，架构的版本号从V2.0到V2.5。让我们来看看ebayV2.0技术架构V2.0开始使用ORACLE服务器。数据库服务器和web服务器分开，数据库独立部署到新机器上的程序逻辑已经开始分层，即mvc3层结构：显示层、业务逻辑层、数据访问层、物理或两层结构web服务器和数据库服务器编程语言使用c ，当时java刚刚兴起，估计没有其他好的语言选择。V2.1每组应用程序对应于多个服务器，多个服务器形成servlerpol（服务池），通过负载平衡服务器转发到不同的服务器数据库部署到性能更好的服务器V2.2添加数据库服务器作为备份服务器，防止失败V2.3版本只为每个应用程序添加更多的服务器，ServerpolV2.4版本最大、最重要的变化是垂直拆分数据库，即根据不同的功能模块划分数据库，如交易库、会员库、会计数据库V2.5版本在2.4版本中，读写和分离部分数据库，并水平拆分Item（项目项目）数据库，根据不同的Categoty将Items分配到不同的Categoty商品库中，从而大大扩展了Items数据库的访问性能。图表2ebayV2系统架构 从以上可以看出，ebayV2的架构变化主要是通过添加服务器、垂直数据库和水平数据库来提高整个网站的性能。图表2ebayV2系统架构 从以上可以看出，ebayV2的架构变化主要是通过添加服务器、垂直数据库和水平数据库的分离来提高整个网站的性能。在web层中，通过添加服务器进行水平扩展，并垂直分割应用服务功能，并根据不同的业务功能划分为不同的系统。在数据库层面，尝试阅读和写作分离，垂直分割数据库，同时根据category水平分割Items库，分散产品库items的集中访问，但需要在DAL层提供透明的访问机制，ebays似乎没有这个成熟的框架，同时不知道分布式事务ebay在这个阶段是如何实现的。 V3的整个应用程序开发平台都被j2ee平台取代，整个网站都被java改写。这似乎是一项相对较大的工作。目的是解耦模块和复用模块。从这里，我们可以看到java在开发复杂企业应用方面的优势。 V3版本在数据库层面进行了更优化的设计。ebay继续优化数据库上的垂直分割数据库，并根据功能模块将其分为更多的子库水平分割数据库。对于同一类数据，根据key值的不同数据分配到不同的数据库（具体的水平分割方法有很多，这里不再介绍。）ebay还必须建立一套透明的DAL访问模式，并提供透明的数据库访问机制和透明的数据库路由功能。数据库的物理结构变化不会影响代码的逻辑变化。 在这里，ebay也给出了数据库层的最佳实践：尽量减少数据库CPU的消耗，如不使用存储过程，只使用少量触发器来减少数据库层的逻辑功能，如数据转换、组合，这些在逻辑层减少动态SQL，主要是SQL参数的动态生成功能，公司DBA也强调尽可能缩短数据库的交易时间，尽早结束事情，尽可能采用异步更新数据库的方式，分散数据库的压力，如夜间处理消耗数据库时间的操作。不使用分布式事务，分布式事务似乎不使用高并发性系统在应用逻辑层面，ebay根据功能将系统划分为许多不同的模块，每个模块作为子系统，并通过水平扩展子系统服务器的数量来提高整个系统的可伸缩性。让我们来看看ebay在应用层面给出的最佳实践，以保持应用层子系统完全无状态。它可以在水平上无限扩展，以提高可伸缩性，并通过负载平衡服务器均匀分配到各子系统的实例池中。让我们来看看ebay在应用层面给出的最佳实践，以保持应用层子系统完全无状态。它可以在水平上无限扩展，以提高可伸缩性，并通过负载平衡服务器均匀分配到每个子系统的实例池中。缓存可以尽可能减少数据库的压力。使用空间可以改变时间，严格划分系统、性能层、业务逻辑层、服务集成层、DAO层和基础设施层的各个层次。在应用层的设计上，ebay通过不同的功能划分了很多domain，每个domain只负责自己功能的业务逻辑，domain和domain不依赖，还提供comondomain提供各个domain之间的互动和依赖，见下图:因为ebay的数据库按逻辑划分了很多不同的字库。然后ebay必须提供访问数据库的透明能力。例如，ebay根据categoray将Items划分为许多subitems库。如果需要查询用户购买的所有Items，则必须查询所有subitems库并组合数据库，然后DAL层必须屏蔽数据库的物理结构，一次性查询所有Subitems库中对应的数据。而且这个访问，对于应用程序来说是透明的。这种访问对应用程序来说是透明的。应用程序不需要注意items有多少个子库。ebay的结构特点：当一个网站开始时，可能每天只有几十个人访问或数百个，也许一个普通的服务器就足够了，db和应用程序可以放在一起，但随着用户的增加，业务的增加，服务器远远不够，自然想要添加服务器，系统应该跟随变化。多一台服务器可以减轻压力。这样就出现了业务分割和数据分割。其实要做到恰到好处并不容易。ebay根据业务功能水平划分应用程序和数据库。这在国内很多网站上都是这样做的，并不奇怪，但在水平划分功能后，单个功能应用程序的划分也有很多文章要做。如何划分，ebay的架构文档很久以前就谈到了这件事。根据业务水平划分数据库后，可以根据一定的规则划分表数，包括许多规则，可以根据主要业务生产者进行划分，所有数据都跟随生产者，至于什么规则可以表达自己的观点。Asynchronyeverywhere同步应用程序会带来强耦合，可用性保证差，尤其是用户体验极度失败。想象一下，如果一个网站的主页同步获取这么多业务信息，很大一部分用户都会流失。如果加上网络慢，蚊子睡觉的时候，人们还有时间看。其实分布式系统应该尽量使用异步处理。EBay的应对策略是：事件驱动和pipeline、多播新闻涉及的技术有:消息中间件(无序，至少一次到达)、基于SRM技术的可靠多播。Automateeeverything配置信息的动态化涉及技术：配置发布/订阅机制的实现和机器学习。不知道国内有多少网站做到了这个超级牛，听说淘宝做到了(呵呵)。现在很多网站都在做RemembereverythingFails故障检测和回滚，但是ebay做得很好，ebay几乎每天都有2TB日志，淘宝也通过监控事件做出了有效的判断和预警。eBay的应对策略是：异常后发送消息，接收者获取消息报警，根据功能降级，以确保核心功能的可用性。涉及的技术包括：消息中间件以及如何根据功能降级。事实上，EmbraceInconsistency有点像我们整天所说的“拥抱变化”。如果系统中的事务太多，会对性能产生很大的影响，尤其是分布式事务。如果盲目追求一致性，性能会很严重。ebay的做法是过程不一致，最终一致。涉及的技术包括：新闻中间件，CAP(Consistency的一致性；Availability的可用性；ToleranceofnetworkPartition分区的容忍度(可以理解为系统在某些节点故障或节点之间的连接故障下仍能正常工作)等。) Expect(R)ebay在evolution这里主要讲的是如何更好地应对变化，EBay的应对策略包括功能演变和架构演变：灵活的schema、可插拔处理流程和增量系统发布的技术相当复杂。EBay采用配置处理流程和系统发布流程，支持多版本共存。随着分布式应用、异步应用和功能的不断增加，DependenciesMatter会变得更加明显，EBay也是如此。随着分布式应用、异步应用和功能的不断增加，dependenciesmatter变得更加明显，ebay也是如此。他们的应对策略:服务拓扑管理和设计控制(只允许依赖……)、客户端负责。说到这一点，我不得不说，客户端承担责任真的很重要。现在很多架构都喜欢在服务端解决N个以上的问题，但在很多情况下，客户端确实需要这样做。当然，这也会带来一些问题，比如升级。结论：在大规模、高并发系统的设计中，最常用的技术是分层和缓存，将业务流程垂直分解为多个系统，每个系统提供不同类型的服务，通过不同的服务组装业务流程，这就是SOA设计的理念。各系统可进行水平集群、无状态服务、水平无线扩展、数据库层面，主要采用垂直库、水平库、读写分离、热备份等技术，提高数据库的读写能力。在应用层中，可以考虑使用集中缓存或分布式缓存来降低数据库的访问压力。