大型网站系统优化方案
时间：2023-04-18 22:20:01 | 来源：网站运营
时间：2023-04-18 22:20:01 来源：网站运营
大型网站系统优化方案：
前言
系统优化的三个基本方向：性能（Performance）、稳定性（Stability）、可维护性（Maintainability）。三者之间并不是完全独立的，而是存在着复杂的相互作用关系，有时甚至会此消彼长。
最优秀的软件系统，并非要把这三个方向都做到极致，而是会根据自己实际的业务需求和场景合理取舍，在这三者之间达到一个综合最优的动态平衡状态，让各方面都能做到足够好即可。
所以，优化不只是一门科学，也是一门艺术。
服务器配置
服务器4台cpu:2Cmemory:2G带宽性能指标:
1.吞吐率（Throughput）：系统单位时间内能处理的工作负载，例如：在线 Web 系统 - QPS/TPS，离线数据分析系统 - 每秒处理的数据量。2.响应时间（Response Time）：以 Web 请求处理为例，响应时间（RT）即请求从发出到收到的往返时间，一般会由网络传输延迟、排队延迟和实际处理耗时几个部分共同组成。3.可伸缩性（Scalability）：系统通过增加机器资源（垂直/水平）来承载更多工作负载的能力；投入产出比越高（理想情况是线性伸缩），则说明系统的可伸缩性越好。此外，同一个系统的吞吐率与响应时间，一般还会存在如下关联关系：吞吐率小于某个临界值时，响应时间几乎不变；一旦超出这个临界值，系统将进入超载状态（overloaded），响应时间开始线性增长。对于一个有稳定性要求的系统，需要在做性能压测和容量规划时充分考虑这个临界值的大小。
注：其实按更严谨的说法，性能就是单指一个系统有多“快”；上述部分指标并不纯粹只代表系统快慢，但也都与快慢息息相关。
性能分析
- 定位性能瓶颈
CPU bound vs I/O bound - 工具
- 系统:tsar、top、iostat、vmstat
- 网络:iftop、tcpdump、wireshark
- 数据库:SQL explain、CloudDBA
- 应用代码:JProfiler、Arthas、jstack
性能优化：(优化做的越多，往往可维护性就会变差)
1）简化(有些事，你可以选择不做)
业务层面：流程精简、需求简化。
编码层面：循环内减少高开销操作、编写更少的代码。
架构层面：减少没必要的抽象/分层。
数据层面：数据清洗、提取、聚合。
2）并行(有些事，你可以找人一起做)
方式：单机并行(多线程)、多机并行(分布式)。
优点：充分利用机器资源(多核、集群)。
缺点：同步开销、线程开销、数据倾斜
- 同步优化：乐观锁、细粒度锁、无锁
- 线程替代(如协程：Java WISP、Go routines、Kotlin coroutines)。
- 数据倾斜：负裁均衡(Hash/RR/动态).
3)异步(有些事，你可以放手，不用死等)
方式：消息队列+任务线程+通知机制。
优点：提升吞吐率、组件解耦、削峰填谷
缺点：排队延迟(队列积压)。
- 避免过度积压：Back-pressure(Reactive思想)
4)批量(有些事，你可以合起来一起做)
方式：多次单一操作 ---> 合并为单次批量操作。
案例：TCP Nagel算法；DB的批量读写接口。
优点：避免单次操作的固有开销，均摊后总开销更低。
缺点：等待延迟+聚合延迟。
- 减少等待延迟：Timeout触发提交，控制延迟上限。
5)时间空间互换(游戏的本质：要么有闲，要么有钱)
空间换时间：避免重复计算、拉近传输距离、分流减少压力。
时间换空间：有时候也能达到“更快”的效果(数据量减少--->传输时间减少)
- 案例: 数据压缩(HTTP/2 头部压缩、Bitmap)
6)数据结构与算法优化(程序=数据结构+算法)
- 多了解一些“冷门”的数据结构：Skip list、Bloom filter、Time Wheel等
- 一些简单的算法思想：递归、分治、贪心、动态规划。
7)池化&局部化(共享经济与小区超市)
池化(Pooling)：减少资源创建和销毁开销。
- 案例：线程池、内存池、DB连接池、Socket连接池。
局部化(Localization) 避免共享资源竞争开销。
- 案例：TLB(ThreadLocalBuffer)、多级缓存(本地局部缓存--->共享全局缓存)。
8)更多优化手段
- 升级红利：内核、内存、JRE、依赖库、协议、硬盘(SSD)。
- 调参大师：配置、JVM、内核、网卡。
- SQL优化：索引、select *、LIMIT 1。
- 业务特征定制优化：凌晨业务低峰期做日志轮转。
- Hybrid思想(优点结合)：JDK sort()实现、Weex/RN
稳定性优化
稳定是相对的，业务规模越大、场景越复杂、系统越容易出现不稳定，且带来的影响也越严重。
衡量指标
不同业务所提供的服务类型千差万别，如何用一致的指标去衡量系统稳定性？标准做法是定义服务的可用性（Availability）：只要对用户而言服务“可用”，那就认为系统当前是稳定的；否则就是不稳定。用这样的方式，采集和汇总后就能得到服务总的可用/不可用比例（服务时长 or 服务次数），以此来监测和量化一个系统的稳定性。
可是，通过什么来定义某个服务当前是否可用呢？这一点确实跟业务相关，但大部分同类业务都可以用类似的方式去定义。例如，对于一般的 Web 网站，我们可以按如下方式去定义服务是否可用：API 请求都返回成功，且页面总加载时间 < 3 秒。
对于阿里云对外提供的云产品而言，服务可用性是一个更加需要格外重视并持续提升的指标：阿里云上的很多用户会同时使用多款云产品，其中任何一款产品出现可用性问题，都会直接被用户的用户感知和放大。所以，越是底层的基础设施，可用性要求就越高。关于可用性的更多细节指标和概念（SLI / SLO / SLA），可进一步参考云智能 SLA 了解。
可用性测量
1）探针模拟
从客户端侧，模拟用户的调用行为。
优点：数据真实（客户端角度）
缺点：数据不全面（单一客户数据）
2）服务端采集
从服务端侧，直接分析日志和数据。
优点：覆盖所有调用数据。
缺点：缺失客户端链路数据。
优化原则
你应该做的：关注 RT 的数据分布（如：p50/p99/p999 分位点），而不是平均值（mean） —— 平均值并没有太大意义，更应该去关注你那 1%、0.1% 用户的准确感受。
你不应该做的：不要尝试承诺和优化可用性到 100% —— 一方面是无法实现，存在太多客观不可控因素；另一方面也没有意义，客户几乎关注不到 0.001% 的可用性差别。
优化手段
常用的稳定性优化手段有哪些？这里也总结了 8 个套路：
1）避免单点 如何避免？
集群部署
数据副本
多机房容灾
只堆量不够，还需要具备故障转移能力（Failover）。
接入层：DNS、VipServer、SLB。
服务层：服务发现 + 健康检查 + 剔除机制。
应用层：无状态设计（Stateless），便于随时和快速切换。
2）流控/限流
- 类型：QPS 流控、并发度流控。
- 工具：RateLimiter、信号量、Sentinel。
- 粒度：全局、用户级、接口级。
- 热点流控：避免意料之外的突增流量。
3）熔断
目的：防止连锁故障（雪崩效应）。
工具：Hystrix、Failsafe、Resilience4j。
功能：自动绕开异常服务并检测恢复状态。
流程：关闭 → 打开 → 半开。
4）降级
触发原因：流控、熔断、负载过高。
常见降级方式：
关闭非核心功能：停止应用日志打印
牺牲数据时效性：返回缓存中旧数据
牺牲数据精确性：降低数据采样频率
5）超时/重试
超时：避免调用端陷入永久阻塞。
超时时间设置：全链路自上而下规划
Timeout vs. Deadline：使用绝对时间会更好
重试：确保可重试操作的幂等性。
消息去重
异步重试
指数退避
6）资源设限
目的：防止资源被异常流量耗尽
资源类型：线程、队列、DB 连接
设限方式：资源池化、有界队列
超限处理：返回 ServiceUnavailable / QuotaExceeded
7）资源隔离
目的：防止资源被部分异常流量耗尽；为 VIP 客户提供服务质量保证（QoS）。
隔离方式：队列划分、独立集群；注意处理优先级和资源分配比例。
8 ）安全生产 程序动态性：开关、配置、热升级。
Switch：类型安全；侵入性小。
审核机制：代码 Review、发布审批。
灰度发布；分批部署；回滚预案。
DUCT：自动/手动调整 HSF 节点权重。
可维护性优化
维护的英文是 maintain，也能翻译成：维持、供给。所以软件维护能有多重要？它就是软件系统的呼吸机和食物管道，维持软件生命的必要供给。
系统开发完成上线，不过只是把它“生”下来而已。软件真正能发挥多大价值，看的是交付后持续的价值兑现过程 —— 是不断茁壮成长，为用户发光发热？还是慢慢堕落，逐渐被用户所遗忘？这并不是取决于它当下瞬时是否足够优秀（性能）和靠谱（稳定），而是取决于未来 —— 能否在不断变化的市场环境、客户需求和人为因素中，始终保持足够优秀和靠谱，并且能越来越好。
相比性能和稳定性而言，可维护性所体现的价值往往是最长远、但也最难在短期内可兑现的，因此很多软件项目都选择了在前期牺牲可维护性。这样决策带来的后果，就跟架构设计一样，是几乎无法（或者需要非常高的成本）去弥补和挽回的。太多的软件项目，就是因为越来越不可维护（代码改不动、bug 修不完、feature 加不上），最后只能慢慢沦落为一个谁都不想碰的遗留项目。
衡量指标
相比性能和稳定性而言，可维护性确实不太好量化（艺术成分 > 科学成分）。这里我选取了几个偏定性分析的指标：
1）复杂度（Complexity）：是否复杂度可控？
编码：简洁度、命名一致性、代码行数等。
架构：组件耦合度、层次清晰度、职责单一性等。
2）可扩展性（Extensibility）：是否易于变更？
需要变更代码或配置时，是否简单优雅、不易出错。
3）可运维性（Operability）：是否方便运维？
日志、监控是否完善；部署、扩容是否容易。
重要性
软件生命周期：维护周期 >> 开发周期。
破窗效应、熵增定律：可维护性会趋向于越来越差。
遗留系统的危害：理解难度，修改成本，变更风险；陷入不断踩坑、填坑、又挖坑的循环。
优化原则
你应该做的：遵循 KISS 原则、DRY 原则、各种代码可读性和架构设计原则等。
你不应该做的：引入过多临时性、Hack 代码；功能 Work 就 OK，欠一堆技术债（出来混总是要还的）。
优化手段
常用的可维护性优化手段有哪些？这里我总结了 4 个套路：
1）编码规范
编码：推荐《Java 开发手册》
日志：无盲点、无冗余、TraceID。
测试：代码覆盖度、自动化回归。
2）代码重构
何时重构：任何时候代码中嗅到坏味道（bad smell）。
重构节奏：小步迭代、回归验证。
重构 vs. 重写：需要综合考虑成本、风险、并行版本维护等因素。
3）数据驱动
系统数据：监控覆盖、Metrics采集等，对于理解系统、排查问题至关重要。
业务数据：一致性校验、旧数据清理等；要相信，数据往往比代码要活得更久。
4）技术演进 死守阵地 or 紧跟潮流? 需要综合评估风险、生产力、学习成本。
当前方向：微服务化、容器化。
在线咨询
