在公司的效劳多了今后，为了挪用上的轻易，同时为了今后的效劳治理，平常都邑运用一些效劳框架，这里主要引见我晓得的几个效劳框架，简析一下这些效劳框架的基本概念。
可投入生产环境运用的
以下两个效劳框架，我已见过有公司投入到生产环境，所以关于稳定性，应当不须要有太大的忧郁。
ServiceStack https://github.com/ServiceStack/ServiceStack
ServiceStack能够没有用过，然则它的别的两个组件，人人应当都用过，ServiceStack.Redis( Redis 接见东西)，ServiceStack.Text(Json序列化东西)，ServiceStack就是一效劳框架，能够很轻易的用他来建立效劳，效劳是基于http的，别的供应了客户端挪用， 数据的序列化体式格局包含Json , xml , 二进制，Protobuf ，而且建立出来的效劳带有肯定的形貌。
1个http要求，有两个东西很症结，要求途径和参数，关于ServiceStack， 参数即对象，即它要通报的参数都封装到一个类内里， 别的在类上打标签，标签内容就是要求途径，如许客户端在挪用的时刻，反射出要求途径和参数，即可提议挪用。
由于ServiceStack自身已供应了demo， 所以这里就不写demo了， 人人能够进修一下。
Hessian https://sourceforge.net/projects/hessiancsharp/
Hessian是一个序列化东西，同时也是一个效劳框架，供应有多语言的完成，包含.net，这个组件在.Net范畴貌似不怎么著名，多是良久没有更新了。
运用Hessian的时刻，起首须要定义接口，然后一式两份，效劳端来完成这些接口， 客户端援用这些接口，然后客户端运用了RealProxxy类做代办， 统统接口挪用终究会挪用代办类内里的Invoke要领， 在Invoke要领内里猎取要挪用的要领的称号， 参数等内容，经由序列化发送到效劳端一个一致的url上， 这个url会以hessian末端， 所以须要在web.config中设置一个handle来阻拦要求， 阻拦到要求后，反序列化参数， 然后经由过程反射提议挪用。
这里挪用能够参考这篇博客 http://www.cnblogs.com/lxsfg/archive/2008/08/27/1277777.html
其他的效劳框架另有许多， 比方thrift，JSON-RPC 然则由于没有用过， 所以这里不做批评。
博客园内的一些效劳框架
以下三个框架是我在阅读博客园的时刻发明的，而且都是开源的，关于进修效劳框架是个不错的项目，别的我不常常上博客园，下面３个框架也是机缘巧合下看到的，博客园应当另有其他优异的效劳框架只是我没有发明罢了，假如你有发明，无妨写到批评区，人人一同进修。
Rabbit.Rpc http://www.cnblogs.com/ants/p/5605754.html
和Hessin的有些像，也是先定义效劳接口，然后一式两份，效劳端经由过程继续接口来完成细致的逻辑，关于客户端，他是经由过程反射，提掏出接口内的统统要领，以及要领参数及返回值信息，然后经由过程动态生成代码的体式格局，生成一份代办类，再动态编译，放入到容器中。 关于生成的谁人代办类，统统要领都是一个一致的完成，即挪用一个Invoke要领把要领和参数发给底层，底层组装发送到效劳端。这里生成代码的体式格局比较好玩，能够进修一下。
别的，这个框架同时集成了效劳治理，效劳注册到Zookeeper， 客户端经由过程Zoopeeper拿到细致的效劳地点举行挪用。 实在到这里，这已不仅仅是一个效劳框架，同时包含了效劳治理功用。
我也仅仅是粗读了代码， 细节还没明白透，想要细致相识的能够看源码。
Dyd.BaseService.ServiceCenter http://git.oschina.net/chejiangyi/Dyd.BaseService.ServiceCenter
看引见基本的功用都有，然则看作者对这个项目的引见是说这个项目属于研究性的，关于效劳挪用的客户端，也是经由过程代码生成的体式格局， 细致能够参看代码。
别的再多引见一下这位博友，他在博客园也有博
客 http://www.cnblogs.com/chejiangyi/ ，其下开源了数个项目 http://git.oschina.net/chejiangyi 都是一些很不错的项目，比方调理效劳，设置效劳，监控效劳，关于上点范围的互联网公司，这些效劳都是须要的，更难得的是这些效劳都是基于.Net的， 所以关于一些运用.Net开辟的互联网公司来讲，有不错的自创意义。
Redola.Rpc http://www.cnblogs.com/gaochundong/p/redola_yet_another_csharp_rpc_framework.html
这个是我近来发明的，该框架运用了Actor模子，序列化运用了protobuf-net，传输体式格局是基于tcp , tcp框架运用的他本身的Cowboy.WebSockets ,看引见也完成了效劳中间，然则由于我对Actor模子并不明白，所以这里就不弄巧成拙了， 有兴致的同砚能够看作者的博客。
我本身写的效劳框架
看了这么多的效劳框架，本身手痒也写了一个，仅仅是一个效劳挪用的且是试验性子的，能够作为一个参考。
框架的道理和Hession相似，先要定义接口，然后效劳端完成接口， 这里我取了个巧，我直接让Web API中的Controller继续了接口，所以就不须要特地定义一个Handle来阻拦要求，同时也不影响Web Api的接见，所以你纵然运用了这个框架，也无阻碍你直接用http的体式格局举行接见。客户端的挪用体式格局和Hession相似，也是须要定义代办，然后网络参数，
起首定义接口
有了接口，接下来就是完成，这里我运用的是Web API， 我们定义一个Controller， 这个Controller除了继续APIController， 还继续了接口，在这个Controller里，完成接口细致的逻辑。
同时把这个接口地点的dll复制到客户端，这里要引见一个功用，就是RealProxy, 这是.Net自带的代办类，同时也是Hession采纳的机制。
using System;
using System.Linq;
using System.Reflection;
using System.Runtime.Remoting.Messaging;
using System.Runtime.Remoting.Proxies;
using Newtonsoft.Json;
using RestSharp;
namespace SimleRPC
{
public class SimpleProxy : RealProxy
{
private readonly Uri _uri;
public SimpleProxy(Type type, Uri uri) : base(type)
{
this._uri = uri;
}
public override IMessage Invoke(IMessage msg)
{
//msg参数包含挪用要领的信息，这里经由过程封装，使信息更雄厚一些
IMethodCallMessage methodMessage = new MethodCallMessageWrapper((IMethodCallMessage)msg);
MethodInfo methodInfo = (MethodInfo)methodMessage.MethodBase;
ParameterInfo[] paramsInfo = methodInfo.GetParameters(); //猎取要领挪用参数
//拼装path 类名即controller名， 要领名即action名 如许就表示出细致的url
string path = "/api/" + methodInfo.DeclaringType.Name + "/" + methodInfo.Name;
//要求范例，post or get
bool isHttpGet = methodInfo.CustomAttributes.Any(customAttributeData => customAttributeData.AttributeType.Name == "HttpGetAttribute");
var client = new RestClient(_uri);
var request = new RestRequest(path, isHttpGet ? Method.GET : Method.POST);
//构建参数
//web api关于传参的统统划定规矩 参考 http://www.cnblogs.com/babycool/p/3922738.html http://www.cnblogs.com/landeanfen/p/5337072.html 两篇博客
if (isHttpGet)
{
//这里默许get要求的参数都是基本范例
for (int i = 0; i < paramsInfo.Length; i++)
{
request.AddParameter(paramsInfo[i].Name, methodMessage.Args[i]);
}
}
else
{
//关于post要求，要么没有参数(固然基本没有这类状况)，要么只要一个参数（这些是受web api的限定）
if (paramsInfo.Length > 0)
{
request.AddJsonBody(methodMessage.Args[0]);
}
}
// 发送要求 拿到效果
IRestResponse response = client.Execute(request);
var content = response.Content;
Type returnType = methodInfo.ReturnType; //猎取挪用要领返回范例，依据范例反序列化效果
object returnValue;
if (IsBaseType(returnType))
{
returnValue = Convert.ChangeType(content, returnType);
}
else
{
returnValue = JsonConvert.DeserializeObject(content, returnType); //假如是一个对象，则用json举行反序列化
}
return new ReturnMessage(returnValue, methodMessage.Args, methodMessage.ArgCount, methodMessage.LogicalCallContext, methodMessage);
}
/// <summary>
/// 推断是不是是基本范例(int long double), string 是援用范例，然则也归到基本范例内里
/// </summary>
/// <param name="type"></param>
/// <returns></returns>
private static bool IsBaseType(Type type)
{
if (type == typeof(string) || type.IsPrimitive)
return true;
return false;
}
}
}
统统的要领挪用都邑挪用Invoke要领，在Invoke要领内，能够拿到挪用要领的细致信息，比方参数，返回值范例等。 然后经由过程反射和拼装，构成一个Http要求，这里我默许接口类名即Controller的名字， 接口要领名即Action的名字。
末了再经由过程RestSharp把要求发送出去。 末了依据http效果反序列化为要领返回值须要的值。
实在关于效劳端来首，Web API是不是继续了接口都不主要，假如不继续，则接口的署名要和Web API中要领的署名保持一致。
经由过程我写的Demo，要领是能够调的通的， 假如有人对这个感兴致，能够再多测试一些状况。
末了
如今许多的互联网公司都有本身的RPC框架，有些是采纳开源的，有些由于历史问题，本身写的，关于通讯体式格局，有基于Http的，也有基于TCP的， 另有两种协定都兼容的。 序列化体式格局也是多种多样， 我上面只列举了5个，实在在github上搜刮，另有许多优异的RPC。
RPC仅是项目生长过程当中一个阶段。 有了RPC今后，能够在此基本上做许多的事变，比方：
效劳治理 统统的效劳在启动的时刻注册到效劳中间，客户端在启动的时刻，从注册中间猎取实在的地点，直接挪用，不经由Nginx等代办，这里能够在猎取实在地点上做一些权限限定，比方哪些客户端能用，哪些客户端不能用，能用多少个，这里能够参考dubbo。
Http要求途径 如今微效劳很盛行， 前端一个要求，能够要经由后端好几个效劳，能够在http头上加上RequestId和RequestIndex， 把这些效劳串起来，比方 A->B->C，A效劳挪用B效劳的时刻，假如发明http head内里没有RequestId， 则能够经由过程GuId生成一个，同时RequestIndex加1 ，B效劳挪用Ｃ效劳端时刻， 由于RequestId已有了，就直接通报下去，同时RequestIndex加1 ，把这些信息纪录到日记中，经由过程剖析，全部挪用就串起来了，经由过程完全的数据就能够绘制出全部效劳的挪用链路图。
除了链路图，由于我们能够阻拦到每一个效劳的挪用，所以我们能够纪录效劳挪用耗时，再加上链路图，全部的效劳信息会越发完美。
以上就是.NET下几个效劳框架引见的内容，更多相关内容请关注ki4网（www.ki4.cn）！
