彩信系统结构介绍
彩信系统已经上线2个多月了，虽然上线后也做了比较多的改进，不过基本都是业务层面的变动，结构上还是比较稳定，所以想花点时间总结一下彩信系统结构的问题和以后希望的改进的方向。
现在的彩信系统结构类似于WCF，但是又不同于WCF所以在编写过程中我一直强调他是一个类WCF的东西，因为它确实有部分WCF的特征，但是WCF里面关键的一部分它并没有实现，也就是服务宿主（我叫它对象维持），这个我会在下面的章节中提到。虽然它并不是WCF但是很多WCF特性它也有，比如松耦合，高扩展性，简化开发等。
实际上，如果非严格的讲，现在的结构中服务宿主其实仍然是有的，只是它不再是单独的一个服务器上，而是分散到了前台JS端，也就是对象被维持在了客户（消费者）端。这样做有好处比如减少部署，方便开发，也可以减少服务器压力，但是也有问题，比如“消费者”买的商品仍然来自工厂而非商店，当前的中介只是给了“消费者”工厂的地址而已，当“工厂”改变了一种消费者无法使用的“运输方式”时它的局限性就体现出来了。所以它较适合部署那些需要快速开发简单部署的系统。对于大系统我仍然建议中间层还是必须存在。实际上最初设计此架构时是包含中间对象维持层的，但是因为考虑到我整个系统（包含业务部分）只有1个月的时间，所以放弃了这种部分结构，改由现在较快速开发的架构。
一、 最初的设计
现在的彩信平台所使用的框架其实并非是最初的设计，它进行了部分的妥协，最早的设计系统中还包含一个维持对象的服务，用户（消费者）并非直接访问“工厂”地址来获取“商品”而是通过访问维持对象的服务来获取一个代理对象，对象维持层会为当前“消费者”维持一个代理对象，“消费者”通过访问对象维持层提供的对象来得到真正“工厂”所生产的商品。“消费者”无需关心“工厂”地址（那怕它已经搬迁）也无需关心“工厂”所使用的运输方式（空运海运陆运）自己是不是可以支持，它只需要关心访问对象维持层（商店）即可。无论“工厂”如何改变，“消费者”也只是去商店买东西而已。图1.0.1展示了最初设计时消费者获得商品所需要经过的流程。
图1.0.1
这样的设计显然是有好处的，就像我前面讲的消费者无需关心商品到底是谁来生产，也无需关心工厂到底在那里，物流如何做，他们要做的只是走进商店，拿好商品然后付钱走人。而工厂也不需要关心到底谁会去买他们的商品，又该如何去和那些最终消费者“沟通”，他们要做的只是生产好商品，然后放到商店去卖，两者互不相干。
同样在安全上这样的设计也较好，因为最终消费者并不知道商品是谁生产的，所以工厂的地址可以不必暴露给消费者，消费者知道的也只是商店的地址而已，工厂也只需要为商店敞开大门，防止一些非法的访问。而且权限由商店来管理，工厂不需要去关心最终消费者到底有没有权限访问当前商品，工厂只要关心商店的权限即可。
从开发上讲，开发人员不需要关心任何关联问题，因为每一块都是相对独立的，只需要完成自己所需要开发的功能即可，然后将接口和访问方式发布给中间对象维持层，前台使用的其他开发人员就可以通过访问中间层得到发布的对象。部署时也可将不同的服务发布在不同的服务器中，重用性也会较好的体现。
二、 现有的结构
实际开发中，我并没有用最初的设想结构来开发，因为整个项目包含业务实现必须在1个月内完成，这个就给框架开发带来较大的压力，权衡下我选择了放弃之前设计里中间层部分内容，改由客户端（消费者）来维持对象，这样可以减少开发模块以便缩短开发周期。
现在的设计中，消费者会首先向“咨询站”询问“工厂”的位置和沟通方式（就好比你打12580的指路服务问他在那里以及如何去），“咨询站”会将这些信息发送给“消费者”，然后消费者会通过获得的“工厂”信息直接去访问“工厂”来获得“商品”。而工厂任何的变化，只需要通知“咨询站”更新他的资料库来方便消费者查询即可。“消费者”无需关心“工厂”的变化，因为“消费者”所有的资讯都来自于“咨询站”而已。“咨询站”保证了“消费者”获得的“工厂”信息是最新的可用的。图2.0.1就是一个现有架构上典型的“商品”购买过程。
图2.0.1
同样和最初设计的一样，“消费者”不需要关心“工厂”的信息，他只需要记住自己要的商品名称，然后询问“咨询站”他会告诉“消费者”那里有你要的商品以及如何去。工厂的任何变化，或者“商品”改成了其他的“工厂”来生产，都不会影响流程，这个时候只需要通知“咨询站”刷新商品对应“工厂”信息即可，而对于“消费者”什么都不会受到什么影响（除非他们改变了访问方式或接口）。
在开发中开发人员也不需要关心不属于自己模块中的关联问题，同上面的设计一样，开发人员将自己开发完成功能模块（商品）发布给“咨询站”让他去通知消费者即可。前端开发人员也只需要通过“咨询站”给的信息得到数据（商品）。而对于部署同样可以将“咨询站”，“工厂”和“消费者”分别部署在不同的服务器上（当然因为最新浏览器为了安全都禁止跨Dom访问所以可能需要将服务地址加入信任站点这个是后话）。
实际开发中框架提供了一个Web Service服务这个服务维持了一个服务容器，服务容器里放着从配置文件中读取的所有业务服务的位置（生产商品的“工厂”位置），客户端需要数据时会首先访问这个服务，将服务名称传入后会返回这个名称对应的服务信息（包括这个服务提供的所有方法），客户端得到这些信息后在JS端通过获得的信息创建一个代理对象，代理对象中的方法是直接指向最终“工厂”生产的“商品”位置的（这也是和最初设计有所不同的地方），消费者只需要在JS中调用代理对象里包含的相应的方法即可获得所需要的数据。
通过现在的方法和最初设计时的设想比较，会发现这个方法基本实现了每一层相对独立的松耦合设计，对于开发也提供了较方便的接口，业务变动对系统稳定性的影响也减到了较低的位置，以最简单的方式实现了最初设计时考虑的绝大部分内容。
但是他所带来的问题也是显然意见的，首当其冲的就是访问方法，现在的系统因为所有的服务提供的访问方法都是Web Service，在开发中因为有这样的优势所以就可以不用考虑其他的方法（如：TCP直连，Remoting等）当用户使用了一种客户端（JS端）无法支持的方法作为数据通路时，这个方法就无能为力了（当然也可以解决，方法是提供一个转接的服务）。而前一种方法因为客户端都是通过访问“商店”获得数据，“商店”的地址和连接方式是确定的如何去和工厂连接也是商店的事情和客户端无关。
接着安全方面也会需要较多的考虑，前一种方法因为“工厂”只对“商店”敞开大门，所以对于它而言无需关心“消费者”的权限，而现在的方法因为消费者是直接访问“工厂”来获得数据，工厂就不得不考虑安全问题。其实这个问题我之前考虑过，原本的设想是通过一个登录服务获取登录凭证，“工厂”必须实现一个凭证获取的服务来获取登录凭证，然后“咨询站”会将登录凭证发送给“工厂”，每次用户获取数据时会将自己的凭证发送给“工厂”来验证，但是因为有很多现有服务需要兼容（需要修改他们并实现一个登录验证，这个是很麻烦的一件事情）而登录模块最终也不是由我来编写所以并没有完成实现。
现有的框架结构虽然不是相当的优秀，而且还会带来很多问题，但是对于现有的彩信管理系统而言我觉得是已经相当足够了，在我看来这个框架比较适合那些需要快速部署的小型系统或站点，他提供了一个相对便捷的解决方案，无论是开发部署都比那些现成的WCF框架方便简单，而对于开发人员同样可以享受到较复杂架构所带来的便利和优势。
彩信系统现在还在业务部门不断的适用中，在不断的运行中我相信应该还会不断的暴露出其他的问题，今天我总结了一下现在框架的结构和可能遇到的问题，在以后的框架设计中我也会尽力避免这些问题，提供一个更好的设计。