58同城架构演进

转自：

好架构是进化来的，不是设计来的（58架构演进）_w3cschool

好的架构是进化的，不是设计的(58架构进化)

良好的结构是进化而来的，而不是设计的----58沈健的核心内容：在58个城市流量从小到大的过程中，该结构是如何发展的？你遇到了什么问题？以及如何解决这些问题？核心观点：良好的结构不是设计的，而是进化的。如何进化：网站流量在不同阶段会遇到不同的问题，找出网站结构在相应阶段面临的主要问题。在不断解决这些问题的过程中，整个系统的结构将不断进化。如何进化，简而言之：找到主要矛盾，解决主要矛盾。第一章：车站建设之初

在车站建设之初，车站流量非常小，可能低于10万级。这意味着平均每秒只访问几次。请求量相对较低，数据量相对较小，代码量相对较小几个工程师在很短的时间内建立了这样一个系统，甚至没有考虑到结构的问题。与许多初创公司一样，最初58个城市的网站结构特征是ALL-IN-ONE”：

这是一个单机系统，所有网站、数据库和文件都部署在服务器上。工程师日常的核心工作是CURD，一些数据从浏览器端传输到分析GET/POST/COOKIE中传的数据组装成一些CURD的sql句子访问数据库，数据库返回数据，组装成页面，返回浏览器。我相信许多创业团队的工程师在早期也做了类似的工作。58个城市最初选择了微软技术系统：Windows、iis、SQL-Sever、C#如果我们再来，我们可能会选择LAMP系统。为什么选择？LAMP？LAMP无需编译，发布速度快，功能强大，社区活跃。可以从前端 后端 数据库访问 业务逻辑处理，免费开源。当公司变大时，没有人会来收钱（许多公司遭受了损失）。现在，如果你再次创业，强烈建议使用它LAMP。

工程师在段，工程师面临的主要问题是：写作CURD的sql句子很容易出错。我们在这个阶段介绍DAO和ORM，让工程师不再直接面对CURD的sql句子，但面对他们擅长的目标开发，大大提高了编码效率，降低了错误率。第二章：流量增加，数据库成为瓶颈

随着流量的增加，老板不仅要求有一个可见的网站，他希望网站能正常访问，当然，速度会更快。此时，系统面临的问题是：流量高峰时段容易停机，大量要求将压在数据库上，数据库已成为一个新的瓶颈，许多人平行访问网站非常卡。此时，我们的机器数量也从一台变为多台，我们的系统已经成为所谓的（伪）分布式架构：

我们使用了一些常见的优化方法：（1）动态和静态分离，动态页面通过Web-Server访问，静态文件，如图片，被放置在一个单独的文件服务器上；（2）读写分离，将落在数据库上的读写请求分配到不同的数据库服务器上；互联网上的大多数业务场景都读得越来越少。对于58个城市，绝大多数用户的需求是访问信息，搜索信息，只有少数用户发布。此时，读取性能很容易成为瓶颈，那么如何扩展整个网站架构的读取性能呢？常用的方法是主要从同步，增加从数据库。我们过去只有一个读取数据库，但现在有多个读取数据库，以提高读取性能。在这个阶段，该系统的主要矛盾是网站耦合 读写延迟。58个城市如何解决这两个问题？第一个问题是网站耦合。对于58个城市，典型的业务场景是：类别聚合主页、发布信息的发布页面、信息聚合列表页面、帖子内容的详细页面。当这些系统在一个网站中耦合时，整个数据库之间的问题就越明显，读写数据库的问题就越明显，读写数据库就越多，整个系统就越明显。

为了解决耦合问题，首先想到的是对核心业务进行划分，工程师也根据业务划分对系统进行划分：我们将业务垂直划分为主页、发布页面、列表页面和详细信息页面。此外，我们还在数据库层面进行了垂直拆分，减少了单个数据库的数据量，以缓解读写延迟。

