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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 2252 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

项目

自焚

选型

玩火

38 条回复 • 2018-11-11 15:20:29 +08:00

YaphetYin

2018-10-24 16:55:51 +08:00

微服务很依赖完善的基础架构

copfee

2018-10-24 17:02:32 +08:00

用 spring boot，业务用包隔离，后续要拆也容易。

bsg1992

2018-10-24 17:02:42 +08:00

@YaphetYin 根本没有完善的基础架构 DevOps 都没人做。我都不知道这项目上了微服务最后咋收场，领导稍微懂点技术，张口就要上微服务，还说前期要把基础打好。他连微服务是啥都不知道。哎。

bsg1992

2018-10-24 17:08:48 +08:00

@copfee 我个人觉得单体架构进行快速开发，看看产品上线市场什么反应，进行试错。效果好在进行扩充团队，拆分业务，都来得及

lhx2008

2018-10-24 17:10:10 +08:00 via Android

上微服务云，花钱消灾

zhangwugui

2018-10-24 17:25:24 +08:00

微服务这要看场景吧，

bsg1992

2018-10-24 17:31:09 +08:00

@zhangwugui 不光得看业务场景，还得看团队人员的配置。有些人上来就是高大上的架构设计，脱离了业务连最基本的也不要了

ghbaqi

2018-10-24 17:34:57 +08:00

上微服务技术上的各种都要提两三个档次，如果按照微服务的那一套去做，数据库拆分运维部署，开发各种难度都上去了，主要还是看业务是不是适合坐微服务吧，用户量少传统项目真没有必要按照微服务标准去做，也做不好，没有业务驱动

whileFalse

2018-10-24 17:36:12 +08:00

哈哈哈哈。
我司就是。我们几个 leader 雄心壮志要上微服务。
架构和运维都还算给力（没拖后腿），只是没精力去逮那帮小的，然后微服务功能划分一团糟。二十多个微服务里，循环引用，一半后端逻辑在其中一个微服务中，现在真是不想看。

不过好处是锻炼了团队，还有现在发布新功能挺方便的。

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

2018-10-24 17:48:51 +08:00

领导张口就微服务，你们要苦逼了，但是能折腾锻炼啊，上吧

xiaoxinshiwo

2018-10-24 17:50:48 +08:00

@bsg1992 #4 你的感觉是对的

changhe626

2018-10-24 17:53:08 +08:00

多大的项目啊,就直接用微服务,除了知道概念还知道啥

adspe

2018-10-24 18:01:08 +08:00

不合适

zwh2698

2018-10-24 18:34:18 +08:00

1.微服务框架有吗？ 2. 生产上微服务管理都是现成的吗？ 3. 项目的技术主导型还是业务主导型，技术主导主要为了干活的同时也要练兵。

微服务切割的好，反而很快哦。

yunye

2018-10-24 18:45:23 +08:00 via Android

先上线卖起来

mortonnex

2018-10-24 18:48:27 +08:00

springboot 很方便的

wenzhoou

2018-10-24 18:49:59 +08:00 via Android

我搞了 springboot 然后告诉领导这就是微服务。哈哈

justfly

2018-10-24 18:53:04 +08:00

microservices are something you grow into, not begin with

https://nickjanetakis.com/blog/microservices-are-something-you-grow-into-not-begin-with

zjsxwc

2018-10-24 18:59:32 +08:00 via Android

设计不好，循环依赖是噩梦

zhzer

2018-10-24 18:59:37 +08:00 via Android

别，吃力不讨好

FingerLiu

2018-10-24 19:48:38 +08:00

不合适。
微服务最难的是服务边界划分。一般只有业务清晰稳定后才能较好的划分。

likuku

2018-10-24 20:06:31 +08:00

为了技术噱头而技术，尤其经验还很少的情况下，那是自寻死路吧...

xiuc001

2018-10-24 20:06:54 +08:00

前期项目单体架构最好，业务开发上想好怎么拆分；微服务的关键在于如何定义边界，划清各个领域的职责，还没搞清楚就上微服务，到后面就是几十上百个服务交叉引用，最后跟打乱了的毛线一样，完全理不清，比单体架构升级还要恐怖

gowk

2018-10-24 20:30:35 +08:00

呵呵呵，作死，后面有你们受的，估计一大波人以离职收场

CFO

2018-10-24 20:46:09 +08:00 via Android

我也是被微服务的唉一言难尽

Leigg

2018-10-24 21:14:29 +08:00 via iPhone

微服务需要完整的团队，而且还是只负责微服务业务，且初期项目上线需要不少时间，而且 bug 一定巨多，这跟开发人员技术能力没有太大关系，因为是多个组件之间进行耦合。

limuyan44

2018-10-24 21:24:36 +08:00 via Android

最优秀的架构不是最复杂的而是最适合的，微服务会引发很多问题，架构本身就是用来迭代的，一个 1tps 的按照双 11 的峰值来设计有什么意义呢。微服务充满了坑，对人员也有一定的要求不建议上来就搞

merin96

2018-10-24 21:25:07 +08:00 via iPhone

等一个背锅侠

sagaxu

2018-10-24 21:27:31 +08:00 via Android

服务注册和发现可以省掉，用 nginx 做负载均衡和灾备，10 个微服务就配 10 个 upstream 集群，这样做并不会产生额外的运维成本，却能享受到微服务的大部分优点。

xiaqi

2018-10-24 23:28:32 +08:00 via Android

楼上大多都在说微服务的不好，估计大多每天都是“真香”吧。哈哈

一上来就上，到底好不好，有的好有的不好。像我们，已经很明确了几个主要业务，之间关系不大，我们尽量不拆太多服务，而且上了 tracing context，部署写了脚本自动部署，真心没多大问题。我们有个服务是跟路由硬件设备直连，如果都放到单体服务里面，反倒不是很合适。