上一篇
服务器体系架构
器 体系架构涵盖集群、负载均衡、分布式等类型，含硬件组件与软件协同 设计，满足高性能及高可用需求
基础概念与核心组件
硬件层
| 设备类型 | 功能描述 | 典型场景举例 |
|---|---|---|
| 物理服务器 | 承载操作系统和应用程序的实体机器（如戴尔PowerEdge系列） | Web服务集群中的节点机 |
| 交换机/路由器 | 实现局域网内高速数据传输及跨网段路由转发 | 数据中心内部东西向流量调度 |
| 存储阵列 | 提供块存储(SAN)、文件存储(NAS)或对象存储服务 | SQL数据库日志冷备份归档库 |
| PDU电源模块 | 集中管理多台设备的供电分配与能耗监控 | 机柜级电力冗余设计方案 |
虚拟化层
通过Hypervisor技术将物理资源抽象为可动态调配的逻辑单元：
Type-1 hypervisor（裸金属架构）：直接运行在硬件上的ESXi/XenServer，适合高性能计算场景；
容器引擎（Docker/Kubernetes）：轻量级进程隔离技术，支持微服务快速部署；
分布式存储池：Ceph/GlusterFS实现跨节点共享存储卷，配合CSI插件供容器使用。
主流架构模式对比
| 架构类型 | 适用场景 | 优势 | 局限性 |
|---|---|---|---|
| 单体式 | 小型初创项目 | 开发简单、垂直扩展容易 | 故障域集中、水平扩展困难 |
| 微服务化 | 中大型互联网应用 | 独立部署/伸缩、技术栈灵活 | 网络延迟增加、运维复杂度提升 |
| 无状态设计 | API网关前置型系统 | 会话保持成本低、横向扩展性强 | 需外部化状态管理（Redis集群） |
| ServiceMesh | 多语言混合架构治理 | 流量可视化、熔断降级策略统一 | Sidecar代理带来额外资源开销 |
关键决策点：根据业务增长曲线选择过渡方案，例如初期采用单体结构快速验证PMF（产品市场契合度），当QPS突破5k时逐步迁移至微服务架构。
高可用性设计方案
冗余机制
- 主从复制：MySQL主库写操作异步同步到备库，RPO<1秒；
- 负载均衡器健康检查：NGINX基于TCP握手检测后端实例存活状态；
- Chaos Engineering实践：定期模拟AZ故障测试故障转移有效性。
容灾策略矩阵
| 灾难类型 | 应对措施 | RTO目标 |
|---|---|---|
| 机房级中断 | 跨可用区部署+BGP任何cast路由切换 | <15分钟 |
| 区域性灾害 | 异地机房异步复制（如阿里云上海→张北） | 2小时内恢复 |
| 云厂商全局故障 | 混合云双活架构（AWS+Azure） | 手动介入修复 |
性能优化路径
缓存层级设计
用户请求 → CDN边缘节点 → L1本地缓存 → L2分布式Redis集群 → DB读副本
每层命中率目标：CDN(85%)→L1(95%)→L2(70%)→DB(≤5%)
异步批处理模式
将非实时任务纳入消息队列：
- Kafka消费者组并行消费订单消息；
- Batch处理器每30秒聚合日志写入Elasticsearch；
- Dead letter queue捕获失败消息人工干预。
安全防护体系
| 层面 | 控制措施 | 工具示例 |
|---|---|---|
| 网络安全 | VPC防火墙规则限制暴漏端口 | Calico CNI插件 |
| 主机安全 | Falco实时行为分析阻止提权操作 | Sysdig监控容器逃逸 |
| 应用安全 | WAF拦截OWASP Top10攻破向量 | OpenResty动态规则更新 |
| 数据加密 | TLS双向认证+AES-GCM算法加密敏感字段 | HashiCorp Vault密钥库 |
相关问题与解答
Q1: 如果业务突增导致现有服务器过载，应该优先扩容还是优化代码？
解答：遵循“监测→定位→优化→扩容”四步法，首先用Prometheus+Grafana确认瓶颈点（CPU/内存/IO等待），若因锁竞争导致线程阻塞则优先重构热点代码；若是纯粹算力不足再考虑横向添加实例，盲目扩容可能造成资源浪费。
Q2: 如何判断是否需要引入服务网格(ServiceMesh)？
解答：当出现以下情况时建议评估Istio/Linkerd方案：①多语言技术栈混合部署；②需要统一的金丝雀发布机制；③跨服务的分布式追踪需求强烈；④现有API网关无法满足复杂的流量管理策略（如按百分比切流），中小型单一语言团队可直接使用Spring
