1.说下你可能没用过的EventBus
2.信号通路分析神器——OmniPath插件
说下你可能没用过的EventBus
最近在Code Review过程中,我发现了一个业务场景:业务处理完成后,需要通知审核人员,通知方式包括短信和邮件。代码如下:
这个方法对吗?
针对这种常见的业务场景,我们首先会考虑同步或异步发送的理财社区app源码问题。
如果选择同步,会对接口的响应时间产生影响,并且与业务逻辑紧密耦合,这显然不是好的做法。
一般情况下,我们会选择异步方式,使用消息队列(MQ)进行消息的发送和消费,或者使用线程池来处理,这样不会影响主业务逻辑,可以提高性能,并且实现了解耦。
此外,我们还需要考虑数据一致性的问题,邮件是否一定要发送成功?
大多数情况下,我们并不要求邮件必须%发送成功,失败了就失败了,只要监控告警的失败率不超过阈值即可。同时,量化源码教程消息服务一旦收到请求,应该自行保证消息的投递。
因此,总的来说,使用MQ发送消息并自行处理,或者使用线程池进行异步处理,最后自行处理补偿逻辑,就能解决这类问题。
那么,今天要介绍的是这两种解决方案之外的处理方式。对于这种场景,我们可以使用EventBus来解决。
EventBus是事件总线的意思,它是Google Guava库的一个工具,基于观察者模式,可以在进程内实现代码的解耦。
以上面的例子来说,引入MQ可能会有些过于复杂,其实使用EventBus也能达到相同的效果。与MQ相比,EventBus只能提供进程内的消息事件传递,但对于我们的业务场景来说,这已经足够了。开源财务源码
接下来,我们来看一下EventBus的使用方法。首先,创建一个EventBus实例。
第二步,创建一个事件消息订阅者,处理方式非常简单,只需在希望处理事件的方法上添加@Subscribe注解即可。
形参只能有一个,如果定义0个或多个,运行时将会报错。
第三步,注册事件。
第四步,发送事件。
这就是EventBus使用的最简单例子。下面我们看看如何结合开头的例子进行处理。
比如上面提到的案例,比如注册和用户下单的场景,都需要发送消息和邮件给用户。
EventBus并不强制要求我们使用单例模式,因为其创建和销毁成本较低,所以更多是setting源码获取根据我们的业务场景和上下文来选择。
在业务逻辑处理完成后,分别注册了邮件和短信两个事件订阅者。
最后,我们发送事件,用户注册时发送一个用户ID,下单成功时发送一个订单ID。
然后写一个测试类进行测试,分别创建两个service,然后分别调用方法。
执行测试类,我们可以看到输出,分别执行了事件订阅的方法。
使用起来你会发现非常简单,对于希望轻量级简单地实现解耦,使用EventBus非常合适。
注意,例子中的参数都是Long类型。如果事件的参数是其他类型,那么消息是无法接收到的。比如,如果我们将下单中发送的订单ID改为String类型,会发现没有消费。因为我们没有定义一个参数类型为String的学宝源码方法。
去EmailMsgHandler和SmsMsgHandler都新增一个接收String类型的订阅方法,这样就可以接收到了。
除此之外,我们还可以定义一个DeadEvent来处理这种情况,它相当于是一个默认的处理方式。当没有匹配的事件类型参数时,就会默认发送一个DeadEvent事件。
定义一个默认处理器。
给BookingService新增一个pay()支付方法,下单完成后去支付,注册我们的默认事件。
执行测试bookingService.pay(),看到输出结果:
OK,简单的介绍就到这里。到目前为止,我们所说的都是同步调用,这并不符合我们的要求。我们当然希望使用异步处理更好。
那就看看源码它是如何实现的。
identifier是一个名字,标记,默认是default。
executor是执行器,默认创建一个MoreExecutors.directExecutor(),事件订阅者根据你提供的executor来决定如何执行事件订阅的处理方式。
exceptionHandler是异常处理器,默认创建的就是打点日志。
subscribers是我们的消费者,订阅者。
dispatcher用来做事件分发。
默认创建的executor是一个MoreExecutors.directExecutor(),看到command.run()你就会发现这其实是同步执行。
同步执行并不太好。我们希望不仅解耦,还要异步执行。EventBus提供了AsyncEventBus,我们可以自己传入executor。
上面的代码我们改成异步的,这样不就好起来了嘛。实际上,我们可以结合自己的线程池来处理。
OK,这个说清楚了。我们可以顺便再看看事件分发的处理。看到DeadEvent了吗?没有当前事件的订阅者,就会发送一个DeadEvent事件,bingo!
OK,这个使用和源码都比较简单,有兴趣的同学可以自己去看看,花不了多少功夫。
总的来说,EventBus提供了一个更优雅的代码解耦方式,你在实际工作中的业务中肯定能用得上它!
信号通路分析神器——OmniPath插件
信号通路,即细胞外分子信号经细胞膜传入细胞内发挥效应的酶促反应通路,对于理解生物过程背后的复杂机制至关重要。然而,现有信号通路资源碎片化、数据库间聚焦点差异大,严重阻碍了信号通路数据库的合理、全面创建。年,TüREI等人对人类信号通路公共资源进行了系统分析,创建了OmniPath数据库。
OmniPath数据库提供了对个资源的集成访问,包括个蛋白质和复合物之间的个相互作用、个转录和个转录后调控关系。然而,如何通过图形用户界面访问OmniPath数据库?如何实现该图形用户界面中将OmniPath与分析工具相连接?为解决此问题,Ceccarelli等人在年月日于Bioinformatics上发表了一个Cytoscape的插件——OmniPath。
OmniPath插件可以直接查询OmniPath Web服务器来实现信号通路数据的定制导入,从而使用户从处理URL查询中解脱出来,并允许直接连接到其他应用程序进行进一步分析。OmniPath插件对人类信号通路包括信号网络、激酶-底物相互作用、miRNA-mRNA相互作用与转录因子(TF)-靶相互作用,并提供了通过基因同源性翻译到小鼠或大鼠的网络和调节子。
OmniPath应用程序基本工作流程如下:用户从预定义选项中选择数据库→OmniPath App根据输入构造查询,并请求访问OmniPath服务器→服务器返回交互,网络在Cytoscape中可视化→导入网络后,可使用其他应用程序选择性地将数据导入Cytoscape并执行网络分析。
接下来,我将分享如何使用OmniPath插件进行信号通路分析。首先,需要安装OmniPath插件,可以访问github或apps.cytoscape.org获取源代码和插件链接。Cytoscape是一款免费的图形化显示网络并进行分析和编辑的软件,最新版本为Cytoscape3.7.2。
在Cytoscape中,打开插件,有三种物种可供选择:Human、Mouse、Rat。有四个数据集可供选择:Signaling networks、Enzyme-substrate interactions、miRNA-mRNA与IF-target interactions。选择TF-target interactions数据集时,可选择不同置信度级别。
完成选择后,点击Launch query开始查询,得到source蛋白与target蛋白存在相互作用的查询结果,并列出数据库来源及参考文献的PMID。得到的网络结构可以进行注释,例如选择CancerSEA/sate,选择特定特征,点击Annotate network进行注释。可以导出Node和Edge Table。
OmniPath允许自动检索PubMed记录,选择连接两个节点的连线,从Cytoscape工具栏下Omnipath -> PubMed references显示支持两蛋白相互作用的文献,点击链接可自动跳转至对应文献。实际应用中,用户经常使用Cytoscape在相邻网络中寻找感兴趣的蛋白质的功能注释,以对STAT3调节子的富集为例,选择ARACNe-GTEx数据库,置信度过滤器选择ALL显示完整列表。
查询得到的互作网络中快速找到STAT3节点,并选择与STAT3连接的节点的子网络,隐藏未选择的节点和边来创建子网络,其中心点为STAT3。通过cytoHubba插件对子网络进行关键节点和子网络预测,cytoHubba提供了种拓扑分析方法。使用BiNGO app对仅与STAT3有相互作用的网络进行富集分析。
总的来说,OmniPath插件是Cytoscape中信号通路分析的强大工具,它提供了一种便捷的方式访问OmniPath数据库并进行深入分析。希望本文的分享能对大家有所帮助。