对于很多创业公司来说，随着业务的增长，网站的流量也会经历不同的阶段。从10万流量到100万流量，再从100万流量到1000万甚至上亿流量，网站架构需要经历哪些变化？且听58同城技术委员会执行主席沉健在OneAPM技术公开课（以下演讲整理）中给出的答案：我在本次演讲中主要讲解，58同城的小流量，中-scaletraffic，大流量，甚至更大流量过程中架构是如何演进的？你遇到了什么问题？以及如何解决这些问题？好的架构不是设计出来的，而是进化出来的。对于很多创业公司来说，在早期，我们很难预料网站的结构在经过十倍、一百倍、一千倍的访问量后会发生变化。它是什么样的。当然，如果在初期就设计千万级并发的流量架构，成本会非常高，估计企业很难做到。所以，我们主要讲架构是怎么演进的。在每一个阶段，我们都会找到那个阶段网站架构所对应的问题，然后在不断解决这些问题的过程中，整个战略架构也在不断演进。其实在58同城成立之初，网站的访问量很小，大概在10万级别，也就是说平均每秒有好几次访问。此时的网站架构特点：请求量比较少，数据量比较少，代码量比较少。找几个工程师是可以的，搭建这样的站点轻而易举，完全没有“架构”可言。其实这也是很多创业公司在早期面临的问题。一开始，58同城的站点架构可以用一个词来概括为“ALLINONE”，如下图所示：它就像一个独立的系统，一切都部署在一台机器上，包括站点、数据库、文件等。工程师每天的核心工作就是CURD。前端传过来一些数据，然后业务逻辑层组装成一些CURD来访问数据库。数据库返回数据，数据组装成页面，最后返回给浏览器。相信很多创业团队一开始都是做类似的工作，每天写代码，写SQL，接口参数，访问数据等等。这里有一个问题需要解释一下。大家都知道58同城目前用的是Windows、iis、SQL-Sever、C#。今天的许多初创公司可能不会这样做。58桐城为何选择这条道路？原因是公司招聘的第一工程师和第二工程师只能做这个，所以只能走这条路。如果可以重来一次？那么很多会选择LAMP创业的同学可能会想，如果我们前期要做一个产品，应该用什么架构呢？如果重来一次，也许我们现在会选择LAMP，为什么？首先，无需编译，快速发布功能强大，从前端到后端，数据库访问，业务逻辑处理等都可以搞定，最重要的是开源产品是完全免费的。如果你用LAMP搭建一个论坛，两天就够了。因此，如果你处于创业初期，尽量不要再使用Windows技术系统。现阶段58同城面临的主要问题是什么？其实就是招人。很多工程师可能在再培训学校培训3个月后就上岗了，所以在写CURD的时候很容易出错。当时，我们引入了DAO和ORM。虽然那些培训了几个月的工程师可能不是特别擅长写CURD，但是他们的一些面向对象的程序引入了DAO和ORM，这样就不再直接面对CURD语句，会相对容易一些。因为工程师更擅长面向对象的数据，而不是CURD，我们当时就引入了ORM。一般来说，如果你现在的项目处于初期孵化阶段，DAO和ORM可以大大提高效率，并且可以降低出错的概率。中规模：当流量超过10万时，数据库已经成为瓶颈。随着58同城的快速成长，我们很快跨过了10万流量的阶段。主要需求是什么？网站可以正常访问，当然，如果速度快点就更好了。此时系统面临的问题包括：在流量高峰期很容易宕机，因为大量的请求会压在数据库上，数据库成为新的瓶颈，人多的时候，访问速度会很慢。这时候我们的机器数量也从一台变成了多台。目前的架构是分布式的，如下图所示：首先，我们使用了一些很常见的技术。一方面，我们将动态页面和静态页面分开。通过Web-Servre访问动态页面，图片等静态图像单独放置。在服务器上。还有一点就是读写分离。其实对于58.com或者大部分网站来说，一般来说都是读多写少。对于58同城来说，绝大多数用户是浏览信息的，只有少数用户是来发帖的。那么如何扩展整个站点架构的读请求呢？常用的是主从同步，读写分离。我们以前只有一个数据库，现在我们使用多个不同的数据库来提供服务。这样就扩展了读写，很快就解决了中等规模的数据访问问题。现阶段系统的主要矛盾是“站点耦合+读写延时”。58同城如何解耦缓解延迟？对于58同城来说，典型的业务场景就是首页，有发布信息的发布页，有信息聚合和标题聚合的列表页，还有点击标题的详情页，这些站点都是耦合在一起的一个程序，或者耦合在一个站点中，当我们一个站点出现问题时，整个站点都会因为耦合而出现问题。第二个问题，大家都知道数据库的读请求和写请求是分布在不同的数据库上的。这个时候再读的话，可能读到的是旧数据，因为读写有延迟。如果用户发了一个帖子，你马上去找，肯定找不到。可能的后果是两条消息将被一个接一个地发布。这是个大问题。尤其是当请求量越来越大的时候，这个问题就更加突出了。在解决这些问题时，首先想到的是将原站点的核心业务进行细分，然后工程师根据自己的站点和业务场景进行细分。首先，业务拆分是58同城尝试的第一个优化。我们将业务垂直拆分为主页和发布页面。另外，在数据库层面，我们也将大数据量拆分成小数据量。这样一来，读写延迟立即得到缓解。尤其是代码分层之后，站点耦合也得到了缓解，数据加载速度也提升了不少。当时也用到了一些技术，前面也提到了动态资源和静态资源的拆分。其中，我们对静态资源使用CDN服务，方便数据缓存和就近访问，访问速度得到明显提升。另外，我们还使用了MVC模型。擅长前端的做表现层，擅长协同逻辑的工程师做Contorller，擅长数据的做数据。效率会逐渐提高，最后是负载均衡技术。#p#大流量：整个Windows技术体系都转移到Java体系上了。流量越来越大。当流量超过1000万时，58同城面临的最大问题就是性能和成本。前面提到58.com最初的技术选择是Windows，大概是在2006年，当时整个网站的性能变得很低。即使进行了业务拆分和一些优化，我们仍然无法解决这个问题，所以我们当时做了一个非常艰难的决定，就是转型：我们将整个Windows技术体系切换到Java体系，涵盖了操作系统、数据库等尺寸。事实上，很多互联网大公司都在流量从小到大的过程中经历过转型，包括京东、淘宝等。对技术的要求越来越高，任何站点都不能挂，对站点可用性的要求也越来越高。此时，58的同城业务也经历了爆发期。于是我们招了很多工程师，大家一起写了越来越多的站点，但是发现效率很低，经常做一些参数分析等重复性的工作。同时，企业之间相互依存。无论是分类子系统还是信息子系统，二手车业务和房地产业务都必须接入用户、信息等一些底层数据。代码之间的频繁通信效率不高。.问题随之而来，站点数量增加，数据量增加，机器数量从最初的几台上升到数百台。那么如何提供整个架构的可用性呢？首先，我们在上层做了一些改进和优化，然后做了进一步的垂直拆分。同时，我们引入了Cache，如下图所示：在架构改进方面，我们构建了一个相对独立的服务层。这个服务层你做的每一行业务都会写相应的代码。如果用户发出请求，将由这个服务层统一管理，所有上游业务线都会像调用本地函数一样通过IDC框架调用这个服务。整个用户登录首先访问Cache。如果Cache发生变化，则直接返回。如果Cache没有变化，它就会访问数据库。这样就会把数据库中的数据取到本地再放回Cache中，再返回到上一轮。这样，所有的业务逻辑都封装在了这个服务的上游管理中。只有服务层可以为这个业务逻辑编写代码，然后服务层集中管理和优化，提高了效率。另外，为了保证网站的高可用，我们主要采用了反向代理技术。对于用户来说，他主要是想使用58同城的服务，并不关心自己访问的是58同城还是十个首页的服务器。58同程采用反向代理技术、DNS组、LVS技术保证接入层的高可用，以及服务层、站点层、数据层的高可用。另外，为了保证高可用，我们往往会采用冗余的方式。站点服务和数据服务都可以这样解决。如果一个站点不可用，我们将更改到另一个站点。如果一个数据库不够用，我们会再添加几个。当然，数据冗余也会带来一些副作用。如果更新数据量，则需要更新所有“冗余”。58同城还构建了图片存储系统，最初存储在操作系统上。随着新站点和新服务的增加，压力越来越大。因此，58同城搭建了自己的站点框架和服务框架，现在这两个框架也开源了（如何降低站点开发成本？https://github.com/58code/Argo如何降低服务开发成本？https：//github.com/58code/Gaea）只需要修改一些基本配置即可使用。当结构变成“蜘蛛网”时，人肉难对付！随着用户数量和并发数据量的进一步增加，58同城也拓展了很多新业务，因此对产品迭代速度的要求非常高，整体架构对自动化的要求也越来越高。为了支撑业务的发展，技术团队进一步对架构进行了解耦。另外，引入了配置中心。如果你想访问任何服务，你不会直接在本地配置中留下一个服务。配置中心告诉服务Features，如果扩容，配置中心会自动下发消息，如果有机器下线，配置中心会反向发邮件通知。灵活服务是指在流量增加时自动增加新的服务。可以看出，进一步解耦后，有垂直业务、无线业务、综合业务等，这些子系统通过配置中心相互关联。还有一点是关于数据库的。当某个点成为一个业务线的重点时，我们就会着重解决这个点的问题。一开始每个业务线都要访问数据库，访问缓存，访问用户数据，所以我们把代码集中在服务层。现在数据量越来越大，每个人都需要拆分数据，每个业务线都需要拆分。这个时候58同城的每个页面都面临着这样一个痛点，所以把这个痛点带到了一个集中的层面。解决。最后一点是效率的矛盾。这时候，很多问题已经很难靠“人肉”来解决了。这就需要自动化，包括回归、测试、运维、监控等回归自动化。这里需要补充的是，在产品层面，我们引入了智能，比如智能推荐，主动推荐一些相关的话题；集合；智能搜索，在搜索过程中加入一些搜索策略，可以增加搜索的权重，也可以增加58同城的PV。当然，所有的自动化产品都是由技术驱动的。未来挑战现在，58同城流量已经突破10亿量级，那么该架构未来将面临哪些挑战？一方面，它是无线和移动的。另一方面是需求有变化，有些东西我们要迭代的快一些。如果你有10亿的流量，在1亿的架构上肯定不行。未来我们会更多的使用并行计算和实时计算。如果能做到实时推荐，效果肯定会非常好。这也是我们的挑战。最后，58同城目前拥有约3000台服务器，未来将扩充至1亿台。这就是运维的挑战。总结：最后是一个小总结。网站在不同阶段遇到的问题是不同的，解决这些问题所采用的技术也是不同的。在流量不大的时候，我们的主要目的是提高开发效率。前期应该引入ORM，DAO这些技术。随着流量的增加，采用动静分离、读写分离、主从同步、垂直拆分、CDN、MVC等方式，不断提高网站的稳定性。面对更大的流量，通过垂直拆分、服务、反向代理、开发框架（站点/服务）等，不断提升高可用。面对亿级更大的流量，通过中心化、弹性服务、消息总线、自动化（回归、测试、运维、监控）来迎接新的挑战。未来是继续实现移动化、大数据实时计算、平台化……
