小团队 适合用 k8s +Spring cloud +微服务吗
monkeydev 2020-12-07 20:00:05 +08:00 via iPhone 14266 次点击这是一个创建于 1827 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前公司技术基础比较羸弱
外面给方案是这一套
但我个人认为这只是谈架构的东西
如果用户不到一定规模似乎，没有必要
外面给方案是这一套
但我个人认为这只是谈架构的东西
如果用户不到一定规模似乎，没有必要
 | 1 lecher 2020-12-07 20:09:37 +08:00  14 有专职的人员维护这套基础设施吗？ 没有的话，公司愿意为这套基础设施投入人力成本和机器成本吗？ 要是都没有，谁来背这套基础设施玩不转的的锅？ 做为技术人员，碰到这种新技术能实践，应该感到兴奋才对。选择成本恰当的技术方案应该是架构师头疼的事情，普通开发难道不是恨不得把业界最新方案全用上，好堆简历背景吗。 |
 | 2 loliordie 2020-12-07 20:09:57 +08:00 via Android 不适合 小团队初期用 django 加 react 撸一套方案就完事了 如果跨平台就用 flutter 或者 kotlin 你们应该考虑的是开发难度而不是扩展性 因为不管你们怎么搞发展到一定规模都是要重构的 对于你们而言快速上线和敏捷开发是第一位的 等你们业务成熟了 再来考虑这样重一点的架构 不然很容易被拖死 |
 | 3 tesguest123 2020-12-07 20:24:08 +08:00 via iPhone 搞半年搞不下去跑路，。 |
 | 5 Leigg 2020-12-07 20:27:19 +08:00 via iPhone 你都说了技术比较弱了，你还搞这套架构那不是坑你自己，还坑了公司。 |
 | 小公司单体就可以了。 |
 | 8 wg20080215 2020-12-07 20:35:25 +08:00 有 10 前端+后端开发没？没有就直接单体就够了。 |
 | 9 kingfalse 2020-12-07 20:44:09 +08:00 via Android 鲁迅说过，不要为了用而用 |
 | 10 glacial 2020-12-07 20:48:44 +08:00 讲实用性 单体集群模式足以, 小团体搞微服务 基本上不是技术上的考量 ，而是商业上的考量，不搞微服务 不高大上 不好与别人讲 不好卖钱 |
 | 11 monkeydev OP |
 | 13 MaxFang 2020-12-07 21:10:49 +08:00 @monkeydev 小团队搞这些东西投入产出比不合适。拆的过小，增加维护难度，可能多个服务是同一个人开发，小团队拆分的边界划分也是需要业务组织上分工清楚。小团队几乎没有人来弄这个东西。 不拆分，做好模块接口隔离也是可以的呀，做到底层业务模块是独立的。 |
 | 14 hantsy 2020-12-07 21:14:45 +08:00 DevOps 跟不上，做不了自动化运维，全部靠人肉运维，还是别想了，额外付出的代价即使天天加班也不够补偿。 |
 | 15 SuperManNoPain 2020-12-07 21:23:24 +08:00 via Android 得不偿失 |
 | 16 statement 2020-12-07 21:25:00 +08:00 via iPhone 可以呀。 面向跳槽编程 |
 | 17 lfzyx 2020-12-07 21:27:31 +08:00 运维这块可以交给专业的公司来做 |
 | 18 wdwwtzy 2020-12-07 21:28:40 +08:00 不适合，太麻烦了 |
| 19 monkeydev OP |
| 20 monkeydev OP 联系方式：c3Zlbml0eQ== |
 | 21 liununu 2020-12-07 22:05:20 +08:00 via Android 上了 k8s，就不要用 Spring Cloud 那一套笨重的东西了，k8s 生态里都有链路追踪和远程调用的替代方案。至于微服务也应该贴合具体业务上下文的关系来，如果每个业务都拆开，维护成本提升会大于利处，徒增消耗。 |
