决策引擎服务平台blaze_是Blaze数据服务还是LiveCycle数据服务？

决策引擎服务平台blaze

摘要

关于数据服务的不同版本的文章很多，但似乎没有任何文章阐明如何在不同版本之间进行选择。同样，也没有人详细讨论端点和通道如何影响应用程序性能。

尽管Adobe指的是Data Services的4个不同版本，但是有两个主要版本。一个是开源的Blaze数据服务，另一个是称为LiveCycle数据服务（LCDS）的专有版本。两种产品都提供了最重要的功能，即通过Message Broker Servlet在Flex和Java之间进行连接。它们都可以使用远程过程调用和通过二进制协议ActionScript消息格式（AMF）的消息传递与服务器进行通信。在这两个核心产品之上，Adobe提供了受支持的版本和更广泛的产品套件。

我们在Gorilla Logic的经验是这两种产品之间的主要区别在于支持选项和数据管理。性能和可伸缩性方面的差异更值得商bat。 LCDS提供了用于客户端通信的其他端点和通道。 Adobe指出，这些功能的主要优点是可扩展性。但是，通信的基本方式始终是基于HTTP的AMF，无论服务器或客户端的配置如何，其性能都相同。

LCDS提供的另一个附加功能是数据管理。这样可以实时解决冲突，从而在Flex客户端和Java Server应用程序之间提供数据同步。它还提供了数据汇编器和采用器，用于通过JDBC，Hibernate或其他客户采用器将数据服务连接到持久性存储。

那么这4个不同的版本是什么？

Blaze数据服务 -免费和开源版
LiveCycle Data Services社区版 -Blaze DS的受支持版本
LiveCycle Data Service单CPU许可证 -商业广告的免费版本版本具有附加功能，但仅限于单个CPU
LiveCycle Data Services-支持的商业版付费版本

还有一个产品套件，Adobe将其称为LiveCycle Data Services Enterprise Suite 。这会将其他产品添加到核心数据服务中，以使用诸如PDF生成，表单和数字签名之类的工具提供内容服务和文档输出。

从理论上讲，可以基于三个主要点来做出决策。

需要支持吗？这取决于应用程序是否需要支持，例如关键任务应用程序。
您需要数据管理服务吗？这取决于应用程序对数据同步和管理服务的要求。
您是否需要LCDS的其他端点和通道？根据Adobe的说法，如果需要建立数百个并发连接，则需要额外的LCDS通道或端点。然而，这一点值得商.。服务器可以处理的并发连接数取决于许多因素，例如线程和I / O吞吐量。还可以通过对多个服务器进行负载平衡来处理大量并发连接，就像扩展任何Java Application Server一样。

在文章的末尾做了一个比较表，概述了不同的版本。

不同端点概述-Servlet和NIO

在数据服务中，端点是服务器如何侦听来自客户端的连接。 Blaze DS和LCDS的标准端点都是在应用程序服务器内部运行的基于servlet的端点。它使用在web.xml中配置的Message Broker Servlet参与标准Servlet过滤器链。这允许将Blaze DS或LCDS部署到现有的Java应用程序中。与任何Java Servlet端点类似，每个客户端连接在服务器上都需要一个单独的线程。

NIO端点的工作方式完全不同。 NIO代表Java New Input / Output。 NIO端点创建一个基于NIO的独立套接字服务器。 NIO的优点是单个线程可以管理多个I / O流，因此需要更少的线程并可以处理更多的客户端。

使用NIO面临一些挑战。这些是：

客户端无法通过客户端代理访问NIO端点。
该连接没有经过标准的servlet链，这可能会破坏依赖servlet处理的系统的任何部分。例如，在一个项目中，我们使用servlet处理文件上传到服务器。
使用NIO，通常必须使用自定义身份验证。这是因为套接字服务器在与Servlet容器不同的进程中运行。

尽管可以将NIO服务器配置为侦听端口80，但它通常位于单独的端口上。这可能使网络配置具有挑战性，因为必须将网络配置为允许新端口上的传入连接。这可能可能会出现问题，具体取决于服务器的内部网络和不同的客户端网络。解决此问题的一种可能的方法是使用带有粘性会话的负载平衡器。

