• 性能–我们插入了ESB和App Server，所有指标都很完美。 它很好地显示了请求计数，响应时间等。只要负载很低，它就很完美。 如果一台服务器开始发送1000个事件/秒，则事情开始变得难看。 更糟糕的是，如果我们插入几台服务器并开始每天获得10亿个事件，那么从一开始，这将是一场噩梦。 我们甚至无法理解那种规模的情况。
• 可伸缩性–我们需要存储事件并进行处理。 可悲的是，我们发现这将意味着我们需要以许多不同的方式进行扩展。
  • 事件负载–我们需要扩展规模以处理大量事件。
• 可定制性–我们提供了一组可爱的仪表板，显示了您想了解的有关服务器和API指标的所有信息。 但是，没有人对我们拥有的产品感到满意。 他们想要更多。 他们想监视自己的指标并分析其数据并建立自己的图形。 而且，当然，他们希望现在就这样做，而不是两个月之内。

• 分而治之–我们划分了问题。 我们必须汇总，分析和呈现数据。 因此，我们为每个组件构建单独的组件，请记住，我们需要分别缩放每个组件。 我们将它们映射到事件接收器，分析器框架和表示层。 数据代理是任何想要发送事件的人与BAM服务器之间的链接。 WSO2 Carbon平台使我们能够轻松地从任何服务器上卸载组件。 这意味着我们可以制作BAM发行版，卸载其他组件来制作Event Receiver BAM服务器。 或制作分析器BAM服务器。 只需单击一下按钮。

• 可扩展的快速存储–我们选择使用Apache Cassandra作为我们的存储解决方案。 我不想说这是有史以来最好的数据存储。 但是，它对我们很好。 它使我们能够进行快速写入以快速存储大量数据。 而且，它是按比例构建的。 放大Cassandra只需几分钟，而不是几周。 扩大规模并不意味着要花钱。 而且，它是用Java编写的，并且是一间Java房屋，它使我们可以破解代码。
• 快速协议–我们选择使用Apache Thrift作为默认协议。 有很多反对它的论点，但它对我们来说很有利。 它既快速又有效。 它允许我们维护会话，支持多种语言。 一个关键的事情是Cassandra也使用它，使我们能够在不反序列化的情况下将数据流传输到Cassandra中获得更高的性能。
• 可扩展的分析-我们选择编写自己的分析语言。 但是，如果不合适，则可以插入自己的Java代码。 在扩展分析方面，Hadoop是不可避免的。 因此，我们决定采用Hadoop模式处理大量数据，并采用非Hadoop模式，这样任何人都可以使用BAM，而不必担心任何Hadoop集群。

• 基于小工具的仪表板/报告–如果您不想花费数周的时间编写代码以进行可视化，则拖放可视化将非常有吸引力。 我们开发了一个小工具生成器，以便您可以轻松地快速可视化已分析的数据。

参考：在dev_religion博客上， JCG合作伙伴 Mackie Mathew提出了Business Activity Monitor（BAM）2.0的革命 。