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

[monkeydev]

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

[lecher]

有专职的人员维护这套基础设施吗？
没有的话，公司愿意为这套基础设施投入人力成本和机器成本吗？
要是都没有，谁来背这套基础设施玩不转的的锅？

做为技术人员，碰到这种新技术能实践，应该感到兴奋才对。选择成本恰当的技术方案应该是架构师头疼的事情，普通开发难道不是恨不得把业界最新方案全用上，好堆简历背景吗。

[loliordie]

不适合 小团队初期用 django 加 react 撸一套方案就完事了 如果跨平台就用 flutter 或者 kotlin 你们应该考虑的是开发难度而不是扩展性 因为不管你们怎么搞发展到一定规模都是要重构的 对于你们而言快速上线和敏捷开发是第一位的

等你们业务成熟了 再来考虑这样重一点的架构 不然很容易被拖死

[tesguest123]

搞半年搞不下去跑路，🐶。

[fff333]

@loliordie kotlin 能开发 iOS 了？

[Leigg]

你都说了技术比较弱了，你还搞这套架构那不是坑你自己，还坑了公司。

[coderxy]

小公司单体就可以了。

[loliordie]

@fff333 kotlin native 不过这个方案我没用过

[wg20080215]

有 10 前端+后端开发没？没有就直接单体就够了。

[kingfalse]

鲁迅说过，不要为了用而用

[glacial]

讲实用性 单体集群模式足以, 小团体搞微服务 基本上不是技术上的考量 ，而是商业上的考量，不搞微服务 不高大上 不好与别人讲 不好卖钱

[monkeydev]

@lecher
@loliordie
@glacial
不用微服务，那如何实现得功能的模块化，满足不同的需求昵

[NaVient]

@monkeydev #11 搞了微服务，小团队不一定搞出你想的这样

[MaxFang]

@monkeydev 小团队搞这些东西投入产出比不合适。拆的过小，增加维护难度，可能多个服务是同一个人开发，小团队拆分的边界划分也是需要业务组织上分工清楚。小团队几乎没有人来弄这个东西。 不拆分，做好模块接口隔离也是可以的呀，做到底层业务模块是独立的。

[hantsy]

DevOps 跟不上，做不了自动化运维，全部靠人肉运维，还是别想了，额外付出的代价即使天天加班也不够补偿。

[SuperManNoPain]

得不偿失🌝🌝

[statement]

可以呀。 面向跳槽编程

[lfzyx]

运维这块可以交给专业的公司来做

[wdwwtzy]

不适合，太麻烦了

[monkeydev]

@MaxFang
@lecher
@loliordie
@glacial
@hantsy

感谢解答
请添加我微信
请大家喝杯奶茶
也有项目也可以做啊
微信前面帖子里面有

[monkeydev]

联系方式：c3Zlbml0eQ==

[liununu]

上了 k8s，就不要用 Spring Cloud 那一套笨重的东西了，k8s 生态里都有链路追踪和远程调用的替代方案。至于微服务也应该贴合具体业务上下文的关系来，如果每个业务都拆开，维护成本提升会大于利处，徒增消耗。

[monkeydev]

@liununu 感谢指导

[loliordie]

@monkeydev 在并发不高时 可以通过 redis 队列实现 搞几个队列 然后根据不同模块开 worker

比如 heroku 这种集成化的平台 add 一个 redis 然后根据模块开项目即可

起码这个架构 我们目前上千的并发 没啥压力

[namelosw]

如果可以预见的未来还是小团队的话, 单体就好, 部署的话搞个 PaaS. 你说的这些可以搞, 但是对于小团队来说就是凭空创造工作岗位.

[cyssxt]

没有必要的，单体应用就可以了

[S4msara]

不建议，上上家公司小团队，上了整套微服务方案，docker, k8s, cloud，当时我也觉得诧异，以我个人的拙见其实单体就可以，用户量上来了做单体集群即可。后来公司倒闭，发现团队 leader 是面向跳槽编程，害人不浅，当然，老板错误估计公司发展是主要问题

[catror]

微服务，和模块拆分功能拆分没有强相关性

[autogen]

cdn+nginx+springboot+redis+mysql
每分钟请求量小于 3000 的，用这套就可以了

[799635347]

没必要，一个 SpringBoot 他不香么

[Lonely]

单体集群也可以用 k8s，cloud 那套倒不是必要的

[sampeng]

适合。堆简历跑路用

[dayeye2006199]

取决于业务是什么。我目前的公司只有两个人，但我们是做 服务和计算集群管理的，所以使用这个架构基本是唯一的选择。如果是 CRUD boy 就没必要了。django，react 前后端做个分离，一把梭了

