首先声明，这不是写一个高性能应用的唯一选择，只是自己实践后的一些心得分享。
开发前定个小目标
有目标的好处是不会降配开发，也不会过度开发目标指标：并发数，TPS，响应时间等
1、模块独立性让路高性能：
在做业务模块逻辑时通盘考虑，必要时业务功模块的独立性要为高性能让路，比如对集合的操作，如果多个模块里都要循环大集合，不如为了性能，在一次循环中把不同的功能都搞定。
2、化身硬件
在开发过程中，要熟悉所使用的api，要站在CPU，内存，文件IO，或网络IO的角度思考，这样的代码谁会先受不了，会不会在关键时刻闹情绪，如果吃不准，一定要花点时间做demo，验证自己的担忧。还要优化代码，缩短代码执行路径，减轻硬件们的工作量，能一次干完的，就一次干完，不折腾硬件们，比如：能用字典唯一定位元素，不要去遍历List去找一个元素，虽对小集合来说不是事，但涓涓细流，汇集成河，防微杜渐很有必要。
3、放大放远思维
很多时候，当前代码执行没有问题，随着时间的推移，就会变成灾难，因为时间越长，拥有的数据会变多，使用的用户也会变多，当积累到一个临界点，就会爆发一些开发时没有出现的问题，所以不如在写代码时，就按照目标放大放远服务的承受量，一定在开始时就对自己狠点。
4、边开发边测试
在写代码时，关注每个模块的执行时间，使用资源情况，对一次用时过长的api，一定要想办法优化。有一次我用了一个加密算法，执行时长是2ms，当时觉得还行，但对于一个web api来说，这是一个灾难，一是这个加密算法在一次调用中需要几次调用，再有就是高并发时，是否还是用时2ms？所以在后期集成测试时我的代码就出问题了，响应时间提不上来，后来换了一个算法，也就2µs，响应时间一下就降了下来，所以要边写代码边测试，关注自己的模块，怀疑自己模块的性能。应该控制核心模块在1ms以下，辅助模块在µs级别。还要时不时压自己的代码一把，做到且coding且testing。
5、磨合配置
在高性能应用中，一定少不了一些高性能组件配合使用，像Redis，Queue，MemoryDB，或自己的应用也有一堆的配置，可能在开发阶段，或功能测试阶段，甚至性能测试阶段，都不会有事，但上了生产，出事了，因为测试场景绝对不可能等于生产环境，所以这些配置合适与否不可能通过测试出来，或者就根本想不到这种场景，所以一定要给服务上全方位监控，在服务上线前期，做到贴身照顾，护送几个运行周期，以便调整磨合配置的准确性。
想要更快更方便的了解相关知识，可以关注微信公众号
