业务活动监视器（BAM）2.0带来的革命

生产兼具精益和企业价值的中间件是一项艰巨的工作。 它要么不存在，要么需要创新的思维（很多），并且需要在实现中反复进行。 业务风险很大，但是如果您做对了，它就会使您领先于其他任何公司。 这就是为什么我们考虑从头开始重写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