[jwangkun]

我们技术团队目前 20 人，外包团队加起来有 80 人左右，目前就是 SpringCloud+K8s 这一套。目前是我在主推，前期是需要花点时间来做一些基础的工作，但是对于后期来说节省了太多的时间成本，没有用过就没有发言权，那些劝你别上的，估计自己也没用过，而且上 k8s 对于开发人员来说是无感知的，至于 Springcloud 我们用了三年了，你会了 Springboot，业务大了自然后拆分，看你业务的复杂性，我们单体和 SpringCloud 都有，具体业务选择不同的架构，只要做大，上微服务是必须的，就看你们现有业务体量了

[xuanbg]

微服务可以搞，k8s 没必要。

楼上说小团队搞不来微服务的，我表示我一个人就搞起来了。根本没什么难度，开发反而更简单了。

[rapperx2]

个人觉得和公司大小无关，看项目吧。像我们公司 10 人以下。其中一个项目最好的架构就是微服务。不管从那方便都是最好的选择。 这个项目最大的特点就是增长用户数快，前期如果不这样做，后期做架构升级，时间是不够的。而且经常需要第三方扩展

[ArJun]

看公司前景，公司用户多、上升快有必要用，还有有些公司融资会拿这些做噱头也有必要

[leeyuzhe]

像楼上说的，作为研发应该是好事啊，方便堆简历~

[90928yao]

@jwangkun 你也说的是 80 人左右的团队了。几个人的团队搞这个就是扯淡。一个 war 包部署上去就行了，量多了加机器。

[a719031256]

项目后端人数在 10 人以上可以考虑微服务，10 人以下还是算了，没必要

[ChevalierLxc]

看到小团队 那就算了

[zhanlanhuizhang]

可以看看： http://highscalability.com/blog/2019/4/8/from-bare-metal-to-kubernetes.html
http://www.winder520.top/hou-duan-fu-wu-jia-gou-yan-jin/

[f6x]

k8 成本很高的.
人家给你的复杂方案,等你折腾半年弄懂了, 最后会发现有价值的就是服务里那几十行 php 代码.
哈哈哈.

[yedan1206]

不适合

[lamesbond]

要是能上就偷着乐吧，刷简历美滋滋

[q447643445]

同意楼上的. 也就刷刷简历有作用. 实际用起来. 大半时间在维护上. 成本巨高

[securityCoding]

外面给的方案靠谱不 , 不如直接上 a 家的 edas 啊,我们公司在用挺不错

[fx]


[salmon5]

面向跳槽编程，可以可以

[jasonkayzk]

写个 Hello-World 需要用 k8s +Spring cloud +微服务吗？
如果是为了学习，怎么折腾都可以；
如果是商用，不建议折腾，你会发现大部分时间都浪费在了运维上；

[fengliu222]

阿里云、腾讯云、aws 和 gcp 都有现成的 k8s 基础服务，腾讯云好像还是免费的，配置一套下来也就几个小时，成本并不是很高。
个人认为，超过三个人就需要架构，这是在降低风险而不是炫技。
是否需要微服务和 Spring Cloud 是要看你本身业务形态的，大家不知道你业务的需求，也没法给你最适合的答案。

[Ravenddd]

不是用微服务, 那就单体部署, 代码分模块即可, 以后转换微服务也很方便

[renmu123]

小团队用微服务，k8s 没什么意义。用户起不来纯粹就是浪费，何况你们基础差，前期服务器不够加一台就是了，还是先把产品做做好吧

[adspe]

不合适

[CoderGeek]

小团队先活下去，量上来了在考虑这些

[CoderGeek]

先代码上分层分模块即可

[w0nglend]

可以上没问题我们就是小厂（ PS，可以联系我远程支持，逃。。。）

[beneo]

本司从 k8s + springcloud + 微服务，直接搬到了阿里云 sae + 云效，不知道有多爽，以后程序员不用专职运维了，多花钱了吗？当然贵一点点，但是交付效率 biu 的往上涨

[snail00]

我们后端开发不到 10 人, 架构经历是 tomcat+war => spring boot => spring boot + docker => spring boot + 阿里 k8s => spring cloud + nacos + 阿里 k8s , 以上历时一年半

[zoharSoul]

k8s 就不需要 spring cloud 了, spring boot 就够了

[a398058068]

单体够用就单体，如果非得上 单独 k8s，如果非要熔断 限流这些 直接上 istio + spring boot 。 下下策是 spring cloud +k8s

