推荐一套很多人都嗤之以鼻的delphi中间件!

[wpy020327]

为delphi程序员定制的中间件 最新版2.10
为delphi程序员定制的中间件 最新版2.10一套专门为delphi程序员编写的国产三层架构开发系统，中间件部分封装了多节点组网、寻址路由、信息交换等部分的实现过程与细节，而客户端部分包含了应用开发的组件包，由16个控件组成。

系统架构清晰合理、功能强大，支持业务逻辑部件的开发及远程自动挂接与调用。系统没有不宜理解的各种Com/DCom/Com+及Midas等相关概念，只要有初步的delphi开发经验就能轻松上手。

系统组网灵活、配置与部署省力、功能扩充能力强，是Delphi程序员开发三层架构系统或其它跨Internet应用项目的有力工具。

各位，可去http://computer.mblogger.cn/wpy020327了解详情
索取试用：QQ 779545524


QBurro中间件的组网及对象命名规则QuickBurro中间件的优势在于灵活的组网、寻址、路由及信息交换能力。凡是使用该中间件的多个局域网或个人电脑，可以在Internet环境逻辑上“联结”成一个虚拟专用网，并由中间件软件自动维持连接及互相通信。

如下图所示，信息的交换可分成两类，一是WAN通信，另一种是LAN通信，中间件实现前者，而后者则是利用客户端开发包实现的与节点服务器之间的通信或其它类型的内网通信。中间件实现的通信部分已经实现封装，故对客户端应用程序透明。这样的组网非常灵活，大到可以是有大量法人单位参与的大型网络，小则可以仅有一个根接点和一个子节点。

而数据库服务器与应用服务器（运行中间件的服务器）的部署也是很灵活的，若一个节点有大量应用数据的，则可以将数据库服务器与应用服务器分离，否则，两者可以合在一个物理服务器上运行；对于没有应用数据的，可以使用QuickBurro自带的SQL Server高度精简版来存储节点系统数据。



上图所标出的节点代码是示例性质的，但您不难看出这种带“#”号形式的节点代码的编码规则。这样的节点代码层次分明、一目了然，在进行实际的信息交换时，中间件能很好地实现这种代码与实际的IP地址之间的转换，比如，客户端在发送一个群发请求“BroadToNodeUsers('浙江#中国','一则消息')”时，中间件软件能自动根据节点代码'浙江#中国'确定其IP地址，然后将一个群发任务提交给它，让它来完成群发的任务。

而一个节点内的各个用户的代码（在整个网络中的全局代码），则是其本地帐号+@符号+所在节点的节点代码，比如，用户代码“zs@浙江#中国”表示'浙江#中国'节点内的'zs'这个用户，直观、易于理解记忆。

基于QuickBurro中间件的应用开发QuickBurro中间件为Delphi程序员实现了大部分的服务器端软件开发的工作（也许就剩下业务逻辑部件的编写还需要应用程序员来写），所有组网、连接维持、寻址、路由、数据交换等细节都实现了封装，对应用程序是透明的。这种应用开发模型（以数据库存取为例）如下图所示：



在这种模型下，应用程序员的主要精力放在解决应用问题上，远程相关的部分只需要掌握QBClient客户端开发组件包的使用即可，需要访问哪个节点的资源，只需指定“节点代码”，而不需要与IP地址、端口、协议等打交道。而业务逻辑部件的中间层挂接（节点中间件软件处）和客户端的远过程调用，既实现了由应用程序员参与对业务逻辑进行封装、也可扩充节点服务程序的功能。

QBurro服务器端插件编写模板文件


三层架构中，业务逻辑通常封装在中间层，以实现代码重用、提高开发效率与质量的目的。QuickBurro系统也支持这种机制，只是其实现的方法有别于微软的Com/DCom技术，插件的接口规范也就差别很大了。下面这个是QuickBurro系统所支持的插件的编写规范，一个模板文件，只需要改个Library名字，再将你的代码写到RemteProcess主过程即可。
//
// -----------------------------------------------------------------------------------
//
// 服务器端插件编写模板文件 wgz. 2006.12.--2008.8.
//
// -----------------------------------------------------------------------------------
//
//
// 导出函数原型：
//
// RemoteFunction: function(AdoConn: TAdoConnection;
// InText: string;
// InStream: TMemoryStream;
// var OutText: string;
// var OutStream: TMemoryStream): boolean; stdcall
//
// 其中入口参数：
//
// AdoConn：TAdoConnection对象的实例，是调用本模块的节点系统的数据库连接，注意用完后别断开
// InText：TString类型的变量，包含有向本类模块提供的所有简单类型参数，中间以#9字符分隔
// InStream：TStream对象的实例，包含可能存在的二进制类型的入口参数，若为nil，表示不存在
//
//
// 其中出口参数：
//
// OutText：本模块处理结束后得到的简单类型结果数据，若有多项，以#9分隔
// OutStream：本模块处理结束之后得到的二进制类型的结果，若不存在，返回nil
//
// -----------------------------------------------------------------------------------
//
library RemoteModule; {你可以改一下名字}
uses
sharemem,
SysUtils,
Classes,
Windows,
forms,
graphics,
AdoDB;
{$R *.RES}
const
CAPTUREBLT = $40000000;
//
// 主函数...
function RemoteProcess(AdoConn: TAdoConnection; InText: string; InStream: TMemoryStream;
var OutText: string; var OutStream: TMemoryStream): boolean; stdcall;
begin
//
// ----------------------------这里开始写你的程序-----------------------------------------

