StreamBase EventFlow创作实践

由:
最后更新:
2021年4月22日上午6:10

软件实践注意事项

Steve Barber的评论:

这个Wiki页面开始作为TIBCO StreamBase文档>创作指南> StreamBase创作基础>的副本德赢vwin跑分StreamBase最佳实践这个页面一直存在于7.7版本的StreamBase文档中,但是TIBCO德赢vwin跑分流产品团队从10.0版本线中删除了它。我不太清楚为什么这个页面不再出现在文档集中,但确实有些实践已经过时了,这既因为产品本身的发展,也因为后续的领域和客户德赢vwin跑分体验还没有被纳入。

任何和我一起工作过很长时间的人都知道我找到了这个词最佳实践有很大的问题,而我倾向于避免它。我很高兴概述一些已经或将非常可能有益于大多数StreamBase项目的实践。然而,每个项目都有一个特定的环境,实践可能适用,也可能不适用。无论如何,我根据自己的经验更新了这些做法。

请将此页面视为一个活生生的Wiki页面,并根据您自己的经验随意编辑。

EventFlow创作实践清单

下表提供了在编写EventFlow应用程序时要考虑采用的实践列表。

实践
总结 描述
模块化的计划
在编写任何EventFlow之前,考虑应用程序的功能区域以及它们是如何关联的。

模块化有助于确保故障排除和性能调优能够高效、轻松地完成。

将适配器和连接逻辑保存在与定义业务逻辑的模块分离的模块中。这使得测试应用程序的正确性变得更加容易。

基于清晰的功能边界定义模块。在你的应用程序的功能区域使用单独的模块,这些模块具有以下任何一个特征:

  • 是CPU密集型的

  • 需要为输入数据的所有排列重复

  • 执行需要在整个性能测试中监视的重要功能

建立命名约定
对应用程序组件(如模块、动态变量和模式)遵循逻辑命名约定。 例如,在交易系统中,您可以在模块中定义各种算法,其名称为BollingerBand_Algo.sbapp,VWAP_Algo.sbapp等等。
使用命名模式
指定命名的模式,并从公共接口或模块导入它们。

指定输出模式和输入模式。

注意模式大小。模式大小会影响应用程序性能。

确定需要在应用程序中使用某些数据的位置。定义模式的方法有很多种,而定义模式的方式会对应用程序的性能和调试的容易程度产生影响。

使用表模式
在指定查询表时使用表模式。 使用表模式,您可以在大型应用程序的几个模块中快速地将相同的结构分配给查询表。
使用进口模块
重用常量、命名模式、表模式和其他可导入项的定义。 从一个模块导入项到另一个模块简化了应用程序设计,并在创建应用程序模块时提高了工作效率。
使用接口
为经常使用的设计模式定义接口。 使用StreamBase接口,您可以创建同一组流、表和模式的不同实现。
为共享定义使用接口文件
在接口文件中定义可导入项。 在interface (.sbint)文件中定义常量和模式,其目的是维护这些定义以便其他模块使用。您可以使用导入的模块(.sbapp)来实现相同的目的;在这种情况下,定义模块应该有一个完全没有元组处理的空白画布。为此目的,使用接口文件可能比使用模块更好。对于应用程序架构师来说,要使用多少定义接口文件是一个设计问题;适当的粒度可能是每个片段一个项目开始,或者它们可能被分割成单独的功能区域,例如。可能有定义接口文件来定义多个项目使用的实体,但是重用模式和开发组织结构也可能影响有关适当文件范围的决策。
使用增量开发
在应用程序中逐步引入逻辑。

不要一下子就建立起一个庞大的系统。使用单元测试在开发的每个阶段评估附加业务逻辑的影响。

性能指标分析应该使您能够在开发阶段识别应用程序中的热点,从而更容易进行改进。一旦确定了热点,您就可以将热点操作符的处理分配到单独的线程中。

使用模块参数
使用模块参数来增强重用性和灵活性。

