服务器技术架构

原创于 2025-04-03 10:36:14 发布 · 1.1k 阅读

18 ·

CC 4.0 BY-SA版权

文章标签：

#服务器 #架构 #运维

技术架构

1. 单机架构

单机架构，就是只有一台服务器来负责所有的工作，应用服务和数据库服务共用一台服务器。在互联网早期，网络的访问量比较小时，单机架构能够应付需求，被广泛使用。

优点：

部署简单、成本低

缺点：

存在严重的性能瓶颈、数据库和应用相互竞争资源

2. 应用数据分离架构

应用数据分离架构，就是将应用服务和数据库服务分别使用两台服务器进行部署，用于解决单机架构中数据库和应用相互竞争资源的导致站点变慢的缺陷。应用服务器对外提供服务，而数据库服务器用来存储数据。

优点：

成本相对可控、性能相比单机架构有提升、数据库单独隔离，有一定的容灾能力

缺点：

硬件成本搞、性能有瓶颈，无法应对海量并发

3. 应用服务集群架构

应用服务集群架构，就是引入一个负载均衡层，并增加了应用服务器的数量。通过负载均衡层决定用户访问哪一个应用服务器，以集群的方式运作，来应对海量的并发请求。

优点：

应用服务器高可用。

应用满足高可用，不会因为一个服务器出问题整个站点挂掉。
应用服务器具备一定高性能。

如果不访问数据库，应用相关处理通过扩展可用支持海量请求快速响应。
应用服务器具有一定扩展能力。

支持横向扩展。

缺点：

数据库服务器只有一个，成为性能瓶颈，无法对数据库进行海量查询。
数据库是单点，没有高可用性。
运维工作增多。

扩展后部部署运维工作增多，需要开发对应的工具应对快速部署。
硬件成本高。

4. 读写分离/主从分离架构

读写分离/主从分离架构，就是将数据库分为主（写）数据库服务器和从（读）数据库服务器，数据库服务器搭建主从集群，可以实现一主一从、一主多从架构，数据库主机负责写操作，从机只负责读操作。

读写分离/主从分离架构缓解了数据库承载压力大的问题，且网络应用对数据库一般是读操作远多于写操作，把读写操作分开可以极大缓解数据库压力。

读写分离/主从分离架构是在应用服务集群架构实现多数据库服务器的架构。

优点：

数据库的读取性能提升。
读取被其他服务器分担，写的性能间接提升。
数据库有从库，提升了数据库的可用性。

缺点：

热点数据的频繁读取导致数据库负载很高。
当同步挂掉，或者同步延迟比较大时，写库和读库的数据不一致。
服务器的成本进一步增加。

5. 冷热分离架构

冷热分离架构，就是引入缓存，将数据库的热数据放到缓存中实现快速响应，以解决读写分离/主从分离架构中热点数据的频繁读取导致数据库负载很高的缺陷。

优点：

大幅度降低对数据库的访问请求，性能提升明显。

缺点：

带来了缓存一致性的问题。

缓存击穿、缓存失效、缓存雪崩等。
服务器成本进一步增加。
数据库数据量大后查询变慢。

业务体量变大后，数据不断增加，数据库单库太大，单个表体量太大，数据查询就会很慢，导致数据库再次称为架构的瓶颈。

垂直分库架构

垂直分库架构，就是将数据库的表进行拆分，数据库数据分布式存储，分布式查询，也可以理解为分布式数据库架构。用来解决数据库数据量大后查询变慢的缺陷。

优点：

数据库吞吐量大幅提升。

缺点：

存在跨库 join ，分布式等问题。
整体代码耦合性高，修改一行代码需要重新发布。

6. 微服务架构

微服务架构是一种架构风格，不是一个具体的架构方法。微服务架构按照业务板块来划分应用代码，使单个应用的职责清晰，相互之间可以做到独立迭代升级。

由于之前的架构都有以下问题：

拓展性差。

每次更新应用程序都要重新构建整个系统。
维持开发困难。

一个小的代码改动，也需要重新部署整个应用，无法频繁并轻松的发布版本。
不可靠。

系统的一个功能不起作用，可能会导致整个系统无法工作。
不灵活。

无法使用不同的技术构建单体应用。
代码维护难。

所有的代码耦合到一起。

所以，需要微服务架构来解决以上的缺陷。

优点：

灵活性高。

服务独立测试、部署、升级、发布。
独立扩展。

每个服务可以自行进行扩展。
提高容错率。

一个服务问题并不会让整个系统瘫痪。
新技术的应用容易。

支持多种编程语言。

缺点：

运维复杂度高。

随着应用和业务不断增多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还需要解决运行环境冲突的问题。在需要动态扩缩容的场景下，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维工作变得十分困难。
资源使用变多。

所有独立运行的微服务都需要占用内存和 CPU。
处理故障困难。

一个请求跨越多个服务调用，需要查看不同的服务日志完成问题定位。