V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
monkeydev
V2EX  ›  DevOps

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

  •  3
     
  •   monkeydev · 2020-12-07 20:00:05 +08:00 via iPhone · 11762 次点击
    这是一个创建于 1206 天前的主题,其中的信息可能已经有所发展或是发生改变。
    目前公司技术基础比较羸弱
    外面给的方案是这一套
    但我个人认为这只是谈架构的东西
    如果用户不到一定规模似乎,没有必要
    101 条回复    2024-02-06 11:13:16 +08:00
    1  2  
    lecher
        1
    lecher  
       2020-12-07 20:09:37 +08:00   ❤️ 14
    有专职的人员维护这套基础设施吗?
    没有的话,公司愿意为这套基础设施投入人力成本和机器成本吗?
    要是都没有,谁来背这套基础设施玩不转的的锅?

    做为技术人员,碰到这种新技术能实践,应该感到兴奋才对。选择成本恰当的技术方案应该是架构师头疼的事情,普通开发难道不是恨不得把业界最新方案全用上,好堆简历背景吗。
    loliordie
        2
    loliordie  
       2020-12-07 20:09:57 +08:00 via Android
    不适合 小团队初期用 django 加 react 撸一套方案就完事了 如果跨平台就用 flutter 或者 kotlin 你们应该考虑的是开发难度而不是扩展性 因为不管你们怎么搞发展到一定规模都是要重构的 对于你们而言快速上线和敏捷开发是第一位的

    等你们业务成熟了 再来考虑这样重一点的架构 不然很容易被拖死
    tesguest123
        3
    tesguest123  
       2020-12-07 20:24:08 +08:00 via iPhone
    搞半年搞不下去跑路,🐶。
    fff333
        4
    fff333  
       2020-12-07 20:25:37 +08:00 via Android
    @loliordie kotlin 能开发 iOS 了?
    Leigg
        5
    Leigg  
       2020-12-07 20:27:19 +08:00 via iPhone
    你都说了技术比较弱了,你还搞这套架构那不是坑你自己,还坑了公司。
    coderxy
        6
    coderxy  
       2020-12-07 20:31:56 +08:00
    小公司单体就可以了。
    loliordie
        7
    loliordie  
       2020-12-07 20:33:02 +08:00 via Android
    @fff333 kotlin native 不过这个方案我没用过
    wg20080215
        8
    wg20080215  
       2020-12-07 20:35:25 +08:00
    有 10 前端+后端开发没?没有就直接单体就够了。
    kingfalse
        9
    kingfalse  
       2020-12-07 20:44:09 +08:00 via Android
    鲁迅说过,不要为了用而用
    glacial
        10
    glacial  
       2020-12-07 20:48:44 +08:00
    讲实用性 单体集群模式足以, 小团体搞微服务 基本上不是技术上的考量 ,而是商业上的考量,不搞微服务 不高大上 不好与别人讲 不好卖钱
    monkeydev
        11
    monkeydev  
    OP
       2020-12-07 20:52:59 +08:00 via iPhone
    @lecher
    @loliordie
    @glacial
    不用微服务,那如何实现得功能的模块化,满足不同的需求昵
    NaVient
        12
    NaVient  
       2020-12-07 21:05:28 +08:00
    @monkeydev #11 搞了微服务,小团队不一定搞出你想的这样
    MaxFang
        13
    MaxFang  
       2020-12-07 21:10:49 +08:00
    @monkeydev 小团队搞这些东西投入产出比不合适。拆的过小,增加维护难度,可能多个服务是同一个人开发,小团队拆分的边界划分也是需要业务组织上分工清楚。小团队几乎没有人来弄这个东西。 不拆分,做好模块接口隔离也是可以的呀,做到底层业务模块是独立的。
    hantsy
        14
    hantsy  
       2020-12-07 21:14:45 +08:00
    DevOps 跟不上,做不了自动化运维,全部靠人肉运维,还是别想了,额外付出的代价即使天天加班也不够补偿。
    SuperManNoPain
        15
    SuperManNoPain  
       2020-12-07 21:23:24 +08:00 via Android
    得不偿失🌝🌝
    statement
        16
    statement  
       2020-12-07 21:25:00 +08:00 via iPhone
    可以呀。 面向跳槽编程
    lfzyx
        17
    lfzyx  
       2020-12-07 21:27:31 +08:00
    运维这块可以交给专业的公司来做
    wdwwtzy
        18
    wdwwtzy  
       2020-12-07 21:28:40 +08:00
    不适合,太麻烦了
    monkeydev
        19
    monkeydev  
    OP
       2020-12-07 21:56:00 +08:00 via iPhone
    @MaxFang
    @lecher
    @loliordie
    @glacial
    @hantsy

    感谢解答
    请添加我微信
    请大家喝杯奶茶
    也有项目也可以做啊
    微信前面帖子里面有
    monkeydev
        20
    monkeydev  
    OP
       2020-12-07 21:56:36 +08:00 via iPhone
    联系方式:c3Zlbml0eQ==
    liununu
        21
    liununu  
       2020-12-07 22:05:20 +08:00 via Android
    上了 k8s,就不要用 Spring Cloud 那一套笨重的东西了,k8s 生态里都有链路追踪和远程调用的替代方案。至于微服务也应该贴合具体业务上下文的关系来,如果每个业务都拆开,维护成本提升会大于利处,徒增消耗。
    monkeydev
        22
    monkeydev  
    OP
       2020-12-07 22:30:51 +08:00 via iPhone
    @liununu 感谢指导
    loliordie
        23
    loliordie  
       2020-12-07 23:19:36 +08:00 via Android
    @monkeydev 在并发不高时 可以通过 redis 队列实现 搞几个队列 然后根据不同模块开 worker

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

    起码这个架构 我们目前上千的并发 没啥压力
    namelosw
        24
    namelosw  
       2020-12-08 00:18:51 +08:00
    如果可以预见的未来还是小团队的话, 单体就好, 部署的话搞个 PaaS. 你说的这些可以搞, 但是对于小团队来说就是凭空创造工作岗位.
    cyssxt
        25
    cyssxt  
       2020-12-08 00:38:09 +08:00
    没有必要的,单体应用就可以了
    S4msara
        26
    S4msara  
       2020-12-08 00:41:09 +08:00
    不建议,上上家公司小团队,上了整套微服务方案,docker, k8s, cloud,当时我也觉得诧异,以我个人的拙见其实单体就可以,用户量上来了做单体集群即可。后来公司倒闭,发现团队 leader 是面向跳槽编程,害人不浅,当然,老板错误估计公司发展是主要问题
    catror
        27
    catror  
       2020-12-08 00:45:34 +08:00 via Android
    微服务,和模块拆分功能拆分没有强相关性
    autogen
        28
    autogen  
       2020-12-08 01:06:13 +08:00
    cdn+nginx+springboot+redis+mysql
    每分钟请求量小于 3000 的,用这套就可以了
    799635347
        29
    799635347  
       2020-12-08 01:43:50 +08:00
    没必要,一个 SpringBoot 他不香么
    Lonely
        30
    Lonely  
       2020-12-08 03:47:06 +08:00 via iPhone
    单体集群也可以用 k8s,cloud 那套倒不是必要的
    sampeng
        31
    sampeng  
       2020-12-08 06:39:12 +08:00 via iPhone
    适合。堆简历跑路用
    dayeye2006199
        32
    dayeye2006199  
       2020-12-08 06:45:04 +08:00
    取决于业务是什么。我目前的公司只有两个人,但我们是做 服务和计算集群管理的,所以使用这个架构基本是唯一的选择。如果是 CRUD boy 就没必要了。django,react 前后端做个分离,一把梭了
    jwangkun
        33
    jwangkun  
       2020-12-08 07:45:19 +08:00   ❤️ 1
    我们技术团队目前 20 人,外包团队加起来有 80 人左右,目前就是 SpringCloud+K8s 这一套。目前是我在主推,前期是需要花点时间来做一些基础的工作,但是对于后期来说节省了太多的时间成本,没有用过就没有发言权,那些劝你别上的,估计自己也没用过,而且上 k8s 对于开发人员来说是无感知的,至于 Springcloud 我们用了三年了,你会了 Springboot,业务大了自然后拆分,看你业务的复杂性,我们单体和 SpringCloud 都有,具体业务选择不同的架构,只要做大,上微服务是必须的,就看你们现有业务体量了
    xuanbg
        34
    xuanbg  
       2020-12-08 08:37:15 +08:00
    微服务可以搞,k8s 没必要。

    楼上说小团队搞不来微服务的,我表示我一个人就搞起来了。根本没什么难度,开发反而更简单了。
    rapperx2
        35
    rapperx2  
       2020-12-08 08:47:54 +08:00
    个人觉得和公司大小无关,看项目吧。像我们公司 10 人以下。其中一个项目最好的架构就是微服务。不管从那方便都是最好的选择。 这个项目最大的特点就是增长用户数快,前期如果不这样做,后期做架构升级,时间是不够的。而且经常需要第三方扩展
    ArJun
        36
    ArJun  
       2020-12-08 08:54:57 +08:00
    看公司前景,公司用户多、上升快有必要用,还有有些公司融资会拿这些做噱头也有必要
    leeyuzhe
        37
    leeyuzhe  
       2020-12-08 08:58:17 +08:00
    像楼上说的,作为研发应该是好事啊,方便堆简历~
    90928yao
        38
    90928yao  
       2020-12-08 09:26:11 +08:00
    @jwangkun 你也说的是 80 人左右的团队了。几个人的团队搞这个就是扯淡。一个 war 包部署上去就行了,量多了加机器。
    a719031256
        39
    a719031256  
       2020-12-08 09:31:15 +08:00
    项目后端人数在 10 人以上可以考虑微服务,10 人以下还是算了,没必要
    ChevalierLxc
        40
    ChevalierLxc  
       2020-12-08 09:33:34 +08:00
    看到小团队 那就算了
    f6x
        42
    f6x  
       2020-12-08 09:56:57 +08:00
    k8 成本很高的.
    人家给你的复杂方案,等你折腾半年弄懂了, 最后会发现有价值的就是服务里那几十行 php 代码.
    哈哈哈.
    yedan1206
        43
    yedan1206  
       2020-12-08 09:58:32 +08:00
    不适合
    lamesbond
        44
    lamesbond  
       2020-12-08 10:04:02 +08:00
    要是能上就偷着乐吧,刷简历美滋滋
    q447643445
        45
    q447643445  
       2020-12-08 10:10:55 +08:00
    同意楼上的. 也就刷刷简历有作用. 实际用起来. 大半时间在维护上. 成本巨高
    securityCoding
        46
    securityCoding  
       2020-12-08 10:11:53 +08:00
    外面给的方案靠谱不 , 不如直接上 a 家的 edas 啊,我们公司在用挺不错
    fx
        47
    fx  
       2020-12-08 10:17:00 +08:00
    salmon5
        48
    salmon5  
       2020-12-08 10:18:12 +08:00
    面向跳槽编程,可以可以
    jasonkayzk
        49
    jasonkayzk  
       2020-12-08 10:22:00 +08:00
    写个 Hello-World 需要用 k8s +Spring cloud +微服务吗?
    如果是为了学习,怎么折腾都可以;
    如果是商用,不建议折腾,你会发现大部分时间都浪费在了运维上;
    fengliu222
        50
    fengliu222  
       2020-12-08 10:26:47 +08:00
    阿里云、腾讯云、aws 和 gcp 都有现成的 k8s 基础服务,腾讯云好像还是免费的,配置一套下来也就几个小时,成本并不是很高。
    个人认为,超过三个人就需要架构,这是在降低风险而不是炫技。
    是否需要微服务和 Spring Cloud 是要看你本身业务形态的,大家不知道你业务的需求,也没法给你最适合的答案。
    Ravenddd
        51
    Ravenddd  
       2020-12-08 10:35:27 +08:00
    不是用微服务, 那就单体部署, 代码分模块即可, 以后转换微服务也很方便
    renmu123
        52
    renmu123  
       2020-12-08 10:49:22 +08:00 via Android
    小团队用微服务,k8s 没什么意义。用户起不来纯粹就是浪费,何况你们基础差,前期服务器不够加一台就是了,还是先把产品做做好吧
    adspe
        53
    adspe  
       2020-12-08 10:57:58 +08:00
    不合适
    CoderGeek
        54
    CoderGeek  
       2020-12-08 11:06:57 +08:00
    小团队先活下去,量上来了在考虑这些
    CoderGeek
        55
    CoderGeek  
       2020-12-08 11:07:15 +08:00
    先代码上分层分模块即可
    w0nglend
        56
    w0nglend  
       2020-12-08 11:08:37 +08:00
    可以上没问题我们就是小厂( PS,可以联系我远程支持,逃。。。)
    beneo
        57
    beneo  
       2020-12-08 11:14:16 +08:00
    本司从 k8s + springcloud + 微服务,直接搬到了阿里云 sae + 云效,不知道有多爽,以后程序员不用专职运维了,多花钱了吗?当然贵一点点,但是交付效率 biu 的往上涨
    snail00
        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 , 以上历时一年半
    zoharSoul
        59
    zoharSoul  
       2020-12-08 11:23:54 +08:00
    k8s 就不需要 spring cloud 了, spring boot 就够了
    a398058068
        60
    a398058068  
       2020-12-08 11:38:01 +08:00   ❤️ 1
    单体够用就单体,如果非得上 单独 k8s,如果非要熔断 限流这些 直接上 istio + spring boot 。 下下策是 spring cloud +k8s
    zc1249274251
        61
    zc1249274251  
       2020-12-08 11:42:53 +08:00
    没有足够的技术积累 会把自己坑死 而且根据现有业务发展基于现有技术基础 做一定的预估 再去调整技术方案 如果没有那么大的量 负载加单体都可以 一点点去迭代都可以
    ElmerZhang
        62
    ElmerZhang  
       2020-12-08 11:51:13 +08:00
    除非团队里有人对这些东西非常熟,能 cover 各种问题,否则还是不要去碰这些“高大上”的东西了。
    如果公司有钱,直接招更牛的人来做架构带团队。否则还是会啥用啥最靠谱,只要能实现需求就好。
    另外,对于完全不了解你们团队和业务上来就直接说该用 XXX 的,最好都直接忽略。
    kevinwan
        63
    kevinwan  
       2020-12-08 12:24:26 +08:00 via iPhone
    我们最早支撑小几百万日活时后端只有 6 个人,全部基于 k8s,使用自研 go 框架
    matatabi
        64
    matatabi  
       2020-12-08 13:05:32 +08:00
    适合,这些都能为自己的简历加分
    iyangyuan
        65
    iyangyuan  
       2020-12-08 13:42:42 +08:00
    这套架构,业务还没开始做,至少已经跑满 10 台服务器了
    halk
        66
    halk  
       2020-12-08 13:54:19 +08:00
    @kevinwan #63 后来呢?
    devehx
        67
    devehx  
       2020-12-08 13:55:47 +08:00
    我们公司现在只有 3 个后台,运维也没有,居然搞了个微服务写后台管理系统,拆成了几个模块,全部部署到一台机器上,我都不知道做微服务有啥意义,增加了很多写代码的工作量。感觉小团队最好不要搞这玩意儿
    yalin
        68
    yalin  
       2020-12-08 14:05:46 +08:00   ❤️ 1
    听说的大佬话语:康威法则;架构是演化出来的,不是设计出来;没有银弹。
    0bit
        69
    0bit  
       2020-12-08 14:07:53 +08:00
    没必要着急上 k8s,但是容器化可以先做,12 factor 可以先搞起来( https://12factor.net/zh_cn/),有这个基础之后,后续想迁移也容易了。
    0bit
        70
    0bit  
       2020-12-08 14:13:19 +08:00
    kevinwan
        71
    kevinwan  
       2020-12-08 14:13:44 +08:00 via iPhone
    @halk 后来开源了呀,github.com/tal-tech/go-zero
    muskill
        72
    muskill  
       2020-12-08 14:13:56 +08:00
    我们用 swarm +spring cloud ,搞得我这个后端开发都快变成运维了,真心建议:人员不多的小公司,不建议项目搞得太复杂,心累
    jaylee4869
        73
    jaylee4869  
       2020-12-08 14:15:37 +08:00
    Kubernetes 成本也不会非常高;但是如果用了,目测 10 年技术栈不会落后,K8s 的长尾效应带来的时间收益很高。
    kevinwan
        74
    kevinwan  
       2020-12-08 14:16:37 +08:00 via iPhone
    @muskill 不要 swarm 呀,我们 go+k8s,千万级日活三个运维足够了
    jaylee4869
        75
    jaylee4869  
       2020-12-08 14:18:07 +08:00
    @muskill Docker Swarm 赶紧扔掉。我也是后端,最近也在搞运维等基础设施,swarm 彻底死了。
    kennylam777
        76
    kennylam777  
       2020-12-08 14:32:00 +08:00
    一個人搞的 K8s 都比十個人維護 Swarm 強,勸退+1
    ydpro
        77
    ydpro  
       2020-12-08 14:44:42 +08:00
    搞不搞这个技术栈看你们是赚投资者的钱还是赚用户的钱
    ren2881971
        78
    ren2881971  
       2020-12-08 15:16:36 +08:00
    别折磨自己。
    vanityfairn
        79
    vanityfairn  
       2020-12-08 16:10:10 +08:00
    DevOps 没有的话,我赶脚不得行噢,最后还是搞自己。技术薄弱么,单体不香吗?怎么简单怎么来,用户量上来以后,无论怎么样,还是会重构的。。。不然前期这么重,真滴累死
    muskill
        80
    muskill  
       2020-12-08 16:27:48 +08:00
    @kevinwan @jaylee4869 二位说的很对,目前也在努力学习 k8s 中
    LichMscy
        81
    LichMscy  
       2020-12-08 16:30:21 +08:00   ❤️ 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 管理的覆盖开发全开发生命周期的工具链集合。
    ming7435
        82
    ming7435  
       2020-12-08 16:41:38 +08:00
    没有千万级的业务规模强行上这种技术方案简直就是找不自在
    vcode
        83
    vcode  
       2020-12-08 16:51:14 +08:00
    k3s,k0s
    zardly666
        84
    zardly666  
       2020-12-08 17:32:52 +08:00
    我司因为服务端语言很多,py node.js java 所以是 k8s 集群的微服务。感觉花一点时间熟悉以后,用起来很舒服
    zunceng
        85
    zunceng  
       2020-12-08 17:42:09 +08:00
    @ming7435 你这说的... 当年我司只有我一个开发都用 k8s + 微服务架构

    这套东西很好的解耦了运维和开发, 越是小团队越要注意这些呀, 而没什么经验的时候又是最蛋疼的
    wizzer
        86
    wizzer  
       2020-12-08 17:43:21 +08:00
    小团队,建议使用我的 https://budwk.com 框架,有微服务版本也有 mini 单应用版本
    wupher
        87
    wupher  
       2020-12-08 17:47:59 +08:00
    看团队水平, [小] 不影响技术使用,但是技术薄弱就不适合了,K8s 有问题,要能自己搞定的。

    这种情况下,直接用云计算,多专注业务实现挣钱。
    ming7435
        88
    ming7435  
       2020-12-08 17:54:23 +08:00 via iPhone
    @zunceng 一个人能搞定的业务能复杂到哪里去?一个 war 包一把梭说不定效率更高
    JohnSmith
        89
    JohnSmith  
       2020-12-08 18:23:01 +08:00
    上云
    JohnSmith
        90
    JohnSmith  
       2020-12-08 18:23:42 +08:00
    上共有云
    xuanbg
        91
    xuanbg  
       2020-12-08 21:18:00 +08:00
    微服务也可以很简单。一个最简单的微服务,就是注册中心+配置中心+网关而已。需要写额外的代码吗?不需要!都是 pom 引入一个包,然后启动类一个注解,配置文件几行配置就完事。最后就是需要在配置中心分别对每个服务做一下配置。就这点事情,百度一下最多 1 天功夫就搞定了,压根没有什么难度好吧。
    twinsdestiny
        92
    twinsdestiny  
       2020-12-08 23:21:50 +08:00
    duck 不必
    dayeye2006199
        93
    dayeye2006199  
       2020-12-09 02:31:11 +08:00
    问个问题:用了 k8s 为啥还需要 spring cloud ?自带功能,最多加个 istio 就能覆盖各种特性了,而且还是语言中立的,支持各种语言写的服务。
    zarte
        94
    zarte  
       2020-12-09 09:41:53 +08:00
    搞这一套有问题谁加班弄?能简单就简单别像有些自以为是的程序员,到时一堆坑还要别人搽屁股。
    zunceng
        95
    zunceng  
       2020-12-09 10:27:09 +08:00
    @ming7435 几年过去我司有个几十个开发+运维了 仍然是这套架构 老板都说 CTO 来了是站台的 随便折腾 技术架构我来决定就行了
    ericgui
        96
    ericgui  
       2020-12-09 13:59:30 +08:00
    github 其实到了很大的规模的时候,还是 ruby on rails 单体
    dorothyREN
        97
    dorothyREN  
       2020-12-09 15:48:06 +08:00
    不如先想想 你们的项目 值得上微服务吗
    young1lin
        98
    young1lin  
       2020-12-10 11:36:41 +08:00
    @kingfalse 我周树人可没说过这句话。狗头.jpg
    kingfalse
        99
    kingfalse  
       2020-12-10 16:21:00 +08:00 via Android
    @young1lin 我说了是鲁迅,你周树人来凑什么热闹。狗尾巴.gif
    dadagogogo
        100
    dadagogogo  
       2021-04-27 01:01:54 +08:00
    @muskill 感同深受啊
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3888 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 10:32 · PVG 18:32 · LAX 03:32 · JFK 06:32
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.