只是量变累加并不能得到质变

重复就重复呗，现实里无所谓的，统一库抽取的应该是经过考验然后按标准库流程仔细设计后来建的，过于抽取会大幅增加学习成本不说，而且吧设计不标准的大量库其实比重复代码更坑

iptables 重定向，然后代理负责自行解析协议提取域名再发往代理服务器？这样子么

既然不支持 ipv6 ，那路由器也不认识 v6 协议和 NS 数据包啊，所以未知数据包除了丢弃还能咋处理，别本末倒置啊

@dong706 #7 只有 proxyMode 为 iptables 的 NodePort 支持 externalTrafficPolicy 为 Local 会保留源地址吧，如果是 LoadBalance ，那么就要看各自云厂商自己怎么实现了，其他的 proxyMode 也要看具体云厂商的实现吧

https://gist.github.com/snower/1239357e50758991f06dd4b6f60f135c

这样？

认真说楼主别怪大家吐槽你，其实也不是没人愿意，只是按你说的从技术上看大概率不是啥复杂有价值的事情，那么问题就来了，如果最后失败了，你在次过程中记录的营销经验、人脉和市场资源依然是你的收益，日后也会是你的助力也还能变现，再说吧这本来也就是你的工作，可是技术方就不一样了，所做的系统方案不是啥有价值的，各种资源也掌握在你手里，白白浪费了时间，啥收入收益没有，你不觉得这双方明显风险收益不对等么？而且你也说了可能要一年，这时间成本这风险，说你是骗子也没啥可说的吧，所以还是实际一点好

@tool2d #18 你搞错了，作为一个为传输编码设计得数据结构来说，写法方便并不重要，都是计算机编码解码的需要啥手写方便，最重要的是需要在任何语言和场景下通用简洁无歧义且尽可能高效，就楼上说的，如果可以省略引号那么处理起来就多狠很多情况需要处理，比如 key 就是引号或者其他特殊字符，作为传输编码的数据结构来说，除了增加编解码复杂度和速度外这样的价值在哪

此外每个语言都有最方便写 map 的数据结构然后转化为 json ，也就是最符合本语言规范的语法糖，JSON 不止是 JavaScript 的 JSON ，JSON 能得到如此大范围使用是因为其可以非法方便的用于不同场景不同流程不同语言间传递数据，毕竟只有 JavaScript 用着方便毛用没有，而且你确定 JavaScript 的这个语法糖不是一个坑，只是一开始没设计好然后又不好改所以也就将错就错了

10 年 20 年后都老了，恰好有一方或者子女父母残疾了，恰好婚姻自动结束了，恰好他可以自身自灭了，是这样么

婚姻本来就是绑定经济物质宗族深度锲约，共同抵御风险增加生存资源的，本来也不是只看你们感情好不好的，否则以前一两千年父母之命媒妁之言啥的干啥的，也就是现在生存危机不那么紧迫了才搞得起来自由恋爱自由选择了

@tool2d #105 其实私自拷代码确实不太好，不管公司大不大，如果尽职尽责公司也挺开放，最好还是远程回公司电脑继续，做的时候可以和公司 leader 随口说一下看看他是否反对，或者你干脆带自己电脑呗，公司不反对，后面也就不是你的问题了

说白了这就是一个服务质量提前成本会明显非线性增加，而又无法规模化平摊成本，业主自身实际能使用的服务有限沉没成本非常高，很难有好的方案

@Cagliostro 那估计你说的这是平原地区，我们这云贵高原山区，乡村道 3 米算是很高的标准了，而且到处是一个接一个超过 90 度的急转弯，开 20 码才是正常的，开 40 百分百翻车，过村子遇人我都才敢开 10 多码，高原修路太难了，我们这县乡道才修 5 米多，限速就是 40 ，小车超过 50 码基本过不了弯

@gbqqaybc 激动毛啊，都说了乡村道，一般也就 2.5 到 3.5 米宽，经过村子你还想咋滴，县乡道普遍限速 40 ，经过村子估计就是限速 30 了，平原地区乡村道过村子也许能开 40 ，丘陵和高原山区村道你开 40 那是你在找死

乡村道路过村子 40 码超速了，一般都是限速 20 ，你这么开没撞到人自然没人说你，撞到人了你还有啥说的

@northbrunv #14 我说的时从用户这边看上行，也就是云主机得下行，机房那边也就是宽带运营商的下行带宽，因为一般运营商下行带宽一般较高，而实际业务中用户上行流量又毕竟低，一般剩余带宽较多，所以云一般不云主机的下行流量，但是并不意味着这个带宽就是无限的，人家给的 10Gbps 共享是突发带宽 10Gbps ，可没说你可以一直占着 10G 用吧，云也是真金白银的从运营商买带宽，一个机房那么多人，没这种好事吧

上行带宽虽然一般说不计费，但是你这么干估计还是会触发风控的吧，毕竟上行带宽也不是无限的，你直接干掉 1G 而且一直不停，等同于占了同机房的其他人的带宽，可能影响其他人的服务稳定性，机房那边不可能不管吧

认真说人家说次品率 30%，每箱又是 100 个，又是随机整批装箱，那么大概率是符合统计学结果，每箱不好的估计大概率就是在 30 个上下，所以不用纠结这个，这种情况研究概率大概率不会帮助你挑到好的，还是约定次品比 30 高多少就退货更靠谱

挑选的 3 个都是正品的概率似乎是 1-0.3*0.3*0.3 ，但是按这个流程似乎各箱之间是独立事件，所以通过拿出来的 3 个决定买哪箱，3 个是好的坏的情况对你买整箱情况似乎影响不大啊

@BenchWidth #10 没懂 nacos 还能影响这？也不是每个请求都需要请求 nacos 吧，那 nacos 应该和并发无关才对

如果有经常会出现短时间内并发数剧增的情况，建议限流，服务有最佳处理延时和 qps ，限流排队要比直接打到服务上效率要高得多，可以测测看，一般一个节点给 64-256 并发应该就最佳了，而且入股是短时限流排队更有利于削峰吧