转载

六种常用的微服务架构设计模式前言篇

在过去的几年里，微服务一直是IT界的热门话题。ZDNet认为微服务是一项“值得关注的技术”，而软件设计咨询公司ThoughtWorks 已经宣布，微服务架构作为一种编程模型正呈现上升趋势。新闻媒体界正在逐渐认可微服务架构，这个现象可能会让一些架构师和IT主管感到担心，他们害怕自己会错过下一个令人兴奋的趋势。

许多人认为微服务是一种规范性的架构，一个企业假定必须采用微服务架构的话，那么必须以一种特定的方式进行（例如Netflix），否则就无法实现。然而，对于许多企业来说，以特定方式采用微服务是不可行的，并且可能会导致失败。对于那些具备特定结构和文化的企业来说，由于各种规章制度、技术和文化的限制，纯粹的微服务架构也就不再适用了。在企业的需求与这种纯粹的微服务架构不兼容的情况下，如果企业在微服务领域仍然遵循一个过于规范的方法，那么它将注定失败。

拥有大量遗留系统的大型企业的需求与年轻公司的有所不同，企业文化可能就不适合采用纯粹的微服务架构了。一些企业，特别是在高度管制的行业中，与Netflix或Spotify相比，具有不同的安全性或合规性需求，纯粹的微服务架构也就不可行了。

实际上，企业需要从实用的角度出发，以一种对企业有意义的方式，尝试适应微服务架构。毕竟并不是每个企业都必须是Netflix或Spotify。企业可以采用与自身文化、目标和组织架构相适应的微服务架构。微服务架构有多种设计模式，企业可以根据自身的需求来选择这些模式，而不是将微服务作为一种单一的方法（这将违背体系结构的要点）。对于企业而言，没有必要同时采用微服务的每一个模式，只需要采用对自身企业有意义的、实用的一种模式即可。

1987年，厨师费朗·阿德里听到了富有开创性的一句话“创造力意味着不抄袭”。这个简单、不言而喻的说法在烹饪界掀起了一场重大运动。同样地，关于微服务，我们可以说 “微服务不是一个整体”。

实际上，微服务模式最初是作为一个整体应用的替代品而创建的，它本质上应该是非整体的：容易更改，粒度小，可扩展。这也意味着微服务不仅仅是一个东西。相反，我们假定微服务是一类分组的、相关的模式，它们共享同一组目标。这类似于数据库系统；它们都有相似的特点——通常具有不同的优先级，如可扩展性或可维护性。然而，它们之间的具体情况差别很大。例如，RDBMSes、NoSQL存储、时间序列数据库和大数据存储等都有一个相似之处——它们提供了存储和查询数据的能力——但它们各自权衡的具体情况却并不一样。

在接下来的几篇文章中，我们将重点介绍几种广泛实践过的微服务模式。在实践中，这些模式都有各自独特的优势，不能说哪个更好哪个更坏，而需要权衡轻重缓急，选择一种折衷方案。这些模式都遵循微服务体系结构的特点：速度、可伸缩性、内聚性，差异之处在于实现方式有所不同。甚至可以说，其中一些模式是“过程中的步骤”，它们使得体系结构具备微服务的特点。它们自身倾向于产生可预测的失败条件，从而鼓励以这种模式工作的团队寻找替代方案，做出更困难的权衡，然后在不断增长的经验中发展成一种不同的、更专业的模式。

微服务体系结构就是这样形成的。它开始于一个概念方法和一组特点，这些特点导致了第一次架构迭代，然后快速迭代到更专业（许多人认为是更“极端”）的模式。这不是坏事。正在实施或适应这些早期模式的企业并没有做什么倒退的事情，而是将其当前状态改进到可以清楚地看到采取下一步的好处的阶段。这是微服务架构非常“真实”的一种方式，它们遵循人类学习的模式。实施者都是人类，至少现在都是，他们需要通过个人经验来学习更具体的模式和权衡的价值，而不是盲目地跟随任何特定的文本或博客文章。

微服务架构应该是逐渐进化得来的，因为它产生于对软件系统快速更新，以及在多次迭代过程中改进系统的需求。在大多数企业中，从一开始就实现微服务体系结构是相对罕见的（许多人认为这样做是一种反模式）。因此，基于成熟度、需求和时机，通常会有一个体系结构、模式和技术的延续性。这个延续性的其中一些是由团队吸收更改的能力驱动的，另一些依赖于设置启用的基础设施，还有一些依赖于组织变革和团队重组，例如DevOps实践。能够专注于当前可以做的事情，同时使团队不断向更高效的状态发展，这是微服务体系结构的关键优势之一。

微服务架构有六种常用的设计模式，这些模式可以让企业更加容易采用微服务体系结构。这些模式中的每一个都不是通用的模式；相反，每个企业都可以权衡，在特定的场景中采用特定的设计模式。我们希望实现特定模式的用户将此作为参考，按照这些模式来规划其体系结构，而不是试图过度应用任何单一模式，从而打破折衷方案。理想状态是使用这些模式的混合来设计和实现一个微服务体系结构，而不是选择一个模式并向其迁移。

这些模式不存在哪个更好哪个更坏，在特定任务中都有各自独特的优势。在描述每个模式时，我们应该弄清楚要解决的问题是什么。

最后一点需要强调的是， 微服务架构并不适合每个用例 。例如，如果一个企业严重依赖于ERP应用程序，并且不打算替换它，那么对这个企业来说，微服务可能并不适合。然而，对于企业而言，它的部分业务肯定能够通过速度、规模和凝聚力这些特性来获益，那么在这些领域就应该寻找机会利用微服务架构。

微服务模式并不特别适用于任何一种规模或类型的组织。事实上，状态管理的模式往往对大型、快速发展的公司更有用。但是，对于有适当需求并且愿意正确平衡其体系结构需求的企业或者公司，这些模式都是适用的。换句话说，“停在哪里”完全取决于你要解决的问题，而不是通过这些模式的任何线性进展。