小团队 适合用 k8s +Spring cloud +微服务吗

[monkeydev]

目前公司技术基础比较羸弱
外面给的方案是这一套
但我个人认为这只是谈架构的东西
如果用户不到一定规模似乎，没有必要

[zc1249274251]

没有足够的技术积累 会把自己坑死 而且根据现有业务发展基于现有技术基础 做一定的预估 再去调整技术方案 如果没有那么大的量 负载加单体都可以 一点点去迭代都可以

[ElmerZhang]

除非团队里有人对这些东西非常熟，能 cover 各种问题，否则还是不要去碰这些“高大上”的东西了。
如果公司有钱，直接招更牛的人来做架构带团队。否则还是会啥用啥最靠谱，只要能实现需求就好。
另外，对于完全不了解你们团队和业务上来就直接说该用 XXX 的，最好都直接忽略。

[kevinwan]

我们最早支撑小几百万日活时后端只有 6 个人，全部基于 k8s，使用自研 go 框架

[matatabi]

适合，这些都能为自己的简历加分

[iyangyuan]

这套架构，业务还没开始做，至少已经跑满 10 台服务器了

[halk]

@kevinwan #63 后来呢？

[devehx]

我们公司现在只有 3 个后台，运维也没有，居然搞了个微服务写后台管理系统，拆成了几个模块，全部部署到一台机器上，我都不知道做微服务有啥意义，增加了很多写代码的工作量。感觉小团队最好不要搞这玩意儿

[yalin]

听说的大佬话语：康威法则；架构是演化出来的，不是设计出来；没有银弹。

[0bit]

没必要着急上 k8s，但是容器化可以先做，12 factor 可以先搞起来（ https://12factor.net/zh_cn/），有这个基础之后，后续想迁移也容易了。

[0bit]

链接 Bug 了：
https://12factor.net/zh_cn/

[kevinwan]

@halk 后来开源了呀，github.com/tal-tech/go-zero

[muskill]

我们用 swarm +spring cloud ,搞得我这个后端开发都快变成运维了,真心建议:人员不多的小公司,不建议项目搞得太复杂,心累

[lavvrence]

Kubernetes 成本也不会非常高；但是如果用了，目测 10 年技术栈不会落后，K8s 的长尾效应带来的时间收益很高。

[kevinwan]

@muskill 不要 swarm 呀，我们 go+k8s，千万级日活三个运维足够了

[lavvrence]

@muskill Docker Swarm 赶紧扔掉。我也是后端，最近也在搞运维等基础设施，swarm 彻底死了。

[kennylam777]

一個人搞的 K8s 都比十個人維護 Swarm 強，勸退+1

[ydpro]

搞不搞这个技术栈看你们是赚投资者的钱还是赚用户的钱

[ren2881971]

别折磨自己。

[vanityfairn]

DevOps 没有的话，我赶脚不得行噢，最后还是搞自己。技术薄弱么，单体不香吗？怎么简单怎么来，用户量上来以后，无论怎么样，还是会重构的。。。不然前期这么重，真滴累死

[muskill]

@kevinwan @jaylee4869 二位说的很对,目前也在努力学习 k8s 中