生产兼具精益和企业价值的中间件是一项艰巨的工作。
它要么不存在,要么需要创新的思维(很多),并且需要在实现中反复进行。
业务风险很大,但是如果您做对了,它就会使您领先于其他任何公司。
这就是为什么我们考虑从头开始重写WSO2 BAM并进行一次飞跃,而不是通过迭代修复慢慢放弃。
如果您不想听我说而不是读这篇,请在http://bit.ly/xKxm8R上进行在线研讨会。
http://softwarecreation.org/2008/ideas-in-software-development-revolution-vs-evolution-part-1/
当您尝试监视业务活动时,您需要插入服务器并捕获事件。
这听起来很容易,那么有什么大不了的呢?
你可能会问。
这是我们的BAM 1.x初始版本遇到的一些障碍:
- 性能–我们插入了ESB和App Server,所有指标都很完美。 它很好地显示了请求计数,响应时间等。只要负载很低,它就很完美。 如果一台服务器开始发送1000个事件/秒,事情开始变得难看。 更糟糕的是,如果我们插入几台服务器并开始每天获得10亿个事件,那么从一开始,这将是一场噩梦。 我们甚至无法理解那种规模的情况。
- 可伸缩性–我们需要存储事件并进行处理。 可悲的是,我们发现这将意味着我们需要以许多不同的方式进行扩展。
- 事件负载–我们需要扩展规模以处理大量事件。
- 可定制性–我们提供了一组可爱的仪表板,显示了您想了解的有关服务器和API指标的所有信息。 但是,没有人对他们拥有的东西感到满意。 他们想要更多。 他们希望监视自己的指标并分析其数据并建立自己的图形。 而且,当然,他们希望现在就这样做,而不是两个月之内。
2011年5月,我们决定启动一项全新的计划,以从头开始重写WSO2 BAM。
我们对问题做出了一些决策。
这是其中的一些。
- 分而治之–我们划分了问题。 我们必须汇总,分析和呈现数据。 因此,我们为每个组件构建单独的组件,请记住,我们需要分别缩放每个组件。 我们将它们映射到事件接收器,分析器框架和表示层。 数据代理是任何想要发送事件的人与BAM服务器之间的链接。 WSO2 Carbon平台使我们能够轻松地从任何服务器上卸载组件。 这意味着我们可以制作BAM发行版,卸载其他组件来制作Event Receiver BAM服务器。 或制作分析器BAM服务器。 只需单击一个按钮。
BAM 2.0的3个主要组件
- 可扩展的快速存储–我们选择使用Apache Cassandra作为我们的存储解决方案。 我不想说这是有史以来最好的数据存储。 但是,它对我们很好。 它使我们能够进行快速写入以快速存储大量数据。 而且,它是按比例构建的。 放大Cassandra只需几分钟,而不是几周。 扩大规模并不意味着要花钱。 而且,它是用Java编写的,并且是一间Java房屋,它使我们可以破解代码。
- 快速协议–我们选择使用Apache Thrift作为默认协议。 有很多反对它的论点,但它对我们来说很有利。 它既快速又有效。 它允许我们维护会话,支持多种语言。 一个关键的事情是Cassandra也使用它,使我们能够在不反序列化的情况下将数据流传输到Cassandra中获得更高的性能。
- 可扩展的分析–我们选择编写自己的分析语言。 但是,如果不合适,则可以插入自己的Java代码。 在扩展分析方面,Hadoop是不可避免的。 因此,我们决定采用Hadoop模式处理大量数据,而采用非Hadoop模式,这样任何人都可以使用BAM,而不必担心任何Hadoop集群。
- 基于小工具的仪表板/报告–拖放可视化非常吸引人,当您不想花费数周的时间编写代码进行可视化时。 我们开发了一个小工具生成器,以便您可以快速轻松地可视化已分析数据。
经过几个里程碑之后,我们得以剥离出一个alpha。
可在此处获得: http : //dist.wso2.org/products/bam/2.0.0-Alpha/wso2bam-2.0.0-ALPHA.zip。
这不是灵丹妙药,文档仍然是在制品。
但是,如果我们还没有到达目的地,那现在就在我们的范围之内。
参考:在dev_religion博客上,我们的JCG合作伙伴 Mackie Mathew提出了Business Activity Monitor(BAM)2.0的革命 。
翻译自: https://www.javacodegeeks.com/2012/06/revolution-with-business-activity.html