WCF从理论到实践(15):响应变化

本文目的

需求变化是软件开发过程中的一大难题，我们经常扼腕叹息：面对变化，我们的软件为何如此不堪一击？我们常常在众多需求变化导致的功能爆炸中疲于奔命，甚至迷失自我！这到底为什么？面对"拥抱变化"这种得呐喊，我们的感受应该是震耳欲聋，还是振聋发聩？如果你仍在困惑，可以来看一看WCF是如何摆脱这种困境的！

序幕

小王效力于北京的一家系统集成公司，该公司内部有一个WCF服务为各个部门所共用，小王便是WCF服务的开发和维护人员。起初大家在一个办公楼工作，共用一个局域网，WCF运行的非常好，小王也因此获得了公司上下的一致好评。此时他们的WCF的使用状态如下图所示：

起初小王以为公司都在一个局域网之中，考虑到性能，WCF最早采用的是NetTcpBinding的绑定方式，契约部分是根据自己的业务需要开发的， 而他为服务公布的最早的地址为：net.tcp://127.0.0.1:6547/Service。他最早是用代码方式将服务托管到一个Console程序中的，托管代码如下：

ServiceHost host = new ServiceHost(typeof(ServiceLib.Service)); 

NetTcpBinding bind = new NetTcpBinding(); 

Uri address = new Uri("net.tcp://127.0.0.1:6547/Service"); 

host.AddServiceEndpoint(typeof(Contracts.IService), bind, address); 

而此时大家所使用的客户端代码均为： 


NetTcpBinding bind = new NetTcpBinding(); 

EndpointAddress address = new EndpointAddress("net.tcp://127.0.0.1:6547/Service"); 

Proxys.IService ws = new Proxys.ServiceClient(bind, address); 

这样一种情况下，小王的WCF服务与各个部门之间可谓是其乐融融。可好景不长。各位看官，请看下文：

使用范围扩大

随着近几年公司业务的持续发展，公司在唐山的业务量非常大，所以在唐山成立了一个办事处，而该办事处同样需要使用小王的WCF服务，可原本出乎小王意料的事情发生了：唐山办事处和公司总部处于不同的网络，如果还使用tcp这种传输方式，就不适用了。公司头们为这事也挺犯愁，本来以为还要劳烦小王大改一通，没想到小王却说："小意思，马上解决问题！"他首先和公司网络管理人员联系，将WCF服务所在主机配置１个公网IP为202.120.120.3,然后再托管程序的代码中增加几行

BasicHttpBinding bind = new BasicHttpBinding(); 

Uri address = new Uri("http:// 202.120.120.3:80/Service"); 

host.AddServiceEndpoint(typeof(Contracts.IService), bind, address); 

然后将客户端程序场景中的代码修改如下：

BasicHttpBinding bind = new BasicHttpBinding(); 

EndpointAddress address = new EndpointAddress("http:// 202.120.120.3:80/Service"); 

Proxys.IService ws = new Proxys.ServiceClient(bind, address); 

然后将托管程序重新发布了一下。而将修改之后的客户端部署到办事处一台服务器上面，经过测试，新的客户端运行正常，而总部那些客户端也没受任何影响。由此可见，双方相安无事，小王也松了一口气，原本另大家比较头疼的变化问题便迎刃而解了。下面是使用范围变化之后，WCF服务与客户端的工作情况：


停电了，殃及池鱼

昨天请假了，今天兴致勃勃来上班，没想到刚来，却被经理劈头盖脸的数落了一顿:" 昨天停电，来电后，你的服务没有启动，打你电话也不接，下次注意亚！"，小王抓抓了头皮，不好意思的笑笑说："好，我马上想办法，防止出现类似问题"，回到座位上，小王就想到了用iis来替代console作宿主，这样机器重新启动后，服务便会自动加载，可转念一想，不对，iis支持http的访问方式，而且基地址必须和服务所在网站地址一致，我们局域网内部采用的是tcp，排除了iis，小王很快就想到了windows service，恩，就它了。所以问题也便成了下图所示的情形：

经过查证，小王先弄明白了下面的原理：

