几个有趣的系统架构[转]

 

今天看到一篇感受很深，特转载。

 

1. 前言

什么是合适的，那么什么就是成功的。

这句话绝对适用于系统架构和设计。

最简单的例子，如果一个系统需要的实时反应，而不是复杂的业务。那么这个系统在设计的时候就应该更加关注与速度而不是业务的分层。

反过来说，如果一个系统能够容忍客户反应的迟钝，但是要求实现非常复杂，后期可扩展的业务逻辑。那么这个系统就应该有效的对业务进行抽象和分层。

在这里，我想分享几个我所知道的有趣的系统架构设计。

 

2. 一个反应超级快速的系统框架

2.1       该系统的要求

首先我们看一下，这个系统的需求概要

系统作用	一个保险系统
系统运行环境	全国各地的保险分销点，通过 https 协议访问
系统性能要求	要求响应速度高，但是并发量不是很大
系统未来扩展预期	系统未来的业务改动不会很大

 

2.2       该系统的框架设计

 

看到了没有，这个系统设计的多么有趣。没有臭屁的 MVC ，没有乱七八糟的 XML 配置文件，更没有数据库的 ORM 。

非常单纯的系统设计，非常简洁。

所有的业务处理都放在 JSP 中间，而所有的业务处理都是通过一个自定义的 JSP Tag 库。

接着通过这个 JSP Tag 库访问数据库中的 PL/SQL ， PL/SQL 接着做数据库的增删改查。

整个系统中最重的地方就在自定义的 JSP Tag 库，数据库的连接，逻辑业务处理都在这里进行。

后期维护的时候，只要针对新业务扩展 JSP Tag 库就可以了，如果想变换数据库处理逻辑，就直接改写 PL/SQL 。

在整个系统的业务不是很庞大的时候，这样的系统设计是不是更好更实用呢？

另外，可以猜测，这个系统的设计者肯定是以前的银行系统的设计者，或者可能是以前 COBOL 时代的老程序员。因为这种短平快的设计思想绝对是那个时代的经典产物。

虽然已经很古老，但是依旧很实用。

 

3. 一个易于扩展的金融框架

3.1       该系统的要求

首先我们看一下，这个系统的需求概要

系统作用	一个行业内通用的证券系统，需要根据不同的证券公司的业务添加会修改具体的逻辑
系统运行环境	运营在小范围内，同时在线人数不大，但是要求系统的安全性和可重用性
系统性能要求	响应速度和并发量都不大，但是要求信息传输完全正确，不能失真
系统未来扩展预期	该系统其实是一个通用的证券系统平台，然后按照具体用户的要求定制系统模块

3.2       该系统的框架设计

 

我们可以看到，这个系统的框架明显的复杂了起来。

首先在客户端，它采用了 MCO 技术，让框架变成富 B/S 框架。

其次在，服务器层，他部分采用了 Struts 技术，但是有一点很特别的。

他在 Action 和 Logic 层次之间加上了一个 Facade 层次，这个最主要的原因就是减低控制层和逻辑层之间的耦合性，为了后期的扩展性做好准备。

简单的说起来，整个系统的客户端会有一个类似于 ActiveX 的控件在运行，专门用于解析服务器端发送来的 NXML 消息。而服务器端也不是单纯的发送 HTTP 请求来给客户端，而是通过框架发送有特定标识意义的 NXML 消息。

整个框架的技术层次如下：

 

最后提一下，这个框架是如何实现高可重用性的功能，如何满足不同客户快速定制化的要求。

那就是，对具体的业务抽象，抽象出高重用性的 Logic ，用来给予下方的具体业务类继承。具体的抽象 Logic 如下：

機能	Facade 名	Logic 名
登録	TemplateRegistFacade	TemplateRegistLogic
削除	TemplateDeleteFacade	TemplateDeleteLogic
订正数据	TemplateCorrectFacade	TemplateCorrectLogic
出报表	TemplateChohyoFacade	TemplateChohyoLogic
上传	TemplateUploadFacade	TemplateUploadLogic
下载	TemplateDownloadFacade	TemplateDownloadLogic
确认	TemplateApprovalFacade	TemplateApprovalLogic
确认解除	TemplateCancelFacade	TemplateCancelLogic
详细登録 / 更新 / 削除	TemplateCorrectallFacade	TemplateCorrectallLogic
Excel 处理	TemplateExcelFacade	TemplateExcelLogic

 

原文来源：http://blog.csdn.net/nanjingjiangbiao/archive/2010/08/17/5819364.aspx