网站架构的不断衍变

对很多创业公司而言&＃xff0c;很难在初期就预估到流量十倍、百倍以及千倍以后网站架构会是什么样的一个状况。同时&＃xff0c;如果系统初期就设计一个千万级并发的流量架构&＃xff0c;很难有公司可以支撑这个成本。

因此&＃xff0c;这里主要会关注架构的眼花。在每个阶段&＃xff0c;找到对应该阶段网站架构所面临的问题&＃xff0c;然后在不断解决这些问题&＃xff0c;在这个过程中整个架构会一直演进。

在58同城建立之初&＃xff0c;站点的流量非常小&＃xff0c;可能也就是十万级别&＃xff0c;这也就意味着&＃xff0c;平均每秒钟也就是几次的访问&＃xff0c;此时网站架构的特点是&＃xff1a;请求量比较低&＃xff0c;数据量比较小&＃xff0c;代码量也比较小。这个时候的站点可以被几个工程师轻易搞定&＃xff0c;因此根本没什么“架构”可言。

其实这也是很多创业公司初期面临的问题&＃xff0c;最开始58同城的站点架构用一个词概括就是“ALL IN ONE”&＃xff0c;如下图所示&＃xff1a;

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

这里需要说明一个问题&＃xff0c;大家都知道最初58同城使用的是Windows、iis、SQL-Sever、C#这条路。现在很多创业公司可能就不会这么做。

如果可以重来&＃xff1f;那么会选择LAMP

很多创业的同学可能会想&＃xff0c;初期什么样的一个架构合适&＃xff1f; 如果重来&＃xff0c;站在现在这个角度上58会选择LAMP&＃xff0c;为什么&＃xff1f;首先是无须编译&＃xff0c;而且快速发布功能强大&＃xff0c;从前端到后端、数据库访问、业务逻辑处理等等全部可以搞定&＃xff0c;最重要都是成熟的开源产品&＃xff0c;完全免费的。如果使用LAMP搭建一个论坛&＃xff0c;两天的时间就足够了。所以&＃xff0c;如果在创业初期&＃xff0c;就尽量不要再使用Windows。

在这个阶段58同城面临的主要问题是什么&＃xff1f;其实就是招人&＃xff0c;最初工程师写CURD都容易出错。当时引进了DAO和ORM&＃xff0c;从而避免直接面对CURD语句&＃xff0c;而是面对工程师比较擅长的是面向对象&＃xff0c;能够极大的提高工作效率&＃xff0c;降低出错率。

中等规模&＃xff1a;流量跨过十万的阶段&＃xff0c;数据库成为瓶颈

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

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

在这个阶段&＃xff0c;系统的主要矛盾就是“站点耦合&＃43;读写延时”&＃xff0c;58同城是如何进行解耦&＃xff0c;如何缓解延时呢&＃xff1f;

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

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

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

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

大流量&＃xff1a;将整个Windows技术体系转向了Java体系

流量越来越大&＃xff0c;当流量超过一千多万时&＃xff0c;58同城面临的最大问题就是性能和成本。此前曾提到58同城最初的技术选型是Windows&＃xff0c;整个网站的性能变得非常之低。即使进行了业务拆分和一些优化&＃xff0c;依然解决不了这个问题&＃xff0c;所以当时做了一个非常艰难的决定&＃xff0c;就是转型&＃xff1a;将整个Windows技术体系转向了Java体系&＃xff0c;这涵盖了操作系统、数据库等多个维度。

其实&＃xff0c;现在很多大的互联网公司在流量从小到大的过程中都经历过转型&＃xff0c;包括京东、淘宝等等。对技术的要求越来越高&＃xff0c;任何一个站点都不能挂&＃xff0c;对站点的可用性要求也是越来越高。

就在这个时候&＃xff0c;58同城业务量也出现一个爆发期。于是招聘了很多工程师&＃xff0c;大家一起写越来越多的站点&＃xff0c;但是发现效率很低&＃xff0c;经常做一些重复性的工作&＃xff0c;比如参数解析等等。同时&＃xff0c;业务之间相互依赖&＃xff0c;无论是分类的子系统还是信息的子系统&＃xff0c;二手车业务、房产业务都要访问用户和信息等一些底层数据&＃xff0c;代码之间频繁的沟通&＃xff0c;效率也不可能很高。

问题随之而来&＃xff0c;站点数越来越多&＃xff0c;数据量越来越大&＃xff0c;机器数从最开始的几台上升到几百台的级别。那么如何提供整个架构的可用性呢&＃xff1f;首先&＃xff0c;在上层进行了一些改进和优化&＃xff0c;再做进一步的垂直拆分&＃xff0c;同时引入了Cache&＃xff0c;如下图所示&＃xff1a;

在架构的改进上&＃xff0c;这里构建了一个相对独立的服务层&＃xff0c;这个服务层做的每个业务线都会写对应的代码。如果用户发出请求&＃xff0c;就由这个服务层统一来管理&＃xff0c;所有的上游业务线就像调用本地函数一样&＃xff0c;通过IDC的框架来调用这个服务。整个用户登录先访问Cache&＃xff0c;如果Cache变动了就直接返回&＃xff0c;如果Cache不变动&＃xff0c;就会访问数据库&＃xff0c;这样把数据库的数据拿到本地再放回Cache&＃xff0c;再打回上一轮。如此一来&＃xff0c;业务逻辑全部封装在这个服务的上游管理&＃xff0c;该业务逻辑只有服务层能够编写代码&＃xff0c;然后由这个服务层集中管理、集中优化&＃xff0c;这样就提高了效率。

