企业官网建设流程全解析

目录

1、单机架构

2、应用数据分离架构

3、应用服务集群架构

4、读写分离架构

5、冷热分离架构

6、垂直分库架构

7、微服务架构

实际互联网架构示例

1、单机架构

单机架构（Single-Tier / Standalone Architecture）是指整个应用系统——包括用户界面、业务逻辑和数据存储——全部部署在同一台服务器（或同一台机器）上的架构模式。

核心特征

• 一体化部署：前端、后端、数据库运行在同一个物理机或虚拟机上

• 进程内通信：模块之间通过函数调用或本地进程通信，而非网络 RPC

• 共享本地资源：共用同一份 CPU、内存、磁盘和网络

• 无分布式协调：不需要服务发现、负载均衡、分布式事务等机制

优点

缺点

2、应用数据分离架构

应用数据分离架构，是单机架构之后一个非常自然的演进步骤。它的核心动作很简单：把应用服务和数据库服务从同一台机器上拆开，分别部署到不同的服务器上，让它们通过网络通信

为什么要做这个分离？

在单机架构下，应用和数据库在抢同一份 CPU、内存和磁盘。应用处理业务逻辑很吃 CPU，数据库做查询和写入很吃磁盘 I/O，两者混在一起，资源竞争会导致性能互相拖累。分离之后，两类服务可以各自使用更适合的硬件，互不干扰

主要变化与优势

• 资源解耦，各司其职：应用服务器专注处理业务逻辑，数据库服务器专注数据存储与索引。你可以根据各自的需求独立升级硬件，比如给数据库配更快的 SSD。

• 提升承载能力：这是最直接的收益。拆分后，单台机器的压力被分散，系统整体的并发处理能力和响应速度都会得到改善，能支撑比单机更高的用户量。

• 扩展更灵活：如果应用压力大，就扩容应用服务器；如果数据库压力大，就单独升级数据库服务器。这种灵活性是单机架构不具备的。

• 成本相对可控：相比于直接重构成分布式系统，这种“加一台机器”的方案成本较低，是预算有限时提升性能的有效手段。

它的局限

应用数据分离虽然解决了资源竞争，但并没有解决单点故障的问题。如果数据库服务器宕机，整个系统依然会不可用。此外，当访问量继续增长到数据库本身成为瓶颈时，这个架构也无能为力，因为数据库本身还是单点的，无法通过简单加机器来线性提升写入能力。要解决这些问题，就需要进入下一阶段，比如应用服务集群或读写分离。

3、应用服务集群架构

应用服务集群架构，是在“应用数据分离”基础上再进一步：把应用服务部署到多台服务器上，形成一个集群，前端通过负载均衡器统一对外提供服务。数据库通常仍是单点（或主从），但应用层已经可以水平扩展了。

关键前提：应用必须无状态

集群能成立的核心条件是应用服务无状态化：

• Session 不保存在本机内存，而是外置到 Redis / 数据库 / 客户端 Token（JWT）

• 上传文件不落本地磁盘，而是走对象存储（OSS/S3）或共享存储

• 本地缓存不做强依赖，或改用集中式缓存

否则请求被负载均衡打到另一台机器时，用户状态就丢了。

负载均衡的分层

常见做法是 L4 + L7 组合：LVS 做入口扛流量，Nginx 做七层路由和限流。F5（专用硬件设备）和 LVS 属于百万级甚至千万级并发，而 Nginx 通常在万级到十万级并发。

带来的收益

• 高可用：单台应用宕机，负载均衡把流量摘除，其他节点继续服务，故障对用户透明

• 水平扩展：压力大就加机器，理论上应用层容量可以线性增长

• 滚动发布：可以逐台下线更新，实现不停机发布、灰度发布

• 容错隔离：配合健康检查，异常节点自动剔除

仍存在的瓶颈

1. 数据库仍是单点：应用层扩到 10 台，数据库还是那一台，写入和连接数很快成为新瓶颈。连接池放大效应会让数据库承受成倍的连接压力。

2. Session/缓存的一致性：外置 Session 后，Redis 本身又成了新的单点，需要做主从或集群。

3. 负载均衡器自身是单点：LB 挂了入口就断了，生产上通常要做 LB 主备（Keepalived + VIP）或多活。

4. 数据一致性：多应用节点并发写同一份数据，需要数据库层面的锁或事务来兜底。

4、读写分离架构

读写分离架构，是在应用服务集群之后，针对数据库单点读写压力的下一步演进。它的核心思路很直接：把数据库拆成“主库”和“从库”，主库只负责写（增删改），从库只负责读（查询），通过主从复制把主库的数据变更同步到从库。

