首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
bsg1992
V2EX  ›  程序员

新项目选型一开始就上微服务合适嘛?

  •  
  •   bsg1992 · 2018-10-24 16:27:53 +08:00 · 4417 次点击
    这是一个创建于 586 天前的主题,其中的信息可能已经有所发展或是发生改变。

    公司有一个新项目上来就要用微服务开发,而且项目也比较急。后续迭代很频繁。 现在团队也没多少人,感觉是玩火自焚。 最开始我建议是单体架构开发,进度周期上也比较好把控,现在用微服务前期的工作量实在是太大了。

    38 条回复    2018-11-11 15:20:29 +08:00
    YaphetYin
        1
    YaphetYin   2018-10-24 16:55:51 +08:00
    微服务很依赖完善的基础架构
    copfee
        2
    copfee   2018-10-24 17:02:32 +08:00   ❤️ 1
    用 spring boot,业务用包隔离,后续要拆也容易。
    bsg1992
        3
    bsg1992   2018-10-24 17:02:42 +08:00
    @YaphetYin 根本没有完善的基础架构 DevOps 都没人做。我都不知道这项目上了微服务最后咋收场,领导稍微懂点技术,张口就要上微服务,还说前期要把基础打好。他连微服务是啥都不知道。哎。
    bsg1992
        4
    bsg1992   2018-10-24 17:08:48 +08:00
    @copfee 我个人觉得单体架构进行快速开发,看看产品上线市场什么反应,进行试错。效果好在进行扩充团队,拆分业务,都来得及
    lhx2008
        5
    lhx2008   2018-10-24 17:10:10 +08:00 via Android
    上微服务云,花钱消灾
    zhangwugui
        6
    zhangwugui   2018-10-24 17:25:24 +08:00
    微服务这要看场景吧,
    bsg1992
        7
    bsg1992   2018-10-24 17:31:09 +08:00
    @zhangwugui 不光得看业务场景,还得看团队人员的配置。有些人上来就是高大上的架构设计,脱离了业务连最基本的也不要了
    ghbaqi
        8
    ghbaqi   2018-10-24 17:34:57 +08:00
    上微服务 技术上的各种都要提两三个档次 ,如果按照微服务的那一套去做 , 数据库拆分 运维部署 , 开发 各种难度都上去了 , 主要还是看业务是不是适合坐微服务吧 , 用户量少 传统项目真没有必要 按照微服务标准去做, 也做不好 , 没有业务驱动
    whileFalse
        9
    whileFalse   2018-10-24 17:36:12 +08:00
    哈哈哈哈。
    我司就是。我们几个 leader 雄心壮志要上微服务。
    架构和运维都还算给力(没拖后腿),只是没精力去逮那帮小的,然后微服务功能划分一团糟。二十多个微服务里,循环引用,一半后端逻辑在其中一个微服务中,现在真是不想看。

    不过好处是锻炼了团队,还有现在发布新功能挺方便的。
    Youen
        10
    Youen   2018-10-24 17:38:24 +08:00
    Microservices Are Something You Grow Into, Not Begin With

    https://news.ycombinator.com/item?id=18255110
    OMGZui
        11
    OMGZui   2018-10-24 17:48:51 +08:00   ❤️ 1
    领导张口就微服务,你们要苦逼了,但是能折腾锻炼啊,上吧
    xiaoxinshiwo
        12
    xiaoxinshiwo   2018-10-24 17:50:48 +08:00
    @bsg1992 #4 你的感觉是对的
    changhe626
        13
    changhe626   2018-10-24 17:53:08 +08:00
    多大的项目啊,就直接用微服务,除了知道概念还知道啥
    adspe
        14
    adspe   2018-10-24 18:01:08 +08:00
    不合适
    zwh2698
        15
    zwh2698   2018-10-24 18:34:18 +08:00
    1.微服务框架有吗? 2. 生产上微服务管理都是现成的吗? 3. 项目的技术主导型还是业务主导型,技术主导主要为了干活的同时也要练兵。

    微服务切割的好,反而很快哦。
    yunye
        16
    yunye   2018-10-24 18:45:23 +08:00 via Android
    先上线卖起来
    mortonnex
        17
    mortonnex   2018-10-24 18:48:27 +08:00
    springboot 很方便的
    wenzhoou
        18
    wenzhoou   2018-10-24 18:49:59 +08:00 via Android
    我搞了 springboot 然后告诉领导这就是微服务。哈哈
    justfly
        19
    justfly   2018-10-24 18:53:04 +08:00
    zjsxwc
        20
    zjsxwc   2018-10-24 18:59:32 +08:00 via Android
    设计不好,循环依赖是噩梦
    zhzer
        21
    zhzer   2018-10-24 18:59:37 +08:00 via Android
    别,吃力不讨好
    FingerLiu
        22
    FingerLiu   2018-10-24 19:48:38 +08:00
    不合适。
    微服务最难的是服务边界划分。一般只有业务清晰稳定后才能较好的划分。
    likuku
        23
    likuku   2018-10-24 20:06:31 +08:00
    为了技术噱头而技术,尤其经验还很少的情况下,那是自寻死路吧...
    xiuc001
        24
    xiuc001   2018-10-24 20:06:54 +08:00
    前期项目单体架构最好,业务开发上想好怎么拆分;微服务的关键在于如何定义边界,划清各个领域的职责,还没搞清楚就上微服务,到后面就是几十上百个服务交叉引用,最后跟打乱了的毛线一样,完全理不清,比单体架构升级还要恐怖
    gowk
        25
    gowk   2018-10-24 20:30:35 +08:00
    呵呵呵,作死,后面有你们受的,估计一大波人以离职收场
    CFO
        26
    CFO   2018-10-24 20:46:09 +08:00 via Android
    我也是被微服务的 唉 一言难尽
    Leigg
        27
    Leigg   2018-10-24 21:14:29 +08:00 via iPhone
    微服务需要完整的团队,而且还是只负责微服务业务,且初期项目上线需要不少时间,而且 bug 一定巨多,这跟开发人员技术能力没有太大关系,因为是多个组件之间进行耦合。
    limuyan44
        28
    limuyan44   2018-10-24 21:24:36 +08:00 via Android
    最优秀的架构不是最复杂的而是最适合的,微服务会引发很多问题,架构本身就是用来迭代的,一个 1tps 的按照双 11 的峰值来设计有什么意义呢。微服务充满了坑,对人员也有一定的要求不建议上来就搞
    merin96
        29
    merin96   2018-10-24 21:25:07 +08:00 via iPhone
    等一个背锅侠
    sagaxu
        30
    sagaxu   2018-10-24 21:27:31 +08:00 via Android
    服务注册和发现可以省掉,用 nginx 做负载均衡和灾备,10 个微服务就配 10 个 upstream 集群,这样做并不会产生额外的运维成本,却能享受到微服务的大部分优点。
    xiaqi
        31
    xiaqi   2018-10-24 23:28:32 +08:00 via Android
    楼上大多都在说微服务的不好,估计大多每天都是“真香”吧。哈哈

    一上来就上,到底好不好,有的好有的不好。像我们,已经很明确了几个主要业务,之间关系不大,我们尽量不拆太多服务,而且上了 tracing context,部署写了脚本自动部署,真心没多大问题。我们有个服务是跟路由硬件设备直连,如果都放到单体服务里面,反倒不是很合适。
    Yuicon
        32
    Yuicon   2018-10-25 09:25:13 +08:00
    我作为一个普通员工是希望上的,能学到技术和有相关项目经验。
    hst001
        33
    hst001   2018-10-25 09:57:59 +08:00 via Android
    个人经验,只能说一句不建议。
    ShangAliyun
        34
    ShangAliyun   2018-10-25 11:07:57 +08:00
    看情况,如果后期业务增长快,起码不用费劲改造架构
    salmon5
        35
    salmon5   2018-10-25 13:13:42 +08:00
    @Yuicon
    我作为一个普通员工是希望上的,能学到技术和有相关项目经验。
    ==========================================
    然后玩一年跑路了,剩下一堆没解决的问题。
    Yuicon
        36
    Yuicon   2018-10-25 13:33:47 +08:00
    @salmon5 你预设了能力不足和没责任心 我又有什么好说的呢
    bsg1992
        37
    bsg1992   2018-10-26 14:50:29 +08:00
    @merin96 没准我就是背锅侠 蛋疼
    jack80342
        38
    jack80342   2018-11-11 15:20:29 +08:00
    这是我翻译的 Spring Boot 2.0 的官方文档,可能对你有帮助。github.com/jack80342/Spring-Boot-Reference-Guide
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1182 人在线   最高记录 5168   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 19:27 · PVG 03:27 · LAX 12:27 · JFK 15:27
    ♥ Do have faith in what you're doing.