相信很多人，总是会认为自己编写了很多代码，但是真要让其说出对整个代码的把握只能会自己编写的那点业务逻辑部分，对整个系统是如何运作知之甚少。
很多的开发是在现有的平台上进行二次开发，基本上不用去了解平台是如何运作，就算想去了解平台如何运作。机会也是很难得的：一是代码不一定开源；二是低层的代码难度相对来说是较大的，没有前辈指点或是好的文档，很研究下去（时间不允许）。
跟很多同事聊天，都说自己做过很多的项目，写过很多的代码。可是没有自己拿的出手东西：一套完整的平台如何运作及整个平台各个部分细节配合（即一套属于自己玩转的平台）。
前段时间，有辛公司需要开发一套给刚毕业的同事们开发一套实时交易系统，虽说以前是写过很多代码，但仍是觉得力不从心。开发也是有点难以把握（因为之前写的代码最多的就是工具，很具有针对性，现在框架是具更多的是通用性）。
基本需求：
1）平台（服务端）对接入系统（如终端系统）采用长链接。
2）平台（客户端）与第三方合作机构（如银行）采用短链接。
3）平台本身采用xml格式存储、转换报文。
4）接入系统采用xml格式存储、转换报文。
5）第三方合作机构报文格式随意，暂定为iso8583。
----------------------------------------------------------------------------------------
接下来需要考虑的问题是：
1）平台的并发能力。
2）平台新功能升级是否可以间断。
3）平台新功能的拓展能力。
======================================================
针对需求分析：
1）长链接：顾名思意是针对短链接而言，直到对方或自己主动断开链接时，通讯链路才算是结束。为了判定链路是否断开需要发起心跳包来测试对端的情况（一般是发"0000"）。
这里涉及到平台端端口是否支持多条链接：
只支持一条链接流程：（简单）
1）创建服务端套接字。
2）启动侦听端口。
3）接收客户端链接。
4）处理请求报文。如果出再链路断开回到1。
支持多条链路流程：（复杂）
用到很多高级特性（IPC）。
2）短链接相对来说简单：每次发送报文之前需要进行链接操作，发完之后需要进行断开操作。
3）报文格式，相对通讯来说要简单的多，如xml有开源的libxml2; iso8583有相应的库。
4）平台并发能力：现在充斥在耳边很多概念如分布式、负载均衡等。但最后关键技术还是多进程、多线程技术。
想要平台的并发能力强，将平台的业务与通讯分开也是很有必要的：通迅只负责收到报文，业务只是负责业务，这样可以做多：通讯不够用，直接启多个通讯进程；业务不够用，直接启多个业务进程，即哪个不够用启哪个。二者互不引影响。当然二者之间必需要有某种机制进行关联想来（如通过队例、共享内存、数据库等总之一个共享区域）。
将通讯逻辑进一步细分，收的只负责收，发的只负责发，各司其责。
5）平台新功能升级：需要做到不间断的升级平台，需要应用程序做到多进程启动（进程是否启多个线程与并发能力有关）。只有程序能做到多进程启动话，才能让新旧程序共同运用。
6）平台拓展性：代码布局及代码的基本约定及规范。
============================================================
平台基础模块：
一、日志模块：较大的项目用debug或是fprintf可能会有些力不从心，此时需要将调试信息写入文件中。至少需要以下几个功能：
1）打印ASCCII形式。
2）打印HEX形式。
3）具有debug, error二种模式。
二、通讯模块：数据的传输所必需的功能。
1）TCP/IP长链接。
2）TCP/IP短链接:可以做成群组的更容易并发。
3）其他中间件的组合。
三、定时模块：包括定时与超时。
1）定时机制：设置定时器，当时间到时，发送出相应的通知。
2）超时机制：交易发生时，往超时表里写数据，当时间到时，从超时表里取出数据。进行超时处理。
即当时间到达时，会针对定时还是超时，发出对应的通知，以通知应用程序去处理相关的信息。
四、命令管理模块： 对各个应用程序进行相应的命令管理，如对某条链路进行重新链接、停止等操作。
五、加密模块：涉及到加密操作，如硬加密时与加密机之间的通讯、加密；软加密。
六、报文组、拆包模块：对应各种各样的报文规范。
七、业务模块：业务处理部分，大部分时间是发在此处。
八、配置文件：平台会用到很多参数，参数来源一般如下：
1）以环境变量给出。
2）以配置文件给出。
3）以配置文件+共享内存的方式给出。
890
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