使用模块参数和常量有助于使您的应用程序作为可重用模块更加灵活。例如,您可以使用模块参数根据交易量改变警报的阈值。

设计模块,使其参数可以由人或另一个子系统指定,具体取决于特定站点的需求。

对于具有多个模块引用层的复杂应用程序,使用链接将相同的值传递给内部模块。

仔细而谨慎地使用时钟时间,考虑功能回归测试策略
在业务逻辑中非常小心地使用时钟时间。

使用时钟时间可能会对机器之间的延迟和应用程序正确性产生不可预测的影响。

StreamBase Engine速度很快,因为它在传入元组到达时进行处理,而不是基于内部或壁钟计时器。如果您需要确保您的处理总是在特定的时间发生,那么使用Metronome或Heartbeat操作符发送元组。



使用时钟时间会使编写可重复的功能回归测试具有挑战性;使用模拟时间服务使基于时钟的功能具有确定性可测试性。

完整的业务逻辑,然后进行性能优化
在调优性能之前,完成应用程序每个部分的核心功能。 在关键业务逻辑完成之前不要优化应用程序。过早的优化将使应用程序核心功能的开发变得不必要的复杂。



考虑在.sbapp文件中为EventFlow组件命名的实践

注意:在TIBCO Streaming中有相当多的东西都有名称,并且对于这些不同类型的名称的约定可能是不同的。StreamBase有一组标识符命名规则,所有标识符必须遵循这些规则才能有效(和类型检查),标识符用于StreamBase和EventFlow中的几种不同类型的东西。例如,EventFlow组件名称和模式字段名称都遵循标识符规则,但(或多或少)是独立的名称空间,其中一个的约定可能与另一个的约定不相同。本节假设遵循标识符规则,然后将这些实践建议放在专门针对组件名的实践建议之上。对于这个实践列表,EventFlow组件是出现在EventFlow Editor画布上的东西:流、操作符和适配器,以及数据构造。

  • 好的做法:用名字命名您的组件应用程序域中的上下文中有意义或功能,这样你和你的团队可以更容易地理解代码之后,所以其他利益相关者可以看看EventFlow模块和相当容易理解该模块在做什么。
  • 错误做法:保留Studio生成的默认组件名称,如Filter、Filter1、Filter2、copyfilter、copyofcopyfilter等。这条路充满了灾难和疯狂。花10秒钟考虑并输入一个描述性名称将在应用程序的生命周期中为团队节省大量时间。
  • 实践考虑:将组件类型作为其名称的一部分可能看起来有些多余,例如,如果我有一个过滤掉null元组的过滤器,我应该叫它NullTuple并依赖于可视的filter图标来理解它吗?或者我应该叫它NullTupleFilter?与后者我就去,因为我们的一些监视工具只给组件的名称没有任何信息类型,通常是有用知道组件的类型在一个监控显示,而不必回到工作室,查一下,特别是对于那些不容易接触或理解Studio的操作人员和管理员。
  • 建议:使用CamelCase如果你想要一个组件名称样式的建议。否则,使用您喜欢的,但要与您的约定保持一致,并为您的团队记录它们。如果自动映射外部名称,特别是流名称,那么遵循外部约定可能会很方便,以促进自动化和可跟踪性。
  • 良好实践:EventFlow组件名称标识符规则往往不鼓励字母数字和下划线以外的任何东西,尽管它在这样做时使用了一种称为转义标识符语法的特殊类型的标识符。您可以在组件名称中使用其他类型的字符并不意味着您应该这样做;很多整体的Streaming工具集不能完美地使用这些转义的标识符,如果您选择忽略这个建议,您的生活可能会变得困难。在组件名称中放置空格时要特别小心;人们喜欢尝试这种做法,但这种做法通常不会有好结果,而且最好避免非字母数字/下划线字符,尽管它们可能很诱人。

在产品文档中还有一些其他的EventFlow标识符命名指南,例如:德赢vwin跑分标识符命名规则逃脱了标识符的语法