ICE第二版模板

第2章Zeroc ICE启程

2.1 Zeroc ICE平台介绍

Zeroc ICE（以下简称ICE）师出名门，是由前CORBA专家Marc Laukien、Michi Henning 及SSL安全调用，并且随着IT技术的变化和发展，ICE不断地推陈出新，每年都有新版本问世，从诞生到当下，十几年的历史，其王者地位无人撼动。

ICE

，因此在很多细节方面都有一些值得称道的做法，下面是其中一些关键特性。

?支持多语言之间的RPC互通。与众多平台不同，它的服务端也可以是几种语言开发，比如C、.NET、JAVA、Python等，不同语言开发的服务端与

客户端可以完全互通，对于支持多语言的服务来说，是很难得的一个特性，省

去了大量的开发成本和开发周期。

?高性能RPC调用。这点是业界公认的，一些大型联网游戏及Skype 等对实时性要求很高的系统都采用了ICE平台，足以说明这一点。笔者也曾做

过简单对比，也验证了其高性能，而且在不同语言的客户端调用时，其性能仍

然很好。

?支持传统的RPC调用、异步调用、One-Way调用，批量发起请求，支持TCP通信、UDP通信适用于不同业务场景。

?支持安全通信，ICE框架里提供了支持业界标准的SSL安全加密的可拔插插件。并且多种编程语言都支持该特性。

?多平台支持。包括X86系统、ARM、移动设备等。

?提供了强大的ICE Grid。支持注册表主从备份，无单点故障，服务按需启动，随时扩容和迁移，完备的负载均衡机制无须客户端重启，自动感应

服务位置的变化。

?不断更新，与时俱进。对近些年流行的JavaScript语言及新的移动平台的支持都及时跟上。

这里，笔者仅就多语言开发支持这一特性来分析Zeroc ICE平台所能带给你的额外价值，当你采用ICE框架开发一个服务后所能直接变现的承诺，在图2.1中完

美诠释：。

图2.1ICE多语言支持示意图

对于一个规模较大的平台来说，开发一个服务并不很难，但如何让多种语言都能很一

致地调用你的服务并联调通过，则很不容易，即使对于SOAP这种看似很标准的接口来说，依然存在很多编程语言和SOAP框架的版本等兼容性问题。而HTTP Rest的接口，在联调

时还是会碰到各种参数问题。从经验来看，除非把一个现成的编译好的客户端代码发给对方，否则会开发一次，到处联调，形成平台开发的梦魇。

我们来看看ICE平台的组成，ICE平台从功能可以划分为以下几部分。

?Slice工具。将Slice语言定义的服务接口编译成各种具体语言的实现代码，属于开发环境的一部分。

?ICE容器和命令。包括ICEGrid、ICERegistry、ICENode、ICEAdmin、ICEPatch 等命令，用于启动、管理ICE Grid，需要在运行ICE服务的机器上选择性部署其中

的某一个或几个组件。

?ICE运行库。为一组API库，不同的语言有不同的实现，如Java对应Jar文件，C语言对应.so文件（在Windows下对应为.dll文件），这些运行库需要被ICE

服务端程序和客户端程序所调用，以实现ICE内部的底层通信。

下面我们看看采用ICE平台开发一个具体项目时所要遵循的一般流程，如图2.2所示。

图2.2ICE跨语言开发流程示意图

这个开发流程示意图告诉我们，怎样从零开始，开展ICE跨平台的项目开发活动，简

单的说，就是首先用Slice语言定义中立的服务接口文件，然后采用相应语言的命令行编

译生成对应的程序骨架源文件，最后实现服务端业务代码开发，部署服务，然后客户端利

用Ice提供的运行期客户端Library（JAR文件）实现远程服务方法调用，详细步骤如下所示：

?分析和设计系统的服务：采用面向服务架构或者是“微服务”的设计理念进行系统分析和设计，确定系统中的“服务”单元、每个服务的接口及服务之间的

依赖关系。

?服务接口定义：采用ICE Slice语言对服务接口进行定义，并用Slice工具编译成你所熟悉的开发语言（本书以Java为例）的实现代码，这些实现代码包括服

务端和客户端骨架代码，可以认为是项目中的“公共”包。

?服务端业务逻辑实现：在Slice生成的服务端代码上进行业务逻辑代码的编写，在这个过程中除了在服务之间相互调用时用到ICE的一些API外，在绝大多数

情况下，不会用到ICE的代码。

?编写ICEGrid的服务描述文档：xxxgrid.xml，此文档类似于J2EE的web.xml 或EJB的服务描述文件，定义了每个服务的访问地址（Endpoint）、部署的节点

（ICENode）、负载均衡策略（replica-group）等关键信息。

?打包代码并部署到各个ICENode上，启动ICEGrid，借助ICE工具发布xxxgrid.xml，服务端工作至此基本完成。很重要的一点是，借助ICE平台提供的工

