JointCode.Shuttle,一个简单高效的跨 AppDomain 通信的服务框架

JointCode.Shuttle 是一个用于 AppDomain 间通信的服务架构。

1. 什么情况下使用 JointCode.Shuttle

在 .net / mono 开发中,一般不太需要使用额外的 AppDomain,但在一些 特定情况下,让代码运行在新的 AppDomain 中也许是一个好的选择。

当代码需要跨越 AppDomain 边界访问另一个 AppDomain 时,便产生了跨 AppDomain 通信的问题,JointCode.Shuttle 正是专为此目的而开发的一个服务框架。

2. 为什么开发 JointCode.Shuttle

一般来说,在进行跨 AppDomain 调用时,大部分人会选择使用默认提供的 remoting 库作为底层通信机制。代码也很简单,例如:

 1 namespace JoitCode.Shuttle.SimpleSample
 2 {
 3     public class MyService : MarshalByRefObject
 4     {
 5         public void Do() { }
 6     }
 7
 8     class Program
 9     {
10         static void Main(string[] args)
11         {
12             // 在默认 AppDomain 中创建一个子 AppDomain
13             var serviceDomain = AppDomain.CreateDomain("ServiceDomain", null, null);
14
15             var myService = (MyService)serviceDomain.CreateInstanceAndUnwrap
16                 (typeof(MyService).Assembly.FullName,
17                  "JoitCode.Shuttle.SimpleSample.MyService");
18
19             myService.Do();
20
21             Console.Read();
22         }
23     }
24 }

