闲来谈点一家之言

================================
N系统的实现思路
================================

(I) 综述
----------

N系统主要部分有两个：后台处理，前台管理。
其他周边子系统有：发送服务，接收处理，接口部分，监控服务等。

其中两大部分分别用不同的思路与方法构造。
后台注重效率，因为要处理大量数据，所以选用c++为开发工具。
前台注重表现，故此用Web技术。

共同的思路：建立一个平台，让系统有更好的业务需求响应速度。

(II) 后台处理
-------------

后台系统构造是一个将复杂问题简单化的过程，以如下观点为指导：
1. 层次的观点：将不同的功能按层次划分，底层向高层提供完备的功能接口；
2. 协同服务的观点：也就是C/S的观点，将不同的功能做成服务，其他部分要用的时候，将数据交给服务器处理，得到想要的结果；
3. 有限自动机的观点：任何一个系统中的数据(话单，文件等)，会经历不同的处理，在处理过程中不断改变状态。

用这些观点进行分析，可以有效地将问题局部化，充分降低问题难度，又容易将一个个模块组装成功能完备强大的系统。
下面说说具体思路。

a) 系统的底层

有两个部分：跨平台库，DB处理库。

跨平台库主要以开源项目(xmail server)的跨平台底层为核心，处理OS相关的TCP/IP，进程、线程控制，IPC，文件目录控制等。

另外，包含一些基本功能的c++封装。
DB处理库是对OCI的封装，由于OCI本身是跨平台的，所以封装之后的也容易保持这个特性。
DB用的是free源码改造了一下。

这部分需要有比较全面的OS/DB/Oracle方面的综合知识。
需要研发人员了解VC++/各Unix下的c++研发环境。

目前跨平台库可以支持Window/Linux/Solaris/HP-Unix等。

b) 应用协议层

用跨平台库，构造各种应用特性的功能，主要是一些编解码模块，网络协议处理，以及数据库处理的模板类。
编解码：ASN1，MIME一些编码格式分别来源于开源，进行了改造；
网络协议处理：FTP，SMTP，POP3等协议处理来源于VC的开源，进行了改造，其中FTP几乎重写；
数据库模板类：对数据库处理的相同结构模式，进行抽取重构，形成模板类以降低上层的编码复杂性。

这部分编码方面，需要有编译原理的知识，因为协议编解码会涉及到分析技术。
网络协议方面，需要能了解各种网络协议。
数据库模板类是一个积累，主要是抽象能力。

c) 线程管理层

这是一个非常关键的部分。多线程是有效利用计算机资源的技术，故此高效服务无不是多线程。

线程管理在本系统中有统一的管理模式。
主要来说，这个层次是需要支持可管理的，对称多并行处理(SMP)的服务线程。
这对使用多线程拓宽处理瓶颈有很大益处。

另外，这个层面的线程封装，让上层得到很好的简单使用接口：只要专注于处理一个事件就可以了，其他由底层进行调度。

d) 业务层

N业务层主要由多个不同的服务组成，这些服务分别用线程表达。通过数据库、线程通讯进行协同工作。

服务可配置运行：也就是可以将系统的任意几种功能，组合定义成一个运行方式，单独在一个进程运行。

故此可支持多进程运行：让某些进程运行这些，某些运行那些。

发送服务器会和生产后台服务运行在不同机器中，所以单独编写。

由于其发送用SMP技术比较合适，使用了可配置多线程运行，也就是系统启动几个发送服务线程，可以配置。

生产后台分别由如下独立服务线程处理：
1       国际口文件接收(接口)
2       国际口发送(接口)
4       批价计算
5       国际口文件生成
6       高额累计
7       高额判断
8       同步EHUR高额记录(接口)
9       国内口文件生成
10      发布高额处理结果到EHUR(接口)
11      国内口接收(接口)
12      国内口发送(接口)
13      异常告警检测(接口)
14      邮件报告发送(接口)
15      公参同步与服务监控(接口)

(接口)是与外部系统通讯的服务。

能够将服务分成这些个，还归功于有限自动机观点：
某个数据文件，或者话单，必定在某个阶段，进行处理后改变状态到达下个处理。处理失败需要重试告警等。

系统单个服务的编程需要对业务充分了解，另外在数据结构方面需要有些要求，比如：
批价规则的内存结构是网状的，这样可以高效索引，加快批价运算速度。
高额累计需要掌握Oracle统计函数的高级功能运用。
大批量数据的支持处理，需要对数据库运行优化技术有了解。

(III) 前台服务处理
--------------------

a) 背景

当前的Web表现技术已经非常成熟。
服务端用JSP或者ASP均可，前端是ajax/DHTML/javascript。

服务端采用Tomcat/IIS，以数据库，FTP与后台服务共享数据与文件。

目前，能够快速适应业务变化的框架，还是很难找。
我想，主要因为，业务要求需要灵活性，B/S技术又将程序拆成了前后台多个部分，有些还需要互动。
比如表单处理：有前台展示，前台数据校验，后台数据校验，前台数据处理，后台数据处理。

要搞配置化，比较困难。这里需要很强的抽象能力，而国外的工程师似乎还难以完成这样的抽象。如果理论工作者加入会好些。

其他，导航、列表等也都存在这样的问题。

b) 框架

基于综合考虑，我们采用本公司的可配置业务平台生成框架，这个框架主要思路是：解释执行。

也就是前后台都按照配置，进行解释执行。大部分业务功能，用配置完成。

系统主要模块：
前台解释部分：根据配置进行展示，前台数据校验等；
后台解释部分：根据配置进行前台数据生成，后台数据校验、处理等；
联动解释部分：前台事件联动后台获取数据，即时展现部分。

框架将B/S系统功能展示处理抽象成两大类功能：导航、内容。

导航比较简单，就是一棵导航树，但活动的树，根据业务数据生成的树，处理就复杂一些。
这部分展现模式有：分页、导航树、逐级展开、快速定位等。

内容分两大类：单纯的，组合的。组合的是可分解的。
常用的内容分：表单、查询列表两类。这两种类型的解释执行功能分散在前后台，用对象定义将其归纳分类管理。

安全方面，主要就是权限配置管理。系统分角色，角色类型，组织，个人。

权限的最小配置粒度为：列表记录的操作。更大的粒度就是导航树的节点或者数据列表。

前台服务底层研发，需要掌握Web知识外，还需要有一定编译原理基础，以及抽象能力。
编译原理的掌握，主要为解释执行用。如表单可配置展现执行等。
抽象能力，需要将普遍适用的功能，抽象成某个概念，充实到某个框架模块中，才能有效地简化上层的研发。

#