// ----------------------------你的程序写到这里为止---------------------------------------
//
// 返回成功代码...
result:=true;
end;
//
// 向主程序提供的函数或过程的输出声明...
exports
RemoteProcess;
//
// 初始化代码...
begin
//
end.






QBClient组件包控件结构图


TQBConnection是基础连接控件，建立的实例将作为后面15个控件实例的一个属性。TUserLogin是用于实现本地用户登陆的控件，因大部分的其它控件都是需要用户事先登陆的，因此，它也是相对基础性的控件。而其它14个控件都是功能性的控件，比较容易理解。





功能示例：消息群发控件

在一个有多个节点组成的大型应用网络中，消息广播是普遍存在的需要，其群发对象是各个节点中的各个用户，为此，QuickBurro节点系统就此专门进行了实现。而TRemoteBroad控件则是客户端实现短消息群发的控件。
基本的群发模式有两种，一种是发送给某个节点（及下属各子节点）的所有用户；另一种是发送给某个地区（及下辖地区）的所有用户。而是否包含下属（或下辖），由控件的BroadToSons属性控制。
消息体最大长度一般要小于8KB，因封包时还需要添加包头数据、加密数据等，因此，用户发送的信息体的最大长度最好<7KB，否则，会因最大长度超过某些节点的消息长度限制而部分失败或全部失败。

以下程序段是客户端用TRemoteBroad控件实现短消息群发的示例代码：
//
//
// 群发给节点用户…
procedure TForm1.Button3Click(Sender: TObject);
begin
remotebroad1.BroadToNodeUsers('中国','这是一个群发给节点用户的消息！');
end;
//
// 群发给地区用户…
procedure TForm1.Button4Click(Sender: TObject);
begin
remotebroad1.BroadToAreaUsers('中国','330000','这是一个群发给中国地区用户的消息！');
end;
//
// 发给地区用户失败时…
procedure TForm1.RemoteBroad1BroadToAreaFail(Sender: TObject);
begin
memo1.lines.add('群发消息到地区用户群失败！');
end;
//
// 发给地区用户成功时…
procedure TForm1.RemoteBroad1BroadToAreaSuccess(Sender: TObject);
begin
memo1.lines.add('群发消息到地区用户群成功了！');
end;
//
// 发给节点用户失败时…
procedure TForm1.RemoteBroad1BroadToNodeFail(Sender: TObject);
begin
memo1.lines.add('群发消息到节点用户群失败！');
end;
//
// 发给节点用户成功时…
procedure TForm1.RemoteBroad1BroadToNodeSuccess(Sender: TObject);
begin
memo1.lines.add('群发消息到节点用户群成功了！');
end;
本贴来自ZDNetChina中文社区 http://bbs.zdnet.com.cn ,本贴地址：http://bbs.zdnet.com.cn/viewthread.php?tid=615041

[僵哥]

我只关心一个，性能如何，比如怎么样子的配置可以达到什么样子的处理能力。

[jasonke]

肯定有好的使用说明和例子，祝楼主生意好

[wpy020327]

性能方面：
使用环型队列+多线程+Polling技术实现，最大工作线程数可调。
未经过权威的测试，而且测试的内容（所提交任务的复杂性）也相差很大，因此无法给出具体数字。
但有一点：并发用户及任务多时自动排队处理，采用非阻塞模式，不会引起堵塞现象。

系统特色：
灵活组网、连接维持、寻址路由、透明信息交换、加密/压缩传输、业务逻辑部件动态挂接与RPC、开发控件简单易用

[僵哥]

