大型网站技术架构的原理与分析

相关阅读：

腾讯开发微信花了多少钱？真的技术难度这么大吗？难点在哪里？

鹿晗关晓彤公开恋情，是如何把微博服务器搞炸的？ 附大型网站高可用架构和解决方案

互联网技术(java框架、分布式、集群)干货视频大全，不看后悔！(免费下载)

一丶 单服务器-俗称all in one

all in one

从一个小网站说起。一台服务器也就足够了。文件服务器，数据库，还有应用都部署在一台机器，俗称ALL IN ONE。

随着我们用户越来越多，访问越来越大，硬盘，CPU，内存等都开始吃紧，一台服务器已经满足不了。

这个时候看一下下一步演进。

数据服务与应用服务分离

数据服务与应用服务分离

我们将数据服务和应用服务分离，给应用服务器配置更好的 CPU，内存。而给数据服务器配置更好更大的硬盘。

分离之后提高一定的可用性，例如Files Server挂了，我们还是可以操作应用和数据库等。

随着访问qps越来越高，降低接口访问时间，提高服务性能和并发，成为了我们下一个目标，发现有很多业务数据不需要每次都从数据库获取。

二丶使用缓存，包括本地缓存，远程缓存，远程分布式缓存

使用缓存

因为 80% 的业务访问都集中在 20% 的数据上，也就是我们经常说的28法则。如果我们能将这部分数据缓存下来，性能一下子就上来了。而缓存又分为两种：本地缓存和远程缓存缓存，以及远程分布式缓存，我们这里面的远程缓存图上画的是分布式的缓存集群(Cluster)。

三丶使用负载均衡，进行服务器集群

使用负载均衡，进行服务器集群

增加了负载均衡，服务器集群之后，我们可以横向扩展服务器，解决了服务器处理能力的瓶颈。

1. 负载均衡的调度策略都有哪些？

2.各有什么优缺点？

3. 各适合什么场景？

打个比方，我们有轮询，权重，地址散列，地址散列又分为原ip地址散列hash，目标ip地址散列hash，最少连接，加权最少连接，还有继续升级的很多种策略......

Session管理-Session Sticky粘滞会话：

打个比方就是如果我们每次吃饭都要保证我们用的是自己的碗筷，而只要我们在一家饭店里存着我们的碗筷，只要我们每次去这家饭店吃饭就好了。

对于同一个连接中的数据包，负载均衡会将其转发至后端固定的服务器进行处理。

解决了我们session共享的问题，但是它有什么缺点呢？

1.一台服务器运行的服务挂掉，或者重启，上面的 session 都没了。

2. 负载均衡器成了有状态的机器，为以后实现容灾造成了羁绊。

Session管理-Session 复制

就像我们在所有的饭店里都存一份自己的碗筷。我们随意去哪一家饭店吃饭都OK，不适合做大规模集群，适合机器不多的情况。

解决了我们session共享的问题，但是它有什么缺点呢？

1. 1. 应用服务器间带宽问题，因为需要不断同步session数据。

2. 2. 大量用户在线时，服务器占用内存过多。

Session管理-基于Cookie

打个比方，就是我们每次去饭店吃饭，都自己带着自己的碗筷。

解决了我们session共享的问题，但是它有什么缺点呢？

1.cookie 的长度限制。

2.cookie存于浏览器，安全性是一个问题。

Session管理-Session 服务器

打个比方，就是我们的碗筷都存在了一个庞大的橱柜里，我们去任何一家饭店吃饭，都可以从橱柜中拿到属于我们自己的碗筷。

解决了我们session共享的问题，这种方案需要思考哪些问题呢？

1. 保证 session 服务器的可用性，session服务器单点如何解决？

2.我们在写应用时需要做调整存储session的业务逻辑

打个比方，我们为了提高session server的可用性，可以继续给session server做集群。

四丶数据库读写分离

数据库读写分离

使用数据库提供的热备功能，将所有的读操作引入slave 服务器，因为数据库的读写分离了，所以，我们的应用程序也得做相应的变化。我们实现一个数据访问模块(图中的data access module)使上层写代码的人不知道读写分离的存在。这样多数据源读写分离就对业务代码没有了侵入。这里就引出了代码层次的演变。

五丶 使用反向代理和 CDN 加速网站响应

反向代理和 CDN 加速网站响应

使用 CDN 可以很好的解决不同的地区的访问速度问题，反向代理则在服务器机房中缓存用户资源。

访问量越来越大，我们文件服务器也出现了瓶颈。

六丶 分布式文件系统

分布式文件系统

1. 分布式文件系统如何不影响已部署在线上的业务访问？不能让某个图片突然访问不到呀

2. 是否需要业务部门清洗数据？

3. 是否需要重新做域名解析？

这个时候数据库又出现了瓶颈。

七丶数据垂直拆分

数据垂直拆分

数据库专库专用，如图Products、Users、Deal库。

解决写数据时，并发，量大的问题。

1. 跨业务的事务？如何解决？使用分布式事务、去掉事务或不追求强事务

2. 应用的配置项多了

3. 如何跨库进行数据的join操作

这个时候，某个业务的数据表的数据量或者更新量达到了单个数据库的瓶颈。

八丶数据水平拆分

如图，我们把User拆成了User1和User2，将同一个表的数据拆分到两个数据库中，解决了单数据库的瓶颈。

1. 水平拆分的策略都有哪些？各有什么优缺点？

2. 水平拆分的时候如何清洗数据？

3. SQL 的路由问题，需要知道某个 User 在哪个数据库上。

4. 主键的策略会有不同。

5. 假设我们系统中需要查询2017年4月份已经下单过的用户名的明细，而这些用户分布在user1和user2上，我们后台运营系统在展示时如何分页？

这个时候，公司对外部做了流量导入，我们应用中的搜索量飙升，继续演进。

九丶拆分搜索引擎

使用搜索引擎，解决数据查询问题。部分场景可使用 NoSQL 提高性能，开发数据统一访问模块，解决上层应用开发的数据源问题。如图data access module 可以访问数据库，搜索引擎，NoSQL。

总结

到这里，大型网站技术架构的原理与分析就结束了，，不足之处还望大家多多包涵！！觉得收获的话可以点个关注收藏转发一波喔，谢谢大佬们支持。（吹一波，233~~）

下面和大家交流几点编程的经验：

1、多写多敲代码，好的代码与扎实的基础知识一定是实践出来的

2丶 测试、测试再测试，如果你不彻底测试自己的代码，那恐怕你开发的就不只是代码，可能还会声名狼藉。

3丶 简化算法，代码如恶魔，在你完成编码后，应回头并且优化它。从长远来看，这里或那里一些的改进，会让后来的支持人员更加轻松。

看完本文有收获？请转发分享给更多人

---

欢迎关注“互联网架构师”，我们分享最有价值的互联网技术干货文章，助力您成为有思想的全栈架构师，我们只聊互联网、只聊架构，不聊其他！打造最有价值的架构师圈子和社区。

本公众号覆盖中国主要首席架构师、高级架构师、CTO、技术总监、技术负责人等人 群。分享最有价值的架构思想和内容。打造中国互联网圈最有价值的架构师圈子。

• 长按下方的二维码可以快速关注我们

• 

  如想加群讨论学习，请点击右下角的“加群学习”菜单入群