利用IceGrid部署的一个Demo

最新推荐文章于 2020-02-27 01:07:01 发布

骑在木马上的黑客

最新推荐文章于 2020-02-27 01:07:01 发布

阅读量1.1k

点赞数

分类专栏： InternetCommunicationsEngine（服务器适配，客户端代理）文章标签： ICE（服务器适配，客户端代理） ICE（服务器适配，客户端代理）

本文链接：https://blog.csdn.net/knightonhourse/article/details/80600785

版权

InternetCommunicationsEngine（服务器适配，客户端代理）专栏收录该内容

32 篇文章 1 订阅

订阅专栏

这里将简单介绍一个样例应用来帮助我们了解IceGrid的功能。我们的应用是从CD光盘上面rips音轨，然后把它们压缩成为MP3文件，就像图35.3里面演示的那样。

The Ripper Application

rip整张CD通常需要几分钟的时间，因为MP3压缩需要消耗大量的CPU资源。我们的分布式ripper应用要通过利用远程Ice服务器上的CPU资源来加快这个过程，让我们同时压缩多个歌曲成为可能。

MP3编码器的Slice的接口看上去很简单：

module Ripper {

   
exception EncodingFailedException {
        string reason; 
    };

   
sequence<short> Samples;

   
interface Mp3Encoder {
        // Input: PCM samples for left and right channels
        // Output: MP3 frame(s).
        Ice::ByteSeq encode(Samples leftSamples, Samples rightSamples)
            throws EncodingFailedException; 

       
// You must flush to get the last frame(s). Flush also
        // destroys the encoder object.
        Ice::ByteSeq flush()
            throws EncodingFailedException; 
    };

   
interface Mp3EncoderFactory {
        Mp3Encoder* createEncoder();
    };

};

MP3编码的算法实现与我们这次的讨论无关，我们需要关注的是IceGrid的特性——即应用的不断增长和改进。

1架构

我们的应用架构是非常简单的，我们人工启动注册表和节点构成的IceGrid。下图显示了客户端通过EncoderFactory代理发出的一个请求如何触发隐性的定位请求。

相对应的客户端C++代码在下面：

Ice::ObjectPrx proxy = communicator->stringToProxy("factory@EncoderAdapter");
Ripper::MP3EncoderFactoryPrx factory = Ripper::MP3EncoderFactoryPrx::checkedCast(proxy);
Ripper::MP3EncoderPrx encoder = factory->createEncoder();

客户端使用了 MP3EncoderFactory的间接代理。这个字符串化的代理可以逐字地理解为“ factory对象在EncoderAdapter对象适配器”。MP3编码服务器创建了一个对象代理，并且确保这个对象代理使用指定的字符串作为唯一标识。由于每一个对象代理必须被唯一标识，注册表可以很方便的确定创建了这个对象代理的服务器，并将endpoint返回给客户端。

客户端的第一个请求checkedCast是对factory对象的第一个远程调用。所以定位请求会在这次调用的整个过程中被执行。后续的请求createEncoder将直接发送到服务器，不再需要牵扯到IceGrid。

2 配置注册表

注册表需要一个子目录来创建数据库并保存数据，出于这个原因，我们使用/opt/ripper/registry作为数据库存放位置（在注册表启动之前，这个目录需要已经被创建成功）。我们也需要创建Ice的配置文件来保存注册表所需的属性。/opt/ripper/registry.cfg包含下面的属性：

IceGrid.Registry.Client.Endpoints=tcp -p 4061
IceGrid.Registry.Server.Endpoints=tcp
IceGrid.Registry.Internal.Endpoints=tcp
IceGrid.Registry.AdminPermissionsVerifier=IceGrid/NullPermissionsVerifier
IceGrid.Registry.Data=/opt/ripper/registry
IceGrid.Registry.DynamicRegistration=1

一些属性定义了endpoints，但是仅仅IceGrid.Registry.Client.Endpoints需要一个固定的端口。这个属性特指了IceGrid的定位服务的endpoints；IceGrid客户端必须将这个endpoint定义到Ice.Default.Locator中，这是我们下一节需要继续讨论的。在这个例子中使用的TCP端口4061是IceGrid注册表的Internet Assigned Numbers Authority (IANA)保留端口，4062是它的SSL使用端口。

一些其他的属性也需要提一下：

IceGrid.Registry.AdminPermissionsVerifier

这个属性控制着注册表管理是否可用的权限（请参考35.11.2）

IceGrid.Registry.Data

这个属性标明注册表数据库的存储路径

