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

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

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、数据库的性能调优，有……

有技术，有情怀，有温度

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

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

12306.cn网站挂了”好文章收藏，引发的技术架构问题讨论。
12306.cn网站挂了,被全国人民骂了.我这两天也在思考这个事,我想以这个事来粗略地和大家讨论一下网站性能的问题.因为仓促,而且完全基于本人有限的经验和了解,所以,如果有什么问题还请大家一起讨论和指 ...
一文读懂ARM技术架构（转）
据BBC报道称,其最近获得的内部文件显示,英国芯片设计公司ARM已经告诉员工,必须暂停与华为的业务往来.在文件中,ARM指示员工暂停与华为及其子公司的"所有有效合同.支持津贴,以及任何尚未签 ...
技术：一文读懂ARM技术架构
本文转载自传感器技术据BBC报道称,其最近获得的内部文件显示,英国芯片设计公司ARM已经告诉员工,必须暂停与华为的业务往来.在文件中,ARM指示员工暂停与华为及其子公司的"所有有效合同.支 ...
大型网站系统架构演化之路（转）
前言一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思 ...
大型网站系统架构演化之路
前言一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思 ...
【转】大型网站系统架构演化之路
前言一个成熟的大型网站(如淘宝.天猫.腾讯等)的系统架构并不是一开始设计时就具备完整的高性能.高可用.高伸缩等特性的,它是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术 ...
大型网站技术架构的演讲之路
作者:翟志军原文:https://my.oschina.net/zjzhai/blog/389266 最近我在阅读2本关于大型网站架构的书:<大型网站技术架构--核心原理与案例分析>李智 ...
读-李智慧-大型网站技术架构：核心原理与案例分析
网站构架演进大型网站的特点架构演化历程价值观架构模式分层分割分布式集群缓存异步冗余自动化安全性能性能测试 web前端性能优化应用服务器性能优化存储性能优化可用性可 ...
《大型网站技术架构》读书笔记一：大型网站架构演化
来源:http://www.cnblogs.com/edisonchou/p/3773891.html 此篇已收录至<大型网站技术架构>读书笔记系列目录贴,点击访问该目录可获取更多内容. ...

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

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

最新文章

热门文章