个人随笔，如请转载，请注明出处：http://blog.csdn.net/dingwood/article/details/7540988。

 

1 高扩展性

我理解的高扩展性就是在需求变动或新增需求时，开发人员能够基于以前的系统架构做出快速开发。

1.1例子：

项目经理李峰把JAVA EE项目架构搭建好后，实习生张飞就按照工作安排进行A、B、C、D四个模块的开发。由于维护需要，在编写业务逻辑处理的代码时，需要将用户的操作记录下来，以方便维护。张飞在写完A模块的日志记录及业务逻辑后，就老老实实的将日志记录代码拷贝到B、C、D等模块，代码的复用变成了代码的粘贴复制，随着工作的进展，客户提出需求，将用户的操作记录下来，权限高的用户可以查看权限低的用户，此时，小张听到这个消息立马傻掉了，因为他的记录日志方法以硬编码的方式散落在各个业务对象中，数十个业务对象都需要修改，即便是修改了一个业务对象，粘贴复制到其他对象也够累的，此时，项目经理李峰说，要用OO思想看世界，将公用的系统需求（比如记录日志、权限验证）进行封装，以方便在每个业务对象中进行调用。在张飞奋斗了一天后，终于把他所负责的模块改完了。------整体架构稳固，公共功能进行封装，提供各模块调用，好比bizware的通讯适配层被封装起来，将报文处理函数（接收8字节、发送8字节函数）以数据库形式记录，主控程序通过读取数据库配置来调用通讯函数，以满足各种不同的并且多变的通讯接口要求。

1.2 针对网银项目的理解

传统网银包括老三样：查询、转账和理财。网银所有的功能都是基于这三类发展和演变的。针对这三类交易，网银接入系统的一般处理流程为：接收并解析报文-->校验（如果有需要）-->记录数据库（方便查询问题）-->数据字典转换-->通讯（转发至核心或其他系统并接收返回信息）-->更新数据库-->数据字典转换-->返回报文 。 

针对报文解析模块进行分析，我们会发现，解析报文的过程就是将收到的报文按照某种规则进行截取并赋值给对应的变量的过程（这种规则我们称为通讯协议，有公用的如ISO8583协议，还有各个系统私有的如定长、分隔符、XML协议等）。解析报文的动作是公共特性，但解析规则是各个交易特有的。针对公共特性进行封装形成公共模块，这个模块能够解析各类通讯协议的报文，但解析的规则还得由各个交易告诉主控程序，可以将每个交易的通讯协议及规则保存在文件或数据库中，主控程序从文件或数据库获取对应交易的解析规则，然后进行解析。

针对校验模块进行分析，我们会发现，每个交易校验的内容可能不一致，甚至有的交易不需要校验，没有公共特性可言，校验模块应由每个交易的自身处理。

针对记录数据库模块进行分析，我们会发现，记录数据库的方式多种多样，有的需要记录下整个交易报文（方便根据数据库检索日志）；有的需要详细记录交易的每个字段（如账务交易可能需要进行统计）。记录整个交易报文可以说是公共特性，进行封装。无法封装的记录数据库由各个交易自身处理。

针对数据字典转换模块进行分析，我们会发现，每个交易都会用到数据字典的转换（如将核心成功的返回码ESS0000转换成农信银的成功返回码000000），将此模块进行封装，还是老习惯，要么通过配置文件，要么通过数据库，保存数据字典和数据字典值的对应及转换关系。

针对通讯模块进行分析，我们会发现，每个交易的通讯目的地有可能不一样，有的发送到核心，有的发送到支付系统，有的可能发送到短信平台，有的还有可能与两到三个系统通信。但多数交易只是发送到核心，并且只是发送单条交易请求，然后接收核心单条返回信息。

还有一部分交易需要涉及到多条明细返回，如查询账户交易明细交易；还有少数交易涉及到发送多个系统。针对此模块，我们可以采取两种方案。方案一：一刀切。交易主控只负责调用通讯接口，具体逻辑由各个交易自身实现；方案二：分而治之。针对大多数通讯逻辑相似的交易形成通讯的公共模块，供主控程序调用，通讯逻辑比较特殊的则由各个交易实现。

