一、单体架构 

单体架构就是把所有业务模块编写在一个项目，最终打包成一个 war 包，进行部署

单体架构的优点：

部署简单：由于是完整的结构体，可以直接部署在一个服务器上即可

技术单一：项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发

用人成本低：单个程序可以完成业务接口到数据库的整个流程

单体架构的缺点：

系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动，重启周期边长

系统错误隔离性差，可用性差，任何一个模块的错误可能导致整个系统的宕机

可伸缩性差，系统的扩容只能对整个应用扩容，不能做到对整个功能点进行扩容

线上问题修复时间长，任何一个线上问题修复需要对整个应用系统进行全面升级

二、微服务架构 

微服务是一种架构模式，将整个系统拆分成多个服务的架构，服务之间相互协调

每个服务都有独立的生命周期，可以单独的维护和部署，各个业务模块之间是松耦合的

若对系统进行升级扩展，只需要为额外的组件部署，不需要部署一个完整的系统即可完成更新迭代

微服务的优点：

开发简单：每个服务完成独立的功能

技术栈灵活：可以选择不同的语言完成不同的服务，发挥各种语言的最大优势

服务独立无依赖：每个服务都可以独立部署，一个服务出现问题不会导致整个系统瘫痪

独立按需扩展：以应对高并发大流量

可用性高：当其中一个点出现问题时，能够及时切换，不影响业务的正常运行

复杂应用解耦为小而众的服务：拆分可以基于一定的原则，将耗时的应用解耦

各服务精而专：也就是常说的专人干专事，映射到微服务中就是专服务干专事

服务间通信通过 API 完成：选择轻量的 API 通信 

微服务的缺点：

多服务运维难度：服务的增加意味着运维的难度，如何有效管理是一个挑战 

系统部署依赖：当业务复杂时，系统之间的耦合关系高度耦合，如何高效部署是一个挑战 

服务间通信成本：包括网络延迟、接口不可用性等，保证服务的高可用性是一个挑战

数据一致性： 各个服务间如何有效的共享数据，确保相应服务的数据一致性是一个挑战

系统继承测试：拆分后，需要测试的内容成倍的增加，如何高效降低测试成本是一个挑战 

重复工作：服务拆分之后，由于信息的不对称导致的重复性工作，如何有效抽象是一个挑战 

性能监控：原本只需要一个监控的部分，现在需要分开监控，如何快速定位问题是一个挑战 

沟通成本的成倍增加：服务拆分后，各个服务由专人来维护，如何高效沟通是一个挑战 

参考资料：《微服务架构实战》—— 张锋 

一  叶  知  秋，奥  妙  玄  心