易搜资源网

大型网站如何做好seo优化?一篇详解

前言:

系统优化的三个基本方向:性能(Performance)、稳定性(Stability)、可维护性(Maintainability)。三者之间并不是完全独立的,而是存在着复杂的相互作用关系,有时甚至会此消彼长。

最优秀的软件系统,并非要把这三个方向都做到极致,而是会根据自己实际的业务需求和场景合理取舍,在这三者之间达到一个综合最优的动态平衡状态,让各方面都能做到足够好即可。

所以,优化不只是一门科学,也是一门艺术。

运营指标:

DAU、MAU、APP日下载量、日订单量、日下单用户、日销售额

服务器配置:

服务器数量、cpu、memory、带宽

性能指标:

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)时间空间互换(游戏的本质:要么有闲,要么有钱)

空间换时间:避免重复计算、拉近传输距离、分流减少压力。

案例:缓存、CDN、索引、只读副本。

时间换空间:有时候也能达到“更快”的效果(数据量减少--->传输时间减少)

案例: 数据压缩(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)编码规范

编码:推荐《阿里巴巴开发手册》

日志:无盲点、无冗余、TraceID。

测试:代码覆盖度、自动化回归。

2)代码重构

何时重构:任何时候代码中嗅到坏味道(bad smell)。

重构节奏:小步迭代、回归验证。

重构 vs. 重写:需要综合考虑成本、风险、并行版本维护等因素。

3)数据驱动

系统数据:监控覆盖、Metrics采集等,对于理解系统、排查问题至关重要。

业务数据:一致性校验、旧数据清理等;要相信,数据往往比代码要活得更久。

4)技术演进 死守阵地 or 紧跟潮流? 需要综合评估风险、生产力、学习成本。

当前方向:微服务化、容器化。

本文链接:https://www.yisozy.com/27.html

版权声明:

本站所刊载内容均为网络上收集整理,包括但不限于代码、应用程序、影音资源、电子书籍资料等,并且以研究交流为目的,所有仅供大家参考、学习,不存在任何商业目的与商业用途。

若您使用开源的软件代码,请遵守相应的开源许可规范和精神, 若您需要使用非免费的软件或服务,您应当购买正版授权并合法使用。如果你下载此文件,表示您同意只将此文件用于参考、学习使用而非任何其他用途。

发表评论

还没有评论,快来说点什么吧~

联系客服
返回顶部