好处：逻辑清晰
这一特点是微服务单一责任的要求带来的。 负责明确业务的微服务肯定比复杂系统更容易逻辑理解。
逻辑清晰是微服务的可维护性，当我们对微服务进行修改时，可以更容易地分析这种修改会产生什么影响，通过完整的测试来保证修改质量。
简化部署
在一个系统中，只需修改一行代码，就需要重建、测试整个系统并部署整个系统。 微服务可以引入微服务。
这样做的一个好处是，您可以更频繁地修改软件，以更低的成本快速发布新功能。
可扩展
适应系统业务增长的方法通常在向外扩展或向上扩展的方向上扩展。 在分布式系统中，通常用Scale out方式进行扩展。 由于每个功能都会面临不同的负载变化，因此采用微服务的系统比单个系统具有更好的可扩展性。
灵活组合
在微服务架构中，将现有的微服务组合起来可以实现功能复用的目的。
例如，如果添加Booking Service，则可以在保留时直接重用Account Service和Inventory Service以检查用户权限和库存情况。
技术异构
在大型系统中，不同的功能可能有不同的特征，不同的团队可能有不同的技术能力。 由于微服务之间的松散耦合，不同的微服务可以选择不同的技术堆栈来开发。
另外，应用新技术时，可以只快速改造一个微服务，不影响系统内的其他微服务，有利于系统的发展。
例如，由于清单系统中的数据量较大，如果需要将数据从当前sqlite数据库更改为MySQL，则无需替换整个系统中的所有数据库，只能更改库存服务。
高可靠
微服务之间独立配置，一个微服务的异常其他微服务不会同时异常。 可以避免隔离、熔断等技术大大提高微服务的可靠性。
缺点复杂度高
由于微服务之间以REST、RPC等形式进行交换，因此对于Monolithic模式下的API形式，需要考虑调用方的故障、过载、消息丢失等各种异常情况，代码逻辑变得更加复杂。
对于微服务之间的事务操作，由于每个微服务都使用不同的数据库，因此无法利用数据库本身的事务机制来保证一致性，需要引入两阶段提交等技术。
另外，如果微服务之间存在共同功能的一部分，但不能提取为微服务，则每个微服务通常需要对该功能的一部分进行重复开发，或者至少进行代码复制，以避免微服务之间的耦合，从而实现开发副本
运维复杂
采用微服务体系结构时，系统由多个独立运行的微服务组成，需要设计良好的监控系统监测各微服务的运行状态。 运输业者必须对系统有详细的了解，才能建立更好的运输系统。
影响性能
相对于Monolithic架构，微服务之间以REST、RPC等形式相互作用，通信延迟受到较大影响。