@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 并发应该就最佳了，而且入股是短时限流排队更有利于削峰吧

3000 并发已经很高了，200-400ms 延时，每秒 qps 过万了吧，502 估计就是 #5 楼说的问题，网关无响应被标记为不可用节点了，3000 并发已经是很高的值了，每个请求都要查询数据库的话，想不超时估计需要各种优化了

@morty0 redis 只能单主的，不存在网络分区问题吧，网络分区后 redis 在哪个区只有哪个区能用，都不在就都不能用

@Nnq #11 dev 和 test 分支其实还有个用途是，dev 是开发分支所以应该自动更新部署到开发患教，test 则应该自动部署到测试环境，master 是最终版肯定是只包含可发布的代码才对，所以一般都是测试完成从 test 分支合并过去的

微服务 devops 还有个麻烦的事情就是，假如同时有个功能版本同时开发，那就需要部署多个不同版本，服务非常多那这个工作量就非常大了而且非常耗资源，所以我们的做法是标准的 dev 和 test 分支其实是基础版本，一般不能直接用于开发测试，而是每个版本再次创建 dev-v1 和 test-v1 这样的版本分支，然后在通过 CI CD 自动部署到 k8s 集群里，这个过程只有你当前版本需要改动的项目才建版本分支部署项目，然后通过流量染色和服务网格来组一个完整服务切面，这样就能用很小的资源和工作量给每个版本一个相对独立和完整的环境了

通过流量染色和服务网格来组一个完整服务切面这个过程也不复杂，就是前端请求里应该都带标准的版本、设备、用户标识信息，这些信息到后端后会在整个请求链路中传递，然后通过服务网格的流程来做流量匹配，如果某个服务有对应版本就请求对应版本的服务，没有则由基础版本来处理，这样你只要部署你需要修改的项目，然后用当前版本的 app 访问就能访问到你修改的服务上去，无论你的服务位于请求链路的前面和后面，而创建 dev-v1 和 test-v1 分支部署到 k8s 并注册服务网格信息这个过程完全由 CI CD 自动完成

比如整个微服务由 200 个服务组成，现在有一个版本 v1 的迭代只需要修改项目 A 和 B ，那么你只需要在项目 A 和 B 创建 dev-v1 分支，这样你就有了一个独立的 v1 版本的开发环境，其余的项目无需任何处理，测试环境也是一样的

这样一个 v1 版本的整个开发测试发布过程就变成了 dev-v1 分支完成开发，然后基于 dev-v1 创建 test-v1 提测，测试完成等到发布周期是合并进 master 统一发布，发布后 master 再合并到 dev 和 test 分支完成基础版本更新，最好删除 dev-v1 和 test-v1 分支清理环境和资源

也许只是你没装宽带所以你爸妈才不会上网，而他们说不会上网也许只是想省点钱和没用过，如果费用无所谓又有条件，先装上再说呗，也许后面就发现他们其实会的，你不给创造条件那肯定不会了啊

没必要吧，反正各 app 也只是代销，就算人家倒闭了你的基金理财也不会有啥事，找个大一点的平台或者招行这样的 app ，就算有啥事偶尔出点毛病基金理财啥的难道你还能立刻去买了止损？股票这种虽然你能立刻卖，但是吧一般小散来说除了自己闹心，早卖一点晚卖一点最后一看估计也差不多，人家挂也不可能挂几天的，搞这么多说不定自己哪天记错了或者收益损失算不清买错卖错损失更大来着

如果是 CI CD 后端微服务的话其实感觉都不好，在这个流程中，GIT 的分支管理应该满足三个不同需求

开发-》不同人不同功能分别在不同分支开发 codereview 后合并进总 dev 分支
测试-》按不同测试提测进度合并到 test 分支然后构建测试服务自动完成部署更新
发布-》测试完成合并进 master 构建发布版最少上线同时创建 tag ，这个过程可能又有多个不同功能分别开发测试最后一起发布

微服务 devops 流程中 GIT 分支不应该只管理开发过程，测试发布依然用镜像版本号来管理提测和发布进度，感觉过于坑了，因为镜像不能直接 diff 出改了啥，配合 CI CD 后应该随时提测更新发布，一天一个项目更新个十几或者几十次很容易就乱七八糟了完全分不清哪个改动是哪个版本的，所以镜像版本实操性太弱，应该还是以代码来做版本管理，然后在 build 的镜像信息里打入 git 的 commit 信息，然后同时记录到链路追踪日志里，整个就比较清楚了，CI CD 的执行也会比较顺畅

当然以上流程需求其实实际操作上是大多简化运行的，毕竟迭代虽然很多但是微服务体系下单个项目同时被修改的概率还是低很多的，所以大多数情况下只一个人改一个功能应该就 dev test 和 master 三个分支就行吧

既然如此，为啥第一步编译打包 jar 要放在 docker build 里呢，用 docker run 来运行 mvn package 就是了呗，把项目目录和 maven 缓存都-v 映射进去就是了呗，编译完了 jar 文件就在宿主机目录里了，然后再 docker build 就是了

既然如此，直接实现成分布式锁的逻辑就是了呗，谁获取锁成功谁就能操作或者是 leader

且不说各种饲料主要成分就是转基因豆粕，做菜和各种零食的油一大半估计都是转基因压榨的，都吃了喝了十几年几十年了，不止我们吃喝，国外那不照样是，这 up 主根本就是狗屁不通，瞎 BB 哗众取宠，还什么讳莫如深“不能细说”，这种基础品可不是食品添加剂，根本不可能防得住，要是不足够安全，搞这个自己也得掂量掂量