这种方式有什么问题?

  • AppDomain 的访问是单点的,即它只能由创建它的宿主(或称父 AppDomain)访问,而不能由其他 AppDomain 访问,即使是由相同宿主创建的其他 AppDomain,甚至其宿主的父宿主也不行。
  • 缺少灵活性,由于要求服务类必须继承 MarshalByrefObject 类,这限制了灵活性。
  • remoting 库的架构设计复杂(这一点是由需求决定的,因为 remoting 不仅仅是一个跨 AppDomain 通信组件),从本质来说更适合于进程间通信。事实上,进程间通讯才是它的初衷,AppDomain 之间的通信只是其附带产生的价值。
  • remoting 的性能问题,由于架构设计的复杂性,必然带来额外的性能开销,因此它造成的最大问题显然是两个 AppDomain 之间访问的速度太慢(测试结果表明跨 AppDomain 访问比普通对象访问慢几百到一千倍)(示例
  • 双向通信。remoting 尽管也支持双向通信,但是服务端如果要调用客户端的代码,需要使用事件 / 回调。对于 AppDomain 之间的通讯来说,这不是一种自然的方式。事实上,它采用的还是一种客户端服务端的思路。

3. JointCode.Shuttle 的特点

与 remoting 相比,JointCode.Shuttle 除了具备相同的跨 AppDomain 通信的功能之外,还有自己的一些特点:

  1. 面向接口/服务
  2. 服务可管理:可动态注册/注销服务组
  3. 更好的性能:比 remoting 快 60~70 倍
  4. 使用 Attribute 方式标注服务,对代码无侵入
  5. 强类型,使用方便(remoting 依赖 magic string 来查找服务类)
  6. 内置 IoC 功能,自动管理服务的依赖项
  7. 支持延迟加载类型 / 程序集
  8. 支持访问任意 AppDomain 的服务
  9. 简单,快速上手
  10. 更自然的、任意 AppDomain 之间的通信(remoting 也可以实现双向通信,但不那么自然)
  11. 可通过租约方式管理远程服务生命期,也可自行管理
  12. 支持 .net 2.0

4. 目前的限制

JointCode.Shuttle 是一个非常新颖的框架,现在功能还不是十分完备,尽管作者计划在未来继续完善现有功能,并推出更多新的功能,但目前还是存在着一些不足,包括:

  1. 仅支持 32 位应用程序
  2. 仅支持 Windows(目前仅支持 .net framework,不支持 mono)
  3. 暂时不支持事件
  4. 测试得不够

5. 如何使用 JointCode.Shuttle

如果您对 JointCode.Shuttle 有兴趣,请移步前往 这里,我们提供了一个简单的示例来说明如何使用这个框架。

时间: 2024-08-11 01:35:40

JointCode.Shuttle,一个简单高效的跨 AppDomain 通信的服务框架的相关文章

使用 JointCode.Shuttle 进行跨 AppDomain 通信的一个简单示例

JointCode.Shuttle 是一个用于进程内 AppDomain 间通信的服务架构(不支持跨进程). 本文通过一个简单的示例来演示如何使用 JointCode.Shuttle. JointCode.Shuttle 的发行包 在 JointCode.Shuttle 的发行包中,包含两个文件:JointCode.Shuttle.dll 和 JointCode.Shuttle.Library.dll,其中 JointCode.Shuttle.dll 是使用托管语言编写的库文件,JointCod

PGET,一个简单、易用的并行获取数据框架

使用场景 当我们的服务收到一个请求后,需要大量调用下游服务获取业务数据,然后对数据进行转换.计算后,响应给请求方. 如果我们采用串行获取下游数据,势必会增加响应时长,降低接口的qps.如果是并行获取下游数据,则是不错的. 最直接想到的并行获取方法,无非是将一个个获取数据的方法封装成一个个task,然后放到线程池里执行.但这种没经过设计的使用方式,易用性很低,可复用性也很低. 经本人在实际的业务系统中,多次思考与设计.终于设计出当前这个框架. 特点:绝对的简单.绝对的易用. 相关概念 BizDat

Android跨进程通信AIDL服务

服务(Service)是android系统中非常重要的组件.Service可以脱离应用程序运行.也就是说,应用程序只起到一个启动Service的作用.一但Service被启动,就算应用程序关闭,Service仍然会在后台运行. android系统中的Service主要有两个作用:后台运行和跨进程通讯.后台运行就不用说了,当Service启动后,就可以在Service对象中 运行相应的业务代码,而这一切用户并不会察觉.而跨进程通讯是这一节的主题.如果想让应用程序可以跨进程通讯,就要使用我们这节讲的

Golang中使用heap编写一个简单高效的定时器模块

定时器模块在服务端开发中非常重要,一个高性能的定时器模块能够大幅度提升引擎的运行效率.使用Golang和heap实现一个通用的定时器模块,代码来自:https://github.com/xiaonanln/goTimer 也可以查看文档:http://godoc.org/github.com/xiaonanln/goTimer,下面是完整的代码,并进行适当的注释和分析. 从性能测试结果来看,基于heap的定时器模块在效率上并不会比时间轮(TimeWheel)的实现慢多少,但是逻辑上要简单很多.

一个简单高效的多线程解决方案

import java.io.File; import java.util.concurrent.BlockingQueue; import java.util.concurrent.LinkedBlockingQueue; import java.util.concurrent.atomic.AtomicInteger; /**  * 多线程抓取数据的简单程序  */ public class MultithreadFetcher { /** 阻塞队列的最大长度,防止内存溢出.  */ pub

一个简单的UDP协议的通信

Server import socket #引入socket模块 #建立一个UDP的服务端 udpServer = socket.socket(socket.AF_INET,socket.SOCK_DGRAM) #127.0.0.1 - 127.255.255.254 都属于访问本地 但是都是用 127.0.0.1 udpServer.bind(("10.0.144.160",8244)) #将server绑定一个ip和端口号,以便客户端访问 while True: print(&qu

Thrift RPC的一个简单c++ demo

Thrift是一种开源的跨语言的RPC服务框架,最初由facebook公司开发的,在2007年facebook将其提交apache基金会开源了.对于当时的facebook来说创造thrift是为了解决facebook系统中各系统间大数据量的传输通信以及系统之间语言环境不同需要跨平台的特性. 首先需要定义.thrift接口文件: namespace cpp project struct CompanyInfo{ 1: i32 id; 2: string name; 3: string desc;

论PHP模板的简单高效实现

大家都知道PHP是世界上最好的语言,PHP在项目开发中的灵活性是个非常重要的优点,非常适合经常变动的业务逻辑和页面内容,当然都离不开一个好用的模板引擎,市面上最常见的PHP模板引擎是smarty,但是smarty功能十分丰富,有些重量级了.那有没有更好的模板引擎呢? 先来探讨一下模板引擎的几大特点: 书写简单,执行速度,逻辑表达,方便扩展等.从这几方面看最适合的模板引擎就是PHP本身了,所有的要求都能满足要求,不管是smarty还是其他的模板引擎,在执行速度,逻辑表达,方便扩展的方面都不可能超过

Directx11学习笔记【十一】 画一个简单的三角形--effect框架的使用

这里不再介绍effect框架的具体使用,有关effect框架使用可参考http://www.cnblogs.com/zhangbaochong/p/5475961.html 实现的功能依然是画一个简单的三角形,只不过使用了effect框架. 为了体现使用effect框架方便变量绑定的优点,我们对着色器代码做了修改,增加了一个常量float4x4 gWorldViewProj cbuffer cbPerObject { float4x4 gWorldViewProj; }; float4 VS_M