陈显铭(山丘)

读完需要

6分钟

速读仅需 2 分钟

陈显铭，花名山丘，就职于蚂蚁集团，对分布式应用架构、服务化、性能优化等有深入的理解。参与支付宝支付链路核心系统，设计、调优应用系统关键能力， 高效、稳定保障系统平稳支撑大促。曾历经多年双十一大促，对于性能调优、构建高可用系统有丰富的实战经验。熟悉常见的性能优化模式，比如应用结构优化、链路级、单系统优化等多种优化方式。对于常见的压测模式，如单机压测、链路级压测都有深厚的积累。作为一名性能专家，以追求性能最大化为己任，与之相伴的自然是高技巧、高难度的代码优化。这也是一名性能专家的毕生追求。

本章希望通过对性能优化的模式进行总结，使读者了解常见的性能招式，并能通过这些招式，找到自己系统中的性能瓶颈点，或者当前应用所处的发展阶段及下一步可能演进的模式。

性能是驱动应用结构演进的主要动力之一，本文会通过应用结构的变化揭示性能是如何在不同阶段、以不同的结构驱动应用结构朝着下一个结构演进的。通过应用结构的发展也可以揭示，如何不做过度的设计，在应用尽量简化且不浪费企业资源的情况下支撑企业业务的发展。首先说明性能优化的价值。

1

性能优化的优缺点

对性能进行优化有如下几个优点：

• 降低业务成本。

• 提升系统稳定性。

• 提升用户体验。

性能优化的缺点是可能会使维护成本增加，增加代码、结构及技术栈的复杂度。以上所讲到的性能优化的优缺点如图 17.1 所示。

图 17.1

2

性能优化的两种模式

纵观性能优化案例，性能优化整体上可以分为两类：单应用优化和结构型优化。

• 单应用优化：关注单系统瓶颈，通过解决单系统瓶颈提升性能。

• 结构型优化：通过改造链路结构和配比进行整体性能的优化。

3

单应用优化

3.1

优化基本思路

图 17.2

如图 17.2 所示，优化基本思路包含如下几个方面。

• 确定性能瓶颈/热点。

• 确定优化方案。

• 实施优化方案并反馈优化情况。

3.2

确定性能瓶颈点/热点的常见方法

确定性能瓶颈点/热点的常见方法有如下两种。

• 性能压测：通过工具、人工等方式量化运行时的性能情况。

• 业务/代码梳理：通过代码走读发现资源消耗热点，通过统计代码对资源的操作量化代码对资源的消耗(比如一个业务操作会进行多少次数据库调用，进行多少次服务运算等方式)。

3.3

压测时通常观察的内容及其所使用的工具

以 Java 环境为例，压测时通常使用 JMeter 及 LoadRunner 发起压力测试并收集压测指标，使用 nmon 来检测 Linux 的性能情况。nmon 是一种在 AIX 与各种 Linux 操作系统上被广泛使用的监控与分析工具。除此之外，压测时通常观察的内容及其所使用的工具如下：

• 内存的使用情况：MAT、GC 日志、vmstat。

• I/O 情况：iostat。

• 网络情况：Netstat。

• 热点代码：JProfiler、BTrace、JStack、JStat。

• CPU 情况：Linux top 命令。

3.4

常见的优化手段及模式

常见的优化手段及模式大概有如下几种。

• 静态化：动态数据和静态数据分离。

• 异步化：使用异步化减少主流程中的非关键业务逻辑。

• 并行化：使用多线程并发处理，缩短响应时间。

• 内存优化：减小对象所占空间，减少对象创建的数量，优化数据模型。

• 去重复运算：优化业务逻辑，或者使用缓存。

• 减少数据库操作：为此，需要减少数据冗余、数据缓存等。

• 缩短数据库事务：可以考虑使用短事务、异步化、最终一致性等方式。

• 精简代码逻辑：去除冗余代码，诸如重复判断的代码。

• 精简日志操作：要关注日志大小，注意 I/O 上的瓶颈。日志太多，说明生成的 String 也会很多，会增加 GC 的负担。

4

结构型优化

