译者 | 李睿
审校 | 重楼
本文将分享一些在Mule4中创建高可靠应用的优秀实践。而用户对可靠性的期望是在Mule应用程序停止或崩溃之后不会丢失消息或数据。
这里分享的大部分配置细节(与可靠性相关)都来自MuleSoft文档/文章。
当在单个运行时实例模式下运行Mule应用程序时,持久队列通过序列化并将内容存储在磁盘上来工作。但是,当在集群运行时实例模式下运行Mule应用程序时,持久队列会备份在内存网格中。在单个运行时实例模式或集群运行时实例模式下,当使用持久队列时,发送的数据必须是可序列化的。
CloudHub(1.0)部署的应用程序可以选择使用CloudHub持久队列。CloudHub持久队列是一种云服务,允许将发布到虚拟机(VM)队列的消息存储在应用程序的外部。
CloudHub持久队列可以在每个应用程序的基础上启用,该选项可以在运行时管理器→应用程序→设置页面中找到。如果用户拥有这一权限,还可以选择加密持久队列以增加安全性。这一功能仅适用于拥有白金及以上订阅权限的用户。
Anypoint MQ是一个多租户的云消息传递服务,允许客户在其应用程序之间执行高级异步消息传递方案。Anypoint MQ与Anypoint平台完全集成,提供基于角色的访问控制、客户端管理和连接器。
Anypoint MQ确保安全可靠的消息传递。自动启用跨多个数据中心的持久数据存储,以确保消息队列架构能够处理数据中心中断并具有完全的灾难恢复。对消息队列进行加密以确保数据处于静止状态,或将消息发送到死信队列以提高可靠性。
安装和配置Anypoint MQ
在Anypoint Studio中,
用于JMS(Java消息服务)的Anypoint连接器(JMS连接器)支持向实现JMS规范的任何消息服务的队列和主题发送和接收消息。
配置源:
可以配置以下三个输入源中的一个来使用JMS连接器:
要配置“新建消息”源,执行以下步骤:
在JMS配置窗口中,为“连接”选择要提供给此配置的连接类型之一:
要为JMS连接器添加操作,遵循以下步骤:
对象存储是一个存储键值信息的存储容器。对象存储可以是持久的或暂时的(非持久的),在应用程序重启的情况下,持久性操作系统不会丢失任何信息(键值),而非持久性(键值)信息丢失。
使用默认对象存储
在默认情况下,每个Mule应用程序都有一个持久的对象存储,并且总是可以在不需要任何配置的情况下对应用程序可用。数据流可以使用它来持久化和共享数据。
如果希望使用默认的对象存储,可以为对象存储指定键,而无需为对象存储操作选择或创建对象存储引用,也无需在对象存储组件的XML元素中指定对象存储属性。
Mule应用程序使用运行时管理器部署到CloudHub worker,但是默认对象存储的内容在应用程序的应用程序数据页面的运行时管理器中是不可见的。
使用自定义对象存储
自定义对象存储必须指定对象存储属性。这些对象存储可以配置为不同于默认对象存储的行为。例如,可以指出对象存储是持久的(这样对象存储的数据在Mule运行时崩溃时仍然存在)还是瞬态的(在Mule运行时崩溃时数据不存在)。
Anypoint Runtime Fabric提供Persistence Gateway。
允许部署到Mule运行时实例的Mule应用程序在应用程序副本和重启之间存储和共享数据,从而确保可靠性。
在Anypoint Runtime Fabric中配置了Persistence Gateway后,它就可以用于部署到Mule运行时引擎(4.2.1或更高版本)的Mule应用程序。在配置完成后,用户可以在使用运行时管理器部署应用程序时选择“使用持久对象存储”。
Mule应用程序通过对象存储连接器使用对象存储v2 REST API连接到Persistence Gateway。这使得用户可以同时部署到Anypoint Runtime Fabric和CloudHub,而无需修改Mule应用程序。
在配置过程中,Persistence Gateway创建所需的数据库模式。然后,当部署到Runtime Fabric的应用程序被配置为使用持久对象存储时,Persistence Gateway将必要的行写入数据库。
要配置Persistence Gateway,必须创建一个Kubernetes自定义资源,该资源允许集群连接到持久性数据存储。
Create a Kubernetes Secret
Shell
kubectl create secret generic -n rtf --from-literal=persistence-gateway-creds='postgres://
es://username:pass@host:port/databasename'
为数据存储创建自定义资源
1.将自定义资源模板从Kubernetes自定义资源模板复制到一个名为custom-resource.yaml的文件中。
2.确保secretRef:name的值与Kubernetes秘密文件中定义的name字段匹配。
3.根据环境的需要修改自定义资源模板的其他字段。
4.运行kubectl apply-f customientresource.yaml。
检查Persistence Gateway Pod的日志,以确保它可以与数据库通信
Shell
kubectl get pods -n rtf
寻找具有名称前缀Persistence Gateway Pod
Shell
kubectl logs -f persistence-gateway-6dfb98949c-7xns9 -nrtf
参考上面的“异步处理”。
另一种选择是将数据持久化在外部存储系统中,如DB、FTP、外部缓存等。Mule应用程序可以使用连接器连接到这些系统。
不同的外部存储提供不同的服务质量(QoS)级别,从而确保可靠性:
当Mule应用程序中的操作无法连接到外部服务器时,默认行为是操作立即失败并返回连接错误。
为了确保不丢失数据,可以通过为该操作配置重连接策略来修改这一默认行为。
可以通过修改操作属性或修改操作的全局元素的配置来配置操作的重连接策略。
连接性测试在Mule应用程序启动时运行,然后在应用程序运行时定期运行。重新连接策略指示当连接失败时应该做什么。
以下是可用的重连接策略及其行为:
XML示例代码:
XML
XML
在默认情况下,只会记录一个失败的连接测试,Mule应用程序无论如何都会启动或继续运行而不尝试重新连接。但是,可以在某些连接器操作上配置重新连接策略,以代替重复尝试连接。
配置属性/参数如下:
< reconnection >的属性
failsDeployment:如果为true,当测试连接失败时导致部署失败。默认为false。
Blocking:如果为false,重连接策略在一个单独的非阻塞线程中运行。默认为true。
Frequency:重新连接的频率(毫秒)。默认为2000。
Count:尝试重连的次数。默认值为2。
Blocking:如果为false,重连接策略在一个单独的非阻塞线程中运行。默认为true。
Frequency:指定重新连接的频率(单位:毫秒)。默认为2000。
重新传递策略(Redelivery Policy)是一个过滤器,通过限制Mule运行时引擎(Mule)执行产生错误的消息的次数来帮助节省资源。
当向流的源添加重新传递策略时,Mule会在执行流的组件之前评估接收到的数据。如果消息传递失败了指定次数,则重新传递策略将阻止流处理接收到的数据,并引发REDELIVERY_EXHAUSTED错误。
在流中的事件源上配置重新发送策略,例如:HTTPListener;关于新建或更新的文件;在JMS连接器的新消息等上指定编号。在引发REDELIVERY_EXHAUSTED错误之前,流可以处理由事件源发出的“相同”事件的次数。
以下是配置参数:
每次源接收到一个新消息,Mule通过生成它的密钥来识别该消息。
Mule4引入了可重复流作为处理流的默认框架。可重复流使用户能够:
该策略最初使用的内存缓冲区大小为512KB。对于较大的流,该策略在磁盘上创建一个临时文件来存储内容,而不会溢出内存。
如果需要处理大文件或小文件,可以改变缓冲区大小(inMemorySize)来优化性能:
还可以设置缓冲区的度量单位(bufferUnit)。
XML示例代码:
XML
事务是Mule应用程序中的操作,其结果需要保持确定。当流中的一系列步骤必须作为一个单元成功或失败时,Mule使用事务来划分该单元。
Mule支持单一资源(默认为本地)和扩展架构(XA)事务类型(transactionType)。唯一可以定义事务类型的组件是消息源(例如jms:listener和vm:listener)和Try scope。
单一资源事务(也称为简单事务或本地事务)仅使用单一资源发送或接收消息:JMS代理、VM队列或JDBC连接。
XML示例代码:
XML
Mule只提交成功通过完整流的消息。如果在流中的任何一点上,消息抛出了一个传播的错误(不是由出错时继续处理的),Mule将回滚事务。
扩展架构事务(或XA事务)可用于将来自多个事务资源(如VM、JMS或Database)的一系列操作分组到单个可靠的全局事务中。
XA(扩展架构)标准是一个X/Open组标准,它指定了全局事务管理器和本地事务资源管理器之间的接口。XA协议定义了一个两阶段提交协议,可用于跨不同类型的多个服务器可靠地协调和排序一系列原子操作。每个本地XA资源管理器都支持A.C.I.D属性(原子性、一致性、隔离性和持久性),这些属性有助于确保XA资源管理器管理的资源中操作序列的完成。
XML示例代码:
XML
${insertQuery}
如果db:insert操作失败,事务将在错误处理程序(on-error-propagate)执行之前回滚(即它不是由on-error-continue处理的)。因此,通过vm:publish发送的消息不会被确认发送,而jms:consume中的消息也不会被实际使用,因此下次可以再次使用它。
下表描述了每种事务类型的特征以及加入事务的操作所需的条件:
Mule4中支持事务的常见连接器操作:
事务操作(transactionalAction)定义了操作对事务采取的操作类型。
下表描述了所有可用的事务操作:
在消息源中,可以从消息源启动事务。在这种情况下,整个流成为一个事务。
要从消息源发起事务,请配置其事务类型和事务操作:
XML
Mule流也能够以非事务性连接器(如HTTP)开始,它需要流中的事务。在这种情况下,可以使用Try scope来设置事务。
可以在Try scope组件中通过设置事务类型和事务操作来设置事务:
•在Anypoint Studio中:打开Try scope的General选项卡,设置事务类型和事务操作值:
•在配置XML中:添加transactionaction元素和transactionType元素(如果需要的话),并设置它们的值:
XML
INSERT INTO main_flow_audit (errorType, description) VALUES (:errorType, :description)
Bitronix是Mule应用程序的XA事务管理器。Bitronix事务管理器允许Mule在重启时自动恢复中断的事务。
要使用Bitronix(在单个应用程序中或在Mule域中的所有应用程序中),在Mule应用程序中将其声明为全局配置元素:
XML
...
可以添加Bitronix
从Studio导入到应用程序或域,执行以下步骤:
下表列出了Bitronix的配置属性:
批处理作业组件设计用于对大于内存的数据集进行可靠的异步处理。它自动拆分源数据,并将其存储到持久队列中,从而可以处理大型数据集。
该组件可配置如下:
Until Successful作用域依次执行其中的处理器,直到所有处理器都成功,或者该作用域耗尽了最大重试次数。Until Successful同步运行。如果作用域内的任何处理器未能连接或未能产生成功的结果,则Until Successful将重试其中的所有处理器,包括失败的处理器,直到所有配置的重试都耗尽。如果重试成功,作用域将继续到下一个组件。如果最后一次重试不成功,Until Successful将报错。
要配置Until Successful作用域,需要在应用程序流中添加
可以在Until Successful作用域内配置以下属性:
XML示例代码:
XML
上面的XML示例配置了由调度器组件和执行FTP写入操作的Until Successful作用域触发的流。
First Successful路由器遍历已配置的处理路由列表,直到其中一条路由成功执行。如果任何处理路由执行失败(抛出错误),路由器执行下一个配置的路由。如果配置的路由都没有成功执行,First Successful路由将抛出一个错误。
First Successful路由器在成功执行路由后停止执行。
XML示例代码:
XML
可靠性模式是一种为应用程序提供可靠消息传递的设计,即使应用程序从非事务性连接器接收消息。可靠性模式将可靠的获取流与应用程序逻辑流耦合在一起。
可靠获取流(图的左侧)可靠地将消息从没有实现事务的消息源传递到实现事务的连接器的出站操作。操作可以是任何类型的事务端点,比如VM或JMS。如果可靠获取流不能传递消息,它将确保消息不会丢失。
应用程序逻辑流(图的右侧)将使用事务连接器的消息源中的消息传递到应用程序的业务逻辑。
XML示例代码:
XML
(1)
(2)
在实现可靠性模式时,需要考虑以下几点:
可靠性测试是一项重要的软件测试技术,由团队执行,以确保软件在每种环境条件下以及在指定的时间内始终如一地执行和运行。
该测试包含了功能测试和非功能测试的结果,例如压力测试、安全测试、功能测试、生产测试等。
JSON模块验证可用于根据JSON模式验证JSON。它将显示JSON有效负载的确切错误,因此可以将传入的JSON错误通知客户端。
类似地,有XML模块验证来根据XML模式验证XML。
因为有适当的验证,这些模块可以防止在流中进一步抛出错误,从而节省了确保可靠性的额外工作,例如持久化到DB、推入到DLQ等。
应该正确处理上述任何实践抛出的错误,以确保没有数据丢失。
当引发错误的执行次数大于配置的maxRedeliveryCount值时,从配置Redelivery策略的任何地方抛出。
在这种情况下,在“On Error Continue”作用域上,确保将消息(正在处理的当前消息)传送/持久化到死信队列(DLQ)中,这样它就不会丢失。一旦持久化到DLQ中,任何类型的通知都可以发送到相关团队。
XML示例代码:
XML
当某个执行块的重试已经耗尽时,从给定操作或从Until Successful作用域抛出。
在这种情况下,在“On Error Continue”作用域内,确保将消息(当前消息正在处理中)推送/持久化到死信队列(DLQ)中,以使其不会丢失。一旦持久化到DLQ中,就可以向相关团队发送通知失败的任何类型的通知。
XML示例代码:
XML
当事务期间发生错误时,应用程序必须处理错误并继续执行或执行回滚。
On Error Propagate
On Error Continue
错误得到处理,事务保持活动状态并能够提交。on-error-continue中的处理器在事务中运行。
在上述任何一种情况下,确保将当前消息推入DLQ或DB等存储系统。
Mule有三个选项来处理记录级别的错误:
1.Finish processing停止当前作业实例的执行。完成当前正在执行的记录的执行,但不要从队列中提取更多记录,并将作业实例设置为FAILURE状态。调用OnComplete阶段。
2.继续处理批处理,不考虑任何失败的记录,使用acceptExpression和acceptPolicy属性指导后续批处理步骤如何处理失败的记录。
3.继续处理批处理,不考虑任何失败的记录(使用acceptExpression和acceptPolicy属性指示后续批处理步骤如何处理失败的记录),直到批处理作业积累了失败记录的最大数量,此时执行将停止,就像选项1中那样。
在最后两种情况下,在ONLY_FAILURES批处理步骤中,将失败的记录推入DLQ或DB之类的存储系统。
当配置的路由都没有成功执行时,通过将消息推入DLQ或DB之类的存储系统来处理抛出的错误。
这是在一个地方整理各种可靠性问题的解决方案的努力,热衷于构建高可靠性应用程序的Mule开发人员可以参考一些详尽的列表。
需要记住的是,其中一些解决方案/实践的性能可能会受到影响,因此在选择时需要谨慎。
原文标题:Best Practices for Creating Highly Reliable Applications in Mule 4,作者:Praveen Sundar
本文标题:在Mule4中创建高可靠性应用程序的优秀实践
链接分享:http://www.csdahua.cn/qtweb/news14/467414.html
网站建设、网络推广公司-快上网,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 快上网