正因为问题的存在,所以我们才知道如何进步。《糟糕的设计》一文中所提到的几个问题都是我曾经和正在处理的。有些已经被解决,有些至今还没有。可能很多人会问,为什么一开始就没有考虑好这些情况呢?记住一句话:罗马不是一天建成的,任何优秀的产品也不是一次就能设计得很完美。

本文主要是分享三个问题,相信对很多用C#.NET开发信息系统的朋友们有帮助。

1)连接问题

1.1 不同协议的两个Web信息系统互传数据的问题

当一个Web系统通过POST方式向另一个Web系统提交数据的时候,出现如下错误信息:

Could not establish trust relationship for the SSL/TLS secure channel.

注意一点,这个错误信息不是每次都能遇到。还有,提交信息的Web系统是HTTP协议,接受信息的Web系统是HTTPS协议。后来经过大家的努力,在网上找了一些资料,终于把这个问题给解决了。解决的方式很简单:添加下面红色框里面的代码就可以了。

image

具体的情况,可以参考如下两篇网上资料:

A. RemoteCertificateValidationCallback Delegate

B. SSL Encrypted Session with ServerCertificateValidationCallback


1.2 WebService的超时异常

由于我们平时习惯在web.config里面设置Web Service的连接超时时间。如下图,此处的300是300 Second.

image

但是,在负责付费中转的站点(另外一个单独的站点)里面,连接超时长度在代码中被设置为300毫秒(自以为是300 秒),结果导致不时的连接超时异常。而且,这个问题也不是经常可以碰到的。一般情况下,我们作为技术支持与服务工程师的第一反应是问题在网络速度上。无论何种超时异常(可能原因:网络,数据库,事务处理),我们都建议提交请求的一端在Timed Out Exception出现时应该尝试3次。

image

2)缓存问题

这个问题很奇怪!在几秒钟前我们把数据存进Cache里面,突然间莫名其妙地丢失,导致整个付费流程失败。后来查了一些系统日志,发现IIS中的某一个进程进行了回收操作,所有存储在Cache里面的数据都被清掉。最后,我发现IIS的默认设置是每隔29个小时就会自动回收。为了避免因为Application Pool的自动回收操作导致的问题,我们建议用户修改IIS的Application Pool的设置,采用在固定时间进行回收,例如凌晨2:00。

image

image 

image

3)并发问题

 这个问题更加的奇怪!一般所说的并发问题,是指多个用户同时操作某一个东西。这里所说的并发问题,是一个用户同一时间多次提交相同的请求信息。例如:首先我在一个站点购买一个产品,然后跳转到第三方去付费。在第三方付完费之后,第三方站点将会“回调”原来站点的某一个界面。按照正常的情况,原来的站点只需要根据传回来的唯一标识码进行处理就可以了。但是,第三方站点不知道出于何种意图,使用相同的信息对同一个界面“回调”了多次,前后两次请求的间隔很短,即第一次请求还没有处理完毕,第二条请求就提交过来,导致创建了两条付费记录。(注:此处的回调是第三方站点通过POST方式提交数据)

很多人的想法是用锁,问题是如何用好这把“锁”。要做到两点:1)支持多个用户同时付费;2)不支持对同一个用户的一个付费记录同时在多个事务中处理。就好比:几个人可以同时在不同的ATM机上取款,但是不支持同一个用户在不同ATM机上同时取款。

image

后话

从客户将这些问题反馈过来,我们一直用电子邮件交流直到解决,前前后后花了很长的时间。很多时候不是我们不努力,而是很多时候彼此的测试环境不一样。所以,很多问题都没有办法很容易地找到问题的根源。当然,技术能力和经验也是一个很大的因素。不过,有了这种在客户抱怨的压力之下工作的经历,使得我们真正体会到客户和用户的感受 - 他们非常的信任我们这些技术工程师!