-
应用程序扩展方便
微服务通常是无状态的，如果使用Docker，Kubernetes或其他基础架构对其进行仔细部署，则微服务可以在几秒钟内提供水平扩展。 -
开发速度
微服务的规模通常很小（几百到几千行行代码）。由于大小，在微服务中添加新功能通常会更快。 -
开发规模
微服务是自治的，可以独立开发。不同的开发人员/团队可以自动处理不同的微服务，不会碰到彼此的代码。 -
发布周期
每个微服务都可独立部署。因此，微服务应用程序中的软件发布周期要短得多，并且使用 CI / CD 可以每天发布多个版本。 -
模块化 微服务的边界是物理分隔的一堆外部接口集合组成。因此，正确设计的微服务通常具有“高内聚，低耦合”的特性。 现代化 | 由于微服务之间是松散耦合的，并且只能通过与语言无关的方式相互通信，因此可以轻松地用一种新的微服务替换单个微服务，该新服务可以使用新的编程语言和技术栈开发，而不会影响整个系统。
-
设计复杂性
微服务边界的划分、单个微服务可能由许多方案组成以及微服务间的融合都会导致设计复杂。因此，错误的服务划分，必然导致微服务架构的失败，极端情况相比单体应用差。 -
分布式系统复杂性
微服务通常是分布式系统，我们知道分布式系统比单机系统复杂，并且面临着一系列独特的挑战。简而言之，分布式微服务中可能会出现以下问题：总体系统延迟更高，网络故障或单个节点故障会使整个系统瘫痪，操作复杂性更高。 分布式系统复杂性 | 微服务通常是分布式系统，我们知道分布式系统比单机系统复杂，并且面临着一系列独特的挑战。简而言之，分布式微服务中可能会出现以下问题：总体系统延迟更高，网络故障或单个节点故障会使整个系统瘫痪，操作复杂性更高。 -
操作复杂性 一旦复杂的 Monolithic 应用程序分解为许多微服务，复杂性通常会从源代码转移到操作。诸如日志记录，监视之类的简单操作变得更加复杂，因为需要处理一个系统而不是一个系统。通常，现有的日志记录/监视工具不适合微服务，因此需要新的日志记录，监视工具。
-
安全性
确保一个软件应用程序的安全非常困难，要保护数百个通常是分布式系统的微服务，这更是一个很大的挑战。 -
数据共享和数据一致性
理想情况下，每个微服务都应拥有自己的数据存储。缺点是微服务需要在它们之间共享数据才能实现业务目标。数据一致性是另一个挑战，因为不建议使用经典的两阶段锁定来支持分布式数据库中的一致性，原因有两个：不能扩展，许多现代数据存储不支持它。大多数现代NoSQL数据库仅提供最终一致性，这需要仔细设计。 -
通信的复杂性
微服务通过边界的划分实现了严格的模块化和开发自主性。缺点是服务只能通过物理网络进行通信，这最终会导致更高的网络延迟。微服务可以通过多种方式相互通信：使用REST的同步通信，gRPC或使用Message Queue的异步通信，Message Broker，其中每个服务都有优缺点。同步通信更易于实现，但会导致所谓的D 分布式单片。通过消息传递的异步通信以更大的实现复杂性为代价，提供了更大的灵活性。在微服务架构中，根据应用选择正确的通信机制也具有挑战性。
云原生应用定义:
基于微服务原理而开发的应用，以容器方式打包。在运行时，容器由运行于云基础设施之上的平台(比如kubernetes)进行调度。应用开发采用持续交付和DevOps实践