[Quote=引用 3 楼 wpy020327 的回复:]
性能方面：
使用环型队列+多线程+Polling技术实现，最大工作线程数可调。
未经过权威的测试，而且测试的内容（所提交任务的复杂性）也相差很大，因此无法给出具体数字。
但有一点：并发用户及任务多时自动排队处理，采用非阻塞模式，不会引起堵塞现象。

系统特色：
灵活组网、连接维持、寻址路由、透明信息交换、加密/压缩传输、业务逻辑部件动态挂接与RPC、开发控件简单易用
[/Quote]
没有一个性能指标和环境配置方案，能有多少价值？又有谁会无端地做出选择？

就算整体的性能无法评估，也可以对局部的关键部位做一些测试，出一份比较有利的分析报告。比如说网络IO（光用ECHO测试）能达到什么样的效率，一个简单的加法器组件DEMO，做个简单的压力测试，简单的网络拓扑结构上面加密与不加密，压缩与不压缩各能达到每秒多笔的处理能力等等。

[Bear_hx]

楼主需要给出一些测试参数，及性能说明，好给客户选择做说明，否则很难卖的。

[wpy020327]

最近的两次升级：

（1）、2.20升级到2.30版本的具体内容：（8.24.完成）

1、修改了客户端控件，使得本地节点未登陆到父节点时也允许用户连接到本地节点

2、修改了核心服务程序中接收数据编号的生成方法，不再每次读数据库确定，从而提高了效率

3、修改了核心服务程序中的远程运行程序服务，增加对命令行参数的支持

4、修改了TRemoteRun控件的RunProgram方法，增加了一个Parameters入口参数（命令行参数）

5、修改了核心服务程序，增加了一个批量SQL语句执行的服务

6、修改了客户端开发组件，在TRemoteADO控件中，增加了一个ExecBatchSQL方法及相关的成功、失败事件

7、增加一份“计划任务”数据表，并在核心服务中增加计划任务的注册、注销、即时执行等服务

8、修改“节点服务监控程序”，增加对计划任务的管理功能

9、修改客户端的TRemoteRun控件，增加计划任务的远程注册、注销、即时运行三个方法及相关事件


（2）、2.10到2.20升级内容 （8.17.完成）

2.10版本到2.20版本的升级主要是将核心服务BurroService.exe改成了标准的Windows Service，具体如下：

a、节点服务程序去掉了原来的“随Windows启动自动运行开关项”，将程序改成了Windows标准的Service。

这样，节点核心服务程序将在windows启动且用户登陆之前就自动启动，使得系统“无人职守”指标得到

保证（有些远程服务器在重启后，管理员并不去登陆的）。

b、修改了相关的RemoteScreen插件，使之在Windows Service环境也能正常远程截屏

c、修改了相关的RemoteMouse插件，使之在Windows Service环境也能正常地远程控制鼠标

d、改进了远过程调用中的一个微小的缺陷，RPC调用的可靠性得到了提高

e、对几个插件的容量进行了压缩，在装载时速度更快

f、对节点服务管理器的服务控制方式同时进行了修改，使之实现了对Windows标准Service的监控

g、对安装程序进行了一点修改，在安装时自动装载节点服务程序

[僵哥]

说点具体的吧,我们现在有一个需求,当前是1000000(一百万)在线用户(实际注册用户有8000000以上),每秒钟以10%的活跌度(这个值是比较恒定的,预估正常峰值为30%),通讯次数大约为100000×2个通讯包,每包平均500字节.现在需要当某一用户登录上来之后,需要通知前一次未退出的登录下线.

假设需要部署到楼主的平台当中,楼主会以什么样的硬件,网络,辅助性软件的配置建议(暂时不考虑可扩充性)?

[僵哥]

登录/退出操作约占总量的20~30%,架构当中各服务器需要对用户的所有报文进行分析,包括身份验证,交易量审核,流水日志记录等.

[wpy020327]

1、先把用户按某规则（如按地区）分组，每组一个节点服务器
2、根节点不提供用户注册
3、若2层不符合需要，再挂第三层
4、对业务类型及数据库进行合理分组，充分考虑负载平衡性
5、客户端软件对访问规则进行限定，避免上层节点负荷重

[僵哥]

[Quote=引用 9 楼 wpy020327 的回复:]
1、先把用户按某规则（如按地区）分组，每组一个节点服务器
2、根节点不提供用户注册
3、若2层不符合需要，再挂第三层
4、对业务类型及数据库进行合理分组，充分考虑负载平衡性
5、客户端软件对访问规则进行限定，避免上层节点负荷重
[/Quote]
所有用户就是一组.

