转载

58同城沈剑：好的架构不是设计出来的，而是演进出来的

对很多创业公司而言，随着业务的增长，网站的流量也会经历不同的阶段。从十万流量到一百万流量，再从一百万流量跨越到一千万甚至上亿的流量，网站的架构需要经历哪些变化？我们一起听听

58 同城的技术委员会执行主席沈剑在 OneAPM 技术公开课上的回答（以下演讲整理）：

本场演讲我主要阐述一下，58同城从小流量、中等规模流量、大流量，到更大的流量过程中，架构是怎么演进的？遇到了哪些问题？以及如何解决这些问题？

好的架构不是设计出来的而是演进出来的

对很多创业公司而言，在初期的时候，我们很难在初期就预估到流量十倍以后、百倍以后、一千倍以后网站的架构会变成什么样。当然，如果在最初的时期，就设计一个千万级并发的流量架构，那样的话，成本是也是非常之高的，估计很难有公司会这样做。

所以，我们主要来讲架构是如何进行演化的。我们在每个阶段，找到对应该阶段网站架构所面临的问题，然后在不断解决这些问题的过程中，整个战略的架构就是在不断的演进了。

其实，在 58 同城建立之初，站点的流量非常小，可能也就是是十万级别，这也就意味着，平均每秒钟也就是几次的访问。此时网站架构的特点：请求量是比较低，数据量比较小，代码量也比较小。可能找几个工程师，很容易就做一个这样的站点，根本没什么「架构」可言。

其实，这也是很多创业公司初期面临的问题，最开始58同城的站点架构用一个词概括就是「ALL IN ONE」，如下图所示：

58同城沈剑：好的架构不是设计出来的，而是演进出来的

就像一个单机系统，所有的东西都部署在一台机器上，包括站点、数据库、文件等等。而工程师每天的核心工作就是 CURD，前端传过来一些数据，然后业务逻辑层拼装成一些 CURD 访问数据库，数据库返回数据，数据拼装成页面，最终返回到浏览器。相信很多创业团队，初期做的工作也是类似，每天写代码，写 SQL、接口参数、访问数据等等。

这里需要说明一个问题，大家都知道目前 58 同城使用的是 Windows、iis、SQL-Sever、C# 这条路。现在很多创业公司可能就不会这么做。58 同城为什么当时选择了这条路？原因是公司招聘的第一个工程师和第二个工程师只会这个，所以只能走这条路。

如果可以重来？那么会选择LAMP

很多创业的同学可能会想，如果我们初期希望做一个产品的话，我们应该使用什么架构？如果让我们重来，可能我们现在会选 LAMP，为什么？首先是无须编译，而且快速发布功能强大，从前端到后端、数据库访问、业务逻辑处理等等全部可以搞定，最重要的是因为开源产品，是完全免费的。如果使用 LAMP 搭建一个论坛，两天的时间就很足够了。所以，如果在创业初期，就尽量不要再使用 Windows 的技术体系了。

58同城沈剑：好的架构不是设计出来的，而是演进出来的

在这个阶段 58 同城面临的主要问题是什么？其实就是招人。很多工程师可能都是再培训学校里培训了3月就过来上班，所以他们写 CURD 的话很容易出错。当时，我们引进了 DAO 和 ORM。虽然那些培训了几个月的工程师可能写CURD不是特别的擅长，但是他们写面向对象的一些程序引入了 DAO 和 ORM，让他们不再直接面对 CURD 语句，这样就会相对容易一些。因为工程师比较擅长的是面向对象的数据，不是 CURD，所以我们当时引入了 ORM，总的来说，如果大家现在的项目处于一个初期孵化的阶段，DAO 和 ORM 能够极大的提高效率，而且可以降低出错的概率。

中等规模：流量跨过十万的阶段，数据库成为瓶颈

随着 58 同城的高速增长，我们很快跨越了十万流量的阶段。主要需求是什么？网站能够正常访问，当然速度更快点就好了。而此时系统面临问题包括：在流量的高峰期容易宕机，因为大量的请求会压到数据库上，所以数据库成为新的瓶颈，而且人多的时候，访问速度会很慢。这时，我们的机器数量也从一台变成了多台。现在的架构就采用了分布式，如下图所示：

58同城沈剑：好的架构不是设计出来的，而是演进出来的

首先，我们使用了一些非常常见的技术，一方面是动静分离，动态的页面通过 Web-Servre 访问，静态的像图片等就单独放到了一些服务器上。另外一点就是读写分离。其实，对 58 同城或者说绝大部分的站点而言，一般来说都是读多写少。对 58 同城来说，绝大部分用户是访问信息，只有很少的用户过来发贴。那么如何扩展整个站点架构的读请求呢？常用的是主从同步，读写分离。我们原来只有一个数据库，现在使用多个不同的数据库提供服务，这样的话，就扩展了读写，很快就解决了中等规模下数据访问的问题。

在这个阶段，系统的主要矛盾就是「站点耦合+读写延时」，58 同城是如何进行解耦，如何缓解延时呢？

对 58 同城而言，典型业务场景是主页，发布信息有发布页，信息聚合、标题聚合有列表页，点开一个标题有详细页，而这些站点都是耦合在一个程序中的，或者说耦合在一个站点中的，当我们有一个站点出现问题的时候，整个站点就会因为耦合一起出问题。

58同城沈剑：好的架构不是设计出来的，而是演进出来的

第二个问题，大家都知道做数据库读请求和写请求，分布在不同的数据库上，这个时候如果再读取可能读到的是旧数据，因为读写有一个延时。如果有用户发帖子，马上去找的话肯定找不到，很可能带来的后果就是陆续在发布两条信息，这就是一个很大的问题。尤其是在请求量越来越大的时候，这个问题就更加突出。

在解决这些问题是，最先想到的是针对原来站点的核心业务做切分，然后工程师根据自己的站点和业务场景进行细分。首先，业务拆分是 58 同城最先尝试的优化。我们将业务垂直拆分成了首页和发布页。另外，在数据库层面，我们也随之进行了拆分，将大数据量拆分成一个个小的数据量。这样，读写延时就马上得到了缓解。尤其是在代码拆分成了不同的层面之后，站点耦合也得到了缓解，数据量加载速度也提升了很多。

58同城沈剑：好的架构不是设计出来的，而是演进出来的

当时，还使用了一些技术，前面也提到了对动态资源和静态资源进行拆分。其中，我们对静态资源使用了 CDN 服务，便于数据缓存和就近访问，访问速度得到很明显的提升。除此之外，我们还使用了 MVC 模式，擅长前端的去做展示层，擅长协作逻辑的工程师就做 Contorller，擅长数据的人就负责数据，效率就会逐步的提高，最后就是负载均衡技术。

正文到此结束