优势

使大型的复杂应用程序可以持续交付和持续部署

  1. 拥有持续交付和持续部署所需要的可测试性（因为服务小，自动化测试容易）
  2. 拥有持续交付和持续部署所需要的可部署性（每个服务可以独立于其他服务进行部署）
  3. 使开发团队能够自主且松散耦合（团队成员能够自由组合，负责部分业务）

每个服务都相对较小且容易维护

服务可以独立扩展

  1. 每个服务都可以部署在适合他们需求的硬件上，选择最为合适的硬件。而单体架构选择的硬件必须满足所有的服务需求

更好的容错性

  1. 可以实现更好的故障隔离，某个服务中的内存泄漏不会影响到其他服务

更容易实验和采纳新的技术

弊端

服务的拆分和定义困难

  1. 如果拆分出现偏差，会产生相互之间紧耦合却又必须部署在一起的所谓分布式系统

分布式系统固有的各种复杂性

  1. 必须使用进程间通信机制
  2. 因为每个服务都有自己的数据库，所以跨服务的事务和查询不方便
  3. IDE等开发工具不易使用
  4. 编写自动化测试也不容易
  5. 部署不容易，需要使用K8S等部署工具

当部署跨越多个服务的功能时，需要谨慎协调更多的开发团队

  1. 需要制定发布计划，吧服务按照依赖关系进行排序等

需要考虑什么时候将单体架构转变为微服务架构

  1. 因为微服务框架自有的复杂性，对于初创公司来说不适合，此时应该使用单体模式；等到业务发展到单体带来的各种问题已经超过了微服务能够带来的问题时，这时才考虑将单体应用重构为微服务

参考：《微服务架构设计模式》