gongbenwen的专栏

原创 2017年底总结，一套落地的框架和应用的开发之路

感谢公司和项目组的信任，17年年中开发了四年的开发框架，在项目中正式开始使用。框架开发从第一天开始，就是要打造中间件自身的解耦，框架开发机缘巧合，从最底层的中间件开始了，大概在13年八九月份，第一梯队的中间件雏形诞生，分别是底层通信中间件、线程调度中间件、日志记录中间件，曾经因为工作变动原因，从一个超高速的快节奏环境，换到了一个舒缓的工作环境，有了大量的思考时间，这段时间重新把Windows核

原创 Zebra打印机，中文转ZPL指令的.net实现，替换FNTHEX32.DLL

API下载地址：http://pan.baidu.com/s/1o8qnhEE编写API的目的，Zebra官方提供的Unicode转化组件FNTHEX32.DLL，是一个非托管组件，托管环境下还需要再封装。该组件直到现在还未找到对应的64位程序兼容组件，为了解决32位和64位的兼容问题，最后编写开发此API，此API完全用.net开发，无需考虑兼容性问题，实现与FNTHEX32.DLL

原创 Winform 巧用组合界面组合，实现业务解耦和复杂界面呈现

在进行业务建模时，一般是从业务层开始，构建业务需求，在业务需求的基础上，进行模块抽象，转化成对应的设计类图、对象图等，在此基础上向前，设计对应的人机体验界面，向后，构建对应的存储。前端界面和后端存储，忠实的服务于业务模型，但是一般在一个业务点上，会由多个类图互相关联，也即不同的对象组合互相协作。在业务数据处理上，对象之间通过消息通信，达到互相之间的边界隔离，但在界面呈现上，我们需要给用户一个尽

原创 Trace.ORM.Service、Trace.ORM.Data OR映射数据库访问中间件介绍

这个中间件的编写前提，是从大量的数据库访问操作SQL中解放出来，将开发者的业务点，引入到纯粹的业务层面。中间件参考了Hibernate和早期一套在用框架的一些想法观点，更多的想法是做了变体处理，以增加更高的灵活性和易用性。此处中间件，分两个接口，一个为查询接口，一个为实体映射操作接口，其中的查询接口，主要是应对，很多的面向多表查询，笛卡尔积查询，或聚合查询等条件，因为这些查询，太过于灵活和

原创 分布式企业应用系统服务部署和配置

原创 .net基础中间件开发完毕总结

从2013年9月份的第一个急迫的线程中间件构思开始，到2016年结束，最后一个OR映射中间件结束，三年中80%的周末和假期时间，花费在中间件的资料查询、设计、编码、打磨之上。一路下来很辛苦，基本上.net底层或整个类库，不论从广度还是深度，用了个遍。上图是整个中间的包图，主要包括了几大类，按照历史时间编码顺序和底层顺序分为：1、线程调度中间件，Trace.Common.Thre

原创 .net下通用事务注入中间件

在做业务逻辑时，经常会遇到，多表或多数据库操作。涉及到循环存储更新数据时，采用传统的数据库事务，事务嵌套是不可避免，事务嵌套一不小心，就会造成，事务无法回滚操作。微软提供了操作系统层级的事务环境，TransactionScope，默认为隐性事务，支持自动事务嵌套，只需要在需要事务的调用方法作用域，包围环绕即可，利用操作系统提供的事务，既可实现多表也可实现不同的数据库的同一事务范围的事务协调

原创 MemberCache缓存中间件测试版

拥抱分布，迎接大数据，两个周末，加上几个晚上的时间，基于.net的memberCache缓存中间件，终于编写完毕。测试版Demo下载地址：http://pan.baidu.com/s/1bprD6UF，测试版代码中只是做为中间件的基本操作功能，不包含服务器端的资源和策略管理。基于RMI做远程调用，采用TCP长连接，作为管道中的通信链路，默认管道中，同时开启了三个连接，以应对

原创 两个线程池模型Demo

Demo下载地址：http://pan.baidu.com/s/1gfdr9WR可取消任务线程池模型，当前应用场合，客户端界面的异步等待加载、服务器端TCP正在执行任务取消。固定线程数量，自动排队线程模型，应用场合，高并发，大批量的任务，按照有序调度，比如：大并发、快速设备数据应答场合，设备数据需要排队，同时因为设备数量大，而无法给每个设备分配一个固定的处理线程时候，采用设

