目录???
?某项目现场，发现每天晚上服务会挂，不是OOM就是服务假死，拒绝连接请求。1、OOM，直接看日志服务挂掉了 2、服务假死，看服务日志，日志还在正常打印，但是所有请求都被拒绝
??
项目背景： 以前在别的项目现场，数据中台，使用API服务对外提供接口之前，都是对数据进行加工处理之后，API只需要查询简单sql，不涉及复杂业务，而且接口有每次请求最多返回1w条的限制。
? ?这个项目，在以前API服务做了定制。1、项目甲方，不会数据治理，不会对数据加工，API提供的服务是多个表多次联合查询的接口。2、项目甲方，把API服务接口当做数据同步工具，让我们去掉每次只返回1W条数据的限制。
原因：查询日志，发现用户每页设置返回100w条数据，通过这个接口查询出的数据内存大小有12G,API服务总共就8G内存，直接OOM
解决：拿着有效证据，找甲方沟通，把每次接口请求最多1w条，加上。
原因：单接口，用户自定义的查询sql，sql很慢，分钟级别。每个数据源，后端数据库线程池核心连接数只有10个，高并发情况，导致10个核心线程还没返回请求，后面的请求已经达到，导致服务假死
? ? 解决：1、接口返回时间，做15秒限制，超时直接报错
? ? ? ? ? ? ? ?2、单接口并发做限制，每秒只接受5个请求
? ? ? ? ? ? ? ?3、其实最核心的解决方案，是推动甲方使用数据中台的离线、实时、集成工具，对数据进行加工，再发布API，否则上面的都不能完全解决问题。
? ? 原因：需要找甲方沟通，看看他们使用场景。他们把API当做数据同步工具
? ?解决方案：需要找甲方沟通，推动他们使用中台其他工具。如果不使用，问题解决不了。
甲方还没同意，所以问题未解决。。。。
可能还有别的原因，这个项目比较奇葩，天天都有新问题，以后补充
?奇葩项目，说服不了甲方。那就只能保证自己服务不挂，做限流，做超时限制，做连接限制，做服务数据量限制。限制不轻易放开，如果用户发现自己都用不了，反向推动去做数据治理、数据加工