微服务架构

什么是微服务？

微服务 - 也被称为微服务架构 - 是一种架构风格，它是使一个整合了业务功能的程序成为一个松耦合服务的架构。微服务架构使大型的，复杂的应用程序，可以连续快速的实现和部署。另外，它也使得企业可以发展自己的技术栈体系。

微服务不是银弹

微服务架构不是银弹，它有几个缺点。此外，采用这种架构的时候，你必须解决许多问题。微服务架构模式语言是一系列实现微服务架构模式的集合。 它有两个目标：
1，模式语言使您能够决定微服务是否一个非常适合你的应用程序。
2，模式语言使您能够成功使用微服务架构。

从哪儿开始？

一个很好的出发点是单片架构模式，这是传统的架构风格，也仍然是许多应用的理想选择。然而，它也有许多局限性和问题，因此对于大型 / 复杂的应用程序更好的选择是微服务架构模式。

运用微服务架构模式语言
微服务架构模式语言包含了一组模式，它的价值超过了个别模式的综合，因为它定义了模式之间的这些关系：
开创者模式 - 是刺激微服务模式产生的一种模式。例如，微服务架构模式是开创者模式语言，因为它是除了该单片式架构模式的剩余部分。

继承者（组件）模式 - 这是一种解决引入微服务架构模式所带来的一系列问题的模式。例如，如果您采用微服务架构模式，必须再申请众多的继承者模式，包括服务发现模式和服务熔断模式。

替代者模式- 是一种提供可替代的解决方案的模式。例如，单体应用架构和微服务架构师一种替代者模式，你可以选择这一个，也可以选择另一个。这些替代者模式，可以在你选择架构模式时，提供宝贵的指导意见。当你采用一个模式产生问题时，你必须通过继承者模式去解决它。而在解决的过程中，你必须在这些继承者模式中递归选择，直到确定你的解决方案，或者没有可供选择的解决方案。如果存在两个或多个模式替代品，那么你必须选择一个。

让我们来看看如何应用微服务架构模式语言来构建应用程序。在这篇文章中，我们将看看你必须做的3个关键性决策。在以后的文章中，我们将看看其他不是最为关键，却也十分重要的影响因素。

关键决策
决策＃1：单体架构或微服务架构？
你必须做出的第一个决定是：使用单体架构模式或微服务架构模式？如果你选择的微服务架构模式，你必须选择许多其他方式来处理决定所带来的后续问题：

决策＃2：如何分解应用到服务？
如果你已经决定使用微服务架构，则必须定义您的服务。有两个主要选择，
按业务功能分解 -定义相应的业务能力服务
由子域分解 -定义对应DDD子域名服务
这种模式产生相同的结果：一组围绕业务概念，而不是技术概念组织的服务。

决策之三：如何保持数据的一致性和执行查询？
微服务的一个重要特点是每个服务都有其独立的数据库。它的替代方案，共享数据库模式事实上是一个很好的逆向选择和避免问题最佳的方案。每个服务模式的数据库带给你一个重大的挑战是：如何保持数据的一致性和执行查询。您将需要使用saga模式，并经常需要实现使用查询命令查询职责隔离（CQRS）模式。