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
测试程序本地是完全没有问题,所以兴高采烈拿去服务器,马上就出现下面的问题:
说明:ManagedONS.dll就是Ons的.NET接口,这个错误以前也遇到过,猜测可能是自己疏忽目标平台编译错误,因为是在64bit环境下使用32bit程序。
结果总么修改还是不行,由于我部署的Windows服务程序,怕有错误,马上拖了一个控制台去测试,还是同样的问题。。。。搜索了很多,也总结了一下:
Why:开发机也是64,没问题,为什么服务器不行,肯定是环境问题,环境差距在哪里?貌似也就是多了一个VS,然后我把本机的控制面板打开,看看那些是和开发环境相关的,如下图所示:
由于Ons的.NET接口是C++编写的,后来才知道是C++/CLI编写的,所以首先就怀疑Visual C++2012 Redistribution这个东西,马上去下载了一个相同版本的东西,安装下来,还是不行,杯具的是,后来才注意的,(我安装的版本是11.0.5XXX,实际上安装11.0.6XX也是不行的,原因不明,看下面分解)>。
各种折腾,问题依旧,我马上找了几个分析程序集依赖的工具,看看到底和哪些dll相关,找出来Copy进去就好了,想法是好的,但使用了好几个工具,如exescope,Dependency Walker等等,查找一遍后,确认该有的文件,服务器都有。。。。无果。。。 各种折腾都不行后,我只能向Ons官方旺旺群求助,他们的响应速度还可以,马上有一个技术人员和我联系,寻找问题和解决方法。首先阿里的技术人员对照说明文档让我核实了一些步骤,都没有问题,然后让我修改项目属性,分析所有dll的最低支持系统版本等等,最后让我把项目配置都该为X86+Release,结果这次出现的是这个问题:
是找不到指定模块。。。。毫无疑问,还是环境问题,经过我和同事刘哥的确认,Win10开发机,以及Win7的开发机都是可以运行的,最后我们迫不得已,正好刘哥电脑有一个Win 2012的虚拟机也是同样的问题,为了验证我们的想法,直接在虚拟机上安装了一个VS2013,真的是泪流满面。。。VS2013安装到一半,马上就OK了,我们马上打开控制面板,看看多了哪些东西,和最上面还是一样的,多了Visual C++2012 Redistribution,马上我们把这个东西对应的版本重新安装了一半到开发机,版本号是:11.0.6,兴高采烈,结果还是失望,难道是传说中的日了狗了。。。
Win2012虚拟机安装VS2013的确是可以运行,卸载后就又歇菜了。无奈,怀着沉重的心情,我们去吃了晚饭,回来后向新生命群的C++/CLI大神 石头求助,把Ons的相关文件发过去后,他反编译了一下,马上给我发过来一个 更高版本的 运行时版本:12.0.3,就是下面这个鬼,
我很纳闷,因为前面试了几个版本都不行,也不知道这个行不行,但是还是充满希望的安装上去,果然,一切OK。。。。。心情舒畅了,只能由衷的感谢。最后将解决方法发给了阿里的技术人员,希望他们写更完善的文档,不然开放测试服务,只会让更多的人充当小白鼠。。。
3、资源与工具
至今不懂为什么开发机的版本安装上去不行,但高一个版本就可以。时间紧迫,解决问题就好了吧。为了解决这个问题,看到一篇文章,非常不错,推荐给大家,虽然没从其中找到问题,但也学了不少东西,今天可算是把system32的文件翻了底朝天:
dll文件32位64位检测工具以及Windows文件夹SysWow64的坑
http://www.cnblogs.com/hbccdf/p/dllchecktoolandsyswow64.html
其中有一个检测Win32和64位dll文件的代码,为了检测自己的dll,特别把该博客的代码抠下来,做了一个winform工具,一起都留下来吧。核心代码如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
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
;
}
}
|
界面如下,比较简陋,比较急着用,没有加工,大家自己看着办,使用方法是把程序拷贝到你要检测的程序集目录,如下图:
小工具源码在这里:FileDetect.rar
本文转自叶小钗 h数据之巅博客园博客,原文链接:http://www.cnblogs.com/asxinyu/p/dotnet_api_alibaba_ons_service_MQ.html,如需转载请自行联系原作者