如果你应聘互联网企业的架构师 分布式解决方案属于必问环节 因为流行SOA 关于SOA就不废话了 网上资源很多 重视4个字“基于消息”
本篇只测评大家项目中常用的几种
Remoting（TCP,HTTP,IPC）
WCF(basicHttpBinding,netTcpBinding)
Hessian
MSMQ
WebService
......
环境介绍
客户机 windows Xp 服务器 windows2003（虚拟机）
带宽2M
测试环境和线上环境差距比较大 我们看相对性就可以了
所有方案基于相同远程对象
public class DtoClass : MarshalByRefObject
{
public static Message GetMessageInfo(string param1, int param2, bool param3)
{
var dto = new Message {Param1 = param1, Param2 = param2, Param3 = param3};
return dto;
}
}
[Serializable]
public class Message
{
public string Param1 { get; set; }
public int Param2 { get; set; }
public bool Param3 { get; set; }
}
public interface IMaoyaTest
{
Message GetDto(string param1, int param2, bool param3);
}
[ServiceContract]
public interface IWcfMaoyaTest
{
[OperationContract]
Message GetDto(string param1, int param2, bool param3);
}
不同的通信方案 客户端请求相同的对象
例如 remoting
public Message TcpSingleCall()
{
var proxy = (IMaoyaTest)Activator.GetObject(typeof(IMaoyaTest), "tcp://192.168.234.129:8001/MaoyaTestURL");
return proxy.GetDto("chongzi", 10, true);
}
hsssian
public Message HessianTest()
{
var factory = new CHessianProxyFactory("userName", "password");
const string url = "http://192.168.234.129/HessianService.hessian";
var hessianinstance = (IMaoyaTest)factory.Create(typeof(IMaoyaTest), url);
return hessianinstance.GetDto("chongzi", 10, true);
}
不同的通信方案对远程对象进行不同的处理
例如 remoting
public class RemotingTest : MarshalByRefObject,IMaoyaTest
{
public Message GetDto(string param1, int param2, bool param3)
{
return DtoClass.GetMessageInfo("remoting:"+param1,param2+1,param3);
}
}
hsssian
public class MaoyaService : CHessianHandler, IMaoyaTest
{
public Message GetDto(string param1, int param2, bool param3)
{
return DtoClass.GetMessageInfo("HessianService:" + param1, param2 + 3, param3);
}
}
Remoting
NET Framework 远程处理。这种技术可用于与呼叫中心应用程序进行通信，因为二者都是建立在 .NET Framework 之上的。远程处理专门为紧密耦合的 .NET 到 .NET 通信而设计，因此它为本地网络中的应用程序提供了无缝而直接的开发体验。
Remoting支持3种通道TCP HTTP IPC
Remoting支持2种激活方式服务端激活与客户端激活，服务端激活分为singlecall，sington区别为是否有状态，sington给每个客户端分配同一个对象实例，sington有状态。客户端激活为在激活每个对象实例的时候，会给每个客户端激活的类型指派一个URI。其与singcall的主要区别在于客户端激活方式对于对象周期的管理以及有状态。
了解使用场景，我们更关心性能。
TCP：Transmission Control Protocol 传输控制协议TCP是一种面向连接（连接导向）的、可靠的、基于字节流的运输层（Transport layer）通信协议
HTTP（HyperText Transport Protocol）是超文本传输协议的缩写,HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URL、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应，响应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。
IPCChannel是.NET Framework 2.0 里面新增的，它使用 Windows 进程间通信 (IPC) 系统在同一计算机上的应用程序域之间传输消息。在同一计算机上的应用程序域之间进行通信时，IPC 信道比 TCP 或 HTTP 信道要快得多。但是IPC只在本机应用之间通信。所以，在客户端和服务端在同一台机器时，我们可以通过注册IPCChannel来提高Remoting的性能。但如果客户端和服务端不在同一台机器时，我们不能注册IPCChannel。
remoting总结
优点（相对于其他分布式方案） tcp方式效率相对较高 ipc王道 可以自定义宿主
缺点 平台限制
应用场景（实例） 统一新闻系统中新建新闻的异步自动审核、逻辑报表 等 使用remoting可以有效分担服务器硬件压力并且不需要对外服务开放 各个模块高效 紧密合作
WCF
Windows Communication Foundation (WCF) 是 Microsoft 为构建面向服务的应用程序而提供的统一编程模型。借助这一模型，开发人员可以构建既能跨平台与现有投资集成又能与现有投资交互的安全、可靠的事务处理解决方案。
wcf是WebService,Remoting,...之上的一层抽象，让程序员们以一种统一的方式去编写基于WebService或Remoting。。。的程序，而且它们之间的切换很简单，只需要改一下配置。 也就是说，开始服务以WS向外提供，因为需求改变，改为Remoting向外提供，只需要修改配置。WCF封装了各种不同实现的具体细节。WCF服务元数据是WCF服务的核心部分服务地址（Address）、绑定（通信协议Binding）、契约（服务、操作、数据Contract）的原始描述信息。
我们这里只测试2中常用的case
BasicHttpBinding不支持可靠性，BasicHttpBinding面向旧的ASMX Web服务，是不具有可靠性的；
NetTcpBinding 支持可靠性，显然使用TCP传输数据。以及各种WS绑定，默认情况下并不支持可靠性，允许启用；
其他协议：
NetMsmqBinding不支持可靠性，MSMQ协议，使用消息队列，针对断开调用，不存在传输会话；
MsmqIntegrationBinding不支持可靠性；支持WCF与MSMQ协议通信，不存在传输会话；
NetPeerTcpBinding不支持可靠性。NetPeerTcpBinding则为广播场景设计。
WSDualHttpBinding支持可靠性的，建立两个http会话通道，保持回调通道，确保基于HTTP协议的客户端存在；
NetNamedPipeBinding绑定总是拥有一个确定的从客户端到服务的跳数，因而它的可靠性是绑定固有的；
WSFederationHttpBinding支持可靠性，支持联邦通信协议，支持在多个安全区域进行安全会话。
WCF 总结
优点 兼众家之长 易用性、灵活性、易调试性、易部署
缺点 和腾讯的口碑差不多 论tcp 比起remoting 你效率没人高 论http 比起webservice 你没人方便
应用场景（实例） 事件调度中心 作为soa最常用的工具 wcf市场还是蛮大的
Hessian
这货java程序员用的比较多 c#程序员估计有点茫然，这是神马。传输二进制？和remoting比,自然比不上。关键是hessian是基于http协议，不过不是用的soap协议，咱们还是和webservice比吧。
Hessian是一个轻量级的remoting onhttp工具，使用简单的方法提供了RMI的功能. 相比WebService，Hessian更简单、快捷。采用的是二进制RPC协议，因为采用的是二进制协议，所以它很适合于发送二进制数据。
难怪c#没人用了......
hessian的处理过程 由客户端、序列化到输出流、远程方法（服务端）、序列化到输出流、客户端读取流、输出。
优点 开源 轻量级 可以自己扩展 相对webservice可以自定义宿主 减轻iis压力
缺点 目前的版本 性能比较差
应用场景 一些开源软件 框架
MSMQ
Message Queue（微软消息队列)是在多个不同的应用之间实现相互通信的一种异步传输模式，相互通信的应用可以分布于同一台机器上，也可以分布于相连的网络空间中的任一位置。它的实现原理是：消息的发送者把自己想要发送的信息放入一个容器中（我们称之为Message），然后把它保存至一个系统公用空间的消息队列(Message Queue)中；本地或者是异地的消息接收程序再从该队列中取出发给它的消息进行处理。
用于与基于 Windows 的合作伙伴应用程序进行通信，这些应用程序对数据传送、工作量分离以及应用程序生存期均要求有保证。消息队列提供持久稳定的消息传送，这通常是间歇式连接的应用程序的最佳解决方案。
优点: 稳定性 消息优先级 脱机能力 安全性
缺点：比remoting更大的局限性 如果是远程msmq 限于安全性 服务器需要在同一个域
应用场景：（实例） 邮件系统 站内信系统
WebService
这个你们都懂的 不说了 直接看测试结果
优点： 跨平台
缺点： 效率相对比较低
应用场景： 很多 大家最常用的方式了 例如商城赠品服务等等
其它
Enterprise Service，wse等等不一一列举了 有空大家自己玩了
本篇到此 希望对大家有帮助