原创 可执行任务取消处理线程池

周末闲来无事，把思考了很久的一个线程池处理算法，实现了，总结了一下设计的思路和设计的初衷。在进行多线程异步任务调用时，我们经常会用到.net中的线程池System.Threading.ThreadPool.QueueUserWorkItem，随着微软在线程池调度算法上的优化，线程池的效率和智能化等方面，越来越高，但是该线程池，也存在操作的缺陷，比如发起一个异步的大数据保存操作，执行数据保存可能

原创 .net下的面向工控领域的远程方法调用（RMI）中间件，测试程序

Demo下载地址：http://download.csdn.net/detail/gongbenwen/9639402从开始构思到整个中间件编写完毕，前前后后，大概有一年多的时间，中间几次因为通用性和灵活性不足，或是关键点没想清楚，推翻了或重写。最后一次重订底层通信协议，大概是三个月前，参阅了几本远程通信的书，把其中关键的消息分发环节，想通了，重新做的协议。最后一次重构，对序列化方式、

原创 Winform异步界面调用设计

在超长时间调用时，如果采用同步调用，因为窗口的Windows消息循环被阻塞，会造成界面出现假死或卡死的状态。为了避免窗口出现假死状态，通常采用异步调用，利用定时器周期性的泵入消息到主窗口，提示操作执行的进度。同时为了优雅的取消长时间的操作，需要提供对应的异步操作取消操作处理。主窗口中应该可以同时发起多个异步操作，相互之间互不干涉。基于以上的处理需求，编写了异步处理调用窗口基类。每一个具

原创 .Net下两种TCP监听服务的对比

在200万条数据构建的序列化通信传输上，采用异步TCPServer进行监听处理，并缓冲对应的字节流，采用ProtoBuf序列化，内存瞬时峰值会达到1.5G，在GC不进行强制回收的过程中，其占用内存会在1-1.5G之间波动。采用基于IO完成端口的TCP监听处理，采用相同的Protobuf序列化，内存瞬时峰值会达到1G左右，在GC不进行强制回收内存的过程中，其内存会在0.15-1G之间波动，基本上传输

原创 两种序列化方式在大数据量下的压力测试

谷歌的ProtoBuf一直被称为序列化的神器，这在很多测试场合下也是被证明了，今天在RMI中间件同步调用单元写完之后，进行通信和压力测试，同样的200万条数据，由服务器端构建，客户端进行拉取，Protobuf序列化、反序列化，加上通信时间大概用了40秒左右，服务器端吃内存在1.5G左右，用Json做序列化、反序列化，加上通信用时在4分20秒左右，服务器端吃内存大概在2.9G左右，两者无论空间占用和

原创 .net下的面向工控领域的远程方法调用（RMI）中间件，通信层实现

在协议栈实现的基础上，如何将封包后字节流发送到远端设备，或从远端设备接收封包的字节流，则需要通信层辅助实现，通信层负责连接构建、监听、会话管理等，是在远程方法调用，代码编写的最底一层，其中连接的管理、数据调度的分离等，一直是底层通信服务端开发人员在不断解决的问题，要做到更多的性能优化，比如异步IO、重叠IO、IO完成端口等，每一种方式无不是在尽可能提高通信的效率，增大并发的连接数，会话的稳定等。

原创 .net下的面向工控领域的远程方法调用（RMI）中间件，客户端协议栈应答端实现

远程方法调用，在服务器端执行完毕后，其反馈结果也必然是，按照字节流的方式返回，服务器端按照通信协议，做封包处理，而客户端的应答处理部分，从通信连接会话上，接收到待解析的字节流数据，负责解析，转化成客户端可执行的结构体数据。解包过程时，需要从外到内逐级向下，上级解包状态决定了下级解包时，调用的消息处理器。下面是同步调用过程的客户端协议拆包过程：1      通信协议包格式

原创 .net下的面向工控领域的远程方法调用（RMI）中间件，客户端协议栈请求端实现

为了实现客户端与服务器端的透明传输通信，必须在客户端方法调用时，自动对调用方法对应的参数、值、返回类型等进行流化处理，在服务器端能根据流化后的字节流，自动实现反向解析。在对通信协议封装的过程中，因此引入了客户端协议栈，客户端协议栈，分两部分，发送部分和接收部分，其中发送部分为消息封包过程，需要进行消息封包拦截处理，而接收部分，为消息解包过程，需要进行进行消息解包处理。其中封包过程，

