微服务项目和单体系统的思考
单体系统
单体系统优点
所谓单体系统，就是项目启动后只存在一个服务，对外也只提供一个URL访问（这里只讨论Java），所有的模块功能均在一个项目中。
- 开发相对便利：架构起来方便，创建一个空的Maven项目，可以直接写业务代码，项目落地会更快，对于要抢占市场，或者项目经理立了军令状的那种，建议单体系统先落地，然后考虑业务拆分，系统重构
- 事务维护简单：因为是单体系统，在容器选择Spring的情况下，事务控制就便利很多了，在充分了解了Spring的事务隔离级别之后，一个注解就OK了
- 部署运维简单：不论是SSH（Spring + Struts +Hibernate）、还是SSM（Spring + SpringMVC +Mybatis）抑或是现在的SpringBoot项目，一个Tomcat就可以部署了。
- 集群系统简单：在单体系统访问量达到一定的量，或者想短时间解决访问量的问题，直接横向增加一台服务器，使用Nginx转发一下，至少能提高70%-80%的性能
之前和另外一个公司的技术大佬做交流的时候，他有句话说的我觉得非常好，Java就是烧服务器的，如果能通过提升服务器服务器配置活着增加服务器数量解决的问题，为什么还要写多余的代码呢。
单体系统缺点
说是单体系统的缺点其实也不准确，更像是瓶颈。
- 业务隔离较弱：因为单体系统的所有调用都在一起，也就是实际代码落地的时候，各个业务是实际杂糅在一起的，很难保证业务隔离，基本上一个方法里面会有大量的同步业务
- 代码维护成本：单体系统大量的代码会使得代码的维护成本相当高，笔者曾经维护过一套09年的代码，稍微加一点东西都感觉要伤筋动骨
- 扩展性比较差：项目落地后肯定会有大大小小的需求要改这改那，毕竟产品经理一般都是傻X，如果是自己写的代码还好，要是某位前辈留下的上古代码，要再加一个新的功能，只能说加油吧
- 并发访问瓶颈：现在都在讲高并发高可用，单体系统做到高可用还是很简单的，但是在处理高并发的场景还是有瓶颈的，毕竟一个单体系统的承载量是有限的
- 不利于模块：假设一个下单系统，可能订单和支付访问量是比较高的，其余的模块访问量可能并没有那么高，这种情况下其实更偏向于把订单和支付做一个高可用，但是单体系统就做不到对某个模块做垂直集群，只能通过扩展整个系统的方式
微服务系统
微服务系统的优点
要开始一个微服务项目，首先要考虑的是，要解决哪些问题，不能单纯的为了用SpringCloud而用SpringCloud，要知道在引入一个新的技术的时候，会因此出现新的问题，就SpringCloud而言，项目的维护成本成倍增加，开发成本也会高很多。
- 服务隔离: 根据微服务的最小服务原则，将业务可以系统化拆分，各个业务服务之间相对隔离
- 方便扩展: 可以在注册中心任意注册其他业务模块，如电商系统，最开始只有订单模块、结算模块、支付模块，现在想加入一个WMS仓储系统，要怎么加呢，如果式单体系统，肯定就是把原本已经复杂的系统，再硬生生嵌入一层仓储系统，但是微服务系统则不然，可以直接单独开放一个业务模块，将新的仓储模块注册到注册中心，提供Feign接口即可
- 集群方便: 对於单个服务而言，想要做垂直集群，只需要，更改模块的启动端口，在访问的时候gateway会自动转发
微服务系统的缺点
- 开发门槛高: 微服务系统的开发门槛相对於单体系统来讲，开发门槛还是要高一些的，开发者首先要理解微服务的各个组件，并能对其做基本配置和调优，其次要对分布式系统有一定的了解，对CAP原则要有比较深刻的认识，知识要求更加全面，更加有深度
- 服务之间调用繁杂: 服务隔离之后必然带来的就是系统各个模块之间调用的成本，把整个系统的链路都画出来，你会发现那更像是一团毛线
- 事务控制难度高: 其实这个问题并不是无服务的问题，这个问题的根本在分布式事务，因为服务隔离，更多的是去保证数据的最终一致性，所以单个事务就很难去准确的控制，更多的是通过数据补偿的形式保证数据最终一致性
- 维护成本高: 这个成本不是一般的高，可以说是普通单体系统的10倍以上，当业务模块多到一定量的时候，系统在部署和运维上开销会非常大
以上是本人在经历了数个单体项目和微服务系统之后的一些思考，也仅作参考，希望对大家在技术选型的时候，整体架构的大方向是单体还是微服务有一点参考价值。