同时，利用这些技术优化系统，提高R&D效率:(1)拆分动态资源和静态资源。我们使用静态资源CDN服务，用户就近访问，静态资源访问速度明显提高；(2)此外，我们还使用它MVC模式，擅长前端工程师做显示层，擅长业务逻辑的工程师做控制层，擅长数据的工程师做数据层，专人，研发效率和质量进一步提高。第三章：开源技术系统的全面转型

流量越来越大。当流量达到数百万甚至数千万时，网站面临的一个大问题是性能和成本的折衷。上述58个城市的最初技术选择是Windows，在这个阶段，我们进行了技术转型，全面转向开源技术：（1）操作系统转型Linux(2)数据库转型Mysql（3）web服务器转型Tomcat(4)语言开发转向Java事实上，许多互联网公司在流量从小到大的过程中也经历了类似的转型，如京东和淘宝。随着用户数量的增加，对网站可用性的要求也越来越高，机器的数量也从最初的数量增加到数百台。那么，如何确保整个系统的可用性呢？首先，我们在业务层进行了进一步的垂直拆分，并引入了它Cache，如下图所示：

在架构上，我们抽象了一个相对独立的服务层，通过这个服务层统一管理所有数据访问。上游业务线就像调用本地函数一样RPC该服务获取数据，服务层对上游屏蔽底层数据库和缓存的复杂性。

此外，为了确保网站的高可用性，我们使用了反向代理。什么是代理？代理是代表用户访问xxoo网站。什么是反向代理？反向代理代表58个网站，用户不必关注58个城市的哪个服务器，反向代理代表58个城市。58个城市通过反向代理，DNS轮询，LVS等技术，来保证接入层的高可用性。另外，为了保证服务层和数据层的高可用，我们采用了冗余的方法，单点服务不可用，我们就冗余服务，单点数据不可用，我们就冗余数据。这个阶段58同城进入了一个业务高速爆发期，短期内衍生出非常多的业务站点和服务。新增站点、新增服务每次都会做一些重复的事情，例如线程模型，消息队列，参数解析等等，于是，58同城就研发了自己的站点框架和服务框架，现在这两个框架也都已经开源：（1）站点框架Argo：https://github.com/58code/Argo(2)服务框架Gaea：https://github.com/58code/Gaea在这个阶段，为了进一步解耦系统，我们引入了配置中心和软 ** 和新闻总线。

引入配置中心，业务访问任何服务，不需要在当地配置文件中配置服务ip list，只需访问配置中心。这种方法具有很好的可扩展性。如果有机器离线，配置中心将反向通知上游订阅者，而无需更新本地配置文件。** 是指当流量增加时，自动扩展服务和网站。新闻总线也是解耦上下游呼叫关系的常用技术手段。机器越来越多。此时，依靠人肉很难解决许多系统问题，因此自动化变得越来越重要：自动化回归、自动化测试、自动化操作和维护、自动化监控等。最后，在这个阶段，我们引入了许多智能产品，如智能推荐和一些相关数据，以增加58个城市PV；智能广告，通过一些智能策略，让用户点击更多的广告，增加城市收入；智能搜索，在搜索过程中添加一些智能策略，提高用户点击率，提高58个城市PV。这些智能产品都是由技术驱动的。第四章:进一步挑战

现在，58个城市的流量已经达到了10亿元。我们计划在架构上做什么？有几个方向：（1）业务服务（2）多架构模式（3）平台（4）...

第五章：总结

最后，做一个简单的总结。网站在不同阶段遇到的问题不同，解决这些问题的技术也不同：（1）当流量较小时，我们应该提高开发效率，并在早期引入ORM，DAO；(2)流量变大，可采用动静分离、读写分离、主从同步、垂直分离CDN、MVC不断提高网站的性能和R&D效率；(3)面对更大的流量，可以通过垂直拆分、服务化、反向代理、开发框架(网站/服务)等方式不断提高可用性(R&D效率)；(4)面对数亿流量，通过配置中心和软 ** 、新闻总线、自动化(回归、测试、运维、监控)迎接新挑战；

.