我要的是具体的配置信息.比如什么什么型号或者级别的服务器要多少台,内存和硬盘各配置多少,安装什么操作系统版本,需要什么样的特殊设置,如何一种部署结构.

[僵哥]

或者说得再直接一点,以如下的服务器配置为例,Intel E5405(2Ghz,12MB Cache,4核),内存4GB,应该完成上面我说的任务,需要多少台机器,如何一个部署结构.
http://publish.it168.com/2008/0814/20080814026701.shtml

[wpy020327]

QuickBurro 2.40版本于9月7日升级完成，请下载：
http://www.taomaba.com/thread-121606-1-1.html
或者：
http://www.winu.cn/viewthread.php?tid=111530


本次升级内容如下：

1、修改了核心服务的长耗时线程部分代码，加强了数据库存取部分的可靠性

2、修改了核心服务启动部分代码，确保能连上自带的数据库，增强了开机自动启动服务的可靠性

3、修改了客户端开发包，使得UserLogin、NodeManager、UserManager、RemoteADO、RemoteFTP、
RemoteRUN等控件中的主动传输方法可以多任务并发运行（提交一个方法对应的任务后，马上
提交另一个方法对应的任务），客户端与节点服务之间的数据交换能力得到大幅提升。

4、修改了核心服务的停止服务部分的代码，确保Windows关机时不会由于该服务无法关闭引起的
Windows无法关闭问题

5、去掉了核心服务程序在程序启动和退出时自动登记事件消息的功能，因为在“系统事件”里
存在关于BurroService服务的信息，不必要重复。

6、修改了服务管理器界面上的一些东西，加了点皮肤。

7、将演示、资料部分的文件夹移到上一层，让客户能方便点

8、对演示程序进行了重新Build，不再依赖Delphi的运行时库，另外增加了几个压力测试程序并在网站上公示

[wpy020327]

QuickBurro 2.50版本升级完成，公布客户端组件源码，请下载

本次升级内容如下：

a、采用了密钥自定义机制，确保在协议格式可知的情况下外人仍会由于不知道通信加密密钥而无法侵入
网络，同时，这一机制为公布客户端开发组件的源代码创造了条件

b、核心服务中将连接数据库、SystemInit过程放到OnExecute事件中，确保OnStart不超时失败（经最近
在不同操作系统环境下测试，2.40版本仍不可靠，原因是启动过程连接数据库超时）

c、改变业务逻辑部件的加载、卸载方式，修改了核心服务程序，不再需要在默认文件夹下生成dll文件

d、修改了核心服务，使调用插件时的模块代码大小写无关（以前版本DllId区分大小写，不是很方便）

e、修改了服务控制程序，增加了“网络通信密钥”和“未用插件内存驻留时间”等参数设置功能

f、修改了客户端开发包，在TQBConnection控件中，增加了一个“TransferKey”属性，用于指定密钥

g、服务管理器的基本运行状态监视页中增加了对活动插件数、挂接的计划任务数的监视

h、服务管理器增加了程序启动、界面恢复时的身份验证功能，防止被管理员之外的人查阅系统敏感资料

i、将核心服务程序的资源释放定时器从1秒激发一次改为2秒激发一次，防止主线程过于繁忙

j、修改了因TQBConnection控件增加了密钥属性而需要修正的演示程序，修改了1.X版本的客户端开发控件

k、界面上作了一些细微的调整；安装后的文件夹作了些调整，特别是把各个delphi版本的组件分在不同文
件夹下了；修改了客户端开发包用户手册；对修改后的系统重新作了一次近、远程测试

l、正式对外公布客户端组件的源代码，本系统用户从此可以Build出不带任何BPL运行时库的程序了


QB2.5版本的RPC性能得到大幅度提高！

系统不再采用Delphi默认的动态加载DLL的方法，而是采用了自行加载、管理DLL模块的方法，因此，DLL模块在不再引用之后，不象以前那样马上释放，而是驻留内存一段时间，这样，DLL模块不会出现频繁地调进调出（每次磁盘操作都会浪费很多时间），RPC的效率因此有了大幅度的提高。

[wpy020327]

最新的2.51版本修正了两个Bug：（9月15日完成）

a、修改了核心服务的各个线程组程序，增加了对服务停止标志的检测，使得服务停止加快，同时，对节点服务管理器的“停止”按钮作了点修正。

b、9月15日检测到局域网中非节点所在机器连接本地节点失败的Bug，对程序进行了分析，通过修改核心服务程序的节点发现服务，排除了该BUG。