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

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

  •  
  •   bsg1992 · 208 天前 · 3071 次点击
    这是一个创建于 208 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

    不过好处是锻炼了团队,还有现在发布新功能挺方便的。
        10
    Youen   208 天前
    Microservices Are Something You Grow Into, Not Begin With

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

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

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