TIPS的架构．嘿嘿．是什么哈．

看大漠博客，学习知识．不明白TIPS架构是什么哈.

到客户那里，讨论了一下TIPS的架构，以及支付系统的一些新改造。看来后面项目又开始多了。。:lu2:

BAIDU了一下.:lu5:
架构师Tips
   架构师的职责是创建并维护系统的蓝图。如何得到一个好的架构、怎么才能做好架构师不是一本书、一篇文章能够教我们的。
   好的架构、合格的架构师需要来自于实践。正所谓实践出真知。

   这里记录本人在实践中，结合理论知识一点体会。

   Tips1: 简单就是美
   来自于理论或书本的架构最常见的问题是“过度设计”，言必谈“N层”，SOA。好像层次分得越多，就是越先进。
   没有具体实际需求的支撑，任何“凭空而降”绝妙思路的价值都是可疑的。
   架构设计的第一铁律：简单就是美。
   越简单的架构越稳定。
   越简单的架构越清晰。
   
   请不要认为简单的就是容易的。恰恰相反，我们对外部世界的理解一般都是遵循简单-复杂-简单这样一个周而复始的过程。从复杂到简单的过程，就是一个抽象的过程。而这种抽象能力需要你对你所设计的系统的业务、技术有透彻的理解才能够达到。
   套用一个不是很恰当的武侠的比喻:入门者只会3招。大侠会N招，往往大战300回合。到了真正的高手，往往3招致胜，又快又准。

   Tips2：架构师需要加入到设计编码人员中
   我是看了Flower推荐的一篇文章才体会到的。以前，我一直困惑于设计小组的设计质量。为什么一个好好的设计会随着时间变得越来越笨拙和臃肿，或者为什么一个好的想法没有被吸收，被继承或别的小组借鉴。或者为什么没有事先在架构设计阶段被限定和约束？
   架构师脱离业务和具体的详细设计和编码，结果就使我们的架构只是一个美观的文档，或者仅仅是一个架构愿景。
   架构师加入设计编码团队的主要工作不是去负责某一个模块的编码，而是去深入理解业务本质，业务可能在哪些方面需要扩展性，去及时和设计编码人员沟通设计过程中发现的架构的问题。对前期的架构进行调整和修正。

:lu5: 再GOOGLE一下.

基于SOA架构的国库信息处理系统应用分析



信息系统的秘密

　　随着国民经济和财、税体制改革的发展，预算执行中的业务量逐年增加。但是，每次交税，纳税人都需要多次往返于银行和税务机关之间。就像王榆，他必须要先在网上进行纳税申报，网上申报成功了再赶到税务机关办税大厅取税票，之后到开户银行缴纳税款才能完成纳税程序。对于身处北京的王榆，觉得是一件耗时费力的苦差事。

　　不仅纳税人辗转往复，同时，税务机关、商业银行和人民银行之间的各套数据系统各自为政，不能通过网络连接在一起，造成各单位的数据汇总、核对不能同步进行，税务、银行等各单位也存在着大量的重复劳动，存在着数据不一致和偷逃税的可能性。

　　为此，中国人民银行提出建设国库信息处理系统（以下简称Tips系统 ：Treasury Information Processing System），建立全国集中的统一的横向联网中心，将征税机关、商业银行、国库、财政等各方机构连接起来，推动国库、税收、财政等各方面的信息建设，以解决各单位数据不能连接、纳税人交税麻烦的问题。

　　三座难以逾越的山峰

　　Tips系统的开发、测试和实施工作，给为人民银行建设系统的金融电子化公司项目组提出了极高的要求，这个项目仿佛成了一次“登天之旅”，在无尽的路途上，矗立了三座似乎难以逾越的山峰。

　　第一峰：由于多方交互，联网机构和业务极其复杂。Tips系统涉及人民银行、商业银行、国税、地税、海关等多种机构，需要支持3000家以上的联网机构。系统所需要支持的业务涉及实时单笔扣税和批量多笔扣税，同时每天日终时还需要与所有的商业银行进行核对及对账。这必须是一个批量和实时共存的业务处理系统。

　　第二关：交互的报文复杂，要求Tips有极高的处理能力。Tips系统与联网机构的交互报文既包括单笔业务，也有1000笔的批量业务，报文的大小从2KB到5MB不等，而且不同容量大小报文的处理几乎没有规律。这样的复杂程度要求系统到2009年能达到每秒处理2100笔业务；每笔业务包括税务和银行双向操作，即每秒要求处理4200笔实时报文。

