1.说下你可能没用过的EventBus
2.信号通路分析神器——OmniPath插件
说下你可能没用过的EventBus
最近在Code Review过程中，我发现了一个业务场景：业务处理完成后，需要通知审核人员，通知方式包括短信和邮件。代码如下：
这个方法对吗？
针对这种常见的业务场景，我们首先会考虑同步或异步发送的大金猪棋牌源码问题。
如果选择同步，会对接口的响应时间产生影响，并且与业务逻辑紧密耦合，这显然不是好的做法。
一般情况下，我们会选择异步方式，使用消息队列（MQ）进行消息的发送和消费，或者使用线程池来处理，这样不会影响主业务逻辑，可以提高性能，并且实现了解耦。
此外，我们还需要考虑数据一致性的问题，邮件是否一定要发送成功？
大多数情况下，我们并不要求邮件必须%发送成功，失败了就失败了，只要监控告警的失败率不超过阈值即可。同时，汾酒溯源码消息服务一旦收到请求，应该自行保证消息的投递。
因此，总的来说，使用MQ发送消息并自行处理，或者使用线程池进行异步处理，最后自行处理补偿逻辑，就能解决这类问题。
那么，今天要介绍的是这两种解决方案之外的处理方式。对于这种场景，我们可以使用EventBus来解决。
EventBus是事件总线的意思，它是Google Guava库的一个工具，基于观察者模式，可以在进程内实现代码的解耦。
以上面的例子来说，引入MQ可能会有些过于复杂，其实使用EventBus也能达到相同的效果。与MQ相比，EventBus只能提供进程内的消息事件传递，但对于我们的业务场景来说，这已经足够了。论坛源码md
接下来，我们来看一下EventBus的使用方法。首先，创建一个EventBus实例。
第二步，创建一个事件消息订阅者，处理方式非常简单，只需在希望处理事件的方法上添加@Subscribe注解即可。
形参只能有一个，如果定义0个或多个，运行时将会报错。
第三步，注册事件。
第四步，发送事件。
这就是EventBus使用的最简单例子。下面我们看看如何结合开头的例子进行处理。
比如上面提到的案例，比如注册和用户下单的场景，都需要发送消息和邮件给用户。
EventBus并不强制要求我们使用单例模式，因为其创建和销毁成本较低，所以更多是人人springcloud源码根据我们的业务场景和上下文来选择。
在业务逻辑处理完成后，分别注册了邮件和短信两个事件订阅者。
最后，我们发送事件，用户注册时发送一个用户ID，下单成功时发送一个订单ID。
然后写一个测试类进行测试，分别创建两个service，然后分别调用方法。
执行测试类，我们可以看到输出，分别执行了事件订阅的方法。
使用起来你会发现非常简单，对于希望轻量级简单地实现解耦，使用EventBus非常合适。
注意，例子中的参数都是Long类型。如果事件的参数是其他类型，那么消息是无法接收到的。比如，如果我们将下单中发送的订单ID改为String类型，会发现没有消费。因为我们没有定义一个参数类型为String的pubg热源码方法。
去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数据库并进行深入分析。希望本文的分享能对大家有所帮助。
