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

[bsg1992]

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

[zhzer]

别，吃力不讨好

[FingerLiu]

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

[likuku]

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

[xiuc001]

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

[gowk]

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

[CFO]

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

[Leigg]

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

[limuyan44]

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

[merin96]

等一个背锅侠

[sagaxu]

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

[xiaqi]

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

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

[Yuicon]

我作为一个普通员工是希望上的，能学到技术和有相关项目经验。

[hst001]

个人经验，只能说一句不建议。

[ShangAliyun]

看情况，如果后期业务增长快，起码不用费劲改造架构

[salmon5]

@Yuicon
我作为一个普通员工是希望上的，能学到技术和有相关项目经验。
==========================================
然后玩一年跑路了，剩下一堆没解决的问题。

[Yuicon]

@salmon5 你预设了能力不足和没责任心 我又有什么好说的呢

[bsg1992]

@merin96 没准我就是背锅侠 蛋疼

[jack80342]

这是我翻译的 Spring Boot 2.0 的官方文档，可能对你有帮助。github.com/jack80342/Spring-Boot-Reference-Guide