具，你可以很方便地将xxxgrid.xml中的服务重新规划和部署到新的节点上，而客

户端无须重启和改变任何代码。

?编写客户端软件，访问部署好的服务，并有针对性地做性能测试和调优。

初步了解了ICE的特性、组成部分及开发流程之后，让我们休息一会，因为接下来需

要学习和理解ICE平台的几个重要术语和概念，这个是需要动脑筋的，随便看看绝对无法

过关。

2.2 ICE的概念和原理

一：ICE Object

任何系统都会使用一些专有名词来阐明其原理和实现机制，最终，往往几个名词就概

括了其背后庞大复杂的技术体系，比如现在流行的Hadoop、NoSQL、NewSQL、BigData等。对于一个复杂的系统来说，准确理解和掌握其专有术语非常重要，不仅仅因为相关的技术

文档里大量使用了这些概念和术语，而且因为在编程实践和问题排查过程中，这些概念和

术语有助于我们推理、分析问题产生的根源和发现可能的解决方案。

作为一个复杂的RPC平台， ICE也创造了很多概念和术语，其中一个名词就是Slice，Slice模仿Cobra的IDL（Interface Definition Language）而来，与IDL相似， ICE采用编程语

言中立的Slice这种接口描述语言来定义一个RPC服务接口，然后提供了指向具体编程语言的“翻译工具”——slice2XXX，该工具将Slice文件编译成相应语言的源码，这些源码中包括了客户端运行期Stub代码，以及服务器端的Skeleton框架代码。要理解这一切背后的秘密，需要从ICE最根本的概念——ICE Object说起。

ICEObject具有以下特征。

?拥有一个对象标识符Object Identity来区别于其他类型对象，ICE的对象模型中要求对象标识符是全局唯一的，即没有任何对象的标识符相同。

?一个ICE Object是一个可以对客户端请求进行应答的对象，这个对象可以是存在于“本地进程的地址空间”也可以是位于“远程地址空间”。

?一个ICE Object拥有一个或多个接口，其中一个接口是其主要接口，是此对象区别于其他对象的主要特征，其余接口则被称为Facet。

一个ICE Object在服务端具体化为一个Servant实例，即我们用某种具体编程语言实现的一个Slice接口并新建的某个对象就是一个Servant。而将ICE Object与Servant 进行关联的“桥”则是我们接下来要理解的概念——Object Adapter，它是ICE运行时框架与用户应用程序代码之间的边界点，Object Adatper具有以下功能。

?提供一个或多个通信端点（Transport Endpoint），客户端通过这些端点中的某个端点连接到一个具体的ICE Object对象，一个Endpoint由服务端所使用的通信协议、IP地址、端口等信息所组成，如default -h 192.168.0.1 -p 1000，表明是采用默认的协议（TCP），绑定在192.168.0.1的端口1000上的一个通信端口。

?绑定一个或多个Servant，每个Servant与一个ICE Object映射，将客户端针对某个ICE Object的请求派发映射到对应的Servant上，并完成整个请求流程的处

理过程，包括底层通信。

?协助生命周期管理，消除ICE Object与Servant在启动和销毁过程中所可能存在的竞争问题。

从上面的Object Adapter的功能来看，很多时候我们可以把Object Adapter与在它之上绑定的ICE Object做等价，因为Object Adapter是ICE Object的“宿主”，不但提供了ICE Object的访问地址（Endpoint），而且负责完成请求处理转发的流程。因此，你会看到很多时候有这样的写法：SimplePrinter@PrinterAdapter。

二：Ice Proxy

接下来让我们看看ICE Object在客户端的代表——Proxy，简单地说，Proxy是客户端用来访问远程某个ICE Object的本地“代理”，Proxy存在于客户端的进程地址空间中，“代表”一个远程对象，当客户端调用远程对象的某个方法时，ICE运行时期的客户端代码库（ICE Runtime）会完成如下具体工作。

?定位远程对象ICE Object。

?如果ICE Object所在的Server处于关闭状态，则自动激活此Server，并激活远程对象。

?将方法的入参（传入到远程对象的参数）通过Socket传输到远程对象。

?等待调用完成。

?将方法的出参（返回给调用者的参数）返回给客户端，若发生异常则抛出调用异常。

作为远程ICE Object的本地“代理”，Proxy还持有如下重要信息。

?远程Server的地址信息，用来初始化通信

?用来定位ICE Object的对象标识符：object identity。

?可选的Facet标识符，用来确定引用ICE Object的哪个接口。

?一个具体的Proxy可以用一个包括Endpoint信息的字符串描述，比如SimplePrinter:default -p 10000，表示为在远端的TCP端口10000上绑定的一个

SimplePrinter对象的Proxy，代码中我们可以用这样的特定格式的字符串，来构造一个Proxy对象。

