本文所谈的开发包括需求、设计、实现、测试，即广义的开发。

面向性能的需求分析

离开业务需求谈高性能容易陷入为技术而技术的陷阱。抛开资源、成本谈高性能则容易导致不必要的项目投入。
常规产品、系统除了功能需求外，都会伴随着性能需求。只是因其隐蔽性，导致不是所有的需求提出者都能想到或能给出准确的性能需求。此时就需要系统架构师帮助客户梳理和制定合理的性能需求。性能需求至少包括以下几个角度的信息：

• 什么场景？
• 什么数据量下？
• 多大的业务并发情况下？
• 多大的计算、网络的资源基础上？
• 怎么定义一个性能评估模型？如 TPCC。

面向性能的架构设计

所有架构都有其基础的性能损耗，一方面是性能得以实现的基础，另一方面也是性能上限的瓶颈。

• 比如引入了缓存就可能比不用缓存的要高性能，但同时引入了数据一致性问题，增加了系统的复杂度和脆弱性；
• 比如引入的异步处理，增加了反馈的及时性，同时导致原本一次性的操作被分解为多个操作的协同；
• 比如引入了微服务架构，获取了水平扩展能力，但因增加了服务间调用增加系统性能的损耗。

要逐渐积累一些基本基本组件的性能数据。

• 如广域网的通讯时间几十毫秒很常见；
• 比如数据库的读取和写入是有很大的不同；
• 比如很多系统都有隐式的缓存，如数据库、文件系统。

要知道架构设计的重点之一是平衡各种需求

• 稳定性需求
• 可维护性需求

要将系统的性能需求拆解为子系统、子模块的性能需求，比如整体对外需要 1 秒完成数据处理，有代理、计算、存储 3 个环节，则留给计算环节的平均耗时为多少？

面向性能的系统实现

在很多情况下，系统实现和系统设计是彼此交错的两类工作。在将系统架构落实为系统实现时，要从多个层次来实现系统。一些好的开发实践包括：

• 在开发过程中，除了设计面向功能测试的单元测试外，还要开发面向性能的测试框架；
• 构建符合性能测试需求的基础数据；
• 随着代码的推进，周期性运行性能测试框架，持续跟踪性能劣化的趋势，将其控制在需求范围内；
• 同样的功能有 N 种实现方式，但性能千差万别，甚至 do while 和 for 都要反复权衡写法。

性能测试与性能优化

性能测试本质上是性能摸底，性能测试不能改变系统的性能，但有助于对系统性能指标、性能瓶颈达成共识。
性能测试的设计考验的是技术人员的综合能力。
性能测试的执行考验的是技术人员的耐心和细心。
性能测试的度量有时会干扰被测对象的性能，如写日志、输出到屏幕、测试数据的累计都可能拉低系统的性能。
性能优化的推进需要有系统的视野，不要过早陷入局部优化的泥潭，至少要做好 2 个准备，以形成改进的闭环：

• 系统分段度量的能力
• 系统改进度量的能力

• 期望在测试阶段能优化性能
  木已成舟，架构是性能优化的天花板，代码是性能优化的约束。
• 期望性能开发的银弹
  从项目角度看，加缓存不一定性价比高；一个系统上的性能开发经验不一定能迁移到另一个系统上，注意场景、资源等的差异。