高性能服务器之架构演化之路---建议食用
目录
写在前头
对于后端的开发而言，高并发是一个老生常谈的话题，近期笔者遇到一个很是棘手的问题，就是关于高并发的，目前是支持30W个终端，但是由于后期还会持续增长，当我听到的要支持500W的时候，感觉很快就会拥有秃秃的脑袋咯，不过不要慌，办法总是有的，查看各种资料和请教了几位大佬，将问题一步一步给化解了，接下来将分享怎么去打造一个高性能，高并发的服务器。
架构演化之路
1：最简单的--- 直接访问tomcat 单体应用，基本上没有问题
2：考虑到tomcat处理task的上限（加上调优）还是有点扛不住呀，用nginx做负载均衡，相比这个应该也没有啥问题
3：发现这个时候DB的压力会比较大，于是做了读写分离，没毛病
4：就算是做了读写分离，但是现在大量流的一般都是查询，DB还是存在这瓶颈的，可以考虑DB集群（目前mysql已经支持），此处略过，本篇中考虑到缓存（由于现在项目基本上都是分布式的，然后考虑到分布式缓存），于是有架构图就成了下面这个死样子
5：4中只是基本上解决了读的问题呀，但是要是写的话怎么办？还不是要直接往DB写，每次都写？不存在的好吧，考虑到使用缓存，等数据累积到一定量的时候，再一次性的将数据写入DB，或者是ES（经过本人测试，ES写的性能是真的低，但是读的是真的强大，基本上可以在数G的数据中100ms内返回。），这里使用JVM的缓存，可能需要全局时钟。然后架构图是这个样子滴
6：以为到这里就结束了吗？做为一个即将拥有秃秃的脑袋的人，肯定不能止步于此，于是考虑到能不能不让请求不经过后台服务器而返回结果呢？于是有了很是牛逼轰轰的OpenResty（nginx的加强版本，原作者俄罗斯人，由中国人对其进行强化升级，加入一系列的插件，并开源，目前JD使用这个做商品详情缓存），目前在项目中使用到OpenResty的Cache(操作nginx的缓存，可设置过期时间，缓存大小，策略等等),mysql（可以直接操作mysql）,redis（可以操作redis）模块，配合着Lua脚本一起食用，结果真的很香，然后架构图就演化成了下面这个鬼样子，反正看起来有点小复杂。
总结
在项目中不乏出现很多高并发的问题，可以考虑到很多解决方案，比如说单体不行，我就分布式+集群，还是不行就考虑上缓存，缓存又可以分为两种，服务器缓存和web层缓存，然后还可以代码优化，不必要的同步可以改异步，使用线程池，对于线程池的参数可以去调优，参考https://blog.csdn.net/weixin_45191798/article/details/100153524 ，对于大量数据流量写的时候，可以考虑到号称千万级的KAFKA来做流量削峰，最后还要是真的不行，带着秃秃的脑袋，回家种白菜养猪也不失为一个选择（猪肉还是比较贵的，发家致富之路），喜欢JAVA以及架构的同学可以一起来讨论，交流鸭。