原创 .net下的面向工控领域的远程方法调用（RMI）中间件，通信协议设计

最近正在完善一套面向远程方法调用的中间件，中间件设计初衷主要用于工控领域的分布式控制，因为中间件在前期已做了部分，但在框架化的设计上有问题，因此重新对底层协议进行修订。修订此协议的目的是，配合Trace.RMI.Client.dll和Trace.RMI.Server.dll,两个调用组件的底层通信协议使用的，此协议中，如果需要客户端注册服务器端的回调应用，则必须在客户端启用长连接通信协议。

原创 设备通信协议制定的一些误区避免

计算机设备，通信的核心和执行的核心，是01组成的字节流，而字节流中的指令和数据，如何有效的执行和传输，需要对应的协议来规范和执行。因项目和编写框架需求，前段时间，写了一套IO板卡的设备通信协议，一套RMI远程过程调用的自封装协议，一套与PLC的自动化通信协议，在制定协议的过程中，遇到了很多问题，尤其是协议编写完成之后，后期实现过程，在解包数据处理等过程中，发现了很多致命的问题，曾经为了解决这些

原创 总线机制+细粒度接口容器架构

在工控设备系统开发过程中，随着时间推移，系统集成的工业设备数量越来越大，很多设备具有共性，可以根据设备或行业进行分类，抽象出公共部分的接口，这样在实现逻辑时，根据接口进行业务调用，有效的避免了，业务与具体设备逻辑的交互，解耦了业务层与设备驱动层之间的耦合性。如果在类似的行业中应用，设备的接口基本变动很少，但是系统的变化也随商务场景或公司定位等在变化，当行业应用发生较大变更时，按照分类拆分设备，

原创 周末读书——消息设计与开发

最近一直在思考做分布式应用的消息处理系统，底层通信部分的组件，已经基本完善了，如何做应用层与消息层的自动消息分发和路由，自动分布，是一直不敢下手的原因，想参考工业总线设计，做成系统总线方式，也参考了AllJoyn式的守护进程方式，也参考了基于中心调度的处理方式，发现每一块都很大，好像也未必都需要去用，关键还是将来的业务场景更重要。迟迟不敢下手，还有一方面的原因是，担心有些理论的应用太个人经验化

原创 简单分包传输协议

在做远程通信时，大多数的RMI或RPC框架，在底层通信协议层，都不支持断点续传机制，假设业务数据包数据量很大，由于网络环境原因，在最后一刻网络中断，则前置所有传输的数据，都将丢失。同时由于RMI过程中通信的整体性，无法实现一些传输状态和处理状态的通知，这对用户的体验感会很差。一般采用在底层的TCP、HTTP通信环节，采取分包传输，实现最终的续传机制。下面是简单的分包传输协议，此处属于应用层的分包协

原创 集中设备采集监控系统架构思路

最近在帮朋友优化一套系统，系统为设备黑盒监控，设备黑盒通过移动网络，周期性将设备数据上报服务器，对周期性上报的数据进行分析处理后，进行存储。并将远端的控制指令，带回设备端，实现远端对设备的自动控制。因为终端设备的数量不确定，当前有几十台，采用TCP进行报文上传，服务器端需要进行TCP会话连接上的数据的并发处理，原有系统，将数据存储环节也放在会话连接上了，这造成了很多的问题，因为设备的增加，必然

原创 容器、接口、注册订阅、组合实现驱动层隔离

在工控系统开发中，随着项目和业务量的增加，接触到了各种各样的设备，上位工控系统要与设备通过串口、网口、PCI访问，等各种方式实现设备指令的调用。各种设备指令，在业务调用层被映射到了各种功能调用和视图表现。因为新设备每个项目都在增加，客户也需要对设备的监控或控制的粒度各不同，底层的设备驱动层则要封装大量的功能函数。每次随着新设备的引入，业务场景为了对设备的调用功能更好的描述，也需要更改对

原创 基于总线的工控溯源组态系统设计

