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

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

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

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

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

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

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

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

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

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

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

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

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

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

接下来的文章将分别为你详细介绍微服务架构的六种经常使用设计模式。敬请关注。