概述

通常认为微服务架构思想是SOA思想的一种延续，都强调松耦合，只是SOA高度依赖企业服务总线（ESB），而微服务不需要。

提出MicroService概念的Martin Fowler也说过，“我们应该把SOA看做微服务的超集”，也就是说微服务是SOA的子集。
SOA系统其实可以拆分成多个更细粒度的微服务系统。

SOA（面向服务的架构）

一种架构思想，其中包含多个服务，服务之间通过配合最终会对外提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非采用进程内调用的方法进行通信。

MicroService

一种架构设计思想，是SOA架构概念的细化，更加强调服务拆分的粒度和服务的单独运维管理。

优点

复杂度可控
通过对共享业务服务更细粒度的拆分，一个服务只需要关注一个特定的业务领域，并通过定义良好的接口清晰表示服务边界。由于体积小、复杂度低、开发、维护会更加简单。
技术选型灵活
每个微服务都由不同的团队来维护，所以可以结合业务特性自由选择技术栈。
可扩展性更强
可以根据每个微服务的性能要求和业务特点来对服务进行灵活扩展，比如通过增加单个服务的集群规模，提升部署了该服务的节点的硬件配置。
独立部署
由于每个微服务都是一个独立运行的进程，所以可以实现独立部署。当某个微服务发生变更时不需要重新编译部署整个应用，并且单个微服务的代码量比较小，使得发布更加高效。
容错性
在微服务架构中如果一个服务发生故障，我们可以使故障隔离在单个服务器中。其他服务可以通过重试、降级等机制来实现应用层面的容错。

缺点

故障排查
一次请求可能会经历多个不同的微服务的多次交互，交互的链路可能会比较长，每个微服务会产生自己的日志，在这种情况下如果出现一个故障，开发人员定位问题的根源会比较难，通常需要拉通不同的项目组进行联合定位。
服务监控
在单体架构中很容易实现服务的监控，因为所有的功能都在一个服务中。在微服务架构中，服务监控开销会非常大，比如几百个微服务组成的架构中，我们不仅要对整个链路进行监控，还需要对每一个微服务都实现一套类似单体架构的监控。
分布式架构的复杂性
微服务本身构建的是一个分布式系统，分布式系统涉及服务之间的远程通信，而网络通信中网络的延迟和网络故障是无法避免的，从而增加了应用程序的复杂度。
服务依赖
微服务数量增加之后，各个服务之间会存在更多的依赖关系，使得系统整体更为复杂。假设完成一个需求，需要修改服务A，B，C，而A依赖B，B依赖C。在单体应用中，你只需要改变相关模块，整合变化，再部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。往往一个需要多个团队相互协作，增加了沟通、调试的难度。
运维成本
在微服务中，需要保证几百个微服务的正常运行，对于运维的挑战是巨大的。比如单个服务流量激增如何快速扩容、服务拆分后故障点增多如何处理、如何快速部署和统一管理众多的服务等。