前言
那么这里博主先安利一些干货满满的专栏了！
首先是博主的高质量博客的汇总，这个专栏里面的博客，都是博主最最用心写的一部分，干货满满，希望对大家有帮助。
- 高质量博客汇总
然后就是博主最近最花时间的一个专栏《Docker从认识到实践再到底层原理》希望大家多多关注！
- Docker从认识到实践再到底层原理
博客参考：比特就业课
第一章-技术架构
单机架构
简介
所有的服务都部署到一台服务器上。
简单来说，就是全部都放在一台服务器上。
出现原因
在互联网初期，使用量有限，一个单机服务器架构就能够满足要求。
技术案例
相关软件：
-
Web 服务器软件: Tomcat、Netty、Nginx、Apache 等
-
数据库软件:MySQL、Oracle、PostgreSQL、SQL Server 等
架构优缺点
优势在于配置简便、开销较小，但劣势则在于会面临明显的性能限制，数据库和应用程序会相互争夺资源。
应用数据分离架构
简介
很简单，就是应用服务和数据库服务使用不同的服务器。
注意，数据库和应用之间多了一条线，这条线就是网络。
出现原因
由于资源竞争激烈，单机情况下可能导致网站响应速度减缓。
架构工作原理
DNS返回的是应用服务器的ip，然后应用服务器再去数据库服务里面去找。
优缺点
-
优点：经济可控性较高，性能比单机模式好，在数据库独立隔离方面表现出色，应用故障不会对数据库造成影响，还具备一定的容错能力。
-
缺点：硬件投入增加，性能上存在限制，难以应对大规模高并发需求。
应用服务集群架构
简介
引入了负载均衡，应用是以集群方式运作的。
出现原因
一台应用服务器，不能扛得住高并发，高并发的话容易崩。
架构工作原理
如示意图所展示的情景，采用多个应用服务器的布局方案，以减轻高并发压力。
**负载均衡的意义：**为了解决将用户请求分配到哪个应用服务器的问题，需要引入专用的系统组件来进行流量分发。在实际应用中，负载均衡的范围不仅仅限于应用层，还可以涵盖其他网络层。
同时，负载均衡算法有多种类型，以下是几种常见的简要介绍：
- 轮询算法（Round-Robin）： 将请求公平地依次分配给不同的应用服务器，确保公正性。
- 加权轮询算法（Weight-Round-Robin）： 根据服务器性能等因素分配不同的权重，使性能较好的服务器分配更多的请求。
- 一致性哈希算法： 通过计算用户特征（例如 IP 地址）得到哈希值，根据哈希结果进行请求分发。这种方法的优势在于，相同用户的请求总是被分配给同一台服务器，类似于我们常见的专属客户代表服务。
这种布局的好处在于可以有效地应对高并发情况，确保系统的稳定性和响应速度。
DNS如何做负载均衡呢？
我们知道DNS可以通过域名返回ip地址。
比如我要访问www.taobao.com, 第一次我返回ip1，表示第一个LVS，第二次返回ip2，表示第二个LVS… 以此类推。DNS也可以完成负载均衡的工作了。
优缺点
优势：文章来源：https://www.toymoban.com/news/detail-683589.html
- 保障应用服务的持续可用性：即便某个应用服务器发生故障，整个网站不会因此而崩溃。
- 具备一定的高性能表现：在无需访问数据库的情况下（如已有缓存数据），能够快速响应大量请求。
- 具备一定的横向扩展能力：通过横向增加服务器数量来实现系统的扩展。
劣势：文章来源地址https://www.toymoban.com/news/detail-683589.html
- 数据库性能成为瓶颈：由于只有一个数据库，当多个用户同时请求数据时，数据库可能会面临性能问题。
- 数据库是单一服务器的独立架构，缺乏高可用性。
- 增加运维负担：随着扩展部署，运维任务也增加，需要开发相应工具来解决快速部署的挑战。
- 需要承担较高的硬件成本。
读写分离/主从分离架构
简介
通过将数据库的读写任务分配到不同的节点上，我们建立了数据库服务器的主从集群。在这个集群中，通常会配置一个主节点和一个或多个从节点，也可以是一个主节点和多个从节点。在这种架构中，主数据库负责处理写操作，而从数据库则专注于处理读操作。
出现原因
数据库成为瓶颈的情况下，特别是在互联网应用中，读操作通常明显多于写操作。这种情况下，数据库因为处理大量读请求而承受巨大压力。因此，我们可以将读写操作分离，以应对这一挑战。
架构工作原理
如果是写操作，就访问主数据库，然后更改完之后，将数据同步到所有的从数据库中。
如果是读操作，就访问从数据库即可。
这种中间组件常见的有：MyCat、TDDL、Amoeba、Cobar 等
优缺点
优点：
- 数据库读取性能提升
- 读取被其他服务器分担，写的性能间接提升
- 数据库有从库，数据库的可用性能高了
缺点：
- 热点数据的频繁读取导致数据库负载会很高
- 当同步挂掉，或者同步延迟比较大时，写库和读库的数据不一致
- 服务器成本需要进一步增加
冷热分离架构
简介
引入缓存，实行冷热分离，将热点数据放到缓存中快速响应
出现原因
海量的请求导致数据库负载过高，站点响应再度变慢。
架构工作原理
热点数据直接找缓存，不要去找数据库了。
写入的时候缓存和数据库都要写入！而且只能保证同时成功或者同时失败（软件可以做到）
读取的时候，如果缓存中有就直接在缓存中读，如果没有，就去数据库读。
架构优缺点
优势：
- 明显提升性能：通过分离读写操作，显著减轻了对数据库的访问负担。
缺陷：
- 引发缓存相关问题：此举可能导致一致性问题、缓存击穿、缓存失效以及缓存雪崩等困扰。
- 增加服务器开销：实施该策略可能需要投入更多成本用于服务器设备。
- 业务规模扩大后可能遇到问题：随着业务体量增大，数据量持续增加，可能导致数据库规模过大，单个表数据过于庞大，从而影响查询性能，使数据库再次成为瓶颈。
垂直分库架构（分布式数据库架构）
简介
数据库的数据被拆分，数据库数据分布式存储，分布式处理，分布式查询，也可以理解成分布式数据库架构。
出现原因
上面提到的单机的写库会逐渐达到性能瓶颈，需要拆分数据库，数据表的数据量太大，处理压力太大，需要进行分表，为降低运维难度，业界逐渐研发了分布式数据库，库表天然支持分布式。
架构工作原理
什么是分库分表
如图所示。
分布式数据库架构
优缺点
优点：
- 数据库吞吐量大幅提升，不再是瓶颈
缺点：
- 跨库join、分布式事务等问题，需要解决。目前的mpp都有对应的解决方案。
- 数据库和缓存结合目前能够扛住海量的请求，但是应用的代码整体耦合在一起，修改一行代码需要整体重新发布。
微服务架构
简介
微服务是一种架构风格，按照业务板块来划分应用代码，使单个应用的职责更加清晰，相互之间可以做到独立升级迭代。
出现原因
- 扩展困难：系统无法轻松扩展，因为每次需要更新应用程序时，必须重新构建整个系统。
- 持续开发受阻：即使是微小的代码更改，也必须重新部署整个应用，难以频繁、轻松地发布新版本。
- 不可靠性：即便系统的某个功能出现故障，也可能导致整个系统崩溃。
- 缺乏灵活性：不支持使用不同的技术构建单一应用程序。
- 代码维护困难：所有功能都紧密耦合在一起，使得接管这段代码的人难以找到改进的切入点。
架构工作原理
优缺点
优势：
- 高度灵活性：每个服务都能独立地经受测试、部署、升级和发布。
- 独立可扩展性：每个服务都能独自进行扩展，不会影响其他服务。
- 提升容错能力：一个服务出现问题不会导致整个系统崩溃。
劣势：
- 复杂运维：随着业务的不断发展，应用和服务的数量增多，部署变得更加复杂。
- 资源需求增加：每个独立运行的微服务都需要占用一定资源。
- 故障排查难度增加：由于一个请求可能需要多个服务调用，故障排查变得困难，需要查看不同服务的日志来定位问题。
容器编排架构
简介
借助容器化技术（如docker）将服务/应用打包成镜像，通过容器编排工具（如k8s）来动态分发和部署镜像。服务以容器化方式运行。
出现原因
- 微服务拆分细，服务多部署工作量大，而且配置复杂，容易出错。
- 微服务数量多扩容麻烦，而且容易出错，每次缩容然后扩容后重新配置服务对应的环境参数信息，很复杂。
- 微服务至今啊运行环境可能冲突，需要更多的资源来进行部署或者通过修改配置来解决冲突。
架构工作原理
优缺点
优势：
- 快速部署、轻松运维：使用简单的命令即可完成数百个服务的部署或扩缩容操作。
- 强大隔离性：容器之间在文件系统、网络等方面具有高度隔离性，避免了环境冲突问题。
- 便捷滚动更新：通过单一命令实现不同版本的切换，支持轻松的滚动更新。
劣势：
- 技术栈复杂化，对研发团队的要求较高。
- 需要自行管理机器资源：在非高峰时段可能需要闲置大量机器资源来备战高峰期，这带来了机器成本和运维成本上的挑战。为解决这个问题，可考虑采购云服务商提供的服务器资源。
到了这里，关于Docker从认识到实践再到底层原理（一）｜技术架构的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