除此之外&＃xff0c;为了保证站点的高可用&＃xff0c;主要使用了反向代理技术。因为对用户而言&＃xff0c;他主要为了使用58同城的服务&＃xff0c;不会关注访问是58同城或者有十台首页的服务器。58同城通过反向代理技术&＃xff0c;通过DNS群&＃xff0c;通过LVS技术&＃xff0c;来保证接入层的高可用性&＃xff0c;同时还保证了服务层、站点层、数据层的高可用。另外&＃xff0c;为了保证高可用还使用了冗余的方法&＃xff0c;无论是站点服务和数据服务都可以使用这种方式进行解决&＃xff0c;一个站点不可用&＃xff0c;就换一个站点&＃xff0c;一个数据库不够用&＃xff0c;就多加几个。当然&＃xff0c;数据冗余也会带来一些副作用&＃xff0c;如果数据量更新的话&＃xff0c;那就需要将所有的“冗余”都要进行更新。

58同城也做了一个图片存储系统&＃xff0c;开始都是存储在操作系统之上&＃xff0c;随着新增站点、新增服务&＃xff0c;压力就变得越来越大。于是&＃xff0c;58同城就自建了站点框架和服务框架&＃xff0c;现在这两个框架也已经开源&＃xff08;如何降低站点开发成本&＃xff1f;https://github.com/58code/Argo 如何降低服务开发成本&＃xff1f; https://github.com/58code/Gaea &＃xff09;只需要修改一些基本的配置就可以使用了。

当架构变成“蜘蛛网”&＃xff0c;人肉已很难搞定&＃xff01;

随着用户量、数据量并发量进一步的增长&＃xff0c;58同城也拓展了很多的新业务&＃xff0c;那么对产品迭代速度要求就非常高&＃xff0c;整体的架构对自动化的要求越来越高。

为了支撑业务的发展&＃xff0c;技术团队对架构做了进一步的解耦&＃xff0c;另外就是引入了配置中心&＃xff0c;如果要访问任何一个服务&＃xff0c;不会直接在本地的配置中留下一个服务&＃xff0c;配置中心告诉这个服务的特点&＃xff0c;如果扩展的话&＃xff0c;配置中心自动下达消息&＃xff0c;如果有机器要下线的话&＃xff0c;配置中心会反向通过发邮件的方式进行通知。

而柔性服务是指当流量增加的时候&＃xff0c;自动的新增服务。可以看到进一步解耦之后&＃xff0c;有垂直业务、无线业务、集成业务等等&＃xff0c;这些子系统之间都是通过配置中心相应之间发生关系的。

另一点就是关于数据库&＃xff0c;当某一点成为一个业务线重点的时候&＃xff0c;就会集中解决这个点的问题。最初期的时候每个业务线都要访问数据库&＃xff0c;访问缓存&＃xff0c;访问用户数据&＃xff0c;于是把代码集中的放到了服务层。现在数据量越来越大&＃xff0c;大家都要做数据切分&＃xff0c;每个业务线都做切分&＃xff0c;这个时候58同城的每个页面都面对这样的痛点&＃xff0c;于是把这个痛点拿到集中的层面来解决。

最后一点就是效率矛盾&＃xff0c;此时有很多问题&＃xff0c;靠“人肉”已经很难进行搞定了。这就需要自动化&＃xff0c;包括回归、测试、运维、监控等等都要回归到自动化。

这里需要补充一点&＃xff0c;就是在产品层面引入了智能化&＃xff0c;比如说智能推荐&＃xff0c;主动推荐一些相关的话题&＃xff1b;智能广告&＃xff0c;通过一些智能的策略&＃xff0c;让用户对广告的点击更多&＃xff0c;增加对58同城的收录&＃xff1b;智能搜索&＃xff0c;在搜索的过程中加入一些搜索的策略&＃xff0c;可以提高搜索的权重&＃xff0c;也可以增加58同城的PV。当然&＃xff0c;所有的自动化的产品背后都是由技术在驱动。

未来的挑战

现在&＃xff0c;58同城的流量已经突破了10亿量级&＃xff0c;那么架构上未来面临哪些挑战呢&＃xff1f;一方面是无线化、移动化。另一方面就是需求的变化&＃xff0c;必须加快迭代一些东西。如果拥有10亿的流量&＃xff0c;却跑在一亿的架构上肯定是不行的。未来&＃xff0c;还会使用更多的并行计算、实时计算&＃xff0c;如果能做到实时推荐&＃xff0c;效果肯定非常好&＃xff0c;这也是挑战之一。最后一点&＃xff0c;58同城现在的服务器大概在3000台左右&＃xff0c;未来将拓展到10000台&＃xff0c;这就是运维的挑战了。

总结

最后做一个小的总结&＃xff0c;网站在不同的阶段遇到的问题不一样&＃xff0c;而解决这些问题使用的技术也不一样&＃xff0c;流量小的时候&＃xff0c;主要目的是提高开发效率&＃xff0c;在早期要引入ORM&＃xff0c;DAO这些技术。随着流量变大&＃xff0c;使用动静分离、读写分离、主从同步、垂直拆分、CDN、MVC等方式不断地提升网站稳定性。面对更大的流量时&＃xff0c;通过垂直拆分、服务化、反向代理、开发框架&＃xff08;站点/服务&＃xff09;等等&＃xff0c;不断提升高可用。在面对上亿级的更大流量时&＃xff0c;通过中心化、柔性服务、消息总线、自动化&＃xff08;回归&＃xff0c;测试&＃xff0c;运维&＃xff0c;监控&＃xff09;来迎接新的挑战。未来的就是继续实现移动化&＃xff0c;大数据实时计算&＃xff0c;平台化……系统架构会一直迭代衍变&＃xff0c;就像最初的从零到现在。