| 23 loliordie 2020-12-07 23:19:36 +08:00 via Android @monkeydev 在并发不高时 可以通过 redis 队列实现 搞几个队列 然后根据不同模块开 worker 比如 heroku 这种集成化的平台 add 一个 redis 然后根据模块开项目即可 起码这个架构 我们目前上千的并发 没啥压力 |
 | 24 namelosw 2020-12-08 00:18:51 +08:00 如果可以预见的未来还是小团队的话, 单体就好, 部署的话搞个 PaaS. 你说的这些可以搞, 但是对于小团队来说就是凭空创造工作岗位. |
 | 25 cyssxt 2020-12-08 00:38:09 +08:00 没有必要的，单体应用就可以了 |
 | 26 S4msara 2020-12-08 00:41:09 +08:00 不建议，上上家公司小团队，上了整套微服务方案，docker, k8s, cloud，当时我也觉得诧异，以我个人的拙见其实单体就可以，用户量上来了做单体集群即可。后来公司倒闭，发现团队 leader 是面向跳槽编程，害人不浅，当然，老板错误估计公司发展是主要问题 |
 | 27 catror 2020-12-08 00:45:34 +08:00 via Android 微服务，和模块拆分功能拆分没有强相关性 |
 | 28 autogen 2020-12-08 01:06:13 +08:00 cdn+nginx+springboot+redis+mysql 每分钟请求量小于 3000 的，用这套就可以了 |
 | 29 799635347 2020-12-08 01:43:50 +08:00 没必要，一个 SpringBoot 他不香么 |
 | 30 Lonely 2020-12-08 03:47:06 +08:00 via iPhone 单体集群也可以用 k8s，cloud 那套倒不是必要的 |
 | 31 sampeng 2020-12-08 06:39:12 +08:00 via iPhone 适合。堆简历跑路用 |
 | 32 dayeye2006199 2020-12-08 06:45:04 +08:00 取决于业务是什么。我目前的公司只有两个人，但我们是做 服务和计算集群管理的，所以使用这个架构基本是唯一的选择。如果是 CRUD boy 就没必要了。django，react 前后端做个分离，一把梭了 |
 | 33 jwangkun 2020-12-08 07:45:19 +08:00 1 我们技术团队目前 20 人，外包团队加起来有 80 人左右，目前就是 SpringCloud+K8s 这一套。目前是我在主推，前期是需要花点时间来做一些基础的工作，但是对于后期来说节省了太多的时间成本，没有用过就没有发言权，那些劝你别上的，估计自己也没用过，而且上 k8s 对于开发人员来说是无感知的，至于 Springcloud 我们用了三年了，你会了 Springboot，业务大了自然后拆分，看你业务的复杂性，我们单体和 SpringCloud 都有，具体业务选择不同的架构，只要做大，上微服务是必须的，就看你们现有业务体量了 |
 | 34 xuanbg 2020-12-08 08:37:15 +08:00 微服务可以搞，k8s 没必要。 楼上说小团队搞不来微服务的，我表示我一个人就搞起来了。根本没什么难度，开发反而更简单了。 |
 | 35 rapperx2 2020-12-08 08:47:54 +08:00 个人觉得和公司大小无关，看项目吧。像我们公司 10 人以下。其中一个项目最好的架构就是微服务。不管从那方便都是最好的选择。 这个项目最大的特点就是增长用户数快，前期如果不这样做，后期做架构升级，时间是不够的。而且经常需要第三方扩展 |
 | 36 ArJun 2020-12-08 08:54:57 +08:00 看公司前景，公司用户多、上升快有必要用，还有有些公司融资会拿这些做噱头也有必要 |
 | 37 ThisDay 2020-12-08 08:58:17 +08:00 像楼上说的，作为研发应该是好事啊，方便堆简历~ |
 | 38 90928yao 2020-12-08 09:26:11 +08:00 @jwangkun 你也说的是 80 人左右的团队了。几个人的团队搞这个就是扯淡。一个 war 包部署上去就行了，量多了加机器。 |
 | 39 a719031256 2020-12-08 09:31:15 +08:00 项目后端人数在 10 人以上可以考虑微服务，10 人以下还是算了，没必要 |
 | 40 ChevalierLxc 2020-12-08 09:33:34 +08:00 看到小团队 那就算了 |
 | 41 zhanlanhuizhang 2020-12-08 09:52:52 +08:00 |
 | 42 f6x 2020-12-08 09:56:57 +08:00 k8 成本很高的. 人家给你的复杂方案,等你折腾半年弄懂了, 最后会发现有价值的就是服务里那几十行 php 代码. 哈哈哈. |
 | 43 yedan1206 2020-12-08 09:58:32 +08:00 不适合 |
 | 44 lamesbond 2020-12-08 10:04:02 +08:00 要是能上就偷着乐吧，刷简历美滋滋 |
 | 45 q447643445 2020-12-08 10:10:55 +08:00 同意楼上的. 也就刷刷简历有作用. 实际用起来. 大半时间在维护上. 成本巨高 |
 | 46 securityCoding 2020-12-08 10:11:53 +08:00 外面给的方案靠谱不 , 不如直接上 a 家的 edas 啊,我们公司在用挺不错 |
 | 47 fx 2020-12-08 10:17:00 +08:00 |
 | 48 salmon5 2020-12-08 10:18:12 +08:00 面向跳槽编程，可以可以 |
 | 49 jasonkayzk 2020-12-08 10:22:00 +08:00 写个 Hello-World 需要用 k8s +Spring cloud +微服务吗？ 如果是为了学习，怎么折腾都可以； 如果是商用，不建议折腾，你会发现大部分时间都浪费在了运维上； |
 | 50 fengliu222 2020-12-08 10:26:47 +08:00 阿里云、腾讯云、aws 和 gcp 都有现成的 k8s 基础服务，腾讯云好像还是免费的，配置一套下来也就几个小时，成本并不是很高。 个人认为，超过三个人就需要架构，这是在降低风险而不是炫技。 是否需要微服务和 Spring Cloud 是要看你本身业务形态的，大家不知道你业务的需求，也没法给你最适合的答案。 |
 | 51 Ravenddd 2020-12-08 10:35:27 +08:00 不是用微服务, 那就单体部署, 代码分模块即可, 以后转换微服务也很方便 |
 | 52 renmu123 2020-12-08 10:49:22 +08:00 via Android 小团队用微服务，k8s 没什么意义。用户起不来纯粹就是浪费，何况你们基础差，前期服务器不够加一台就是了，还是先把产品做做好吧 |
 | 53 adspe 2020-12-08 10:57:58 +08:00 不合适 |
 | 54 CoderGeek 2020-12-08 11:06:57 +08:00 小团队先活下去，量上来了在考虑这些 |
