卧看春秋负平生
2004-01-01, 01:14 AM
我们当年的北京市人民政府是中国最“爱国”的一个地方政府，要运行全北京市的医疗保健和社会保健电子政务系统，首先选择的当然是多年的国际关系户IBM公司，因为没有人说IBM是美国公司，应该和国产的"linux"一样是自己人，所以选择是安全可靠的保证。
但，随后IBM在系统投入运营后出了个状况，当人们都挤在上面超过200万的时候，IBM的系统瘫痪了！结果，北京的各大医院骂声漫天飞，患者是交了费投了保的一律不知道，要知道这是什么人啊，是北京大小的官员和中央结构的人员啊，首信被弄的灰头土脸，不好惹啊，怎么办？
以前不是坚决打击微软吗？叫你傲气不向IBM老兄知道中国情，想靠技术不进贡？问问BEA公司吧，SUN公司也还是懂事的结果，所有的“盟友”都请遍了，冤枉钱化了不少，计算机的病还是没有解决，搞不定，怎么向领导交代啊，丑丢大了去拉。最后脸一抹，实在没辙，还是很尴尬地找上了微软的门...
原来，故事的发生是这样的...
经过两年的酝酿，北京市于2001年2月出台了《北京基本医疗保险规定》。为了配合这一规定的实施，2000年8月，首都信息发展股份有限公司受政府委托，着手开发了北京社会保险信息系统的第一个子系统──医疗保险信息系统（简称北京医保信息系统）。在该系统的开发过程中，首都信息发展股份有限公司(简称首信)采用了微软（中国）公司的Visual Studio.NET开发工具，作为北京医保信息系统中“支付管理子系统”和“医院政策分解子系统”的开发平台。
实际上，在整个北京医保信息系统中，首信最初只承担开发了医院政策分解子系统和支付管理子系统.医院政策分解子系统一方面以动态连接库方式，提供给各定点医疗机构的HIS应用程序调用，依据医保政策进行费用分解; 另一方面负责医院和数据中心的信息传递。
该系统的最大难度是要与形形色色的医院信息管理系统（HIS）连接，在通信中又要解决断点续传、压缩、加密、异步处理等一系列技术问题。支付管理子系统的功能包括费用审核、费用结算、特殊病种、转院等情况的审批及现金报销等。医保系统只有通过支付管理子系统进行医疗费用审核后，才能将报销金额支付给定点医疗机构和各企业。为了实现安全、易于扩展、维护方便等需求，该系统采用了叁层架构的软件模式。
首信社会保险事业部总经理艾建京先生说: “从开发者的角度看，选择开发工具是比较关键的一步。市场上有很多优秀的开发工具，如BEA公司的Tuexdo、IBM公司的WebSphere等，都可以实现医保系统的开发功能，因此都在我们的选择范围之内。其中，也包括Microsoft.NET，但当时并没有特别关注它。为什么是叁层结构？
在系统分析的过程中，首信发现，以下关键点是开发者不得不着重考虑的: 该系统一定要是一个叁层或多层结构的软件系统（即客户层/应用层/数据层），因为北京市共有大小医院5000多家，而实现了数据联网传输的就有近800家。另外目前北京市已加入医疗保险的人数达到600万，如此大的客户端如果采取C/S两层结构，那么中心数据库所承受的压力就会非常大。对此，首信采取的解决办法是，在数据服务器的下端增加了一系列应用服务器，应用服务器的数量可根据日后业务量的变化而增加或减少，“这种做法将有效地缓解中心数据库的压力”。
Microsoft.NET正是基于这种架构思想而设计的。这种架构的好处在于，首先实现了更高的完全性，客户端不直接对数据库进行访问，而只对中间层的应用服务器进行访问，而应用服务器处在医保中心网络防火墙之内，不易受到攻击；另一个好处是减少了维护量，不需要经常对几百家医院的计算机进行维护，只需维护应用服务器层。艾建京解释说：“IBM的WebSphere虽然也是叁层结构，但它是基于Web的访问模式，对我们来说是有一些困难的。
这种模式（CGI）的访问速度相对较慢，每当启动一个问答后线路必须断开，另外这种机制主要针对Internet结构考虑，不允许对本地资源进行过多访问，因此一般情况下无法知道客户端的数量。这样产生的问题是，医保信息卡的POS机安装在各个医院，医保中心需要在医院端进行读卡，而这些工作都需要对本地资源进行访问。”
两个开发难点的解决
此次医疗保险系统的开发，对于艾建京的又一个挑战是，开发时间非常有限，而且编程量非常大，“在这种情况下，选择一个好的开发工具对我们来说尤为重要。”此外，艾建京还认为，一个好的开发工具，必须能够帮助系统实现极高的并发处理能力，“医保中心和社保中心是一个代办机构，每天可能同时或分时接受成百上千个医院的访问。医保系统的特点是月初或月末是业务高峰期，每当这个时间段，几万家企业将同时向数据库传送大量的新参保信息。在这些访问过程中引发的是多事例、多线程管理问题，这是系统开发的又一个难点。
我们选择开发工具必须从这些难点开始考虑。”首信同时分析过Tuexdo、WebSphere、Visual Studio.NET等多种开发工具的利与弊。艾建京认为，Tuexdo是一个非常好的中间件产品，它在许多系统上都得到过成功的应用。但是，在北京医保信息系统项目中，Tuexdo只能在传输上实现负载平衡、多进程、压缩、加密等功能，并不能提供一整套解决方案，而且在对于数据库的访问方面，该软件还存在一些不足。“我们迫切地需要一种从访问数据库到中间层一直到客户层的一揽子解决方案，同时还能够配合操作系统完成并发处理的操作和控制。”首信人如是说。
问题的症结
鉴于在Unix系统所存在的问题，IBM转而引进相对廉价的linux，linux是Unix的衍生系统，该系统大量存在使用古老、低效率的 CGI方式提供Web服务。在医保系统中，兼顾敏感的成本考虑，同时为了改善并发网络访问的速度瓶颈，技术架构上采取了以静态文件为高速缓冲分布到多个服务器上（其中关键的计算机群集实时数据同步等技术除在IBM昂贵硬件、Unix系统上实现外，其他的开源技术由于没有真正得到完整的技术，所以只能用于学习与小规模演示，如果不加大幅改进就实际应用在大规模工程应用中，结果自然会是漏洞百出。
否则也太小看IBM得以雄霸江湖的独门秘技啦。）的技术，让用户能感觉浏览速度的提高，实际对数据库的操作却大幅减少，从根本上说还是不能满足实际的工程技术要求，导致大量的医保数据操作的不同步，甚至要使用软磁盘人工每天在不同医院间来同步数据！后期虽然采用了FTP实现了单位间数据的传输，但实时同步数据的问题依然不能得到很好解决。
由于Unix的性价比在现实中不具备竞争优势，IBM遂利用linux系统以期待用较低的成本换取较高的系统性能，加之开发工具的频繁更替，实际取得的进展似乎不甚理想。导致后期医保系统虽屡次改进，但还是和实际要求的性能差距出入太大，导致医保系统长期不能投入正常的运行，尤其是医院方的抵触较大，导致了很多不必要的医患纠纷。在IBM引进linux这一现象上，不禁使人想起了历史上的OS之争,但愿IBM OS/2的悲剧不要再次重演，否则会应了一句“历史将会惊人地重复 ”那句话了。历经数年实践过Bea、IBM等世界级公司提出的不同技术方案后，经过仔细的权衡，最终首信接受了微软的Visual Studio.NET方案，结束了遗患多年的一块病。
但，随后IBM在系统投入运营后出了个状况，当人们都挤在上面超过200万的时候，IBM的系统瘫痪了！结果，北京的各大医院骂声漫天飞，患者是交了费投了保的一律不知道，要知道这是什么人啊，是北京大小的官员和中央结构的人员啊，首信被弄的灰头土脸，不好惹啊，怎么办？
以前不是坚决打击微软吗？叫你傲气不向IBM老兄知道中国情，想靠技术不进贡？问问BEA公司吧，SUN公司也还是懂事的结果，所有的“盟友”都请遍了，冤枉钱化了不少，计算机的病还是没有解决，搞不定，怎么向领导交代啊，丑丢大了去拉。最后脸一抹，实在没辙，还是很尴尬地找上了微软的门...
原来，故事的发生是这样的...
经过两年的酝酿，北京市于2001年2月出台了《北京基本医疗保险规定》。为了配合这一规定的实施，2000年8月，首都信息发展股份有限公司受政府委托，着手开发了北京社会保险信息系统的第一个子系统──医疗保险信息系统（简称北京医保信息系统）。在该系统的开发过程中，首都信息发展股份有限公司(简称首信)采用了微软（中国）公司的Visual Studio.NET开发工具，作为北京医保信息系统中“支付管理子系统”和“医院政策分解子系统”的开发平台。
实际上，在整个北京医保信息系统中，首信最初只承担开发了医院政策分解子系统和支付管理子系统.医院政策分解子系统一方面以动态连接库方式，提供给各定点医疗机构的HIS应用程序调用，依据医保政策进行费用分解; 另一方面负责医院和数据中心的信息传递。
该系统的最大难度是要与形形色色的医院信息管理系统（HIS）连接，在通信中又要解决断点续传、压缩、加密、异步处理等一系列技术问题。支付管理子系统的功能包括费用审核、费用结算、特殊病种、转院等情况的审批及现金报销等。医保系统只有通过支付管理子系统进行医疗费用审核后，才能将报销金额支付给定点医疗机构和各企业。为了实现安全、易于扩展、维护方便等需求，该系统采用了叁层架构的软件模式。
首信社会保险事业部总经理艾建京先生说: “从开发者的角度看，选择开发工具是比较关键的一步。市场上有很多优秀的开发工具，如BEA公司的Tuexdo、IBM公司的WebSphere等，都可以实现医保系统的开发功能，因此都在我们的选择范围之内。其中，也包括Microsoft.NET，但当时并没有特别关注它。为什么是叁层结构？
在系统分析的过程中，首信发现，以下关键点是开发者不得不着重考虑的: 该系统一定要是一个叁层或多层结构的软件系统（即客户层/应用层/数据层），因为北京市共有大小医院5000多家，而实现了数据联网传输的就有近800家。另外目前北京市已加入医疗保险的人数达到600万，如此大的客户端如果采取C/S两层结构，那么中心数据库所承受的压力就会非常大。对此，首信采取的解决办法是，在数据服务器的下端增加了一系列应用服务器，应用服务器的数量可根据日后业务量的变化而增加或减少，“这种做法将有效地缓解中心数据库的压力”。
Microsoft.NET正是基于这种架构思想而设计的。这种架构的好处在于，首先实现了更高的完全性，客户端不直接对数据库进行访问，而只对中间层的应用服务器进行访问，而应用服务器处在医保中心网络防火墙之内，不易受到攻击；另一个好处是减少了维护量，不需要经常对几百家医院的计算机进行维护，只需维护应用服务器层。艾建京解释说：“IBM的WebSphere虽然也是叁层结构，但它是基于Web的访问模式，对我们来说是有一些困难的。
这种模式（CGI）的访问速度相对较慢，每当启动一个问答后线路必须断开，另外这种机制主要针对Internet结构考虑，不允许对本地资源进行过多访问，因此一般情况下无法知道客户端的数量。这样产生的问题是，医保信息卡的POS机安装在各个医院，医保中心需要在医院端进行读卡，而这些工作都需要对本地资源进行访问。”
两个开发难点的解决
此次医疗保险系统的开发，对于艾建京的又一个挑战是，开发时间非常有限，而且编程量非常大，“在这种情况下，选择一个好的开发工具对我们来说尤为重要。”此外，艾建京还认为，一个好的开发工具，必须能够帮助系统实现极高的并发处理能力，“医保中心和社保中心是一个代办机构，每天可能同时或分时接受成百上千个医院的访问。医保系统的特点是月初或月末是业务高峰期，每当这个时间段，几万家企业将同时向数据库传送大量的新参保信息。在这些访问过程中引发的是多事例、多线程管理问题，这是系统开发的又一个难点。
我们选择开发工具必须从这些难点开始考虑。”首信同时分析过Tuexdo、WebSphere、Visual Studio.NET等多种开发工具的利与弊。艾建京认为，Tuexdo是一个非常好的中间件产品，它在许多系统上都得到过成功的应用。但是，在北京医保信息系统项目中，Tuexdo只能在传输上实现负载平衡、多进程、压缩、加密等功能，并不能提供一整套解决方案，而且在对于数据库的访问方面，该软件还存在一些不足。“我们迫切地需要一种从访问数据库到中间层一直到客户层的一揽子解决方案，同时还能够配合操作系统完成并发处理的操作和控制。”首信人如是说。
问题的症结
鉴于在Unix系统所存在的问题，IBM转而引进相对廉价的linux，linux是Unix的衍生系统，该系统大量存在使用古老、低效率的 CGI方式提供Web服务。在医保系统中，兼顾敏感的成本考虑，同时为了改善并发网络访问的速度瓶颈，技术架构上采取了以静态文件为高速缓冲分布到多个服务器上（其中关键的计算机群集实时数据同步等技术除在IBM昂贵硬件、Unix系统上实现外，其他的开源技术由于没有真正得到完整的技术，所以只能用于学习与小规模演示，如果不加大幅改进就实际应用在大规模工程应用中，结果自然会是漏洞百出。
否则也太小看IBM得以雄霸江湖的独门秘技啦。）的技术，让用户能感觉浏览速度的提高，实际对数据库的操作却大幅减少，从根本上说还是不能满足实际的工程技术要求，导致大量的医保数据操作的不同步，甚至要使用软磁盘人工每天在不同医院间来同步数据！后期虽然采用了FTP实现了单位间数据的传输，但实时同步数据的问题依然不能得到很好解决。
由于Unix的性价比在现实中不具备竞争优势，IBM遂利用linux系统以期待用较低的成本换取较高的系统性能，加之开发工具的频繁更替，实际取得的进展似乎不甚理想。导致后期医保系统虽屡次改进，但还是和实际要求的性能差距出入太大，导致医保系统长期不能投入正常的运行，尤其是医院方的抵触较大，导致了很多不必要的医患纠纷。在IBM引进linux这一现象上，不禁使人想起了历史上的OS之争,但愿IBM OS/2的悲剧不要再次重演，否则会应了一句“历史将会惊人地重复 ”那句话了。历经数年实践过Bea、IBM等世界级公司提出的不同技术方案后，经过仔细的权衡，最终首信接受了微软的Visual Studio.NET方案，结束了遗患多年的一块病。