[2016-03-18] [架构] 读《58同城沈剑：好的架构不是设计出来的，而是演进出来的》

Posted 2020-09-12 有梦就能实现

文章摘录： ———————————————————————-

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

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

最开始58同城的站点架构用一个词概括就是「ALL IN ONE」

如果可以重来？那么会选择LAMP。首先是无须编译，而且快速发布功能强大，从前端到后端、数据库访问、业务逻辑处理等等全部可以搞定，最重要的是因为开源产品，是完全免 费的。

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

主要需求是什么？网站能够正常访问，当然速度更快点就好了。

而此时系统面临问题包括：在流量的高峰期容易 宕机，因为大量的请求会压到数据库上，所以数据库成为新的瓶颈，而且人多的时候，访问速度会很慢。

首先。我们使用了一些非常常见的技术，一方面是动静分离，动态的页面通过 Web-Servre 访问，静态的像图片等就单独放到了一些服务器上。

另外一点就是读写分离。

在这个阶段，系统的主要矛盾就是「站点耦合+读写延时」，58 同城是如何进行解耦，如何缓解延时呢？解决这些问题是，最先想到的是针对原来站点的核心业务做切分

前面也提到了对动态资源和静态资源进行拆分。其中，我们对静态资源使用了 CDN 服务，便于数据缓存和就近访问，访问速度得到很明显的提升。

量越来越大，当流量超过一千多万时，58 同城面对最大的问题就是性能和成本。

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

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

在 架构的改进上，我们构建了一个相对独立的服务层，这个服务层做的每个业务线都会写对应的代码

当架构变成「蜘蛛网」，人肉已很难搞定！

为 了支撑业务的发展，技术团队对架构做了进一步的解耦，另外就是引入了配置中心

未来的挑战

现在，58同城的流量已经突破的 10 亿的量级，那么架构上未来面临哪些挑战呢？一方面是无线化、移动化。另一方面就是需求的变化，我们必须加快迭代一些东西。如果拥有10亿的流量，却跑在一 亿的架构上肯定是不行的。

未来，我们会使用更多的并行计算、实时计算，如果能做到实时推荐，效果肯定非常好，这也是我们的挑战。最后一点，58同城现在的 服务器大概在3000台左右，未来将拓展到 10000 万，这就是运维的挑战了。

———————————————————————-

个人小结：

1、一般网站会经历1万、100万、1000万、10亿、10亿+等几个阶段，但是根据网站业务复杂度不同，此值只是参考值，但总体上，包括初创期、成长期、快速发展期、成熟期等，对于每个阶段需要特定的架构设计支撑。

1）初创期。

关键词：All In One/系统可用/快速开发 流量在1万/天，即平均每分5到6次访问，峰值每份15次左右。 目前网站业务也处于雏形期，技术的重点是需要快速满足业务开发需求，推动业务快速开展。 网站可以放在一台机器上，保证系统相对稳定即可。 做好数据和程序备份，随时可以重新构建。

2）成长期。

关键词：稳定性/架构/拆分/CDN/监控/ 流量在100万/天，即平均每分60次访问，峰值每分100次以上。 业务开始走上正轨，技术在快速满足业务开发需要的同时，要考虑系统架构优化和调整。 保证系统高可用速度相对有所提升。 技术调整主要包括： a.应用和数据拆分，就是把数据库拉出去独立部署。 b.session共享应用多节点（至少两个）。 c.静态资源上CDN，构建独立文件服务器。（如果速度需要有所提升） d.技术组织架构调整，分为业务产品开发和系统开发，就是说有人重点面对业务需求，有人重点优化基础系统。 e.建立开发规则/规范/流程，尽可能减少技术债务。

3）快速成长期。

关键词：分布式/消息队列/缓存/安全/解耦/服务化/集群/高可用/ 流量在1000万/天，即平均每秒100次访问，峰值每秒200次左右。 业务开始快速扩张，同时会带来大量功能需求开发，蜘蛛开始结网阶段，相互依赖、交叉调用、代码冗余、数据庞大等等。 开始考虑构建业务架构和系统架构雏形。 业务架构需要资深开发和资深运营共同参与设计。从产品特性、依赖、关联等方面入手，包括从用户入口到服务结束整个流程体系和架构。 系统架构需要业务架构和系统架构一起设计。从可用性、稳定性、扩展性、安全性等方面入手。说白了就是该拆分的拆分，该收敛的收敛，该聚合的聚合。 业务架构设计（如B2C电商）： a.用户（登录注册密码、第三方、地址、订单、收藏、评论、投诉、卡券/积分） b.产品（分类目录、列表、详情、活动、筛选） c.交易（购物车、支付、订单、退换货） d.物流（采购、发货、库存、跟踪、退换货） f.数据（搜索、推荐、历史、消息通知）

系统架构设计： a.这时的系统架构水平可以分为：前端、应用、服务、数据四个层，垂直可分为：前台、后台、配置管理、日志中心、运维监控、数据分析与处理 b.前端层增加LB负载均衡、DDos预防、流量控制等。 c.应用层需要拆分应用为各个独立app，降低耦合，提高性能，提升开发效率。 d.抽象独立服务构建服务层，如搜索、统计、消息、session服务、配置中心等。 e.数据库开始成为瓶颈，考虑数据库垂直拆分，前置缓存等。

4）成熟期。

关键词：稳定性/成本/自动化/可伸缩/可配置/开源共享/产品化/技术沉淀 流量稳定在1亿/天级别，即平均每秒千次访问，峰值每秒5k+次。 业务趋于稳定，研发开始进入休整期，应用、系统、数据开始进入完善优化整理阶段，技术需要沉淀，开始技术推动业务发展。 各个组件模块专业性优化，核心技术抽离趋向通用化 技术完善： a.技术体系T型发展，一切向稳定靠拢。 b.关键点优化，通过技术手段降低研发成本，如去IOE，自动化等。 c.技术深入探究，用技术推动业务发展。

总之，任何所谓的架构一定是依托公司特有的业务模式逐渐演变而来的，不是一蹴而就设计出来的，之所以会成为现在这个模样，一定有其道理和原因。

整个演变过程基本原理就是聚合-拆分-聚合的过程，其本质就是时间和空间问题。

http://developer.51cto.com/art/201510/494827.htm