在软件开发过程中，我们往往会遇到这样的情况，在项目或者平台建设中，我们到底该如何建立平台的架构？是选择传统开发模式的单体应用这种一体式的工程方式，还是选择时下流行的微服务架构呢？
一、单体应用
传统开发模式的“单体应用”就是将应用程序的所有功能都打包成一个独立的单元，可以是JAR、WAR、EAR或其它建档格式。
优点
-
易于开发、部署简单;
团队开发人员只有通过代码管理工具一次性下载工程目录下的所有代码，即可进行功能开发，并且可以直接在IDE中集成应用服务器，进行调试，而开发完成后把所有功能打包到单个归档文件中，复制到应用服务器目录下即完成应用的部署。 -
集中部署、方便测试;
因为单体应用所有功能都在一个归档文件中，应用一旦部署，即可使用所有功能，而我们就可以测试这个应用的所有功能。
缺点
-
效率低
团队所有开发人员都在同一个工程项目上新增、修改代码，功能存在相互依赖时，耦合程序高，会产生冲突或者相互等待的情况。 -
维护难
项目初期这种情况并不明显，随着业务的发展，代码功能起来越耦合，维护修改将会越来越困难。 -
不灵活
每次修改一个小功能都要重新构建整个项目，并重新部署，影响效率。 -
相互影响
因为应用所有功能都部署在一个服务里面，只要有一个功能异常，都可能影响其它功能无法使用。 -
难以扩展
随着业务需求的快速发展变化，可扩展性的需求不断增长，单体应用将难以应对这种快速变化。
- 技术债务
随着业务日益完善，系统也随之庞大，原来写好的代码也越来越难修改，随着时间的推移，这样的技术债务也将越来越重。
二、微服务
微服务是一种架构风格，而不是一种全新的技术。微服务是将原有的单体应用以模块或者功能的方式，分散开发，形成一个小应用服务，每个服务有自己的归档文件，并独立部署，然后共同组成一个大应用程序。
优点
-
易于开发、方便维护
微服务往往是以模块或者功能进行拆分，业务逻辑相对来说没那么错综复杂，只要完成自身模块的功能即可，开发人员更容易进行开发与后期维护。 -
启动更快
因为独立部署的服务，体量相对来说小很多，所占用资源更少一些，应用启动更加快速。 -
易于部署
由于模块与模块之前早已进行拆分，独立部署，服务都在各自的容器内，更新部署并不会有直接影响，这样更有利于我们的持续集成和持续交付。 -
故障隔离
单个服务故障只在本服务容器内产生，不影响其它的服务继续使用，当然，调用本服务的应用，将会受限使用，这样一个服务出现问题不至于导致整个应用受到影响。 -
更宽的技术栈
由于微服务都在自身环境下相对独立的开发，所在团队满足所使用的技术要求即可，而服务于服务之间统一遵循约定的协议，而不必受限于相同的技术体系，这样对于有特殊要求的服务，在技术造型上更灵活一些。
缺点
-
增加运维成本
-
接口约定更加复杂
网友评论