接下来的流程分别为更新数据库-->数据字典转换-->返回报文，这三个模块就不做分析了，因为和之前的流程有很多相似甚至相同的地方。

最后，我们在主控程序中，调用每个流程环节中抽象出的公共模块，在每个流程环节中，每个交易的个性化处理进行单独开发，将个性化处理程序和交易名称进行一一对应，实现配置化（文件或DB方式记载），主控程序通过读取配置获取对应关系，根据不同交易调用调用不同的个性化处理程序。

当需求变动或增加时，主控程序（所谓架构）基本不用变动，只要针对每个交易的个性化处理进行插件式的开发（如验证），增加一些交易配置即可（如解析报文模块）。如果主控程序无法满足需求变动，可以增加另外一套主控程序，针对不同的需求调用不同的主控程序即可。当然，具体的实施需要根据实际情况而定。

这就是我理解的软件的高扩展性。即在需求增加或变动时，程序的架构基本不动或做一些很优雅的变动，然后针对每个功能的个性化处理进行插件式的开发，增加若干配置，即实现相应功能。

2 高可用性

2.1 例子

这两天重新安装了foxmail，发现已经升级到了版本7，原来需要设置的发送服务器和接收服务器，而现在软件本身都会根据用户输入的邮箱名自动设置发送服务器和接收服务器。去繁就简，设置一步搞定，这就是高可用性的体现。

2.2 针对网银项目的理解

就个人理解，作为网银接入这类交易转发的系统，高可用性主要表现在以下两个方面：一是转发的效率，二是转发的稳定性。

先谈谈效率。用户登录网银并发起交易请求到农信银网银，交易通过internet传送到农信银网银的服务器（这个时间记为T1），经过农信银网银系统处理后再转发至我方的网银接入系统（农信银网银的处理时间记为T2，转发至网银接入系统的时延为T3），网银接入系统处理后(处理时间为T4)，与核心进行通讯并返回农信银网银(与核心通讯时延为T5，返回农信银网银的时延记为T6)。

我们得出如下公式：T（整个交易的处理时间）=  T1+T2+T3+T4+T5+T6。

我们能控制的只是T3、T4、T5、T6，如何能让T3在合理的范围内变动，并且网络的花费不会太高（拉个100G的光纤也没必要），首先我们获取行内现有的银行卡用户，大致估算出推广后的网银用户，然后针对网银用户再估算出日常的在线用户数，进而估算出日常的交易请求数，再针对各种报文，估算出日常发送的交易报文的大小。从而计算出网络带宽，再加上1/4的带宽冗余。这样就得出大致的网络带宽。（这种评估方法缺乏数据的支持，有待推敲）。

保证T3在合理范围内变动后，在推敲T4(网银接入系统处理交易的时间，是不是忘记了？呵呵)，为了保证用户的并发访问，我们设计出多线程或多进程的程序来处理用户的请求，针对第一节中高扩展性的流程分析，抓住主要矛盾，忽略次要矛盾（如验证这样的操作），整个转发过程中无非做了三个大的方面：报文转换、通讯和数据库操作。针对报文转换，如果采用读取配置文件的方式，则需要用文件缓冲流以提高读取速度，如果采用数据库配置的方式则需要进行优化（包括建索引、设立分区表等）；针对通讯，则需要设置好超时时间，确保与核心的通讯时间小于农信银网银系统与网银接入系统的时间，防止交易超时；针对数据库操作，则需要进行优化（包括建索引、设立分区表等）；当然，数据字典的转换虽然做成公共模块，但每次都要读取数据库获取转换关系也比较耗时，让数据字典转换更高效的做法是将其做成系统服务，数据字典的对应关系保存在系统缓存中，每次读取缓冲区进行数据字典转换。当然，同时产生的问题就是数据同步的问题------同步数据库（也有可能是配置文件）与缓冲区中的数据，同步的方案有很多，有自动同步方式（如凌晨3点自动同步），手工同步方式（最简单的就是重启服务，当然智能点，可以设置标志位进行同步）。综上所述，T4也可以保证在合理范围内变动。

