背景：日前公司需要将客户企业站增加在线升级功能。即客户登录自身网站管理后台后台，发生请求到我公司门户网站，如果存在新版本则提示用户更新。客户从我们公司买到的空间、数据库、和网站代码后可以直接根据智能提示完成webconfig配置，后期客户可以从我们手中购买网站模版实现个性化风格主题的网站设置。我们所有客户的网站结构是一模一样的。因为前台客户浏览的页面均为代码自动生成的静态页，所以更新过程不影响访客浏览。
分析：BS架构项目不同与CS架构——通过请求检测版本更新后返回更新包，根据本地安装目录即可完成覆盖更新，我姑且称之为“服务器与客户端的一次往返通信”。BS架构下网站更新实际完成操作是：将资源所在服务器（我公司的服务器）的安装包发送到客户服务器上，实现覆盖更新，我称之为“服务器与服务器之间的通信”。
过程总结：
起初对于这个课题，我想了个投机取巧的方法。
（1）虚拟目录
网站更新的前提是 我们知道自身资源包（bin文件夹和web页面文件夹）所在的位置，同时也知道客户网站下的安装目录。直接在客户服务器上映射一个虚拟目录，将多个网站指向同一目录下，即可实现一次网站发布便间接更新所有网站。这样的方法无疑是非常致命的，且不说客户的网站是否都在同一台服务器上，单是一个主程序崩盘便能导致所有客户网站瘫痪。
其次，从实际出发，我想到三个解决方案。
（2）File本地物理文件操作法
如果客户服务器与我们的服务器在同一台电脑上，那么网站更新的实质就是把bin文件夹从我们网站的目录下挪到客户网站目录下，进行覆盖。这样的批量复制文件的方法从理论和技术上是可行的。值得一提的是你要具备目标文件夹的读写权限。然而它也有致命的缺陷，即客户服务器和我们的服务器不在同一主机上，我们将无能为力。
（3）FTP上传方法。
用户发送包含自身标识信息的升级请求到我们的服务器，我们解析识别后通过FTP方式静默发送到客户服务器，实现覆盖升级。这里需要考虑的问题是获取用户的FTP信息，这里通过各位看官的需求进行取舍。但这条方式没有被聂总采纳，原因是，部分客户网站选择了托管的方式，其网站没有被分配FTP。
（4）WebService和WCF
通过安装web服务，进行物理文件的传输，因为每次升级的资源文件在三十兆以内，所以理论上不需要考虑大文件传输带来的宽度占用或者文件丢失等隐患。
然而通过实际操作得出每个dll文件传递平均用时2-6分钟，因为目前客户服务器和我们的服务器在同一台主机上，所以此解决方案占用了相当大的带宽。从本日18时开始网站更新，至次日九点为止，bin文件夹未全部成功传输。其中部分文件传递报错”web服务请求超时”
课题延伸：
经过切实讨论和需求分析，从功能可移植性和易用性角度出发，决定采用web服务传输物理文件解决网站升级问题。
注意事项：
1. 更新有两种，一个是更新文件，一个是更新数据库，建立两个xml的文件，一个存文件更新的内容，一个存的是数据库更新的内容。
2.保存数据库更新的xml文件，由开发者手写ＳＱＬ语句，客户下载后由程序提取，直接后台运行。从而对数据库结构或者数据库记录进行增、删、改操作。
3.保存文件更新的xml文件，包括：文件名称、文件路径、版本号、目标路径等信息。
4、鉴于“每次更新的文件可能是一个也可能是多个”，所以客户端调用Web服务接口是需要传他本地文件版本配置列表，通过对比网上的，看看有没有需要更新的文件
Web服务中包含的方法：
1.判断是否有更新的方法
2.获取更新文件的方法（传递文件更新列表的方法）
3.需要有一个重新传送失败文件的方法
4.记录文件信息以及传输(接收)文件情况的Log日志的方法
重要问题：
同一台主机上使用web服务传输会占用大量带宽，对于211.90.16.**服务器网络环境有一定要求要求，现阶段此服务器FTP上传速度基本处于停滞状态，且经过测试www.soft***.com和www.our***.com两台服务器之间每个.dll文件通过Web服务传输时间约为2-6分钟，有鉴于此，需要改善此服务器网络环境。
欢迎留言评论，共同进步。允许转载，请标明原地址http://www.cnblogs.com/happyxiaoyao/p/3921208.html
技术交流群：165609857