工业自动化与传统业务系统数据的复杂交互整合，是溯源系统设计的难点，尤其是随着各种不同设备的增多，如何能更优雅的兼容各种系统，是软件架构设计的难点。      总线设计，无论是在设备控制的组态系统中，还是基于企业SOA设计的企业总线，在两种系统中都有了好的应用。      为了更平滑的整合，让设备驱动开发人员关注于设备驱动编写，业务开发人员关注于业务软件系统的编写，按照两种总线设计方式，对整

原创 利用心跳和消息队列进行离散闭合控制

最近做完的一个项目，涉及到实时监控多个设备的状态，以供业务调度处理。由于每种设备有很多监控信息因素，包括实时运动位置信息、设备启停状态信息、设备通信情况、工作时间、计数器等等，一系列的状态信息，所有的信息因为是无法主动通知回上位机，需要上位机根据协议指令，进行动态拉取。初始设计时，考虑了两种处理思路：第一种，考虑利用定时器，定时器发送了设备状态获取指令后，异步线程回调更新全局变

原创 通用通信协议栈完善总结

一切都是最好的安排，14年的6月份，开始把通用通信协议栈纳入一个构件层面的规划，到第一版颤颤兢兢下线，再到后续的项目应用，及面对灵活性的优化，到性能的优化，转眼间经历了有一年半的时间，到本月的TCPServer开始在项目中使用，基本上整个通信组件中的所有通信模块和协议栈都开始应用于产品和项目中了。几次大的变更总结：1、第一版，通用通信协议栈的规划设计阶段，在几年的工控行业应用中，做了很多面

原创 项目总结新技术在项目中的应用风险和机遇

新技术应用到项目中，尤其是面临上线压力的项目中，风险总是很大。因为新技术中有很多不确定的东西，稍有考虑不周之处，就会带来巨大的项目风险和项目灾难。但新技术又带来新的机遇，因为老的技术体系或技术思路，可能已经不适合一些处理场合了。本次项目应用场景中的新技术，原来在项目中上位机软件对传感器信号或设备IO信号的监测，靠时间对信号进行处理，包括信号滤波检测等，当在一个过程控制中，涉及到产品在产线上

原创 STM32 中断缓存队列的竞态争用问题

利用STM32 中断进行串口数据读写，由于引入中断机制，串口的读是放在中断回调函数中，由于中断的高速性，很容易引起指定的缓存区满，因此增加串口读缓冲队列，是保证数据高效可靠的保证。STM32中，没有高级操作系统中的线程调度这一概念，也就无锁的概念，但是中断的优先级高，会不停的打断主程序的执行，当主程序重回中断向量位置时，由于中断对一些数据状态的改变，主程序很容易读到脏数据。因为缓冲队列

原创 由开发项目衍生出的框架级别副产品

曾经有几年，一直在纠结着分布式系统开发和消息中间件，尤其是如何在不改变现有的开发思路，和开发模式，包括代码调用方式的基础上，实现异步消息调用和路由的分发均衡。这其中曾经去看了不少别人的思路，也去看了开源分布式框架的一些思路，但是总感觉与自己想要的不一致。但具体实现也没有个定型的思路，这其中，曾经总结或探讨过一些方法、方式，曾经想着去套用一些别人的东西，但发现很难整合。

原创 框架代码的打磨之路

大概两年前，我就在想写一套按照自己架构的属于自己的通用通信类库。从一年半前，开始着手编写，刚开始，不得其门，参考了很多开源通信框架，但是其应用实现场景，与自己想要的或需要抽象表达的，总差了一些方向。这其中修修改改，大概有三到四个月的时间，曾经变动了几次大的设计架构，总算做出了一个版本。但是这个版本，离自己想要的还是差一点火候，但是缺在哪里自己又不清楚，后来意识到了，缺的是定位，想大而全

原创 好的系统是由意识、想法决定，而不是由语言决定

做系统，一直使用C#,其开发环境简单好用，被称为宇宙第一编译器，没有第二。经常会看到一些争论，关于程序语言的争论，这个从不同的程序语言诞生，一直就存在的。很多开发者，会有一些抱怨，使用的语言决定了软件或代码的组织结构。这个因为一直在用C#做开发，一直没有体会到，我认为C#语言上的应用，确实能实现代码的完美艺术化。最近，在开发一款，嵌入式的系统，用C语

原创 基于强类型的客户端异步刷新调用

