____
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, 搜索引擎等等.
最后, 数据中台也有了.
所谓分久必合, 新三国成型了.
来源: https://www.cnblogs.com/yaomaomao/p/11882060.html