Chapter 2. 架构

Jolokia的结构完全不同于JSR-160连接器,其中最明显的差异就是Jolokia的typeless approach(无类型访问)。

JSR-160, 于2003发布, 与Jolokia的实际目的不同.是一个客户端可以透明的调用MBean的标准, 不论MBean是mbean驻留在本地还是远程MBeanServer。 API中虽然为Java客户端提供了很好的解决方案,但同样存在风险,应为他隐藏了远程的JMX调用。 这里有许多小问题,性能就是其中之一. 无论是本地还是远程调用,调用者必须会发生什么以及会有什么结果。 另外, 这是一种显式地远程调用方式, 以让调用者知道要调用的潜在昂贵的远程调用的编程模式。 这可能是RMI(默认协议栈JSR - 160连接器)在显式的远程协议方面失去的市场份额的主要原因。

JSR-160的一个问题是它的隐式依赖于RMI并且需要对一个完整的(Java)对象进行序列化机制来通过连接床底管理信息。但这意味着对非Java(或更确切地说,JVM)关上了大门。Jolokia使用typeless approach(无类型访问)某种轻量级的序列化JSON的方式(在双向上,他的功能是不对称的)。当然,这种方法也有一些缺点,但也颇有一定的优势。至少,它在JMX世界是唯一的;-)。

2.1. Agent 模式

图 2.1, “Jolokia 架构”说明了Jolokia的工作环境. 前端基于JSON通过HTTP协议桥接来调用本地JMX MBean获取代理出口。此架构在JSR-160空间以外,因此需要不同的设置。有多种技术可用于输出协议,可以通过HTTP。最突出的是将Agent部署到一个servlet容器中。这可能是一个轻量级的,如Tomcat或Jetty或者其他完全成熟的JEE服务器。由于它的作用就像一个通常的Web应用程序来部署Agent, 对任何一位会用Java Web应用程序的开发人员来说没有门槛。

图 2.1. Jolokia 结构

Jolokia architecture

但也有更多的选择。专业化的Agent可以使用OSGi HTTPService或嵌入式Jetty服务器中的Mule Agent的方式。 JVM Agent使用的HTTP-Server包括所有版本的Oracle JVM 6,并且可以动态地附加到任何正在运行的Java进程。有关Agent的详细描述,请参照Chapter 3,Agent

Jolokia可以很容易地集成到自己的应用程序中。joloki核心库(被打成JAR包),其中包括一个servlet,它可以很容易地添加到自定义应用程序。 Section 3.1.3, “Jolokia Agent的servlet的编程使用” 包含更多信息。

2.2. Proxy 模式

如果不能在目标平台上部署Jolokia agent, 那么Proxy模式将是一种解决方案。这种模式下,访问目标服务器的唯一先决条件是一个JSR-160连接。在大多数情况下,出于策略性原因,根本就不允许部署额外的软件或这样做需要一个漫长的审批过程。另一个原因可能是目标服务器通过JSR-160已经提供JMX,你应该避免额外的步骤部署agent。

承载jolokia.war需要一个专门的proxy servlet服务器,默认情况下支持agent模式和proxy模式。一个轻量级的容器,如Tomcat或Jetty这样的设置是一个完美的选择。

图 2.2, “Jolokia JMX代理服务器” 描述了一个典型的proxy模式设置。通常客户端发送Jolokia请求,其中包含一个额外的部分来指定要访问的目标。所有路由信息都包含在请求本身,因此 代理可以普遍地使用,而不需要特定的配置。

图 2.2. Jolokia 作为 JMX Proxy服务器

Jolokia as JMX Proxy

说了这么多,proxy模式也有一定的局限性,详情 Chapter 5, Proxy 模式 .

总结,代理模式应仅在需要时使用。 agent Servlet与proxy模式相比,是更强大的,因为它消除了额外的层,增加了整体复杂性和性能。此外,在代理模式下不提供的一些功能,如合并MBeanServers。