微服务的架构使得小改动频繁上线和下线非常容易，可以直接在运行的产品上推送一个新的功能或者下线一个无用的功能：获得持续交付的能力。

SOA 的起源

• SOA（Service-Oriented Architecture）：将应用组织成一个独立的功能单元，可远程访问并进行操作和更新。SOA 的接口可以是 socket、IPC、共享内存、消息队列、RPC……，只要是在独立的进程中，通信方式并无限制。
• 微服务是 SOA 的一种特定实现方式。

单体架构

• 单体架构的代码组织简单，各个模块容易做到同构；部署简单，适合小型应用，通常是一个项目开始的最好方式
• 数据通常中心化，对一个模块代码的改动容易扩散到其他模块
• 可以合理划分模块，以软件包和软件库的方式重用代码：单体架构的运行是同一个进程，所以接口不够松散，库接口的升级可能导致“依赖地狱”。

微服务架构

• 每个模块单独运行在独立的进程空间
• 通过 REST 接口交互：交互格式与语言无关
• 每个服务都独立保留数据，没有中心化的数据库
• 定义：微服务是一个轻量级应用，它通过定义良好的接口提供一组有限的功能，具有单一的责任，可以独立开发和部署。

微服务的好处

• 开发团队的分工
• 限制项目规模
• 容易扩展和部署

微服务的缺点

• 不合理的拆分：过早拆分是万恶之源
  • 如果你总是必须一起部署两个微服务 ，或者一个服务的修改会影响另外一个数据模型：可能没有正确拆分。
• 更多的网络交互：网络问题、同步异步、相应时间、传输数据量
• 数据的存储和分享：数据独立会不会造成重复的数据冗余
• 兼容性问题：某个服务的升级，影响向后的兼容（重点是 API 设计）
• 测试难度增加：越灵活 => 越难测试；越松散 => 越难测试