业务活动监视器（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的革命。