大型网站架构体系的演变

文章出处来源

摘自 微信--IT搬运工
地址:http://mp.weixin.qq.com/s?__biz=MzAxNTI4NDAzNA==&mid=205960169&idx=1&sn=765e64eef36e5d459d69bbc11dd0c11d&key=c468684b929d2be2dea6dd3defba65255295bcd81d2374e6ab6b07547319d2760635b2617d8ccd8dcb448b446f3bd89e&ascene=0&uin=MTg0NTcyMzIwMQ%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.3+build(14D136)&version=11020012&pass_ticket=45gjHSy1JOgwVtPykwOGsVqBsD%2BucYl70CCFFCz0kTPASf%2BxYsdrvHw83SEwGjfr

  互联网上有很多关于网站架构的各种分享,有些主要是从运维和基础架构的角度去分析的(堆机器,做集群),太关注技术细节实现,普通的开发人员基本看不太懂。

本文上篇将主要介绍大型网站基础架构的扩展,下篇则重点从应用程序的角度去介绍网站架构的扩展和演变。

  草根时期,快速开发网站并上线。当然,通常只是先试水,用户规模也没有形成,经济能力和投入也非常有限。

有一定的业务量和用户规模了,想提升网站速度,于是,缓存出场了。

市场反响还不错,用户量每天在增长,数据库疯狂读写,逐渐发现一台服务器快撑不住了。于是,决定把DB和APP做分离。

单台数据库也感觉快撑不住了,一般都会尝试做“读写分离”。由于大部分互联网“读多写少”的特性所决定的。Salve的台数,取决于按业务评估的读写比例。

数据库层面是缓解了,但是应用程序层面也出现了瓶颈,由于访问量增大,加上早期程序员水平有限写的代码也很烂,人员流动性也大,很难去维护和优化。所以,很常用的办法还是“堆机器”。

加机器谁都会加,关键是加完之后得有效果,加完之后可能会引发一些问题。例如非常常见的:页面输出缓存和本地缓存的问题,Session保存的问题......

到这里,已经基本做到了DB层面和应用层面的横向扩展了,可以开始关注一些其它方面,例如:站内搜索的精准度,对DB的依赖,开始引入全文索引。

Java领域用的较多的是Lucene、Solr等,而php领域用的比较多的是sphinx/coreseek。

到目前为止,一个能够承载日均百万级访问量的中型网站架构基本介绍完了。当然,每一步扩展里面都会有很多技术实现的细节,后续有时间会写文章单独去剖析那些细节。

在做扩展满足了基本的性能需求后,我们会逐渐关注“可用性”(也就是我们通常听别人吹牛时说的SLA、几个9)。如何保证真正“高可用”,也是个难题。

几乎主流的大中型互联网公司,都会有用到类似的架构,只是节点数不同而已。

还有一招用的比较多的,那就是动静分离。可以需要开发人员配合(把静态资源放独立站点下),也可以不需要开发人员配合(利用7层反向代理来处理,根据后缀名等信息来判断资源类型)。有了单独的静态文件服务器之后,存储也是个问题,也需要扩展。多台服务器的文件怎么保持一致,买不起共享存储怎么办?分布式文件系统也派上用场了。

还有一项目前国内外用的非常普遍的技术CDN加速。目前该领域竞争激烈,也已经比较便宜了。国内南北互联网问题比较严重,使用CDN可以有效解决这个问题。

CDN的基本原理并不复杂,可以理解为智能DNS+Squid反向代理缓存 ,然后需要有很多机房节点提供访问。

截止目前为止,都没有怎么去改动应用程序的架构,或者说通俗点,都不怎么需要大面积的修改代码。

如果上面那些手段都用光了,还是支撑不住怎么办?不停的加机器也不是办法啊?

随着业务越来越复杂,网站的功能越来越多,虽然部署层面是采用的集群,但是应用程序架构层面还是“集中式”的,这样会导致很多耦合,不便于开发、维护,而且容易“一荣俱损”。所以,通常会把网站拆分出不同的子站点来单独宿主。

