一丶 单服务器-俗称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. 应用服务器间带宽问题，因为需要不断同步session数据。
- 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 可以很好的解决不同的地区的访问速度问题，反向代理则在服务器机房中缓存用户资源。
访问量越来越大，我们文件服务器也出现了瓶颈。
六丶 分布式文件系统
分布式文件系统
- 分布式文件系统如何不影响已部署在线上的业务访问？不能让某个图片突然访问不到呀
- 是否需要业务部门清洗数据？
- 是否需要重新做域名解析？
这个时候数据库又出现了瓶颈。
七丶数据垂直拆分
数据垂直拆分
数据库专库专用，如图Products、Users、Deal库。
解决写数据时，并发，量大的问题。
- 跨业务的事务？如何解决？使用分布式事务、去掉事务或不追求强事务
- 应用的配置项多了
- 如何跨库进行数据的join操作
这个时候，某个业务的数据表的数据量或者更新量达到了单个数据库的瓶颈。
八丶数据水平拆分
如图，我们把User拆成了User1和User2，将同一个表的数据拆分到两个数据库中，解决了单数据库的瓶颈。
- 水平拆分的策略都有哪些？各有什么优缺点？
- 水平拆分的时候如何清洗数据？
- SQL 的路由问题，需要知道某个 User 在哪个数据库上。
- 主键的策略会有不同。
- 假设我们系统中需要查询2017年4月份已经下单过的用户名的明细，而这些用户分布在user1和user2上，我们后台运营系统在展示时如何分页？
这个时候，公司对外部做了流量导入，我们应用中的搜索量飙升，继续演进。
九丶拆分搜索引擎
使用搜索引擎，解决数据查询问题。部分场景可使用 NoSQL 提高性能，开发数据统一访问模块，解决上层应用开发的数据源问题。如图data access module 可以访问数据库，搜索引擎，NoSQL。
总结
到这里，大型网站技术架构的原理与分析就结束了，，不足之处还望大家多多包涵！！觉得收获的话可以点个关注收藏转发一波喔，谢谢大佬们支持。（吹一波，233~~）
下面和大家交流几点编程的经验：
1、多写多敲代码，好的代码与扎实的基础知识一定是实践出来的
2丶 测试、测试再测试，如果你不彻底测试自己的代码，那恐怕你开发的就不只是代码，可能还会声名狼藉。
3丶 简化算法，代码如恶魔，在你完成编码后，应回头并且优化它。从长远来看，这里或那里一些的改进，会让后来的支持人员更加轻松。
欢迎关注“互联网架构师”，我们分享最有价值的互联网技术干货文章，助力您成为有思想的全栈架构师，我们只聊互联网、只聊架构，不聊其他！打造最有价值的架构师圈子和社区。
本公众号覆盖中国主要首席架构师、高级架构师、CTO、技术总监、技术负责人等人 群。分享最有价值的架构思想和内容。打造中国互联网圈最有价值的架构师圈子。
- 长按下方的二维码可以快速关注我们
