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

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

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了。
至于为何？
呵呵，一个字，贵。两个字，很贵。三个字，太贵了。

集群的好处有两个：一、缓解服务压力；二、高可用，其中一台坏了，另外一台还能够继续使用，给你恢复服务的机会。

通常软件演化到这里就完事了。

可是网站有个不同的地方，不少时候，都是读多写少。
点赞的、吃瓜的比上场评论的少不少对吧？

而读多的状况虽然经过缓存配置消化了一部分，但仍是有一部分读操做（缓存未命中、缓存过时）和所有的写操做会访问数据库。
因此在你的用户量又迅猛增长到必定规模时，又是数据库成为了咱们的瓶颈。

目前大部分数据库都是支持主从热备功能的，主数据库经过主从复制机制将数据更新同步到从数据库。
此时咱们的应用就能够建设专门的读、写数据库的访问模块，使数据库读写分离对应用透明。

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

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

为何要作CDN？
移动、电信、联通……，华东、华南、西南、西北……，网络环境复杂，每一个地区访问网站的速度都不太同样。
CDN跟反向代理是加速访问的一种手段，它们的基本原理都是缓存。
区别是CDN部署在网络厂商的机房，反向代理是部署在网站机房。
CDN跟反向的目的都是尽早返回数据给用户。

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

分布式数据库是一种最后手段，只有在单表数据很是庞大的时候才使用。
不少网站和软件根本用不到这一步，分布式数据库会带来更麻烦的复杂性。
网站更经常使用的手段是拆分业务，拆分不一样的业务应用，拆分不一样的业务库，部署在不一样的物理服务器上。

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

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

应用之间能够经过首页超连接创建关系，也能够经过消息队列进行数据分发，固然，最多的仍是访问同一个数据存储系统，来构成一个完整的系统。

这叫微服务。

随着业务拆分愈来愈小，应用愈来愈复杂，其中又出现了一些能够共用的服务。如用户管理、商品管理，那么就能够将这些共用的业务提取出来，独立部署。
用如今流行的话来讲，叫业务中台。

在技术上，你们又造了各类各样的轮子，解决的问题其实有不少共性。例如文件、图片的处理、数据的存储与搜索系统。
技术中台也有了。

在数据上，你们的系统由于拆分的越来越零碎，存储到了不一样的数据库中，又造成了一个个数据孤岛。把这些打通，作成数据仓库，分析用户画像岂不美哉？优惠券推送、大数据杀熟了解一下。
而在技术上，随着数据愈来愈多，数据存储和检索的技术需求也愈来愈高。因此咱们又会引用一些非关系型的技术如NoSQL、搜索引擎等等。
最后，数据中台也有了。

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

---

欢迎关注个人公众号：姚毛毛的博客

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

有技术，有情怀，有温度

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