由于网银接入系统与核心同属于一个局域网，所以T5考虑的意义不大。

针对T3已经做出考虑，所以T6也不做重复讨论。

当然，提高效率需要考虑很多方面，比如机器性能、硬件设备的横向和纵向的扩展带来效率的提升等。由于能力有限，这里不做赘述。

接着谈谈对稳定性的理解，我的想法很简单，就是确保不会发生单点故障。这里就会考虑使用各种集群软件。当然，这是架构上的设计。当然，如果设计的软件具有这部分功能，客户就不会操心买集群软件了，对客户是个吸引。 由于集群技术的专业性以及自身知识的匮乏性，就不出丑了。呵呵。

 

这就是我对基于网银接入系统的高可用性的理解，当然，我觉的不同的软件对高可用性的要求不一样。并有一个一概而论的统一标准。

3 高可维护性

3.1 例子

笔者在使用QQ软件或PL/SQL的过程中，出现异常或错误时，都会弹出一个提示界面，让用户将错误信息提交到给后台。供后台的工程师进行优化及处理。这就是高可维护性的体现。当然这只是一方面，QQ软件很少出错，即便出错重启仍能正常运行，这本身就是高可用性的体现。

3.2 针对网银项目的理解

个人觉的，网银目前还没做到高可维护性。系统在生产上运行。当客户做交易出现异常了，反映到业务部门，业务部门再反映到科技部门，科技部门才会去查询相关交易的异常，查证问题时还可能会和农信银网银、核心系统、支付系统等技术人员的沟通，当科技部门查证完后反映给业务部门异常原因，业务部门再对客户进行反馈。整个流程不仅繁杂，而且耗时，在消息流转的过程中，可能存在失真，加大了工作难度。 当然，整个流程有优化的必要，虽然属于流程银行的内容，但不可避免的会和软件相挂钩（目前行内也在做一些流程银行的工作，如数据应用平台的研发，将数据统一下发，查询交易独立出来，确保柜面最大限度的处理账务交易，大大优化了柜面业务处理能力，个人认为也属于流程银行的内容）。分析整个流程，不难发现，问题的查询或业务咨询无非是在客户与技术人员、业务人员之间搭建一个透明的沟通桥梁，借鉴人人网、FACKBOOK的做法，可以在网银界面上开发出基于WEB的聊天功能，在农信银网银的内管中开发出针对业务、技术人员的服务端。客户发现交易异常或遇到业务问题时，无需转移视线，即可在线的沟通业务技术问题。沟通距离缩短了，用户体验感加强了。

当然这种办法属于被动防御型的，目前大多数系统都是基于客户反馈，进行问题排查的。那么有没有主动进攻型的办法呢？答案是肯定的。针对目前统计的问题进行分类，将出现次数最多的拎出来。比如问题是交易超时。可以在交易的开始记录交易开始时间，结束时记录交易结束时间，当出现多笔交易都超过某个时间时，交易存在问题的可能性就大，就通过短信平台通知运维人员。当然这只是一个案例，举一反三，我们也可以再目前的管理台做出一些优化，比如针对操作人员提出的一些问题，形成小贴士，记录入库，每当操作人员点击管理台的某支交易时，会将对应的贴士返显在比较显眼的地方，让用户可以注意到常见问题。（类比浩方对账平台的DOTA游戏进入后，会提示游戏玩家某些攻略技巧等）

 这是我对高可维护性的一些理解。

 

 

 

纵观整篇文章，不乏我个人过于理想化的一些想法，主观愿望稍强烈了一些，有的地方可能我过几天看，都可能会发现不成熟甚至幼稚。

希望路过的人，对不满意的地方提出批评指点。

阅读更多

更多精彩内容