基于微服务的解决方案的好处
- 开发人员很容易理解并以良好的生产力快速入门。
- 容器启动很快，这使开发人员的工作效率更高。
- 像Visual Studio这样的IDE可以快速加载较小的项目，使开发人员高效。
- 每个微服务都可以独立于其他微服务进行设计，开发和部署，从而提供灵活性，因为它更容易经常部署新版本的微服务。
可以扩展应用程序的各个区域。例如，可能需要扩展目录服务或购物篮服务，而不是订购流程。对于扩展时使用的资源而言，微服务基础结构将比单片体系结构更有效。
您可以在多个团队之间划分开发工作。每个服务都可以由一个开发团队拥有。每个团队都可以独立于其他团队管理，开发，部署和扩展他们的服务。
问题更加孤立。如果一个服务中存在问题，则最初只影响该服务（除非使用了错误的设计，微服务之间存在直接依赖关系），其他服务可以继续处理请求。相比之下，单片部署体系结构中的一个故障组件可能会导致整个系统崩溃，尤其是当涉及资源（如内存泄漏）时。此外，当解决微服务中的问题时，您可以仅部署受影响的微服务，而不会影响应用程序的其余部分。
您可以使用最新技术。因为您可以独立开始开发服务并并行运行（感谢容器和.NET Core），您可以方便地开始使用最新的技术和框架，而不是被困在整个应用程序的旧堆栈或框架上。
基于微服务的解决方案的缺点
像这样的基于微服务的解决方案也有一些缺点：
分布式应用。分发应用程序会增加开发人员在设计和构建服务时的复杂性。例如，开发人员必须使用HTTP或AMPQ等协议实现服务间通信，这增加了测试和异常处理的复杂性。它还增加了系统的延迟。
部署复杂性。具有数十种微服务类型并且需要高可伸缩性的应用程序（它需要能够为每个服务创建多个实例并在多个主机上平衡这些服务）意味着IT操作和管理的高度部署复杂性。如果您不使用面向微服务的基础架构（如协调器和调度程序），那么额外的复杂性可能需要比业务应用程序本身更多的开发工作。
原子交易。多个微服务之间的原子事务通常是不可能的。业务需求必须包含多个微服务之间的最终一致性。
增加全局资源需求（所有服务器或主机的总内存，驱动器和网络资源）。在许多情况下，当您使用微服务方法替换单一应用程序时，新的基于微服务的应用程序所需的初始全局资源量将大于原始单片应用程序的基础架构需求。这是因为更高的粒度和分布式服务需要更多的全局资源。但是，考虑到整体资源成本低，并且与单个应用程序发展过程中的长期成本相比，能够扩展应用程序的某些区域的好处，增加资源的使用通常是一个很好的权衡期限申请。