[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 ,搞得我这个后端开发都快变成运维了,真心建议:人员不多的小公司,不建议项目搞得太复杂,心累

[jaylee4869]

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

[kevinwan]

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

[jaylee4869]

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

[kennylam777]

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

[ydpro]

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

[ren2881971]

别折磨自己。

[vanityfairn]

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

[muskill]

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

[LichMscy]

我们团队现在运行维护着一整套的 k8s 平台和微服务平台，遍布全球十几个数据中心，拥有 20+套集群，最近还合并了另一个团队的 devops 平台，感觉应该有点发言权

其实用 k8s 和团队大小没有强对应关系，团队小就找两三台虚拟机搭一套小集群满足需求即可。我理解微服务所利用的 k8s 特性主要是实现滚动更新、灰度发布以及 hpa 等，还可以利用 cicd 工具一键发布，这些特性不用 k8s 甚至不用 springcloud 都能实现，只是现有比较成熟的方案的确是 k8s+springcloud 微服务。我建议楼主从最小需求做起，切忌过度架构，构建出的组件稳定可用满足最低需求即可。
可以理解基于 k8s 的模块是一套 paas 平台，基于 springcloud 微服务的模块是 saas 平台(当然我们也基于 istio 构建了一套 service mesh 模块，那个才是真正的 sass 平台）。如果从开发角度，专注实现 saas 平台的基本功能就可以了，往后团队大了，面临的问题还有日志采集，服务监控，链路追踪，网关路由，容器网络管理，底层计算资源维护等等等等。


TLDR：最小化架构的话只要能给开发部署和发布版本带来便利即可，比如使用 jenkins/搭建 k8s 进行容器化的初步集成 /使用 k8s 滚动更新 /进行微服务改造并搭建 eureka 和 gateway 管理所有的微服务等等；再发展下去就可以考虑构建一个微服务平台（ SAAS ）来管理整个微服务的生命周期，包括链路追踪 /API DOC/服务间调用 /配置中心 /分布式事务等等；最终就是一整套 k8s 管理 /微服务管理 /Devops 管理的覆盖开发全开发生命周期的工具链集合。

[ming7435]

没有千万级的业务规模强行上这种技术方案简直就是找不自在

[vcode]

k3s，k0s

[zardly666]

我司因为服务端语言很多，py node.js java 所以是 k8s 集群的微服务。感觉花一点时间熟悉以后，用起来很舒服

[zunceng]

@ming7435 你这说的... 当年我司只有我一个开发都用 k8s + 微服务架构

这套东西很好的解耦了运维和开发， 越是小团队越要注意这些呀， 而没什么经验的时候又是最蛋疼的

[wizzer]

小团队，建议使用我的 https://budwk.com 框架，有微服务版本也有 mini 单应用版本

[wupher]

看团队水平， [小] 不影响技术使用，但是技术薄弱就不适合了，K8s 有问题，要能自己搞定的。

这种情况下，直接用云计算，多专注业务实现挣钱。

[ming7435]

@zunceng 一个人能搞定的业务能复杂到哪里去？一个 war 包一把梭说不定效率更高

[JohnSmith]

上云

[JohnSmith]

上共有云

[xuanbg]

微服务也可以很简单。一个最简单的微服务，就是注册中心+配置中心+网关而已。需要写额外的代码吗？不需要！都是 pom 引入一个包，然后启动类一个注解，配置文件几行配置就完事。最后就是需要在配置中心分别对每个服务做一下配置。就这点事情，百度一下最多 1 天功夫就搞定了，压根没有什么难度好吧。

[twinsdestiny]

duck 不必

[dayeye2006199]

问个问题：用了 k8s 为啥还需要 spring cloud ？自带功能，最多加个 istio 就能覆盖各种特性了，而且还是语言中立的，支持各种语言写的服务。

[zarte]

搞这一套有问题谁加班弄？能简单就简单别像有些自以为是的程序员，到时一堆坑还要别人搽屁股。

[zunceng]

@ming7435 几年过去我司有个几十个开发+运维了 仍然是这套架构 老板都说 CTO 来了是站台的 随便折腾 技术架构我来决定就行了

[ericgui]

github 其实到了很大的规模的时候，还是 ruby on rails 单体

[dorothyREN]

不如先想想 你们的项目 值得上微服务吗

[young1lin]

@kingfalse 我周树人可没说过这句话。狗头.jpg

[kingfalse]

@young1lin 我说了是鲁迅，你周树人来凑什么热闹。狗尾巴.gif

[dadagogogo]

@muskill 感同深受啊