| 55 CoderGeek 2020-12-08 11:07:15 +08:00 先代码上分层分模块即可 |
 | 56 w0nglend 2020-12-08 11:08:37 +08:00 可以上没问题我们就是小厂（ PS，可以联系我远程支持，逃。。。） |
 | 57 beneo 2020-12-08 11:14:16 +08:00 本司从 k8s + springcloud + 微服务，直接搬到了阿里云 sae + 云效，不知道有多爽，以后程序员不用专职运维了，多花钱了吗？当然贵一点点，但是交付效率 biu 的往上涨 |
 | 58 snail00 2020-12-08 11:23:27 +08:00 我们后端开发不到 10 人, 架构经历是 tomcat+war => spring boot => spring boot + docker => spring boot + 阿里 k8s => spring cloud + nacos + 阿里 k8s , 以上历时一年半 |
 | 59 zoharSoul 2020-12-08 11:23:54 +08:00 k8s 就不需要 spring cloud 了, spring boot 就够了 |
 | 60 a398058068 2020-12-08 11:38:01 +08:00 1 单体够用就单体，如果非得上 单独 k8s，如果非要熔断 限流这些 直接上 istio + spring boot 。 下下策是 spring cloud +k8s |
 | 61 zc1249274251 2020-12-08 11:42:53 +08:00 没有足够的技术积累 会把自己坑死 而且根据现有业务发展基于现有技术基础 做一定的预估 再去调整技术方案 如果没有那么大的量 负载加单体都可以 一点点去迭代都可以 |
 | 62 ElmerZhang 2020-12-08 11:51:13 +08:00 除非团队里有人对这些东西非常熟，能 cover 各种问题，否则还是不要去碰这些“高大上”的东西了。 如果公司有钱，直接招更牛的人来做架构带团队。否则还是会啥用啥最靠谱，只要能实现需求就好。 另外，对于完全不了解你们团队和业务上来就直接说该用 XXX 的，最好都直接忽略。 |
 | 63 kevinwan 2020-12-08 12:24:26 +08:00 via iPhone 我们最早支撑小几百万日活时后端只有 6 个人，全部基于 k8s，使用自研 go 框架 |
 | 64 matatabi 2020-12-08 13:05:32 +08:00 适合，这些都能为自己的简历加分 |
 | 65 iyangyuan 2020-12-08 13:42:42 +08:00 这套架构，业务还没开始做，至少已经跑满 10 台服务器了 |
 | 67 devehx 2020-12-08 13:55:47 +08:00 我们公司现在只有 3 个后台，运维也没有，居然搞了个微服务写后台管理系统，拆成了几个模块，全部部署到一台机器上，我都不知道做微服务有啥意义，增加了很多写代码的工作量。感觉小团队最好不要搞这玩意儿 |
 | 68 yalin 2020-12-08 14:05:46 +08:00 1 听说的大佬话语：康威法则；架构是演化出来的，不是设计出来；没有银弹。 |
 | 69 0bit 2020-12-08 14:07:53 +08:00 没必要着急上 k8s，但是容器化可以先做，12 factor 可以先搞起来（ https://12factor.net/zh_cn/），有这个基础之后，后续想迁移也容易了。 |
