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

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

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 三个分支就行吧