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

别，吃力不讨好

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

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

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

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

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

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

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

等一个背锅侠

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

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

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

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

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

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

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

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

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

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