转载

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原文  https://segmentfault.com/a/1190000019769217
正文到此结束
Loading...