为什么需要读写分离？

在应用服务集群架构下，应用层可以靠加机器水平扩展，但所有请求最终都压到同一个数据库上。而绝大多数互联网业务是读多写少的（比如商品浏览远多于下单），数据库的读压力会首先成为瓶颈。读写分离把读请求分摊到多个从库上，主库专注处理写操作，从而提升整体吞吐量。

关键问题：主从延迟与一致性

这是读写分离最大的代价。从库重放 binlog 需要时间，刚写入主库的数据，立刻去从库读可能读不到。延迟来源包括网络传输、从库单线程回放瓶颈、大事务阻塞等。

常见的应对策略：

• 写后强制读主库：对一致性要求高的场景（如支付后查订单），代码层面或中间件层面临时把读请求路由到主库。

• 事务内全部走主库：事务中的读操作必须读主库，否则可能读到不一致数据。主流中间件和云服务默认都支持这一点。

• 延迟阈值剔除：监控从库延迟，超过阈值时自动把读流量摘除，避免返回过期数据。

• 开启并行复制或半同步复制：减少回放瓶颈，或确保至少一个从库收到日志后才返回写成功。

局限与定位

读写分离解决的是读性能瓶颈，不是写瓶颈。主库仍然是单点，写入能力无法线性扩展。如果写压力也上来了，就需要分库分表或引入更高阶的分布式数据库。此外，它引入了主从延迟这个新的复杂度，业务开发需要感知并处理一致性问题。

读写请求分离的实现方式

主要有三种路径：

• 应用层自己路由：在代码或 ORM 里判断 SQL 类型，SELECT 走从库，其余走主库。灵活但侵入性强，事务中容易写错。

• 中间件代理（主流）：通过 ShardingSphere、MyCat、ProxySQL 、TDDL 等中间件，对应用暴露一个统一地址，中间件解析 SQL 后自动路由。对应用透明，便于统一管理权重和故障切换。

• 云数据库原生支持：阿里云 RDS、腾讯云等提供数据库代理地址，开通后自动读写分离，应用无需改代码。

5、冷热分离架构

冷热分离架构，是在读写分离之后，针对数据访问频率差异的进一步优化。核心思路是：把"热数据"（频繁访问的）和"冷数据"（很少访问的）分开存储和处理，让有限的资源优先服务高频访问，同时用低成本方式承载历史数据。

为什么需要冷热分离？

读写分离解决了"读"的并发压力，但没解决数据量本身的问题。随着业务运行，数据库里堆积了大量历史订单、日志、归档记录——这些数据占了 80% 以上的存储空间，却只贡献不到 20% 的访问量。它们仍躺在高性能的主库/从库里，占用内存（缓冲池）、拖慢索引、增加备份成本。冷热分离就是把这些"低价值存量"迁出去，让热库保持轻量。

6、垂直分库架构

垂直分库架构，是数据拆分中“垂直拆分”思路在数据库层面的落地。它的核心动作是：按照业务模块，把一个原本包含所有表的大库，拆分成多个独立的数据库，每个库只存放特定业务领域的表，并且可以部署在不同的服务器上。

为什么需要垂直分库？

• 在读写分离、冷热分离之后，你解决的主要是“读”的压力和“存量数据”的负担，但数据库里仍然可能混着用户、订单、商品、支付等不同业务的表。它们共享同一个数据库实例的 CPU、内存、连接数和磁盘 I/O。一旦某个业务（比如订单）出现突发流量，就可能拖垮整个库，影响所有业务。
• 垂直分库的本质是按业务边界做资源隔离，让不同业务的数据和压力互不干扰。

典型拆分方式

以电商系统为例，拆分前是一个大库ecommerce_db，拆分后可能变成：

• 用户库（user_db）：存放用户信息、地址等表

• 订单库（order_db）：存放订单主表、订单项等表

• 商品库（goods_db）：存放商品信息、库存等表

• 支付库（pay_db）：存放支付记录、退款记录等表

每个库可以独立部署、独立扩容，某个库压力大时，可以单独升级它的硬件，而不必动其他库。

缺点

垂直分库不是免费的，它把单库的简单性换成了分布式系统的复杂度：

1. 跨库 JOIN 消失：拆分前可以通过 SQL JOIN 关联的表，拆分后分布在不同的库甚至不同的服务器上，无法直接 JOIN。通常的应对方式包括：在应用层通过服务调用拼装数据、冗余关键字段（比如订单表里冗余用户名）、或把一些公共的“数据字典”表在每个库都存一份。