| 70 0bit 2020-12-08 14:13:19 +08:00 链接 Bug 了： https://12factor.net/zh_cn/ |
| 71 kevinwan 2020-12-08 14:13:44 +08:00 via iPhone @halk 后来开源了呀，github.com/tal-tech/go-zero |
 | 72 muskill 2020-12-08 14:13:56 +08:00 我们用 swarm +spring cloud ,搞得我这个后端开发都快变成运维了,真心建议:人员不多的小公司,不建议项目搞得太复杂,心累 |
 | 73 lavvrence 2020-12-08 14:15:37 +08:00 Kubernetes 成本也不会非常高；但是如果用了，目测 10 年技术栈不会落后，K8s 的长尾效应带来的时间收益很高。 |
| 74 kevinwan 2020-12-08 14:16:37 +08:00 via iPhone @muskill 不要 swarm 呀，我们 go+k8s，千万级日活三个运维足够了 |
 | 76 kennylam777 2020-12-08 14:32:00 +08:00 一人搞的 K8s 都比十人 Swarm ，退+1 |
 | 77 ydpro 2020-12-08 14:44:42 +08:00 搞不搞这个技术栈看你们是赚投资者的钱还是赚用户的钱 |
 | 78 ren2881971 2020-12-08 15:16:36 +08:00 别折磨自己。 |
 | 79 vanityfairn 2020-12-08 16:10:10 +08:00 DevOps 没有的话，我赶脚不得行噢，最后还是搞自己。技术薄弱么，单体不香吗？怎么简单怎么来，用户量上来以后，无论怎么样，还是会重构的。。。不然前期这么重，真滴累死 |
| 80 muskill 2020-12-08 16:27:48 +08:00 @kevinwan @jaylee4869 二位说的很对,目前也在努力学习 k8s 中 |
 | 81 LichMscy 1 我们团队现在运行维护着一整套的 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 管理的覆盖开发全开发生命周期的工具链集合。 |
 | 82 ming7435 2020-12-08 16:41:38 +08:00 没有千万级的业务规模强行上这种技术方案简直就是找不自在 |
 | 83 vcode 2020-12-08 16:51:14 +08:00 k3s，k0s |
 | 84 zardly666 2020-12-08 17:32:52 +08:00 我司因为服务端语言很多，py node.js java 所以是 k8s 集群的微服务。感觉花一点时间熟悉以后，用起来很舒服 |
 | 85 zunceng 2020-12-08 17:42:09 +08:00 |
 | 86 wizzer 2020-12-08 17:43:21 +08:00 小团队，建议使用我的 https://budwk.com 框架，有微服务版本也有 mini 单应用版本 |
 | 87 wupher 2020-12-08 17:47:59 +08:00 看团队水平， [小] 不影响技术使用，但是技术薄弱就不适合了，K8s 有问题，要能自己搞定的。 这种情况下，直接用云计算，多专注业务实现挣钱。 |
 | 89 JohnSmith 2020-12-08 18:23:01 +08:00 上云 |
| 90 JohnSmith 2020-12-08 18:23:42 +08:00 上共有云 |
| 91 xuanbg 2020-12-08 21:18:00 +08:00 微服务也可以很简单。一个最简单的微服务，就是注册中心+配置中心+网关而已。需要写额外的代码吗？不需要！都是 pom 引入一个包，然后启动类一个注解，配置文件几行配置就完事。最后就是需要在配置中心分别对每个服务做一下配置。就这点事情，百度一下最多 1 天功夫就搞定了，压根没有什么难度好吧。 |
 | 92 twinsdestiny 2020-12-08 23:21:50 +08:00 duck 不必 |
| 93 dayeye2006199 2020-12-09 02:31:11 +08:00 问个问题：用了 k8s 为啥还需要 spring cloud ？自带功能，最多加个 istio 就能覆盖各种特性了，而且还是语言中立的，支持各种语言写的服务。 |
 | 94 zarte 2020-12-09 09:41:53 +08:00 搞这一套有问题谁加班弄？能简单就简单别像有些自以为是的程序员，到时一堆坑还要别人搽屁股。 |
| 95 zunceng 2020-12-09 10:27:09 +08:00 @ming7435 几年过去我司有个几十个开发+运维了 仍然是这套架构 老板都说 CTO 来了是站台的 随便折腾 技术架构我来决定就行了 |
 | 96 ericgui 2020-12-09 13:59:30 +08:00 github 其实到了很大的规模的时候，还是 ruby on rails 单体 |
 | 97 dorothyREN 2020-12-09 15:48:06 +08:00 不如先想想 你们的项目 值得上微服务吗 |
 | 100 dadagogogo 2021-04-27 01:01:54 +08:00 @muskill 感同深受啊 |
Select Language