Endpoint通常可以理解为一个访问地址，在WebService中也有这个词：“当我们Host一个Web Service时，我们必须为其定义一个或多个Endpoint，然后Service通过这个定义的Endpoint监听来自Client端的请求”。在ICE中，Endpiont有UDP或TCP两种，但基本上很少用UDP，因为在现在的高速网络带宽采用TCP长连接的情况下，UDP 基本上没有什么优势了。

Proxy有Direct Proxy与Indirect Proxy两种：前者的Proxy直接绑定某个远端Object的访问地址，如SimplePrinter:default -p 10000；后者则不绑定到远程Object的某个具体的通信地址上，而且有两种写法，其中第一种写法是直接饮用远程对象的标识符，如

SimplePrinter，这种对象需要被定义为Well Know Object，第二种写法是

SimplePrinter@PrinterAdapter，即访问绑定到某个ObjectAdapter之上的某个对象，此时不

需要ICE Object为Well know Object。对于Indirect Proxy来说，由于没有远程对象的具体

地址信息，因此，需要借助于寻址服务——Location Service来获取对应Object的通信地址。

第三：Location Service

ICE提供的Location Service究竟是什么？其实就是利用了ICE的注册表（Registry）来

实现Object Identity 到Endpoint的查询服务，这个查询服务以及相关的API组成了ICE的Location Service组件，ICE的注册表里保持了ICE Object、Object Proxy、Server等相关信息，属于ICE Grid体系的重要组成部分，而这种注册表组件也是绝大多数分布式系统的关键组

件之一。

理解Indirect Proxy对于理解和掌握Zeroc ICE来说非常重要，因为在ICE Grid这种分布式框架中，所有Proxy都是Indirect的，从而实现了复杂的负载均衡和故障恢复机制。图2.3给出了Indirect Proxy发起服务调用的过程。

图2.3Zeroc ICE Indirect Proxy客户端调用原理图

其过程如下所述。

（1）客户端发起对远程ICE Object的方法InitialOp的调用。

（2）客户端寻址，这个过程非常类似于DNS寻址， Location Service则相当于DNS 服务，寻址过程就是Indirect Proxy向Location Service发出查询命令，而Location Service收

到查询请求后，从注册表Registry中获取对应Object的地址信息并返回。

（3）客户端Proxy直接跟远程对象建立通信连接，实现调用。

第四：总结

最后，我们给出一个包含了上述种种概念的示意图（见图2.4），来做一个总结，并

对之前没有提到的几个概念做一个补充。在ICE中，ICE Object、Object Adapter、Servant

属于服务端的概念，它们存在于一个ICE Server中，这个Server容器通常是一个ICE Box进程。ASM（Active Servant Map）是一个对象标识符（Object Identity）到对应的Servant的

查询表（Lookup Table），也就是ICE Object到Servant的映射表，当一个客户端在某个Endpoint上发起对某个ICE Object的请求访问时，ASM用来快速定位到具体的Servant上，以便高效派发请求。

图2.4Zeroc ICE核心概念示意图

最后，让我们来看看ICE的另外一个重要概念——Replication，该词的含义是让Object Adapter（及上面寄宿的ICE Object）“拥有”多个访问地址。其目标是在多个机器上部署

相同的Server来实现服务的负载均衡和容错机制，另外，当其中一台机器宕机时，客户端

仍然可以通过其他机器正常访问这些对象。当我们用下面的字符串来构造一个Proxy时，这个Proxy就具备了Replication功能：

SimplePrinter:tcp -h server1 -p 10001:tcp -h server2 -p 10002

除了这种简单的方式，ICE还支持另外一种高级的更符合大规模分布式部署的Replication方式：Replication Group，一个Replication Group具备唯一的名字，并且绑定一组相关的Object Adapter，Proxy则通过绑定到这个Replication Group上来实现负载均衡，如我们定义一个名为SimplePrinter@PrinterAdapters的Rep Group，Proxy访问这个Group 的时候，通过ICE的Location Service来解析地址并实现访问，其原理就是上面介绍过的Indirect Proxy机制，这里的不同之处只有一点：Replication Group返回的是一组可用地址信息，以实现负载均衡和容错机制。

看完本节，如果你已经对在本节中出现的这些术语的含义及ICE的实现原理有了清晰的认识和理解，那么恭喜你顺利通关，准备开始扬帆出发吧！但你若此刻头昏脑胀，一团乱麻，则也不必担心，休息一天，明天重新读一遍，因为以下代码绝对不会死循环：

While (not understand)

{

Try read again.

}

// 初始化通信器

ic = Ice.Util.initialize(args);

// 传入远程服务单元的名称、网络协议、IP及端口，构造一个Proxy对象

Ice.ObjectPrx base = ic.stringToProxy("MyService:default -p 10000");

// 通过checkedCast向下转型，获取MyService接口的远程，并同时检测根据传入的名称

//获取服务单元是否OnlineBook的代理接口