2. 分布式事务难题：一个操作如果同时涉及订单库和库存库，本地事务就不再够用。需要引入分布式事务方案（如 Saga、消息队列最终一致性等），复杂度和出错概率都显著上升。

3. 应用改造：应用需要知道去哪个库读写，通常需要引入数据访问中间件（如 ShardingSphere）或在代码里做路由，对开发有一定侵入性。

7、微服务架构

微服务架构，是应用架构演进中一次质变——前面聊的集群、读写分离、垂直分库，本质上还是在"一个应用"内部做拆分和扩展；微服务则是把一个应用本身拆成多个独立的小应用，每个小应用独立开发、独立部署、独立运行，通过轻量级通信（HTTP/RPC/消息）协作。

核心特征

• 服务按业务能力拆分：每个服务对应一个明确的业务领域（用户服务、订单服务、支付服务），边界清晰

• 独立部署与独立生命周期：改订单服务不用重新发布用户服务，各服务可以有自己的发布节奏

• 独立数据存储：每个服务独享自己的数据库（这与前面讲的垂直分库一脉相承），不共享表

• 轻量通信：服务间通过 REST/gRPC 同步调用，或通过消息队列异步通信

• 去中心化治理：技术栈可以异构，团队按服务自治

常见误区：分布式单体

最常见的失败形态是：服务拆了，但数据库还共享、调用链还是同步强耦合、发布还得一起发。结果既没享受到独立部署的好处，又背上了分布式的复杂度。判断微服务是否拆对了，关键看：能否独立部署、数据是否独立、故障是否隔离。

缺点

1. 网络不可靠：远程调用会超时、会失败、会重试，必须处理幂等、超时、重试、熔断

2. 分布式事务：跨服务写操作无法用本地事务，需要 Saga/TCC/最终一致性，复杂度和出错面大增

3. 数据一致性：跨服务查询要聚合，冗余字段要同步，最终一致性要设计补偿

4. 运维复杂度飙升：几十上百个服务，部署、监控、日志、排障都成倍复杂，强依赖容器化和 DevOps

5. 链路排障困难：一个请求经过 10 个服务，出问题要跨服务追踪

6. 组织成本：需要配套的团队划分、CI/CD、可观测性体系，否则微服务会变成"分布式单体"——拆了但没解耦，反而更糟

8、容器编排架构

容器编排架构，是微服务架构落地生产环境后的必然配套基础设施。当微服务被拆成几十上百个独立服务，每个服务又需要多个实例运行时，手工部署和管理容器变得不可行。容器编排架构的核心作用是：用一个自动化系统，接管容器的部署、调度、扩缩容、故障恢复和网络通信，让运维人员从“逐台机器操作”转为“声明期望状态”。

核心思想：声明式管理与期望状态

容器编排与传统运维最大的区别在于声明式模型。你不再写脚本告诉系统“先启动 A，再启动 B”，而是用 YAML/JSON 文件描述“我希望有 3 个订单服务实例在运行”。编排系统（如 Kubernetes）会持续对比实际状态与期望状态，自动执行必要的操作来消除差异。

这套机制自动完成了以下关键任务：

• 自动调度：根据资源需求和约束，决定容器在哪个节点上运行。

• 自愈：容器或节点故障时，自动重启或迁移容器，维持期望的副本数。

• 弹性扩缩容：根据 CPU/内存使用率或自定义指标，自动增减实例数量。

• 服务发现与负载均衡：为服务提供稳定的访问入口，并将流量分发到健康的实例上。

• 滚动更新与回滚：逐批替换旧版本实例，实现零停机发布；新版本异常时可自动回退。

主流方案：Kubernetes 的事实标准地位

在容器编排领域，Kubernetes（K8s）已成为事实上的标准。根据 CNCF 2025 年调查数据，82% 的容器用户在生产环境运行 Kubernetes，而 Docker Swarm 的使用率约为 24%。学术研究也指出，Kubernetes 在复杂环境下的资源分配和自动扩缩容方面表现突出，而 Docker Swarm 更适合小型应用的简单部署。

Kubernetes 的核心架构分为两部分：

• 控制平面（Control Plane）：集群的大脑。核心组件包括 API Server（所有操作的入口）、etcd（存储集群状态）、Scheduler（决定 Pod 跑在哪个节点）、Controller Manager（确保实际状态趋近期望状态）。

• 工作节点（Worker Node）：运行实际容器的机器。每个节点上有 kubelet（与控制平面通信、管理本节点容器）和 kube-proxy（处理网络规则和负载均衡）。

实际互联网架构示例