IceGrid.Registry.DynamicRegistration

如果为这个属性值设置一个非0的数，我们允许节点注册它们的对象适配器。动态注册在下面进行详尽的解释。

动态注册

默认情况下，IceGrid是不允许节点直接注册它们的对象适配器的（这一工作需要通过IceGrid的部署工具来实现，请参考35.5）。在某些情况下，比如我们的rips样例程序，你也许希望在部署一个node节点之前，客户端就可以绑定到间接代理上面。也就是说，只要简单得启动服务就可以让服务器将它自己进行注册来满足客户端的需要。

你可以通过设置IceGrid.Registry.DynamicRegistration属性为一个非0值，来运行注册表来实现动态注册的功能。使用非0值的配置，IceGrid允许对象适配器在被激活的时候将自己注册到注册表，即使它一直没有被部署过。如果强制要求服务器注册它自己的对象适配器，你必须定义Default.Locator（只有这样，服务器才能够找到注册表），并为每一个你希望自动注册的适配器设置<adapter-name>.AdapterId，AdapterId作为注册表里面的标识它必须是唯一的。设置<adapter-name>.AdapterId也会导致适配器不再创建直接代理，取而代之的是需由注册表处理的间接代理。

3 配置客户端

客户端的配置就非常简单了。只需要配置Ice.Default.Locator就可以了。这个属性为对象代理在ice运行时提供定位服务。在IceGrid中，定位服务是由注册表实现的，而需要定位的对象存在于注册表的客户端endpoint上面。在上一部分讨论中所说的IceGrid.Registry.Client.Endpoints属性提供了我们构建代理所需要的绝大部分信息。最后就是定位对象的标识，它的默认值是IceGrid/Locator：

Ice.Default.Locator=IceGrid/Locator:tcp -h registryhost -p 4061

定位服务的使用是允许客户端使用间接绑定，从而避免对服务器endpoint的静态依赖性的。但不管怎样，定位代理必须具有一个固定的端口，否则客户端就会产生一个自启动的问题：如果它不知道定位服务的endpoint，它就无法处理间接代理。

4 配置服务端

我们使用/opt/ripper/server.cfg作为服务器的配置文件。它具有下面的属性

EncoderAdapter.AdapterId=EncoderAdapter
EncoderAdapter.Endpoints=tcp
Ice.Default.Locator=IceGrid/Locator:tcp -h registryhost -p 4061

下面是有关属性的描述：

EncoderAdapter.AdapterId
- 这个属性提供了为间接代理所使用的对象适配器标识。
EncoderAdapter.Endpoints
- 这个属性定义了对象适配器的endpoint。需要注意的是这个值里面不包含任何的端口信息，这意味着对象适配器使用了系统分配的端口。在不使用IceGrid的情况下，使用系统分配的端口会出现一个严重的问题：在服务器每次重新启动的时候，系统会重新分配一个随机的端口，那么客户端如果来创建一个直接代理呢？IceGrid非常完美的解决了这个问题，因为客户端可以使用间接代理，而间接代理不需要依赖endpoint的任何信息。注册表使用在对象适配器每次激活的时候所提供的endpoint信息来处理间接代理。
Ice.Default.Locator
- 服务器需要这个属性值来注册对象适配器。

5 启动注册表

现在配置文件和注册表所需要的文件路径（储注：数据库文件和配置文件路径）都准备好了，我们可以启动注册表了：

$ icegridregistry –Ice.Config=/opt/ripper/registry.cfg

命令行支持附件的命令行参数，比如令注册表以Windows服务和Unix后台应用的方式运行。请参阅35.20.1获得更多的信息。

6 启动服务器

在注册表成功启动之后，我们就可以启动服务器了。在命令行的方式下，我们可以使用–Ice.Config选项来指定配置文件：

$ /opt/ripper/bin/server \
–Ice.Config=/opt/ripper/server.cfg

7 回顾

这个样例演示了如何使用IceGrid的核心组件：定位服务。在将IceGrid集成到我们的应用之后，客户端可以通过Ice.Default.Locator找到定位服务，然后使用间接代理找到MP3EncoderFactory对象。而且，我们不需要修改客户端的任何代码和配置就可以对应用进行重新配置。

对于一些应用，之前提到的IceGrid所提供的功能也许已经足够了。但是，这只是冰山的一角，我们才刚刚开始了IceGrid之旅，为改进我们的应用还有很多可以做的事情。在下一个部分，我们将讨论如何通过将应用部署到IceGrid节点来自动启动我们的服务器。