请各位大佬,指导 /分享一下最佳实践方案

- - 问题是 quarkus 你们团队 hold 住么，这才是问题

3 万终端拉起来这么大的架子，你让我这做过一个 exe 后端抗住几万连接的咋指导

不懂就问，“项目人员基于 人力资源池模式” 是什么意思

1. 赞同 2 楼的观点，“开发人员水平较低”，这种时候不要把复杂度下放到业务编码层面。
2. 时序数据库有个 InfluxDB ，如果已经看过并排除了就算了，不然可以将其加入待选列表进行对比。
3. 从描述上看，你是想将已有的项目更换到新的技术栈？由于没有给出架构图，也不清楚这些设备包含哪些协议，还有常见的日志系统，链路追踪啥的也没看到，不知道是用现有的不改还是怎么样，就目前看你列出的东西都是比较主流的，使用肯定没啥问题，其中 knative 目前的成熟度怎么样，我不太清楚，可以蹲一手大佬。

最后，如果这是在调研方案时发帖寻求帮助，那我觉得没啥问题，群策群力
但是如果这是在内部讨论后发帖询问可行度，那我觉得还是把步子迈小一点，慢慢来，仔细考虑下这其中某些技术能给你带来多大的提升，比如用上 knative ，换 flink ，毕竟你的现状中并没有说目前的架构出问题不是吗。

这指导不了啊 做过的项目中 3W+就是基于 springboot+netty 做 jar 放到一台服务器就完了

同意楼上有几位朋友的观点，做技术选型一定要考虑团队，不要什么高大上选什么，做不出来的高大上都是海市蜃楼。

看了你的规划，我发现你现在的步子非常大，需要大厂才能玩，但是如果是大厂，就没必要来论坛提问了，所以我权当抛砖引玉，做一点自己的感想，说的不好，大牛们补充或者指正：

1：k8s 化过重，你这套选型大量 k8s 的产品，需要团队至少有 3 个人熟悉 k8s ，并且有 2 个专业的全职 k8s 人员才可以，如果不是，建议不要轻易玩的太深，只做单纯的平台就好，等你们后期稳定了，你可以考虑在迁移一些功能到 k8s 上。举例：你的 knative ，kubeflow ，istio 真的有必要么，收益率高么？现在的技术方案问题很多到必须换技术选型才能改正？你先反问自己这几个问题，再做这块的决策。

2：mysql+sqlite 切 dgraph(存储设备信息等数据)/PostgreSQL ，这一步，我的看法是，短期保留 MySQL 应该没问题吧，做好 MySQL 调优即可。

3：victoria-metrics(存储时序数据)/TimescaleDB 这块，我不明白你们的底层数据存储格式，但是我之前做过一次，MySQL+Clickhouse 的组合，很完美、也很省心、省资源，楼主可以参考。当然监控领域，我们选择是 prometheus 。victoria-metrics 不熟悉，不做评价。
这里多说一点，切换存储是个很大的工作，很复杂，也很费事，影响也能大，光这点我觉得就要谨慎对待，不能为了做而做，必须收益率满足团队需求才有意义，所谓的新技术，很多新瓶装旧酒

4：前端：不喜欢有专业开发团队做使用一些低代码平台，按照你的描述，你的 deadline 其实还好，不然不会这么大动干戈。不如自己从头写，做好整体把控。这块仁者见仁，这只是我的看法，大家自己判断。

5：存储：minio 这类支持 S3 满足不了你们吗？ ceph 我不熟，但据我所知，比较复杂，不如 minio 简单，对于一般团队没有专业搞存储的或者做这类的团队，我不建议在这块上太激进。你不如看看 minio+juiceFS 这类方案

6：流式数据很多，对实时性这么敏感？ spark 切 flink 也是大工程量，也是看收益率的工作，我不建议做，用好一个足以，如果实在是符合 flink 场景，那么推荐 streamX

7：微服务：Quarkus 这里我真笑了，不是新项目，重构项目，坚持保留 sringboot 的结构，vert.x 团队有人 hold 住么？响应式玩得转么？如果非要追求 native ，用 springboot3 ，做好原有 springcloud 项目的重构和组合即可，完全不需要重写，更不需要换框架。您要是新项目，当我没说！对了，对于大项目来说，那点 native 冷启动和内存消耗来说，不算什么，需要做好的是：减少你的服务数，一般的服务，不要动不动拆成微服务。这块，能理解就理解，不能理解就去看 DHH 文章，不争论

8：CICD：drone 我用过，效果不错，可以替代 jenkins 了，团队有人能搭建就行。sonarqube 也就配置以下就可以。buildah 这块，配合你们如果有人有精力做专业 cicd 平台可以搞一下，不然我认为，做一套 k8s+drone+gitlab 就足够了，只要设置好项目 hook 和自动化即可。太多工作，反而喧宾夺主了，devOpts 是为了降本提效，让大家省心省力，不是为了让团队把时间都用在这上面，需要明白主次


总结：楼主这套，跟我之前的一些选型有一些像，我也遇到过类似的质疑，为什么不这样，为什么用这个这类问题。很多时候，架构选择，技术选型不是一个先进性的问题，是一个综合问题，你要优先考虑什么。
更重要的是，好的架构和技术选型，一定是能落地的架构，一定是大家（公司和团队）都是受益者的架构，一定不是人云亦云的架构，也一定是做了某些妥协的架构。

不要把新技术、云、大数据等等新技术，一股脑的塞给任何一个团队，任何的架构革新都是抽丝剥茧的变化，从收益率最大的那个入手，一点点来，适可而止，不要只考虑自己的喜好，多想想团队和后续。

以上是我的一些浅见，请楼主和各位大牛轻拍

感觉还是从实际业务出发比较合适，要么就是先重构某个部分，全盘大动也是给自己找难受