1.单体应用与微服务架构区别
如上图左侧为单体应用架构。在传统单体应用中，所有功能模块都在一个工程中编码、部署，即使是集群部署，也只是单体应用的水平复制。
如上图右侧为微服务架构。在微服务架构的项目中，每个应用会按照领域模型划分进行业务、功能聚合，由此拆分后聚合的应用往往：模型高度统一、职责清晰且收敛、应用与应用(领域与领域)之间边界清晰，并且提升了每个应用的独立性、扩展性。
除了应用拆分维度，微服务架构也保证了每个应用可以使用独立语言开发、独立数据存储技术，只要能保持对外统一交互语言即可，存储模型差异如下：
见上图，应用拆分之后对应每个应用会独立、或共享一个数据库，数据库的拆分维度除了要考虑领域边界，还要更多的考虑每个数据库的QPS、TPS，避免高频写操作集中在一个DB，由此起到给数据库减压的功效。
基于上述分析，单体架构存在的问题主要集中在：功能混淆、边界模糊、维护成本高、可靠性差等角度，对于后续应用的升级、扩展同样存在瓶颈。因此随着互联网的发展，我们必须解决上述问题，而微服务就是这样一种架构模式。
2.什么是微服务
自2014年起，微服务架构由Martin Fowler、Adrain Cockcroft、Neal Ford等人接力进行介绍、完善、演进、实践后，一直维持着较高的热度直到现在，内容如下：
微服务架构是一种架构模式，它提倡将原本独立的单体应用，拆分成多个小型服务。这些小型服务各自独立运行，服务与服务间的通信采用轻量级通信机制（一般是基于HTTP协议的RESTful API），达到互相协调、互相配合的目的。被拆分后的服务都围绕着具体的业务进行构建，每个服务都能独立地进行开发、部署、扩展。由于相互独立，且采用轻量级通信机制，各个小型服务也能够使用不同的语言开发，也可以使用不同的数据存储技术。
微服务是一套经过漫长的架构演进、良好架构设计的分布式架构方案。从传统单体应用到分布式独立应用，从应用数据服务到引入缓存优化性能，从反向代理和CDN加速网站响应等等，技术架构不断演进的过程中，逐步出现前后端分离，数据读写分离，云原生、DDD领域驱动，最终孵化出如SpringCloud、SpringCloud Alibaba等成熟稳定的微服务架构方案。
微服务其主要特征：
- 服务自治：团队独立、技术独立、数据独立、部署独立
- 面向服务：微服务对外暴露业务接口，如RESTful API调用
- 单一职责：每个应用领域边界清晰，功能职责单一，无重复工作
3.微服务优缺点
3.1 优点
①易于开发维护
微服务基于领域模型拆分的应用，其内部模型高度统一，功能相对内聚，开发人员只需要对固定模型进行领域业务接口封装即可。
②技术栈开放
微服务因独立部署、独立开发，因此开发团队可以根据资深团队特点进行技术选型。如团队擅长关系型数据库则MySQL，擅长图形计算则Neo4j。
③升级错误隔离
A技术专项升级因单独部署，不再影响整个分布式架构中全部功能，只影响有接口交互的部分应用，而这种应用也可以通过灰度、服务降级、服务熔断的方式兼容和处理，不会因一个错误导致整个应用瘫痪。
3.2 缺点
①运维成本高
更多的服务意味着更多的运维投入，传统应用中只有一个应用，而为服务中，需要保障几十、上百个服务的正常运行和协作。
②调用链路复杂
微服务架构中，不可避免的会出现A服务依赖B服务，B服务依赖C服务，C继续依赖D服务的场景，一旦A调用异常，排查链路可能会从A->B->C->D，才能最终发现服务报错具体信息（后续skywalking可解决）。
③分布式事务问题
同上例A->B->C->D的长链路调用过程中，如果A先修改自己数据，但下游C却异常，此时预期是A回滚自己事务，这一点在单体应用因都是本地事务可以很好做到，但是分布式场景下却提升了复杂度(后续Seata可解决)。
④学习成本高
微服务学习除了需要一定基础之外：Spring、SpringMvc、MyBatis、SpringBoot、Maven、MySQL等，还需学习SpringCloud，中间件、缓存、Docker、文件服务器等多种技术，每一门学习都有很多难点需要克服。
