正因为问题的存在，所以我们才知道如何进步。《糟糕的设计》一文中所提到的几个问题都是我曾经和正在处理的。有些已经被解决，有些至今还没有。可能很多人会问，为什么一开始就没有考虑好这些情况呢？记住一句话：罗马不是一天建成的，任何优秀的产品也不是一次就能设计得很完美。
本文主要是分享三个问题，相信对很多用C#.NET开发信息系统的朋友们有帮助。
1）连接问题
1.1 不同协议的两个Web信息系统互传数据的问题
当一个Web系统通过POST方式向另一个Web系统提交数据的时候，出现如下错误信息：
Could not establish trust relationship for the SSL/TLS secure channel.
注意一点，这个错误信息不是每次都能遇到。还有，提交信息的Web系统是HTTP协议，接受信息的Web系统是HTTPS协议。后来经过大家的努力，在网上找了一些资料，终于把这个问题给解决了。解决的方式很简单：添加下面红色框里面的代码就可以了。
具体的情况，可以参考如下两篇网上资料：
A. RemoteCertificateValidationCallback Delegate
B. SSL Encrypted Session with ServerCertificateValidationCallback
由于我们平时习惯在web.config里面设置Web Service的连接超时时间。如下图，此处的300是300 Second.
但是，在负责付费中转的站点（另外一个单独的站点）里面，连接超时长度在代码中被设置为300毫秒（自以为是300 秒），结果导致不时的连接超时异常。而且，这个问题也不是经常可以碰到的。一般情况下，我们作为技术支持与服务工程师的第一反应是问题在网络速度上。无论何种超时异常（可能原因：网络，数据库，事务处理），我们都建议提交请求的一端在Timed Out Exception出现时应该尝试3次。
2）缓存问题
这个问题很奇怪！在几秒钟前我们把数据存进Cache里面，突然间莫名其妙地丢失，导致整个付费流程失败。后来查了一些系统日志，发现IIS中的某一个进程进行了回收操作，所有存储在Cache里面的数据都被清掉。最后，我发现IIS的默认设置是每隔29个小时就会自动回收。为了避免因为Application Pool的自动回收操作导致的问题，我们建议用户修改IIS的Application Pool的设置，采用在固定时间进行回收，例如凌晨2:00。
3）并发问题
这个问题更加的奇怪！一般所说的并发问题，是指多个用户同时操作某一个东西。这里所说的并发问题，是一个用户同一时间多次提交相同的请求信息。例如：首先我在一个站点购买一个产品，然后跳转到第三方去付费。在第三方付完费之后，第三方站点将会“回调”原来站点的某一个界面。按照正常的情况，原来的站点只需要根据传回来的唯一标识码进行处理就可以了。但是，第三方站点不知道出于何种意图，使用相同的信息对同一个界面“回调”了多次，前后两次请求的间隔很短，即第一次请求还没有处理完毕，第二条请求就提交过来，导致创建了两条付费记录。（注：此处的回调是第三方站点通过POST方式提交数据）
很多人的想法是用锁，问题是如何用好这把“锁”。要做到两点：1）支持多个用户同时付费；2）不支持对同一个用户的一个付费记录同时在多个事务中处理。就好比：几个人可以同时在不同的ATM机上取款，但是不支持同一个用户在不同ATM机上同时取款。
后话
从客户将这些问题反馈过来，我们一直用电子邮件交流直到解决，前前后后花了很长的时间。很多时候不是我们不努力，而是很多时候彼此的测试环境不一样。所以，很多问题都没有办法很容易地找到问题的根源。当然，技术能力和经验也是一个很大的因素。不过，有了这种在客户抱怨的压力之下工作的经历，使得我们真正体会到客户和用户的感受 - 他们非常的信任我们这些技术工程师！
