掌握这几种微服务模式助你成为更出色的工程师

Posted 茶轴的青春

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了掌握这几种微服务模式助你成为更出色的工程师相关的知识,希望对你有一定的参考价值。

导读:对于很多工程师来说,进入微服务领域是很困难的。99%的服务属于五类之一,通过这种方式划分责任考虑如何通过管道服务一起管理特性,就像在Unixshell脚本中一样。

所有的微服务有什么共同之处,域驱动设计之父Eric Evans将其定义为:“(服务)可以消费和生成消息。”

考虑到这一点,对于每个服务模式,会讨论产生或使用消息的类型。

这些消息可以再分为两类:事件和命令。

开始之前,因为上下文很重要,我首先从Matt Walters那里看到了这些微服务模式,它是libraryservicebus的创建者。Servicebus是一个名为NServiceBus的流行.Net库的节点改编,由Udi Dahan创建和推广。

通过Servicebus,可以轻松编写发送和监听命令,并使用AMQP作为通用语言发布和订阅事件,使用JSON有效负载。这意味着其他编程语言可以轻松实现相同的接口,并能够无缝地参与由多种语言编写的部件组成的系统。

技术分享图片

1.模型服务(Model Services)

如果想到MVC,那么可以使用这种类型的服务。模型服务是模型应该存在的地方。边界通常是在聚合或实体层面进行,具体取决于域的复杂性。

模型服务使用与上下文相关的消息。例如,如果有一个库存服务,与消耗相关的命令消息将是inventory.product.create或inventory.product.increaseStock。作为响应,你希望生成一些事件消息,以便系统的其余部分能够了解模型是如何变化的,并响应这些更改。本例中生成的事件消息将是inventory.product.created和inventory.product.stockLevelIncreased。

2. Denormalizer服务

除了分布式系统之外,Denormalizer正是关系数据库所做的事情。它们将多个规范化的输入源合并到一个可读的数据结构中,客户端可以使用这些数据结构。

例如,假设一个电商应用。当库存水平增加或减少,或在库存中可用时,应用程序应该知道它。

想象一下,如果你是应用工程师,他们使用的是与MongoDB类似的东西——他们只是从外部系统获得了实时的库存,而无需编写一行代码。这也适用于RethinkDB和GraphQL订阅!

如果团队需要在Kafka中为大数据提供数据,只需添加一个Kafka的denormalizer服务。

3.网关服务

网关服务非常类似于Denormalizers。但是,它不是连接到数据库,而是与API连接。

最近在和一个叫LiftIgniter的推荐引擎合作,库存需要同步。该服务订阅inventory.product.updated 和inventory.product.added 事件,并将格式化数据发布到适当的端点。

后来,又增加了一项服务,监听相同的事件,并通过建立Magento网关服务,保持更新库存的水平。

4.Ingestor服务

到目前为止,我们讨论的都是通过系统传播的数据,或者在模型服务中创建的数据。但是,经常需要将外部数据输入到系统中。从概念上讲,来自外部源的数据需要被输入到系统其它部分所讲的通用语言中。

Ingestor服务通常只会产生信息。这些服务通常包括通过HTTP接收API POST,或者运行CRON作业,并在一个时间间隔内抓取。获取或接收的数据随后使用通用语言(AMQP w/ JSON)发布到系统中。

5.适配器服务

适配器服务是更少见,但值得一提。与网关服务类似,适配器使用消息,使用该数据来调用系统上的库。这个例子是使用ImageMagick这样的图形处理工具。ImageMagick是一个强大的工具,但是没有Node.js绑定。适配器服务通过执行子进程来解决这个问题,然后以系统的通用语言生成消息。

6.API服务

API服务应该保持轻量级。如果您正在将一大堆业务逻辑构建到API中,那么正在构建一个庞然大物。 它比我们用“n层”架构看到的应用程序和服务器的组合稍好一些,但最终导致臭名昭著的“大泥球”。

要实现这一点,可以使用上面的 Denormalizer 服务,将数据的查询效率视图映射到API读取的数据库中。这就产生了一个单向的数据流。

Unidirectional Systems

使用上述模式可以让企业在单向工作流中使用不可变事件。如果你已经进入应用程序开发,肯定熟悉Redux如何改变了状态管理的游戏。有一个存储在组件树下的状态可以轻松地解释操作如何影响状态,因为它们是所有发生在集中位置的简单的不可变事实。

如果遵循上述模式,将使用更复杂的称为命令查询责任隔离(Command Query Responsibility Segregation ,CQRS)的方法。命令是由模型服务消费的,而事件的生成则是由Denormalizer或网关服务所消耗的。然后对读模型进行查询。

因为使用的是不可变消息,这使得事件采购成为构建模型服务的完美模式。值得一提的是Matt Walters的另一个创造,一个名为[sourced]的微观框架,与servicebus完美协调,可以轻松添加事件采购功能来消费服务的事件,并持久存储到数据库中。

 

 

总结:关于微服务模式这一块,想说的内容已经说完了,希望我的经验可以帮到你们,觉得写的好的,可以点赞关注一下,你的点赞关注就是对我最大的支持。

以上是关于掌握这几种微服务模式助你成为更出色的工程师的主要内容,如果未能解决你的问题,请参考以下文章

六种微服务架构的设计模式

Couchbase 的四种微服务架构

详解4种微服务框架接入Istio方案

微服务架构的设计模式

6种微服务RPC框架,你知道几个?

最流行6种微服务RPC技术,你一定要知道