随着开发团队转向采用微服务，***使用案例有助于提供参考，因此可以了解一些主要厂商的微服务用例。
大多数企业开发团队将不再使用云托管的微服务。因为大多数可能会出现问题，而早期的使用者会放弃甚至拒绝使用微服务。***的微服务用例分为四类，每个企业都应该联系一个或多个早期微服务采用者，让他们提出一些建议。
微服务用例
***个用例是使用微服务来促进云采用。大多数开发团队认识到，***的使用公共云和混合云的应用程序架构是不同的。很少有人准备说明这些差异，以及如何实现有序的部署，安全和合规的运作以及全面的托管效率。微服务提供了一种新的应用程序模型的路径，即使以整体形式，也容易地托管在数据中心中，仍然轻松移动到云平台。
微服务在定义一种在绑定服务方面具有动态性的服务模型方面超越了面向服务架构(SOA)。微服务是一个设计(如果正确完成)功能的单元，是无状态和可扩展的，同时，以紧耦合或松散耦合意义连接。用户可以将微服务和核心应用程序组件集成到单个机器映像中，复制服务并避免组件连接和集成的问题。可以使用API管理器将相同的微服务扩展为受控共享服务，该管理器可复制SOA机制的安全性，然后以治理许可的REST形式暴露。这种选择范围在应用设计中是***的，它是云计算的理想选择。
第二个微服务用例的重点是通过微服务实现以业务为中心的经典面向服务架构(SOA)的目标。微服务要高效，要求应用架构师与企业架构师更加配合，以识别可重用的业务功能，以转变为微服务。这是一个重要的，有价值的，偏离传统的SOA模式，其中服务的定义主要是基于技术考虑。企业最近意识到需要对IT元素和组件化进行更多的基于业务的评估，但是如何开始却不太明确。
通过识别应用程序的业务功能，然后在应用程序之间映射常见或非常相似的功能，开始实施良好的微服务策略。这些功能成为微服务创建的目标，尽管预计将有一些是广义***限度的重用，有些可以基于诸如无状态行为和可扩展性的技术目标映射到一系列微服务而不是单个微服务。
第三个微服务用例是使用微服务来利用云计算的弹性和可扩展性。企业知道，采用云计算的主要好处并不是降低计算成本，而是更有效，更高效的运营，提高业务灵活性和应用程序的体验质量。问题在于，用户并不清楚如何利用云功能实现这些优势。而微服务是***的答案。
弹性或可伸缩性意味着扩展或收缩应用程序资源以匹配工作负载并响应失败。这意味着构建应用程序，以便应用程序的“瓶颈”组件可以实例化多个副本，并且可以在副本之间平衡工作负载。微服务说明如何构建组件以使此过程变得容易，并且用于将安全性/治理实践应用于微服务的API管理器也可用于负载平衡和实例管理。
这种用例也可以被视为将应用程序移动到基于容器的部署的一种方式，这是采用云计算企业越来越重要的一个目标。由于微服务是相对较小的功能元素，它们适用于容器的低开销模型，并且已经做了大量工作来证明两种技术的***结合。
***一个，也许最复杂的微服务用例是创建事件驱动的企业。。应用程序设计长期以来是基于应用程序的概念，它是通过静态工作流链接的一系列组件，通常通过消息/服务总线支持。企业IT作为企业事件响应的一种看法是一种替代模式，对于IT和业务整体而言，它们比组件化或云计算具有更大的潜在影响。然而，事件驱动的企业流程也与传统设计有着深刻的背离，也是架构师和开发人员面临的挑战。
找到工作的用例
微服务比任何当前的技术开发直接支持事件驱动的业务IT方式。作为无状态功能实现的细粒度微服务可以根据需要向外推，这将开启一个全新的应用程序设计模型，功能组件根据需要进行封送，并推送到工作人员起源点，并收集公司数据的信息库。
大多数公司会发现微服务器的这些用例区域之一是相关的，许多公司会发现其中的几个(甚至全部都可以应用)。微服务并不会自动解决这些问题，很明显，用例是应用微服务的指南，但不一定是一个路线图。最聪明的做法就是查看上面的所有要点，并将它们从即刻和长期的重要性中排除。然后，确定与每个重点相关的微服务功能，并决定哪些特定的微服务能力是最重要的。
微型服务仍处于起步阶段，很容易造成错误，因为任何给定领域的***实践仍然不成熟。这意味着，与微型服务一样有价值，如今，它们仍然是一个更多用户支持的更长时间的风险更高的策略。用户需要花费一定的时间评估使用案例，并仔细开发自己的微服务策略，以防止难以纠正早期的错误。
