【从 0 开始学架构】学习笔记 Day3 互联网架构演化

一、架构演化发展阶段

第0阶段：最简单的互联网应用架构

问题

业务早期实验，探索业务模式是否被用户任何

作用

应用程序、数据库、文件系统，全部部署在一台服务器之上，适用于系统简单、用户量少的情况，尤其是业务早期作为实验，探索业务模式是否被用户认可

第1阶段：应用数据分离

问题

单一服务器计算资源不足的问题

计算资源包括CPU、内存、硬盘等

原理

应用程序部署在一台服务器，数据库服务和文件服务部署在另外的服务器上，为了解决应用程序和数据库服务抢占计算资源的问题，单台服务器的计算资源终究是有限的，将应用和数据进行分离

互联架构核心思路

不断增加服务器，提升系统处理能力，增加服务器分摊现有应用的计算资源

第2阶段：使用缓存改善系统性能

问题

硬盘访问速度较慢

原理

将访问频繁的读数据作为缓存，存储在高速的内存中，替代比较低速的硬盘，提高访问速度

应用系统访问缓存，获取数据信息，减少数据库访问压力，如果没有，再从数据服务器中获取数据，然后，再将数据缓存至缓存服务器中，进而提高访问速度

缓存可以分为本地缓存和远程缓存，用户使用的应用程序几乎使用了本地缓存，而远程缓存则通常建立分布式缓存系统

第3阶段：使用应用服务器集群改善系统的并发处理能力

问题

单一服务器面对高并发的问题

原理

部署多台应用服务器，构建应用服务器集群，通过负载均衡调度服务器进行用户请求分摊，高并发的情况，减少单一应用服务器的处理压力

第4阶段：数据库的读写分离

问题

数据库读写访问压力问题

原理

一定数量的数据，必须经过数据库访问获取，随着访问量的增加，数据库压力上升，此时，将数据库采用主从模式，主数据库负责写，从数据库负责读，并且主服务器要同步数据至从数据库，主从复制

第5阶段：使用反向代理和CDN加速网站响应

问题

静态资源与动态资源同时访问造成的系统压力

原理

应用程序是部署在数据中心

CDN（内容分发网络），部署在网络运营商机房的服务，将网络请求分发到数据中心，CDN缓存图片等静态资源，可以加快访问速度，减轻系统压力

用户请求到达数据中心，反向代理服务器作为第一层，依然作为缓存的使用，查看反向代理服务器有没有数据，有，则直接返回，没有，则向下请求负载均衡服务器

绝大部分请求，CDN返回，小部分中的绝大部分请求，通过反向代理服务器返回，只有小部分的小部分请求，到达数据中心

第6阶段：使用分布式文件系统和分布式数据库系统

问题

文件系统和数据库的容量问题

原理

之前阶段，数据库主从分离，数据库的存储能力并没有提高，同时，数据库的写操作只能在一台服务器进行，如果写操作非常多，那么，瓶颈就来了

使用分布式的关系数据库，将数据库进行分片处理，将写操作分摊到多台机器上处理，因此，可以处理的并发请求更多了，同时，数据库的存储能力得到提高

分布式文件服务器与分布式数据库服务器原理相同

第7阶段：使用NoSql和搜索引擎

问题

关系型数据自身的局限问题

原理

关系型数据库的模糊查找功能较差，可以使用搜索引擎和NoSql（MongDB）提供强大功能，提高查询速度，增强存储能力，分布式缓存服务功能在于数据缓存

第8阶段：业务拆分

问题

业务快速发展导致的复杂问题

原理

早期阶段，业务比较简单，随着发展，业务越来越复杂，因此，需要对业务进行拆分，应用之间可以通过 RPC 或者 HTTP 互相调用，也可以异步消息队列进行通信

第9阶段：微服务及中台化

问题

单纯业务拆分无法解决的业务复杂度问题

原理

各个系统都要编写相同的服务，冗余而且易出错，因此，把公共使用的服务抽象出来，建立一个独立的微服务集群

关键的服务由微服务架构提供支持

把更多的微服务统一调度起来，提供更加复杂和通用的产品和调用，各种产品都依赖这个统一调度的平台，这就是中台

第10阶段：大数据及智能化

问题

不同用户如何提供不同服务的问题

原理

不同的用户，会有不同的数据呈现，拥有不同的内容，也就是千人千面，通过大数据的数据挖掘，发现不同用户的偏好，发现内容之间的关联，为不同的用户推荐不同的内容，从而实现系统的智能化

智能化的前提就是大数据

二、架构技术演进模式

架构思维：演化思维，这也是正确的架构做事思维，根据场景寻找解决方案

1、互联网技术演进的推动力量

业务复杂性、用户规模

2、业务复杂度

（1）初创期

初创阶段业务的重点在于“创新”，思考如何留住第一波用户，不在于“完善”

这一时期对于技术的要求就是“快”，能买就买，就开源就开源

（2）发展期

经过初期市场验证业务可行，随着用户越来越多，进入业务快速发展时期，主要目的在于将原来不完善的业务逐渐完善，不断添加新功能

这个阶段技术的核心工作就是快速实现需求，符合业务发展需要

如何做到“快”？

1）堆功能期

业务进入快速发展期的初期，团队规模不大，业务需求紧张，最快实现业务功能就是在原有系统里面增加新功能，重构、优化、架构等工作心有余而力不足

2）优化期

系统越来越复杂，系统耦合性强，做一个需求，需要修改很多地方，导致开发效率低下。

如何解决问题，分两种思维，优化和架构。

优化的核心思想是将现有系统优化，如重构、分层、SQL查询优化，升级硬件，更换性能更好的软件，优势在于系统改动小，优化快速便于实施，但治标不治本

架构的核心思想就是调整系统，将大系统拆分为多个互相配合的小系统，如购物系统拆分为登录子系统、订单系统、查询系统等，优势是一次调整可以支撑比较长期的业务发展，缺点是动作较大、耗时较长，对业务发展影响比较大

3）架构期

优化已经无法达到要求，便开始进行架构调整，手段很多，核心就是“拆”，什么地方都可以拆，如拆功能、拆数据库、拆服务器

（3）竞争期

竞争对手的加入，催生新的业务创新，进而导致系统数量越来越多，引起技术工作的问题：

1）重复造轮子

系统越来越多，各系统相似的工作越来越多

2）系统交互一团乱麻

系统越来越多，各系统的交互关系变成了网状，系统间的交互数量和系统的数量成平方比的关系

针对问题，解决手段主要有：

平台化：解决重复造轮子问题，包括存储平台化、数据库平台化、缓存平台化

服务化：解决“系统交互”问题，常见做法通过消息队列完成系统间的异步通信，通过服务框架完成系统间的同步调用

（4）成熟期

企业进去成熟期，求快求新的空间不大，业务的主要精力转向“求精”

这个时候的技术优化没有固定的套路，只能按照竞争的要求，找出自己的弱项，然后逐项优化。在逐项优化时，可以采取之前各个时期采用的手段

3、用户规模

系统发展随着用户规模的不断增大，用户量的不断增多，技术要求主要体现在两个方面：性能要求越来越高、可用性要求越来越高

（1）性能

用户量增大给技术带来的第一个挑战就是性能要求越来越高，例如单台MySQL机器支撑的TPS和QPS最高也就是万级，低的可能是几千，高的也不过几万

（2）可用性

用户量增大对技术带来的第二个挑战就是可用性要求越来越高