八种架构演进
日升时奋斗，日落时自省
目录
1、单机架构
特征：应用服务和数据库服务器公用一台服务器
出现场景：访问量较小，单机可以满足，由于现在硬件的升级，所以一台服务器够支持很多请求
红色箭头表示请求访问，蓝色箭头表示响应
单机程序中，其实靠的不就是数据库信息的拉取嘛，但是数据库也不是不能去掉，光服务器负责所有操作（单机架构是比较常见架构使用）
一台主机的硬件资源是有上限的，CPU、内存、硬盘、网络每次请求都会收到一个请求，都是需要消耗上述的一些资源，现在一台主机都够用（不行了其实也可以增加硬件资源，但是肯定硬件资源不能在加了就开始使用分布式）
优点：部署简单、成本低
缺点：性能有严重平静、数据库和应用互相竞争资源
2、应用数据分离架构
特征：应用服务和数据库服务使用不同服务器
出现场景：单机架构存在严重的资源竞争，导致站点变慢
红色箭头表示请求访问，蓝色箭头表示响应
优点：成本相对可控、性能相比单机有提升、数据库单独隔离、不会因为应用把数据库搞坏，不至于数据库瘫痪
缺点：硬件成本变高、性能有瓶颈，无法对应海量并发（当前数据库仍然是要接收所有请求处理处理）
3、应用服务集群架构
特征：引入负载均衡，应用以集群方式运作
出现场景：单个应用不足以支持海量的并发请求，高并发的时候站点响应变慢
注：能接收请求量多到数千，多个应用服务器集群同时处理大量请求量（此处tomcat就是横向扩展）
注：如果请求量更大呢，其实也同样可以按照上面的方法，交给一个更大应用服务接收请求，不够再进行横向扩展（第一先交给上层管理，第二同层进行横向扩展）
红色箭头表示请求访问，蓝色箭头表示响应
注：根据需求而定不是说这样的架构一定好，能承载越多并发量就越适合当前，根据情况而定；对于图解有个解释，上面画的只是一个大概的图，实际上有了上层之后，下层就需要更多来接收，毕竟上层是负载均衡器，还是要给下层分配的
优点：
针对应用服务器
（1）高可用：应用满足高可用，不会一个服务出问题整个站点挂掉
（2）高性能：如果不是访问数据库，应用相关处理海量请求快速响应
（3）扩展能力：支持横向扩展
缺点：
针对数据库
（1）性能瓶颈：无法应对数据库的海量查询
（2）可用性：数据库是点单的，所以一旦崩溃就是整个系统挂掉
（3）运维成本高：扩展部署运维工作增加
（4）硬件成本高：说的就是F5这个硬件
4、读写分离/主从分离架构
特征：将数据库集群化，但是为了保证所取数据都是相同的，就让一个数据哭来下，剩下的小弟们跟随大哥进行同步；数据库服务器搭建主从集群，一主一从、也可以一主多从都可以，，数据哭主机负责写操作，从机只负责读操作
出现场景：数据库到达瓶颈，而互联网应用一般读多写少，数据库承载压力主要来源于读的请求你造成的，那么针对这样的情况把读操作和写操作分开
注：红色箭头表示请求是写操作；浅蓝色箭头表示读操作；紫色箭头表示写操作进行同步，同步给从库；蓝色箭头表示响应
优点：
针对请求访问
（1）读取性能提升
（2）读取操作为主数据库减轻了大部分请求的压力，写操作性能也得以提升
（3）可用性：一个数据库的坍塌不会给系统带来致命的伤害，提高了可用性
缺点：
针对热点数据
（1）读库虽然分担了很多请求量，但是它也会负载，热点数据的疯狂访问
（2）同步从库挂掉，或者延时，导致主库和从库数据有一定可能不一致
（3）服务器成本需要增加（添东西了，能不增加）
5、冷热分离架构
这里针对冷热数据进行解析：针对所谓数据都有常用数据，不常用数据，也就衍生出了“二八原则”，20%的热点数据，能满足80%的访问需求（不是说一定就是20%，按照业务需求来定夺分配，“一九”也不是没有）
特征：引入缓存，实行冷热分离，将热点数据放到缓存中快速响应
出现场景：海量的请求导致数据库负载过高，站点响应在度变慢，说明数据库已经开始吃力了；不足以提供较高的舒适度
优点：大幅度降低数据库的访问请求，性能提升非常明显（访问缓存相比访问数据库快）
缺点：
（1）涉及到缓存就会设想到缓存到来的相关问题，缓存击穿、缓存失败、缓存雪崩等问题
（2）服务器成本的提高
（3）业务量支持变大，数据库单库太大，单表个体太大还是会导致数据库查询很慢，导致数据库再度到达瓶颈期
6、垂直分库架构
特征：数据库的数据被拆分，数据库数据分布式存储，分布式处理，分布式查询，也可以理解为分布式数据库架构
出现场景：写操作比较多，单机库性能已经支持不了了，需要拆分数据库，数据表的数据量太多，操作压力大，需要进行分表，降低运维难度，就有了分布式数据库，库表本来也就支持分布式
分库分表：
垂直分库：是指按照业务功能模块进行分库，将不同的业务模块分别放在不同的物理数据库中，这样可以提高系统的性能和扩展性
水平分库：是指按照用户属性（地市或者ID的hash）进行分库，将全省划分为个大区，每个大区有一个物理数据库，这样可以提高系统的扩展性和性能
注：这里就不在往整个架构图中带入了，这里直接将常见到的应用带入到架构中，这些中间件都是可以支持分库操作，内部实现思想也基本如上
分布式数据库：
优点：数据库吞吐量大幅度提升，不再是瓶颈期
缺点：
（1）跨库join操作，分布式事务等问题，需要对应进行解决，目前的mpp都有解决对策
（2）数据库和缓存结合能够支持海量的请求，但是应用代码整体耦合，修改一行代码就需要连带修改很多，整体重新发布
7、微服务架构
特征：按照业务板块来分应用代码，是单个应用的职责更清晰，相互之间可以做到独立升级迭代
出现场景：场景不定全看自己对微服务的定位，这里针对几点进行评定
（1）扩展性差：应用程序不能轻松扩展，因为每次需要更新应用程序时，都必须重新构建整个系统
（2）持续开发困难一个很小的改动会惊动整个系统的代码连带改动，无法频繁并容易发布（这个是灵活性的体现）
（3）不可靠：一个功能不起作用了整个系统可能不能动
（4）代码维护比较吃力，都是在一起的，接手人需要了解整个系统才能每步修改
微服务体现：
架构演示：
注：图并没有画完，这里解释当我们找商品的时候，是可以去访问用户，返回用户信息之后，在去找商品，商品查找操作是一样的，先找缓存，如果缓存没有在找数据库
优点：
（1）灵活性高：服务独立测试、部署、升级、发布
（2）独立扩展：微服务将功能独立起来，各自扩展互不干扰
（3）提高容错性：一个服务问题，不会两边挂
（4）支持编程语言多
缺点：
（1）运维复杂度高：应用和服务的部署变得复杂，同一台服务器上不是多个服务还要解决运行环境冲突的问题，如果需要动态扩缩场景，需要水平扩展服务的性能，就需要在新增服务上准备运行环境（2）资源使用变多：独立一个微服务是需要消耗CPU和内存的
（3）处理故障困难：需要查查看不同的日志完成问题定位，每个都是独立的，如果出问题需要慢慢排查
8、容器编排架构
特征：借助容器化技术（Docker）将应用/服务可以打包为镜像，通过容器编排工具（k8s）来动态分布和部署镜像，服务以容器化方式运行
出现场景：
（1）微服务拆分细致，服务多部署工作量大，配置复杂容易出错
（2）微服务数量多扩缩容麻烦，而且容易出错，每次缩容后再扩容又需要重新配置服务对应的环境参数
（3）微服务之间运行环境可能冲突，需要更多的资源来进行部署或者通过修改配置来解决冲突
容器化举例：
这里就我们比较熟悉的Java一套体系来说 java应用涉及：java、jdk、centos7 但是我们放到服务器上一次一次放太麻烦了，docker可以直接打包这个三个体系称为一个体系，直接部署到服务器上
容器化体现：
容器编排架构：
红色箭头表示请求，蓝色箭头表示响应，紫色箭头表示去拿用户信息，浅蓝色箭头表示缓存没有，访问数据库
注：这里的图没有画完，同样是访问商品时拿到用户数据信息，再次进行数据访问，先访问缓存，数据不存在访问数据库
优点：
（1）部署运维简单快速：一条命令就可以完成几百个服务的部署或者扩缩容
（2）隔离性好：容器与容器之间文件系统，网络相互隔离，不会产生环境冲突
（3）支持滚动更新：版本间奇幻都可以通过一个命令完成升级或者回滚
缺点：
（1）技术栈变多，技术要求严格
（2）运维成本极高，机器不是随时都会面临如此的资源消耗，一般只会维持一段时间，剩余时间还是闲置状态，此时资源利用率低，推荐云厂商服务器解决问题
9、小结
注：最后压力给到了应用，但是并没有结束，应用的改动会影响整个系统的代码耦合性太高，导致运维部署发布都需要很多次，任务量很大（图太长了，不太会截，这里分开截，内容是连续的）
下面就有了微服务，微服务并没有解决运维任务量大的问题，微服务只是将代码解耦，能让开发更加便捷，各司其职互不影响，运维的麻烦还是经过docker容器化打包成镜像交给k8s进行编排降低运维的任务量