码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2017-04-18 17:08:44      阅读:177      评论:0      收藏:0      [点我收藏+]

标签:ddos   本质   前台   入口   阶段   组织架构   关联   工程   数据库访问   

文章摘录: ———————————————————————-

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

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

标签:ddos   本质   前台   入口   阶段   组织架构   关联   工程   数据库访问   

原文地址:http://www.cnblogs.com/firstdream/p/6728656.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!