这是一个介绍性的问题。要做一个微服务项目，首先就是搭建一个项目。应该组织什么样的代码？这是我们面临的第一个问题。在传统项目中，我们经常需要构建聚合项目，这样可以方便的对项目进行模块管理，降低维护难度。在微服务项目中，我们还需要延续这种开发方式吗？今天松哥结合自己在项目中的经历，跟大家简单聊聊微服务项目中代码的组织形式。一、开发模型要想弄清楚代码是如何组织的，首先大家要明白微服务架构是什么样子的！在微服务架构中，一个完整的项目被拆分成许多独立的微服务。例如，一个电子商务项目可能分为产品管理、商户管理、用户管理、交易管理、SEO管理、App管理、财务管理、系统管理等诸多微服务。这些微服务是由不同团队开发和维护的独立项目。不同团队独立开发、独立维护、独立测试（视情况而定）、独立上线，可以有效提高项目的开发效率。结合项目的实际情况，不同的团队甚至可以选择不同的技术栈，比如商品管理模块用Java，交易管理用Go，门户网站用PHP等等，从微服务架构来看，这些都是支持的，这也是微服务的优势之一，就是同一个系统不必拘泥于同一种语言。当然在实践中还需要结合团队的技术栈和语言特点来选择。其实看到这里，你大概就明白聚合项目这里还能不能用了！2.是否要使用聚合项目？首先，从整体来看，也就是整个项目层面，我们不再需要聚合项目。聚合工程可以让项目统一打包，解决项目中的依赖问题，也可以统一管理依赖的版本，但这些特性对于微服务项目来说其实并不重要。如果商品管理模块用Java，交易管理用Go，门户网站用PHP，那么这三个独立的微服务肯定不需要做成一个聚合项目，不能聚合。当然，这是一种极端的情况。即使不同的微服务模块是用Java语言开发的，也没有必要聚合，因为不同的微服务其实是独立的项目，由不同的团队开发和维护，微服务的一大优势就是每个团队独立开发，互不影响.如果你构建一个聚合项目，你会将团队绑定在一起。但是不同的微服务之间，难免要用到一些公共类库，可以打包上传到公司的Maven私服，然后不同的团队可以自己依赖，或者通过gitsubtree来使用。这是大规模的。具体到每一个微服务，聚合工程的优势还是有的，应该用。比如在商品管理模块中，仍然可以使用聚合工程。3、微服务是否要用聚合工程，为什么会有疑问？一种情况是公司的微服务是在老项目的基础上改造的。他们仓促推出，改得面目全非，已经顾不上这些了。功能都可以实现。这时候即使在大的层面上使用Aggregationengineering，结果不同团队开发的时候，还是牵一发而动全身。如果有小伙伴也开发过这种项目，可能会对聚合工程的使用产生疑惑。宋大哥有个朋友在广州做央企的项目，就是这样的。另一种情况可能是由于公司人员较少，为了微服务项目开发方便，整体做了一个聚合项目，这样在项目人员少的时候修改也很方便工程量不大。总之，这个问题不能一概而论。结合项目的实际情况，最好选择适合自己的方案。近期松哥也会打造一个框架供大家参考。小伙伴们请关注消息~本文经授权转载自公众号《造男神》。公众号Mamaboy分享了很多Java微服务干货，欢迎关注！