不仅如此，在不同宿主中寄宿的方法也一致：都是采用ServiceHost来进行托管。知道上面的知识，小王将原本Console宿主中 的托管代码拷贝到Windows服务的代码中，只不过，Console中托管代码写在Main方法，而Windows Service写在OnStart方法中。

秀才遇见兵

原本只是公司内部使用的WCF服务，前段时间也开放给了公司的几个大的合作商，和他们的平台作整合，前几家，合作的非常好，小王正津津乐道之时，却遇到了一个刺头，他是公司一个非常重要的合作商，但要求也非常特殊，服务中原本有个数据契约，用于描述公司订单，契约的定义如下：

旧版本数据协定

而且其他的合作商，对此都没有任何的异议，小王将代理已经发出去10几家了，可现在遇到这位要求必须再上面的基础上再提供订单的创建时间，小王打电话过去，和他解释："目前我们的系统已经被很多厂商使用，而且别人的代理目前也运行的很好，你的这个需求是正确的，但我们如果修改数据契约会影响其它客户端的使用，请理解"，本以为自己苦口婆心的解释，人家会买账，谁想，对方根本不听解释，一个劲地说："这是我们的需求，必须的，必须的！"。气得小王直想摔电话。可"用户是上帝，胳膊扭不过大腿么"，后来一高人指点道："WCF在设计的时候已经考虑到了版本管理的问题，这种问题已经非常容易解决，你可以用IExtensibleDataObject"，经查阅还真有此类问题的解决方案，小王将上面的契约代码更改如下：

新版本数据协定

然后新生成一个代理，发给了***蛮用户，而其他客户的代理版本却不用任何变动。新的用户的代理运行和很正常，而老的也很正常，真爽！小王此时方体会到WCF的强大之处。

凡是符合下面的变动情形的，均可视为非重大更改：

  1. 更改成员名称，且将DataMemberAttribute的Name属性和旧版本保持一致
  2. 大多数添加和移除数据成员的操作
  3. 将成员的特性IsRequired从True更改为False
  4. 实现IExtensibleDataObject接口
  5. 更改枚举成员名称，但用EnumMemberAttribute将协定名称和老版本保持一致
  6. 大多数数据集合的更改

服务也会累么？

问题是一个接一个，解决完上面的几个问题没多长时间，这个WCF又有新问题了，现在客户端越来越多，很多客户反映，最近服务端很不稳定，有时还连接不上去，小王检察了半天业务代码，发现没有问题，而且之前人数少得时候，运行的挺好的亚，此时他经过仔细的查阅，终于找到了一些用的信息：WCF为了改善性能，是有限流（Throttling）措施的。主要包括三种

  1. maxConcurrentCalls ：最大并发数，默认为16
  2. maxConcurrentSessions ：最大的会话数，主要针对于PerSession的情况，默认为10
  3. maxConcurrentInstances：最大实例数，默认为Int.MaxValue

默认的设置比较保守，最大并发数仅为16，非常容易造成排队或者超时现象。修改或者添加限流也非常简单，只需要在服务的配置中修改或者增加ServiceBehavior中的

<serviceThrottling maxConcurrentCalls="16" maxConcurrentSessions="10" />

 

后记

拥抱变化，拥抱变化，我们口号喊得非常响亮，可为什么面对变化的时候，我们有时会暴跳如雷呢？一边骂客户bt,一边还要通宵达旦的加班来完成工作呢？问题的原因不在于用户，不在于变化本身，更多的是我们一味的将一堆垃圾改造成另外一堆垃圾，要想真正解决问题，做好架构，做好基础是关键。我们常常因为时间，人力等因素，刹不住车似的的制造garbage，却忘记了什么叫细节，什么叫品质。无论针对产品还是市场，当前更重视不是你做了多少，而是做了多少有意义的事情，多少别人没有做过或者做不了的事情。品质，细节，ThinkPad，Google。总之我会毫不犹豫地转向WCF，因为它有品，也更能适应变化

posted @ 2008-04-16 17:59  Robin Zhang  阅读(7363)  评论(25)  编辑  收藏  举报