但是，Java NIO的优势值得商bat。 Java NIO被开发为允许单个线程处理多个连接。它是通过让单线程在连接池中进行迭代并查看是否需要读取或写入新数据来实现的。自从2002年NIO与Java 1.4一起引入以来，JVM和Linux中的线程处理已得到了极大的改进。 Java和Linux处理大量线程的能力已大大提高。

例如，Linux内核在2.6中引入了新的线程库。这是本机POSIX Linux线程库（NPTL）。使用NPTL进行的测试表明，可以在两秒钟内在IA-32上启动100,000个线程。 ¹如果没有NPTL，则Linux内核需要15分钟才能创建相同数量的线程。

最有趣的是一个博客文章由保罗季马和其他人指出了Java NIO实际上可能是一个缺点^{^{^2，3，4。}} 保罗通过一系列基准测试证明了以下针对NIO的论点：

Java NIO将吞吐量损失20％到30％
线程上下文切换并不昂贵
同步并不昂贵

根据这些测试，Paul显示了每个连接实际上可以扩展一个线程。在JDK 1.6下，JVM可以处理15K到30K线程。这意味着servlet端点的限制不是几百个连接。相反，它要高得多，可能超过15K连接。当然，实际限制取决于硬件配置，例如内存和CPU。

各种类型的渠道概述

通过基本网络连接，可以使用多种不同类型的通道在客户端和服务器之间进行通信。对于基本的远程过程调用，使用标准的AMF通道。

通讯的另一种类型是消息传递。这可用于创建从服务器推送消息并执行近实时通信的应用程序。示例应用程序是聊天服务器，拍卖客户端和协作服务。

数据服务进行消息传递的主要方式是通过轮询。因为通过HTTP进行的标准通信无法保持通信通道打开，所以轮询通道使客户端请求在服务器端等待，直到数据可用为止。等待时间可以在几毫秒到几分钟之间调节。这模拟了从服务器推送的数据。

轮询通道有两种基本类型，即短轮询和长轮询。主要区别在于服务器等待客户端数据可用的时间。

更高级的通道类型是流式AMF。这将打开与服务器的HTTP连接，并允许服务器通过此通道流式传输无尽的消息。这样做的好处是没有客户端的轮询开销，并且还使用标准的网络配置。这是接近实时流式传输的最接近的选项。流式AMF的挑战在于，它使用HTTP 1.1持久性连接，这些连接由不同的浏览器实现。

最终的通道类型是RTMP（实时消息协议）通道，当前仅在LiveCycle DS中可用。 Adobe最近宣布他们将发布RTMP规范。猜测是它将最终进入其他产品。

RTMP旨在通过双工通道流式传输大型多媒体和数据。 RTMP的主要优点之一是与客户端的连接保持打开状态，因此可用于从服务器推送数据。这使得RTMP可以用于彗星风格的通信和实时数据推送。

有三种RTMP。一种通过TCP进行工作并使用端口1935。此版本的RTMP的缺点是必须从客户端浏览器启动连接。此外，它使用非标准端口，因此通常会被客户端防火墙阻止。

RTMP的其他两种形式将RTMP消息封装在HTTP请求中。这允许该协议穿越防火墙并使用标准端口。这两种类型是通过标准HTTP的RTMPT和通过安全HTTPS的RTMPS。

在Flex中，对服务器的所有调用都是异步执行的，因此这些通道均不影响客户端的性能。但是，它们可能会影响服务器性能，特别是如果同时打开大量客户端连接时。例如，流式AMF可能导致在服务器上打开大量并发客户端连接，从而导致大量线程。但是，如前所述，大量线程的影响可能很小。

如果配置失败，则可以使用默认通道和备用通道来配置所有客户端连接。根据服务器正在进行的通信类型，可以指定不同的通道链。例如一个可以指定RTMP通道，但是如果该连接失败，则可能会故障回到长轮询通道。

结论

相对于Blaze DS，LiveCycle DS的真正好处似乎主要是支持和数据管理的可用性。额外的端点和渠道的好处值得商bat。从我们在Gorilla Logic所做的项目来看，我们没有看到对NIO端点或RTMP的需求。但是，与所有技术一样，没有什么是确定的。我会对评论中的其他经验感兴趣。