本文结合项目经验，整理一份大纲，供参考。
常用指标
RT（Response Time）：响应时间。可能会衍生出 TP999、TP99、TP95、TP90等指标。一般在几毫秒到几百毫秒之间。
QPS（Query Per Second）：每秒查询量。这是我们最常说的一个指标了。视业务复杂度不同而不同，轻量级的可能单机上万，重量级的可能就几百，这是主要依靠水平扩容来解决。
TPS（Transaction per second）：每秒事务量。主要衡量数据库性能，一般比 QPS 低 1~3 个数量级。
吞吐量（Throughput）：单位时间内处理的请求数量。该指标概念比较宽泛：
从业务角度看，吞吐量可以用QPS、TPS等单位来衡量。
从网络角度看，吞吐量可以用bps来衡量。一般用于排查网络抖动等问题，尤其是弱网环境下的RPC请求会更加关注。
PV（Page View）：页面浏览量。一般用于统计页面访问频次，每次刷新页面即被计算一次。高并发系统的单日 PV 基本上会超过千万。
UV（Unique Visitor）：独立访客量。用于统计单位时间内页面访问的用户数，同一个用户多次刷新页面只会被算做一次。高并发系统的单日 UV 基本上会过万。
提升系统性能的两个维度
垂直扩展：提升单机性能。包括硬件配置和软件编写方式两种维度。
水平扩展：集群整体性能。无状态服务加机器可解决；有状态服务还要额外考虑状态存储及迁移。实践中尽量做成无状态服务。
灾备管理
多区域部署机房，通常存在冷备、热备、双活等几种形式。主要用于流量分摊和故障转移。
故障处理
Failover 失败自动切换：当出现失败，重试其它服务器，通常用于读操作。一般核心服务会使用该策略。
Failfast 快速失败：只发起一次调用，失败立即报错，通常用于非幂等性的读写操作。多数场景均有重试机制。
Failsafe 失败安全：出现异常时，直接忽略。通常用于写入日志等操作。
Failback 失败自动恢复：后台记录失败请求，定时重发。通常用于消息通知等操作。
Forking 并行调用多个服务方：其中一个成功即可返回，通常用于实时性要求较高的读操作。
Broadcast广播调用：所有提供方逐个调用，任意一台报错则报错。主要用于RPC框架注册节点使用（更新提供方本地状态），应用型服务基本不会使用。
负载均衡
监控机器性能，并配置机器的权重（静态或动态）。
处理能力越强，分到的流量越多。
某台机器故障时自动摘除流量。
服务刚启动时的小流量预热，防止瞬间高流量把机器打崩。主要是各类中间件资源初始化可能会很耗时，导致请求响应慢，此时如果大量流量涌入会导致 Cpu Load急剧升高，甚至可能打崩。
自动扩缩容。业务高峰时段自动扩容，低峰时段自动缩容，节约成本。
区分服务等级
核心服务：一般都存在Backup，出错时自动切换，同时触发中高级别告警。
非核心服务：出错时可执行（手动或自动）降级甚至熔断，同时触发中低级别告警。
使用缓存
主要针对不易变化的数据，可能是多级缓存，可能横跨客户端和多个服务端。
本地缓存。如 ConcurrentMap、Guava Cache、Caffeine。
分布式缓存。如 Redis、GemFire/Geode。
异步操作
架构层面：
如使用MQ消息队列进行削峰、解耦处理，日志处理也用得比较多。
若追求 Cpu 的稳定性，可使用 Spring WebFlux 等全链路异步化技术，需要上下游服务都改造，才能有显著效果。
代码层面：如 Java 中的 Future 机制（常用 CompletableFuture），同时发起多个微服务的调用，隔一段时间后统一 get 结果。
批量执行
框架层面：可参考 Hystrix 的请求合并机制 HystrixCollapser。
代码层面：服务接口批量调用数据，拿到批量结果后再分派结果。
池化技术
线程池：常用如 ThreadPoolExecutor。
连接池：常用如 HikariCP、Druid、c3p0、DBCP。
对象池：常用如 Apache Commons Pool2。另外，如 Integer 等包装类针对（-127~128）的对象缓存，其实也是一种对象池的体现。
限流处理
服务入口：监控近实时统计QPS，达到阈值时拒绝请求。
常见的几种限流框架：
单机版（JDK自带的锁、信号量、Guava Limiter）
分布式（基于 Redis 的 redis-cell 模块和 Redisson、重量级的 Sentinel，以及老牌框架Hystrix）
常见的几种限流算法：
计数器法。存在临界流量问题，基本不会使用。
滑动窗口。时间片划分精度不好控制，基本不会使用。
漏桶算法。难以应对突发流量，使用较少。
令牌桶算法。常用。
常见的线程池拒绝策略：
CallerRunsPolicy 由调用者运行。
AbortPolicy 抛弃并抛异常。这是默认策略，也是最常用的策略，可以让应用层快速发现失败，进而介入处理。
DiscardPolicy 静静地抛弃，应用层无法感知到。
DiscardOldestPolicy 抛弃最老的请求。
防刷分流
搭建两套服务集群，将存在爬虫标记（依赖于专业的爬虫识别算法）的流量分流到另一套集群，甚至可以返回假数据，做蜜罐处理。
静态资源分发
主要依赖 CDN 技术进行资源的就近部署，可提前预热。常见如html、js、css、image等资源。
数据库并发
单机：MVCC、事务隔离、做好索引优化。
集群：分库分表、读写分离。
结合其他中间件：如简单的查询、统计，或者文本搜索等场景，可使用 ElasticSearch，必要时进行二级检索（ ElasticSearch 检索出 id，再到 SQL 中查询）。
压力测试 /性能测试
Apache JMeter。
搭建压测集群，平时抓取服务真实流量，节日或大促前进行必要的压测，以暴露性能瓶颈。
日常巡检/故障演练
用于提前发现问题，如接口扫描、混沌工程就是做这些事情的。
大纲就写到这里，你还有其他解决方案吗？欢迎评论区讨论。