架构师训练营架构第七周总结

架构设计有三大要素：高性能、高可用、可扩展。

而高性能到底如何保障高性能呢？

如果评估一个系统是否高性能呢？

如何确定系统优化方向呢？

如何确定系统是否能满足性能要求呢？



性能测试

性能测试就是用于架构的高性能优化的前提和基础，也是性能优化结果的检查和度量标准。不同视角下的网站有不同的性能要求标准，而性能压测就是找到当前系统的性能标准，并从而满足性能需求。



性能首先是一个需求，性能优化不是一个盲目的过程，不是哪个框架好，哪个架构好，哪个东西好就用上来，性能就好了，而是要通过量化的方式来看出系统是不是能满足性能要求。



举个例子：现在有一个电商系统，当前用户量有50万，日活用户大概是2000，而同时并发最高有20。

每个月用户增长大概是5万。而且下个月要做双十一活动了，预计活跃用户会增加30倍，那现在需要优化系统性能以保证双十一活动能够稳定运行。



以上就是一个性能的需求，架构师需要对这个需求有个明确的考虑，也许这个需求不是产品提出来的，而且很可能不是产品提出来的，产品可能只是告诉你下个月要搞双十一，活动覆盖用户群多大。而架构师就需要考虑，系统的并发可能会增加到多少，然后如何优化，



性能测试就是首先要测试出当前系统的可承受压力，当前可承受的最大压力是多少，然后在根据当前这个压力和目标压力的差距大小来决定是单纯的增加机器还是要重构系统。

架构就是一个取舍的过程，架构师这时候需要考虑人力成本、资源成本、时间成本，并且综合考量。



现在我们再来分析以上系统：当前并发20，下个月预计并发十倍600，而一年后预计增加一倍用户，常态并发40。

好，接下来开始性能测试。



• 初步性能测试，当前系统最大并发是30。

那可能就糟糕了，如果系统没有改善，可能再过几个月就会达到瓶颈，而且下个月要双十一，要满足600的需求，看似需要增加20倍机器，这个成本相当高，而且增加20倍机器还不够，至少要有一些余量和性能损耗，那可能需要增加30倍机器。明显资源成本过高。

这时候可能就要考虑进行性能优化了，性能优化的三大杀器无疑就是缓存、并行、集群。

这时候进行优化需要把当前系统的并发直接优化到600吗？优化20倍性能？这恐怕没有大改造是做不到的。所以实际上可以在时间成本、资源成本上进行一个权衡，比如我们把性能优化200，然后就只需要再增加2倍机器，或者把并发优化到150，然后就只需要再增加3倍机器。

• 假设当前系统最大并发是200

那好了，至少保证未来一年增长后的常态并发是没问题，而且只要加2倍机器就可以满足600并发，所以这种情况可能只需要加机器就可以了。如果有足够的时间，自然也可以进行一些优化，从而可以加更少的机器。



所以，系统性能实际上一个需求，我们需要知道需求的明确目标，以及了解当前的系统状态，从而选择不同的手段去进行性能优化。而不是拍脑袋就决定要重构，要改架构等等等等。