5分钟了解系统架构设计（5）
如何设计一个高性能的系统架构，这是面试中一般常见的问题，明白回答该类问题的套路可以帮助我们理清思路。本篇会聚焦high-level的思路，实际场景中还需要根据实际条件约束综合考虑。
最近梳理了之前学习的架构设计相关的一些课程学习总结，将其整理成了一个大纲脑图，以每篇5分钟系列展现出来，希望对你有所帮助。
如何设计一个高性能的系统架构，这是面试中一般常见的问题，明白回答该类问题的套路可以帮助我们理清思路。
本篇会聚焦high-level的思路，实际场景中还需要根据实际条件约束综合考虑。
首先，对于这类问题，回答套路为：
明确性能指标 => 保护系统措施 => 保护用户体验 => 快速扩容预备
其次，我们以后端服务为例，下面是回答思路。
画外音>如果不仅是后端视角，那就还需要站在系统的全链路视角来分析到底各个环节的具体指标。
1、明确系统性能指标
假设要求TP99=2s，即保证99%的请求的响应时间都在2s内。
画外音>如果你对TP99概念还不太熟悉，建议阅读本系列的第一篇推文。
但是需要确认并发用户数，即确认系统的承载能力范围，因此明确为：“保证系统并发数在100万用户内的时候，TP99=2s”。
综述，对于系统设计者而言，要清楚系统有所能，也有所不能。
此外，在压测阶段，可以通过绘制吞吐量和延迟的曲线，找到最佳性能点，进而在超过最佳性能点时做限流。
2、明确系统保护措施
当系统并发用户的数量超过100万的时候，要保证有100万用户的TP99=2s，然后保护系统，并拒绝其他用户的连接请求。
具体保护系统的措施包括：系统限流，即通过流量控制来保证系统的稳定性，当实际并发压力超过系统性能设计指标时，就拒绝新的请求连接，让用户进行排队。实际中，我们可以使用Nginx限流 或 API网关（如APISIX或Kong）提供的限流。
实际操作案例：
Nginx限流—控制速率
limit_req_zone $binary_remote_addr zone=myRateLimit:10m rate=10r/s; // 限制单个IP每秒最多请求10次 server { location /{ limit_req zone=myRateLimit; proxy pass http://my_server_upstream; } }
Nginx限流—控制并发连接数
limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn_zone $server_name zone=perserver:10m; server { ... limit_conn perip 10; // 表示限制单个IP同时最多能持有10个连接 limit_conn persever 1000; // 表示server同时只能够处理100个并发连接数 }
3、保证用户体验
当系统达到最大并发用户数时，需要给系统承载量外的用户提供一些优雅的体验，比如：服务器排队机制，并附加具体、明确的信息提示。
4、快速扩容预备
若出现流量压力时，能够在几分钟内完成扩容，并保证在扩容后能承载的并发用户量仍然可以保持TP99=2s。
具体预备的扩容措施包括：存储额外的计算资源，用于不时之需，可以通过事先预估留出一部分资源池。当然，没有把额外的计算资源直接加入，这是基于IT成本的考虑。
在实际场景中，通过云计算可以快速方便的实现虚拟机资源的弹性伸缩，而Kubernetes的滚动更新和横向伸缩（Auto Scale）功能则可以实现应用资源的弹性伸缩。
通过上述的思路，我们大概可以了解在回答高性能系统的设计思路时，应该有的基本套路。
5、事后排查
当然，即使我们事前考虑的再多，也仍然会存在延迟和吞吐量的问题。
那么，如果发现系统存在较高延迟和吞吐量显著降低，如何进行定位呢？
（1）定位延迟的问题
解决思路：
端到端逐一排查时间消耗在哪里。
善用工具：
Java => jstack 打印系统当前线程堆栈, JProfiler 监控系统的内存使用情况、GC、Thread运行情况。
.NET => WinDbg 打印系统当前线程堆栈 和 内存使用情况，CLRProfiler, dotmemory, dottrace 都可以用。
排查案例：
比如你发现了运行的 100 个线程里面，有 80 个卡在某一个锁的释放上面，这时极有可能这把锁造成的延迟问题。
（2）定位吞吐量的问题
对于吞吐量指标要和 CPU使用率一起来看，在请求速率逐步增大时，经常会出现四种情况，对应的建议也一并附在了下面的表格中：
参考资料
李运华，《从0开始学架构》
刘海丰，《架构设计面试精讲》
潘新宇，《23讲搞定后台架构实战》
