能否新增对整个NS的所有配置总的字符大小进行限制的功能

[youngzil]

你的特性请求和某个问题有关吗？请描述

Release 表的 configurations 是一个 LONGTEXT 字段，过大的配置，会给数据库的查询带来巨大的压力，同时也会给Apollo服务端带来潜在的隐患，可能导致网络带宽占满，CPU和线程飙升，RT上升

下面分享一个案例

1. Apollo config 部署4个节点，机器配置8c16G，jvm参数 -Xmx8G -Xms8G
2. 某个公共的NS存储配置总的大小43M+，客户端监听节点数800+
3. 日常/notifications/v2 qps 400+ /configfiles/json qps 400+ /configs qps 2000+
4. 当这个43M+的NS release后，导致网络带宽超过达到上限的50%，CPU被打爆，进而导致服务被SLB判定为下线流量掉底，其他节点重复此流程，直到NS客户端拉取配置结束，导致服务端异常持续几分钟
5. 在此期间Tomcat线程被打爆，其他请求被阻塞，RT上升，Apollo鉴权异常

清晰简洁地描述一下你希望的解决方案

提供NS下所有配置总的字符数（字节数）大小的限制，避免数据库和网络带宽导致的Apollo服务端的不稳定

清晰简洁地描述一下这个特性的备选方案

其它背景

在这里添加和这个特性请求有关的背景说明、截图

[nobodyiam]

通过 item.num.limit + item.value.length.limit 应该能起到控制总大小的效果？

[youngzil]

通过 item.num.limit + item.value.length.limit 应该能起到控制总大小的效果？

这是一个间接控制的方式，但是这个对于item.num.limit 、 item.value.length.limit 的值怎么能既满足所有appid，又能控制不产生huge的NS配置会是一个需要统计的基础数据+一些小技巧

实际业务中不同的namespace可能会有以下几种场景

1. item.num 比较多，但是item.value.length 并不大，所以NS总的配置并不大
2. item.num不多，但是item.value.length 比较大，所以NS总的配置也可控
3. 但是当一个NS是 item.num比较多 + item.value.length比较大，就可能会逃逸出 item.num.limit + item.value.length.limit 的限制，并产生一个huge的namespace

[youngzil]

说一下实际使用的体会和理解，如有不对帮忙指出，解释了item.num.limit + item.value.length.limit 无法满足的原因，就是下面的第【5】点

1. 实际上item.key.length 和 item.value.length 直接通过item表的DB的字段定义就控制了，当然实际也可以起到二次控制的目的（配置比数据库定义字段更小的大小），否则估计都可以不校验
2. item.num、item.key.length、item.value.length 的另一个目的就是可以间接控制NS总的配置大小（Release 表的 configurations ）
3. 实际上对Apollo的数据库和服务影响比较大的是NS总的配置大小（Release 表的 configurations 是一个 LONGTEXT 字段），因为这个如果存在（大configurations + 多次Release + 监听节点多），就可能会导致数据库、Apollo服务的网络带宽、磁盘、CPU都会带来很大的压力甚至直接被打爆的情况，当数据量大的情况下，这个应该是比 item.num、item.key.length、item.value.length 的影响更大
4. 如果存在对NS总的配置大小（Release 表的 configurations ）的控制，其实甚至完全都可以不需要item.num、item.key.length、item.value.length（ item.num的目的是间接控制的作用，后两者直接数据库定义就限制了）
5. 存在对NS总的配置大小，可以直接解决上一条评论里面的3个场景（实际中我们也是尽量保障前2种场景，就导致item.key.length 和 item.value.length 不能设置太小，但是就会导致意想不到的第三种没法限制） BTW：其实还有一种情况：item.num 比较多，但是NS中少量大item.value.length的情况，也可以包含在下面的1和2中

   1.  item.num 比较多，但是item.value.length 并不大【可以覆盖，业务也更灵活，可以自行控制数量和每个配置的大小】
   2. item.num不多，但是item.value.length 比较大【可以覆盖，业务也更灵活，可以自行控制数量和每个配置的大小】
   3.  item.num比较多 + item.value.length比较大【可以覆盖，可以被限制，业务自行决定拆分NS、或者增减  数量 或 配置的大小】

[nobodyiam]

存在对NS总的配置大小，可以直接解决上一条评论里面的3个场景

这个控制粒度更粗，确实可以覆盖上述几个场景，不过目前已经存在了更细粒度的配置项，在精心配置的情况下是可以达到类似的效果，所以我不建议再增加额外配置项了，会令系统的配置变得非常复杂

[youngzil]

Yes，get it