　　挑战极限的第三座山峰：系统对Tips的实时性和可靠性要求高，却要项目组在短时间内完成。系统要求Tips中心内部处理时间必须小于2秒；端到端的响应时间必须小于5 秒；要求支持7×24小时的不间断运行，包括变更接入机构、系统升级等。而且Tips系统在2005年5月开始立项和需求准备，要求在2006年2月试点运行，整个需求、设计、开发、测试、联调、实施的周期只有短短的9个月。

　　“天路”铺在脚下，难道就此束手无策？

　　SOA理念迎接挑战

　　经过反复考察和论证，针对以上的困难和挑战，金融电子化公司项目组采用了SOA（面向服务的系统架构）的解决办法。

　　SOA本身并不仅仅是某种具体技术，更多的是一种系统架构的思维方式。它主张改进编程模型，采用面向服务的思路将复杂的系统划分为各个服务，应用系统之间是采用松耦合的方式连接，各个服务可以独立开发和测试。

　　Tips系统的设计在与外界系统连接时就采用了松耦合的方式，采用MQ（消息队列）和XML格式的报文将各个系统连接起来，这样各个系统（包括Tips、商业银行端、税务端）完全可以各自处理业务而不会互相受到影响。项目组采用了XML格式的报文和基于数据签名的安全体系，使各个接入机构可以在前期分别参照报文接口规范进行开发和内部测试，大大减少了系统联调测试、实施的时间周期。

　　在Tips总体架构设计时，项目组将系统分为MQ服务器、ESB服务器、WAS应用服务器、在线交易数据库、历史查询数据库等多个部分，各自负责不同的事项处理，以提高系统整体的处理效率。

　　在Tips核心业务处理上，项目组采用IBM WebSphere Application Server（简称WAS）作为系统应用服务器，使用J2EE架构实现高并发业务处理的要求，采用MDB（模型驱动技术开发方法）和JMS（Java消息服务）与MQ队列进行交互。

　　JAF(Java Application Framework )是金融电子化公司开发的Java应用开发平台，曾经在人民银行数个大型J2EE项目中使用，它提供了一个良好结构上的分离。JAF将系统划分为数据库接口层、业务逻辑层、用户界面、界面逻辑层、报表等几个相对独立的部分，各部分可以独立开发和测试，提高了开发效率。

　　同时，JAF还提供了一个可配置的面向服务架构，开发人员只要按照一定的规范编写简单的服务文件，有关的服务调用、安全、事务、日志、错误处理等都由配置文件决定，并可以在WAS容器外进行测试，极大地降低了开发测试难度和成本。

　　系统上线 方便纳税人

　　为了给Tips的部署和实施提供经验和参照配置参数，保证系统稳定运行，项目组在IBM中国系统中心进行了Tips的性能压力测试。测试中，系统的实时扣税吞吐率达到了每秒1300 笔业务，相当于系统每秒需要处理2600笔请求；每秒进行2600次XML报文解析和报文组装、2600次签名和验签名；每笔业务要进行43次SQL（结构化查询语言）处理，产生5次，也就是说要每秒要处理55900个SQL，要处理6500次交易。

　　即使在保持1000笔/秒的压力情况下，突然给系统增加数万个请求报文，多余的报文滞留在内部网关上，系统也表现出良好的稳定性，逐步对这些报文进行了处理，没有出现系统崩溃的情况。整个过程中，系统运行稳定，没有出现任何异常情况。

　　今年2月15日，系统顺利上线试运行。也就是从这个时候开始，包括王榆在内的所有纳税人足不出户就可以完成一切缴税程序，再也不像以前一样四处奔走、将时间浪费去往在各单位的路上了。截止目前，系统运行稳定，北京、湖南、贵州共50多家国库、近百家税务机构接入系统。自2006年7月起，第一批推广工作在其它6个省开始进行。如果一切顺利，我国更多地区的纳税人将获得同样方便的交税享受。

:lu4: 再一次GOOGLE一下.

TRIZ，（俄文：теории решения изобретательских задач 俄语缩写“ТРИЗ”翻译为“解决发明家任务的理论”，用英语标音可读为Teoriya Resheniya Izobreatatelskikh Zadatch，缩写为TRIZ。英文说法：Theory of Inventive Problem Solving，TIPS），可理解为发明问题的解决理论，也有人缩写为TIPS。

呵呵。tips是国税系统。

soa现在是流行的一个架构。

;P SOA这个偶知道.以前参加过IBM的一个SOA大会.后来看了一些资料.仅仅是了解一点.:$

[quote]原帖由 [i]大漠孤星[/i] 于 2007-3-17 19:43 发表 [url=http://bbs.loveunix.net/redirect.php?goto=findpost&pid=646164&ptid=70703][img]http://bbs.loveunix.net/images/common/back.gif[/img][/url]
呵呵。tips是国税系统。 [/quote]
;P ;P