此部分介绍的内容在很多网站架构变迁的文章中都会提到，下面通过图示的方式展现出来。每个阶段都有适用的软件架构，出于对建设复杂度、维护成本的考虑，不必强求一开始就建设出很完整的技术体系。个人认为，性能是驱动应用体系演进的重要驱动力，可以通过下面的应用结构演进看出来。单应用时代的常见瓶颈先发生在数据库上。由于所有的业务都存储在一个数据库(DB) 上，因此数据库的读写和性能是可能遇到的第一个问题，如图 17.3 所示。

图 17.3

单应用时代对此问题的第一个常见解决办法是使用缓存(偏向应用级别的缓存)。为了防止所有的数据读写都集中在数据库上进行，首先想到的就是通过缓存减少对数据库的压力，比如将配置数据全部加载到缓存(某些场景可以使用类似 LRU 的缓存)中，如图 17.4 所示。

图 17.4

单应用时代解决此问题的第二个办法是使用独立缓存服务(集中式缓存，如 MemCache)，如图 17.5 所示。

图 17.5

单应用集中式部署带来了应用集群处理能力的提升，可以使应用进行水平扩展，如图 17.6 所示。

图 17.6

单应用集中式部署后的数据库瓶颈如图 17.7 所示。

图 17.7

单应用集中式部署后的数据库瓶颈的解决办法是对数据库进行拆分及读写分离，如图 17.8 所示。

图 17.8

为了应对更大范围的请求量，需要进行服务化拆分，由此进入多应用分布式服务化时代，如图 17.9 所示。

图 17.9

随着业务及数据的规模不断扩大，又逐渐进入多应用分布式服务集群化时代，此时依然存在一些问题需要解决，如图 17.10 所示。

图 17.10

5

两个结构优化的案例

5.1

处理单点/网络瓶颈的可行方式

通过去分布式调用进行去中心化，可以规避网络设备成为瓶颈和单点故障，如图 17.11 所示。

图 17.11

5.2

处理数据库连接池瓶颈的可行手段

增加数据处理中间层可以缓解数据库连接池的瓶颈，最好的处理方式是对架构进行服务化和单元化，将数据量大的数据库进行拆分，分散压力，如图 17.12 所示。

图 17.12

6

总结

对于小型企业的业务，通过进行较为简单的单系统优化，并辅助结构性优化，便能满足大部分企业的要求，如图 17.13 所示。但随着企业的业务量不断增加，单独的单机优化已经不能满足需求。分布式部署是中大型企业的必经之路，水平扩展、垂直拆分、服务化等方式是实现分布式部署的方式。

图 17.13

近年来，像阿里巴巴这类的大型一线互联网公司已经不再满足固定模式的水平扩展， 那么当一个机房的容量不足时要如何应对呢？一个城市的机房容量不足时又要如何应对？综合不断增长的业务述求，阿里巴巴这类公司正在实施单元化进程，根据一定的数据分片规则，使特定分片规则下的用户访问到特定单元化的应用系统，并通过不同城市的单元实现流量的自由切换和容灾。技术总是在不断更迭，今天的解决办法是明天的问题，也许单元化也不是最终的解决办法，总会涌现出越来越多的新挑战和应用模式。

- EOF -

想要加入中生代架构群的小伙伴，请添加群合伙人大白的微信

申请备注(姓名+公司+技术方向)才能通过哦！

扩展阅读

   

阿里专家马飞翔：一文读懂架构整洁之道2020-10-16DDD专家张逸：构建领域驱动设计知识体系2020-10-13京东架构师闫文广：订单系统高可用架构及演变过程2020-10-12架构师，是否需要写代码？2020-09-18阿里高级技术专家箫逸：如何画好一张架构图？2020-09-07大神手把手教你设计秒杀架构模型2020-09-06阿里巴巴闲鱼架构负责人王树彬：万亿交易规模技术架构实践2020-09-05阿里高级技术专家张建飞：应用架构分离业务逻辑和技术细节之道2020-08-31波波老师大解密：如何成为优秀的架构师？2020-06-25微信支付软件架构重构之旅2020-06-08一个思维习惯，让你成为架构师2020-06-03阿里P9专家右军：以终为始的架构设计2020-04-27

   END     

#架构师必备#

点分享点点赞点在看