转载

大型网站的演化之路——读《大型网站技术架构》

大型网站的演化之路——读《大型网站技术架构》

__

author:姚毛毛的博客 & 妖生

01 大型网站or软件有什么特点?

高并发、大流量,微信都日活10亿了

7×24的高可用,俗称的4个9(99.99%)

海量数据的存储与管理

全国甚至全球的用户分布,复杂网络

安全环境很差

需求变更频繁,需要快速迭代

最后,是渐进式的发展。

所有大型网站都是从一个小网站发展起来的。

好的网站与复杂的架构都是演化来的,而不是一开始就设计好的。

当年才出发的时候,谁也想不到微信可以日活十亿,最初的时候肯定也没有成千上万的服务器集群对不对。

02 最初与第一次的演化之路:应用与数据的分离

我们最初的小型网站是什么样的?

从逻辑上看,一个应用服务、一个数据库;从物理上看,一台服务器就搞定了。

在用户量增多后,我们开始需要将应用跟数据库分离。

那应用跟数据库所需要的服务器配置是一样的吗?

当然是NO。

应用需要处理更多的业务逻辑,所以需要好一点多一点的CPU。

数据库则要快速检索磁盘跟放置数据缓存,因此需要快一点的磁盘和大一点的内存。

当然,所有演进的目的都是想更高、更快、更强。只是有时候没法做到面面俱到,需要取舍。

03 第二次演进:缓存优化

恭喜你,网站优化了一次,体验变好了,用户也开始增多了,可是烦恼的又来了。

用户的增多,带来的数据库压力也大了,怎么办?

在IT行业甚至所有现实模型中都存在一个颠扑不破的真理,即二八原则。

在网站访问上也是如此,80%的业务访问总是集中在20%的数据上。

淘宝买东西就翻前面那么一点,淘宝已经为我们找好了信用好、成交量高的卖家;百度一下也就是翻前面那两三页,甚至一页里的前几条(如果没有广告的话);微博热搜吃瓜也就看前十吧,后面的你会一个个点过去吗?

那么,把这20%的数据缓存起来,是不是就可以减少数据库的访问压力,提高网站访问性能了?

YES。

那么,怎么缓存呢?

我们通常使用的缓存方案有两种,即应用服务器上的本地缓存,和独立的分布式缓存。

有什么优缺点?

本地缓存速度快些,但是受限于应用服务器的内存,且会导致与应用争用的情况。

独立的分布式缓存可以使用集群,速度稍慢,但也很快,基本只有网络IO的消耗;但是缺点就一个字:贵。因为需要购买独立的缓存服务器。

所以在现实中,有时候,我们有时并不会购买独立的缓存服务器,而是放在大内存的应用或数据库服务器上,设置好阈值,共用内存。

04 第三次演进:应用集群与数据库的集群和读写分离

哇,用了缓存后,访问数据好快啊。

可是用户又增多了,应用支撑不过来了怎么办?真是幸福的烦恼啊。

单台数据库是不是有宕机的危险啊?

唉,集群呗。花钱就完事了。

应用集群、数据库集群。

这也是我们当今的软件架构中最常用的部署方案。

通过负责均衡调度器(nginx、F5等),可以将用户请求通过轮询或者IP指定的方式,分发到应用服务器集群中的任意一台服务器上,缓解应用压力。

而数据库以Oracle为例,则是可以在生产服务器上安装RAC版本,而应用可以通过访问数据库的VIP(Virtual IP),或者JDBC集群访问的方式访问数据库。

但是在网站的应用开发中,则一般选择mysql的较多。虽然淘宝早期也是使用了Oracle,但是后期也转mysql了。

至于为什么?

呵呵,一个字,贵。两个字,很贵。三个字,太贵了。

集群的好处有两个:1、缓解服务压力;2、高可用,其中一台坏了,另一台还可以继续使用,给你恢复服务的机会。

一般软件演化到这里就完事了。

但是网站有个不一样的地方,很多时候,都是读多写少。

点赞的、吃瓜的比上场评论的少很多对吧?

而读多的情况虽然通过缓存配置消化了一部分,但还是有一部分读操作(缓存未命中、缓存过期)和全部的写操作会访问数据库。

所以在你的用户量又迅猛增加到一定规模时,又是数据库成为了我们的瓶颈。

目前大部分数据库都是支持主从热备功能的,主数据库通过主从复制机制将数据更新同步到从数据库。

此时我们的应用就可以建设专门的读、写数据库的访问模块,使数据库读写分离对应用透明。

有时我们甚至会将专门的查询模块剥离出来,成为另一个子系统。

05 不算演进的第四次演进:CDN与反向代理

为什么要做CDN?

移动、电信、联通……,华东、华南、西南、西北……,网络环境复杂,每个地区访问网站的速度都不太一样。

CDN跟反向代理是加速访问的一种手段,它们的基本原理都是缓存。

区别是CDN部署在网络厂商的机房,反向代理是部署在网站机房。

CDN跟反向的目的都是尽早返回数据给用户。

06 三国演义式的第五次演进:分布式演进、业务的拆分与合并

分布式数据库是一种最后手段,只有在单表数据非常庞大的时候才使用。

很多网站和软件根本用不到这一步,分布式数据库会带来更麻烦的复杂性。

网站更常用的手段是拆分业务,拆分不同的业务应用,拆分不同的业务库,部署在不同的物理服务器上。

这一招,在围棋上,叫分治。在三国里,叫合久必分。

以商城网站为例,可以将首页、店铺、订单、卖家、买家拆分不同的产品线,这其中不同的产品线又可以拆分多个应用,分归不同的业务团队管理。

应用之间可以通过首页超链接建立关系,也可以通过消息队列进行数据分发,当然,最多的还是访问同一个数据存储系统,来构成一个完整的系统。

这叫微服务。

随着业务拆分越来越小,应用越来越复杂,其中又出现了一些可以共用的服务。如用户管理、商品管理,那么就可以将这些共用的业务提取出来,独立部署。

用现在流行的话来说,叫业务中台。

在技术上,大家又造了各种各样的轮子,解决的问题其实有很多共性。例如文件、图片的处理、数据的存储与搜索系统。

技术中台也有了。

在数据上,大家的系统因为拆分的愈来愈零碎,存储到了不同的数据库中,又形成了一个个数据孤岛。把这些打通,做成数据仓库,分析用户画像岂不美哉?优惠券推送、大数据杀熟了解一下。

而在技术上,随着数据越来越多,数据存储和检索的技术需求也越来越高。所以我们又会引用一些非关系型的技术如NoSQL、搜索引擎等等。

最后,数据中台也有了。

所谓分久必合,新三国成型了。

欢迎关注我的公众号:姚毛毛的博客

这里有我的编程生涯感悟与总结,有Java、Linux、Oracle、mysql的相关技术,有工作中进行的架构设计实践和读书理论,有JVM、Linux、数据库的性能调优,有……

有技术,有情怀,有温度

欢迎关注我:姚毛毛& 妖生

大型网站的演化之路——读《大型网站技术架构》

原文  https://segmentfault.com/a/1190000021041998
正文到此结束
Loading...