@beitayongguo 蚂蚁扣项目细节 不咋问算法 shopee 比较常规

@beitayongguo 感觉中等水平吧

@919615766 1.钱多 2.蚂蚁卷

@wonderfulcxm 啊

@rulerstorm 是比蚂蚁多

@learningman 哈哈哈哈啊哈 果然是，没注意到

@ldcloli 嗯，方案可以考虑一下

@crclz 只有最前面的数据核心数据是，后面有大批的组合逻辑，这个逻辑相对独立。需求核心是，保障核心数据安全。
重试是不适合的，1. 性能不允许（支持单机 1w 的 QPS ） 2. 有时候错误的数据或者代码的异常重试无法解决。

自己实现类似 FilterChain 的东西，然后针对 chain 的调用做 try...catch.. 貌似也可以，但是对于前后依赖的数据有点蛋疼

1

在线等

有点奇怪的是，为啥使用 Chrome dev tool 的 Performance 排查的时候，就不卡了。。。

@gesse

[github star 设计初衷] 没仔细想过，估计他们老板或者产品比较清楚。
我个人把 star 当成收藏夹来着... 目的太主观，针对个人没有讨论的意义。

----
[而且楼主你这一连串“是的是的”，说的好像自己什么都懂，别人说的东西你都把八百年前懂了一样，沟通态度有点讨厌。star 当然少]
我也觉得自己讨厌，不过看看评论列表，讨厌的人可不止我一个。看淡点，这个世界就是这样子。

@sonxzjw 喔...那成本似乎比较高...哈哈

@xfriday
1. k3s is not k8s.
2. 注意看下主题的 append 啊... 应该是挺明显的呀。。。难道我写错了。我去查查

@securityCoding [k8s 成为事实标准了] 这个业界公认，没有啥可讨论滴....

@securityCoding 对于云厂商而言，swarm 必然没必要维护了。

但很多个人开发着的产品：1-3 台配置较低的机器

@sampeng 讨论方案不要极端。

[我觉得没有 k8s 我活不下去…实在懒得重复配一堆东西。一个 helm install。该有的都自动有了]
------
这个很多都可以做到，(ps: 我个人工作是这个方案)

[另外楼主说的三样东西只有 Docker swarm 是个容器编排的…其他在哪不能用？而且 swarm 还是个残废，功能被 k8s 甩一万条街。]
----
功能这东西，看个人需求，不是足够多就好。swarm 确实是个竞争中输掉的失败产品，但是某些场景下有其价值

@anubu 1 和 2 非常同意

这个方案看情况，很多人的个人项目，应该相对比较简单的，但是按照目前的大多数技术栈，稍稍为复杂的需求，考虑到一点扩展性，或者 2 -3 台机器部署的场景下，swarm 其实是比较好的方案了。

至于学习 /踩坑成本，swarm 几乎是有容易使用经验的用户几乎没啥障碍。。。