【结果很简单,过程很艰辛】记阿里云Ons消息队列服务填坑过程

    Maybe 这个问题很简单,因为解决方法是非常简单,但填坑过程会把人逼疯,在阿里云ONS工作人员、同事和朋友的协助下,经过一天的调试和瞎捣鼓,终于解决了这个坑,把问题记下来,也许更多人在碰到类似问题的时候,会开放思路。当然不得不说,Ons的.NET接口还很不完善,甚至没有独立在Windos 2008/2012服务器测试过,希望官方加把力。

1、阿里云ONS介绍

   ONS(Open Notification Service)即开放消息服务,是基于阿里开源消息中间件MetaQ(RocketMQ)打造的一款云消息产品,历经多次天猫双十一海量消息考验,在阿里巴巴内部有1000+个应用在使用,产品成熟稳定可靠, 是构建大型分布式系统的核心组件之一。它能为分布式应用系统提供异步解耦、削峰填谷能力,同时也具有海量消息堆积,高吞吐,可靠重试等互联网应用所需特性。从2014年10月至今开始对外公测,目前ONS提供了北京,青岛,杭州三大Region的高可用集群(产品稳定性及可用性完全按照阿里巴巴内部标准来实施,无单点,99.99%的高可用性),公测期间完全免费。

    目前支持Java,C++,.NET, PHP四种语言,Linux平台下支持C++,JAVA和PHP三种语言, Windows平台支持C++和.NET两种语言。

2、系统环境、问题和解决过程

    总的来说,虽然官方的Demo很简单,说明文档也不详细,连参数也没解释清楚,和Java的接口差距很大,但是自己选择的路,含着泪也要走完,既然项目已经选择了.NET,那就上吧。经过同事刘哥的前期尝试,我拿过来之后,做为消息消费者,开发是非常顺利的,只是在测试机测试的时候,碰到数据问题,经过努力,自己将真实数据模拟一下,也能解决。一切都很顺其自然,当所有测试完成,准备去正式环境测试的时候,问题接踵而至。。。。

    开发环境:Win10 + .NET 4.0 + VS2013 ,目标平台:x86 

    测试环境:虚拟机-Windows Server 2008 R2 + .NET 4.0 + x64

    测试程序本地是完全没有问题,所以兴高采烈拿去服务器,马上就出现下面的问题:

【结果很简单,过程很艰辛】记阿里云Ons消息队列服务填坑过程_第1张图片

    说明:ManagedONS.dll就是Ons的.NET接口,这个错误以前也遇到过,猜测可能是自己疏忽目标平台编译错误,因为是在64bit环境下使用32bit程序。

结果总么修改还是不行,由于我部署的Windows服务程序,怕有错误,马上拖了一个控制台去测试,还是同样的问题。。。。搜索了很多,也总结了一下:

 Why:开发机也是64,没问题,为什么服务器不行,肯定是环境问题,环境差距在哪里?貌似也就是多了一个VS,然后我把本机的控制面板打开,看看那些是和开发环境相关的,如下图所示:

【结果很简单,过程很艰辛】记阿里云Ons消息队列服务填坑过程_第2张图片

    由于Ons的.NET接口是C++编写的,后来才知道是C++/CLI编写的,所以首先就怀疑Visual C++2012 Redistribution这个东西,马上去下载了一个相同版本的东西,安装下来,还是不行,杯具的是,后来才注意的,(我安装的版本是11.0.5XXX,实际上安装11.0.6XX也是不行的,原因不明,看下面分解)>。

    各种折腾,问题依旧,我马上找了几个分析程序集依赖的工具,看看到底和哪些dll相关,找出来Copy进去就好了,想法是好的,但使用了好几个工具,如exescope,Dependency Walker等等,查找一遍后,确认该有的文件,服务器都有。。。。无果。。。 各种折腾都不行后,我只能向Ons官方旺旺群求助,他们的响应速度还可以,马上有一个技术人员和我联系,寻找问题和解决方法。首先阿里的技术人员对照说明文档让我核实了一些步骤,都没有问题,然后让我修改项目属性,分析所有dll的最低支持系统版本等等,最后让我把项目配置都该为X86+Release,结果这次出现的是这个问题:

【结果很简单,过程很艰辛】记阿里云Ons消息队列服务填坑过程_第3张图片

  是找不到指定模块。。。。毫无疑问,还是环境问题,经过我和同事刘哥的确认,Win10开发机,以及Win7的开发机都是可以运行的,最后我们迫不得已,正好刘哥电脑有一个Win 2012的虚拟机也是同样的问题,为了验证我们的想法,直接在虚拟机上安装了一个VS2013,真的是泪流满面。。。VS2013安装到一半,马上就OK了,我们马上打开控制面板,看看多了哪些东西,和最上面还是一样的,多了Visual C++2012 Redistribution,马上我们把这个东西对应的版本重新安装了一半到开发机,版本号是:11.0.6,兴高采烈,结果还是失望,难道是传说中的日了狗了。。。

【结果很简单,过程很艰辛】记阿里云Ons消息队列服务填坑过程_第4张图片

  Win2012虚拟机安装VS2013的确是可以运行,卸载后就又歇菜了。无奈,怀着沉重的心情,我们去吃了晚饭,回来后向新生命群的C++/CLI大神 石头求助,把Ons的相关文件发过去后,他反编译了一下,马上给我发过来一个 更高版本的 运行时版本:12.0.3,就是下面这个鬼,

【结果很简单,过程很艰辛】记阿里云Ons消息队列服务填坑过程_第5张图片

    我很纳闷,因为前面试了几个版本都不行,也不知道这个行不行,但是还是充满希望的安装上去,果然,一切OK。。。。。心情舒畅了,只能由衷的感谢。最后将解决方法发给了阿里的技术人员,希望他们写更完善的文档,不然开放测试服务,只会让更多的人充当小白鼠。。。

3、资源与工具

  至今不懂为什么开发机的版本安装上去不行,但高一个版本就可以。时间紧迫,解决问题就好了吧。为了解决这个问题,看到一篇文章,非常不错,推荐给大家,虽然没从其中找到问题,但也学了不少东西,今天可算是把system32的文件翻了底朝天:

dll文件32位64位检测工具以及Windows文件夹SysWow64的坑

http://www.cnblogs.com/hbccdf/p/dllchecktoolandsyswow64.html

其中有一个检测Win32和64位dll文件的代码,为了检测自己的dll,特别把该博客的代码抠下来,做了一个winform工具,一起都留下来吧。核心代码如下: 

private void button1_Click(object sender, EventArgs e)
{
	string path = System.Environment.CurrentDirectory;
	DirectoryInfo directory = new DirectoryInfo(path);
	FileInfo[] fileInfoArray = directory.GetFiles();
	StringBuilder sb = new StringBuilder ();
	foreach (var item in fileInfoArray)
	{
		String str = String.Format("{0}:  {1}",item.Name,IsPE32(item.FullName)? "32bit":"64bit");
		sb.AppendLine(str);
	}
	textBox1.Text = sb.ToString();
}

public static bool IsPE32(string path)
{
	FileStream stream = File.OpenRead(path);
	//移动到e_lfanew的位置处
	stream.Seek(0x40 - 4, SeekOrigin.Begin);
	byte[] buf = new byte[4];
	stream.Read(buf, 0, buf.Length);
	//根据e_lfanew的值计算出Machine的位置
	int pos = BitConverter.ToInt32(buf, 0) + 4;
	stream.Seek(pos, SeekOrigin.Begin);
	buf = new byte[2];
	stream.Read(buf, 0, buf.Length);
	//得到Machine的值,0x14C为32位,0x8664为64位
	Int16 machine = BitConverter.ToInt16(buf, 0);
	if (machine == 0x14C)
	{
		return true;
	}
	else
	{
		return false;
	}
}

 界面如下,比较简陋,比较急着用,没有加工,大家自己看着办,使用方法是把程序拷贝到你要检测的程序集目录,如下图:

【结果很简单,过程很艰辛】记阿里云Ons消息队列服务填坑过程_第6张图片

小工具源码在这里:FileDetect.rar

你可能感兴趣的:(【结果很简单,过程很艰辛】记阿里云Ons消息队列服务填坑过程)