在编写Windows Form应用程序时，为了实现界面的异步调用，有时经常需要将调用抛入线程池，然后在UI端进行同步的接收，已实现异步界面的异步调用效果。但是因为异步调用参数集的不确定性和回调函数方法签名的难以识别性，有时为了实现很好的同步接收，需要引入弱类型的参数变量和返回值，但是弱类型，如果在代码中过多出现，就会造成代码的可读性、可维护性变弱，同时代码执行部分需要增加更多的类型判断

原创 生产计划执行系统或任务系统构建

在组态系统或生产过程控制系统中，不可避免的会遇到与生产任务或制造任务相关的任务下发系统，或叫计划执行系统。     因为生产制造中工艺的差别，在面向不同的产品时，可能会出现不同的差异化工艺流程，但是从共性上来说，成品的基本属性是一致的，差异在过程的处理中，因此如何对过程进行梳理分割，形成不同的子工艺或子任务，就可以实现统一的管理。     因此我们在构建主任务时，找到一个共性点，比如说成品

原创 动态横向数据调用——动态组件绑定

在编写面向终端用户操作的通用界面时，常常需要进行横向数据调用，一个录入数据源是其他数据源的一个提供者。比如ERP中的物料分类和物料，通常在构建物料时，需要选择对应的分类，我们可以通过下拉列表或弹出选择框，选择对应的分类，避免了录入，同时增加了强关联性，此处的物料分类即为横向数据，在其他地方关联带入的。      横向数据一般在硬编码层面写入，因此就降低了灵活性，与特定控件和数据源，包括显示绑在

原创 不可抛弃的软件工程理论

人有了瓶颈才会有进步，当某段时间一直在纠结的东西，不再纠结了，说明想明白了，或彻底放弃了。从事软件开发行业，转眼之间也有八个年头了，在软件开发和设计的道路上，也接触到了很多，发现不论现在的高校教育还是培训机构，越来越抛弃了一些软件工程理论的讲解，或者是讲解者自身也没有能力系统的阐述明白。大多数的开发者包括自己，在从事软件行业的道路上，可能花了几年的时间在一些技巧的磨练上，一些框架的掌握上，

原创 权限设计类图骨架

权限管理是所有系统必不可缺少的模块，通常权限管理分两块：一是功能管理，二是界面管理。功能管理负责所有的角色操作权限分配，而界面管理则负责界面的有选择性呈现，这样可以最大程度的降低代码的硬Coding量，毕竟一套系统有多个使用者，每个使用者的习惯都是不同的。在此前曾有一套权限管理系统，只兼顾了功能管理，并且功能管理的分发实际使用中不是很灵活，因此决定重新设计一套体验更好的权限管理系统，并且兼

原创 小技巧：利用虚拟网卡解决虚拟主机引起的异构网络问题

在开发过程中，需要模拟几个虚拟主机，以实现分布式环境的部署，利用VMWare建立虚拟主机后，按照默认网络配置，虚拟主机部署DataServer。在实际的测试过程中，首先Ping虚拟主机的网络，可以Ping通，远程桌面也可以连接上，但是在应用服务调用DataServer时，出现下面的异常“由于通信问题，MSDTC 事务管理器无法从源事务管理器提取事务。可能原因如下: 存在防火墙并且没有 MSDT

原创 基于总线设计的溯源控制系统

百科中定义的现场总线：现场总线是指安装在制造或过程区域的现场装置与控制室内的自动装置之间的数字式、串行、多点通信的数据总线。它是一种工业数据总线，是自动化领域中底层数据通信网络。工业现场总线，在传统的应用中一般于工厂自动化的过程监控、过程管理和部分的数据采集。传统工业总线一般与组态控制软件和PLC 等结合组成工业控制网络，并且由于工业控制的实时性和封闭性要求，其采用的网络也区别于通

原创 Asp.net MVC 4 Web编程阅读有感

已经有几年没有花时间看一本书了，趁着混合架构迁移的机会，花了几天看了一下 Jess和Toddler合著的Asp.net MVC 4  Web 编程。记得入软件的行就是从B/S着手的，大概在八年前，曾经很痴迷于Asp.net Web Form,那会儿Asp.net MVC刚刚出现一点雏形，而Asp和Asp.net WebForm则是主流，大概写了有不到两年的B/S系统，后来因工作需要转做C/S。