微服务和传统的单体应该各有什么优劣？

传统的单体应用：

面临的问题

1项目过度复杂：比如原本一个很简单的单体应用，经过不断的拓展，功能越来越多，经手的人也在不断的变化，可能到最后已经变成一个非常复杂的大系统了，而且这种复杂情况还会越来越严重。

2开发速度缓慢

因为单体应用复杂了之后，项目会越来越臃肿而且庞大，每一次编译构建运行测试，都要花费大量的时间和精力，而且如果测试有问题，又要重新来一次，有种牵一发而动全身的操作。

3不易拓展

比如部署的时候需要的服务器性能要满足所有功能的要求，比如内存，CPU等

4技术栈不易拓展

项目开始的时候一旦选择了某一种技术栈来开发项目，那么以后就很难在技术栈上做切换。有时候因为某一个功能需要改新的技术去做，那么这是很难去重新改造这个模块的。

曾经的优势

1开发简单，一个IDE可以很快速的就构建出一个单体应用

2测试简单

3部署简单，一个tomcat安装之后把应用放上去就可以了

4集群化部署也很容易，多个tomcat + 一个Nginx就可以搭建好集群环境了

 

微服务的优势

1大项目可以持续交付

微服务将一个大项目拆分成很多个互相独立的服务，每一个服务都可以由一个团队去完成，并且配备自己的开发和部署，各个团队开发的微服务相互独立，互不干扰。每一个小项目都可以非常方便的进行测试部署，不会牵一发而动全身。

2易于维护

一个传统的单体项目，刚接手的时候不一定能很快的理清头绪，但是微服务由于比较小巧，一个微服务只负责一个功能，能很快的理出头绪上手开发。并且微服务的规模都比较小，项目启动和测试速度都会比较快。

3服务可以可以独立拓展

独立拓展可以让我们充分的使用硬件资源。单体应用所有的功能都写在一起，有的模块可能需要内存更大，有的模块需要CPU的运算更大，部署的时候，我们只能选择CPU更强内存更大的机器，而如果是微服务架构，不同的系统独立部署，压力大的时候进行独立的集群化部署，这些操作都不会影响到其他的服务，非常方便灵活。

4更强的兼容性

由于每一个微服务都是独立运行的，处理的当，我们在微服务架构中可以实现更好的故障隔离，当一个微服务发生问题时，不会影响到其他的功能服务。

5可以灵活的采用最新的技术

因为微服务都是独立运行的，单个微服务的技术升级非常简单和容易，

微服务的弊端

1服务的拆分

2分布式系统带来的挑战

主键如何产生、如何熔断、分布式事务如何处理、数据如何同步等一系列问题

3多个研发团队的协调管理

不同的团队研发不同的微服务，那么就需要协调多个团队共同配合，才能做好微服务的开发工作，这堆项目管理提出了挑战。