应用都拆了,由于单个数据库的连接,QPS,TPS,I/O处理能力都非常有限,DB层面也可以去做垂直分库操作

拆分应用和DB之后,其实还是会有很多问题。不同的站点,里面可能会有相同逻辑和功能的代码。当然,对于一些基础的功能我们可以封装DLL或者Jar包去到处提供引用,但是这种强依赖也很容易造成一些问题(版本问题、依赖关系等处理起来非常麻烦)。这样,传说中的SOA的价值就得到体现了。

应用、服务之间还是会出现一些依赖问题,这时候,高吞吐量的解耦利器出现了

最后,还介绍一个大型互联网公司都用的绝技--分库分表。个人经验,不是业务发站和各方面非常迫切,不要轻易走这一步。

因为分库分表谁都会干,关键是拆完之后怎么办。目前,市面上还没有完全开源免费的方案,能让你一劳永逸地解决数据库拆分问题。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏企鹅号快讯

C语言真的太强大了,C几乎无处不在!

今天存在的许多C项目都是在几十年前开始的。 UNIX操作系统的开发始于1969年,其代码在1972年被重写为C语言。C语言实际上是为了将UNIX内核代码从汇编语...

5087
来自专栏花叔的专栏

解读小程序用户信息授权机制的变动,为官方点赞

话说,有同学又问我为什么没有去解读微信小程序最新发布的特性。实在不好意思,最近花叔有点儿忙,所以就耽误了。 但这变动的意义其实比我们想象中大,所以虽然晚了点,还...

9597
来自专栏互联网数据官iCDO

【基础知识】现在很火的app上的deeplink技术,到底是什么?

主编前言: Deeplink,简单讲,就是你在手机上点击一个链接之后,可以直接链接到app内部的某个页面,而不是app正常打开时显示的首页。不似web,一个链接...

3.1K7
来自专栏架构师小秘圈

揭秘大型网站架构进化之路

丁浪,非著名架构师。关注高并发、高可用的架构设计,对系统服务化、分库分表、性能调优等方面有深入研究和丰富实践经验。热衷于技术研究和分享。 声明:版权归丁浪作者本...

4545
来自专栏FreeBuf

选个“靶子”练练手:15个漏洞测试网站带你飞

俗话说进攻是最好的防御,而这与信息安全世界并没有什么不同。通过这15个故意存漏洞网站来提升你的黑客技能,你会成为最好的防守者——无论你是一名开发人员、安全管理者...

3637
来自专栏直播系统源码

三大操作系统,直播APP源码的操作系统选择要怎样

Windows、 macOS和linux是现如今市面上比较流行的三大操作系统,一般来说我更推荐大家在直播APP源码的搭建上选择用linux系统搭建,为什么呢?一...

2282
来自专栏BIT泽清

2018年【开发者必看】金融p2p无资质上架app store已过审经历教程

自从国内上架金融理财贷款P2P类型的App必须要具备金融资质后,现在想要上架到App Store已经很难了,就算你有了资质还不一定能够。下面就给大家分享一下关于...

1.1K15
来自专栏Android开发实战

Android 一直怎样在速度上追赶 iOS

一直以来人们都有这样的印象,认为搭载iOS系统的iPhone一定比搭载Android系统的安卓手机流畅。潜移默化中,不少果粉甚至是普通吃瓜群众都形成了这样的思维...

892
来自专栏镁客网

微软Edge浏览器支持WebVR,小举动背后的“大阴谋”

1113
来自专栏北京马哥教育

Linux 与 Unix 到底有什么不同?

如果你是一名20多岁或30多岁的软件开发人员,那么你已成长在一个由Linux主导的世界中。数十年来,它一直是数据中心的重要参与者,尽管很难找到明确的操作系统市场...

1900

扫码关注云+社区

领取腾讯云代金券