所谓换个思路开发站群系统,那就是和传统的站群套路不一样—— 传统的站群功能此处不赘述,它有个最要命的问题是:所有子站点都是“一锅烩”,你想把某个子站点单独剥离出来,那是不可能的。 数据库共用一个大库、uploadfile等附件文件夹也往往都在一起混着。更要命的是某个子站点如果需要独立开发一些辅助功能,那更是比较麻烦。 为了解决上述痛点,我换了一个思路花了3天时间开发站群系统的雏形。 1、服务端开发 服务端是一个exe程序,如下图所示:
服务器端的管理程序
这个程序(即可WEB请求也可以界面操作)可以一键完成以下流程: 1、创建用户文件夹 2、创建windows系统用户,并授予这个文件夹所有权 3、复制Web网站程序(CMS)到这个文件夹 4、创建IIS站点,并将IIS站点路径指向到这个文件夹,并发布 5、创建FTP账号,并将所有权指向到这个文件夹
程序创建的用户文件夹
程序创建的IIS站点
程序创建的FTP服务
到这里您可能发现我们的站群和传统的站群有着本质的区别: 1、我们的站群里的每个站点都是相对独立的。如果用户觉得上面第3步,我们提供的Web网站程序不好用,甚至可以自己通过FTP上传一个自己中意的CMS,或者技术人员独立设计某个站点,而不会影响其他子站点。 2、每个站点数据也是相对独立的,互相之间没有物理联系,各自的uploadfile也相对独立,如果后期想脱离站群,数据很容易转移。
懂行的朋友看到这里就明白了,这就是一套“虚拟主机管理系统”,通过虚机系统开了多个网站而已,似乎和站群还有些距离。 其实站群的核心功能就是——“子站点之间的数据交换”: 如果都是独立站点,确实不是站群。子站点之间的数据通信主要有三个方面: A、站内搜索(既能搜子站也能搜全站) B、用户中心(用户在任意子站点注册后,全局应同步) C、超级管理员对子站点的启停、超级登录、超级维护等功能。
这一点得益于CMS系统是我们自己开发并维护多年的程序,在源程序的技术上增加了一套API使各个子站点之间可以平行通信,进行数据交换。
CMS用户端独立后台程序
题外话:我的CMS始于1999年,不开源,维护了20多年也为我赚大几百万了吧。那天大概算了下,这么多年装机量累计也有上万个网站了。全手写先有的asp版,陆续写了php版、java版、Python没完成,近五六年主力版本停留在C#版上,其他不维护了,老了折腾不动了。
截至目前,这套与众不同且非常灵活的站群系统已经开发完毕,各位觉得比起传统的一整套程序那种“大锅烩”的站群,是不是先进了不少?
我还为用户管理员准备了维护后台,和虚拟主机管理系统一样,支持FTP登录、备份内容、重启IIS、绑定域名等服务。 也为服务商提供了收费、到期管理、开通停止站点等运营后台。
用户端维护入口
源码片段
这个由虚拟主机系统构建的站群服务,我暂时命名为“分布式站群系统”,工作已经完成70%多,其实也没啥心情往下做了。 业务已经想通,就等着哪天接个单子把它继续做完吧。
先解密几个问题: 1、为啥服务端要用exe程序:因为这个程序要操作IIS、FTP和windows文件夹和windows用户组,尤其是操作iis(启停操作),如果做成web端,iis一旦停止web控制端也就短线了,所以用其他服务器的web去请求这个exe,然后exe去操作iis。这就是被控端服务,我只不过在被控端服务上又加了一套UI,方便管理员上服务器通过UI也能添加删除站点。 2、为啥要生成windows用户:这个基于网络安全考虑,创建好文件夹以后,给这个文件夹赋予生成的这个用户权限,其他权限都去掉; 好处是万一这个网站有漏洞,黑客攻击也仅限于这个文件夹内,无法翻墙去攻击别的文件夹网站。 3、虚拟主机管理系统:这是一个古老的技术,但目前仍然拥有大量用户(并不是所有用户都需要云服务器),当然了就算你买了云服务器,放了多个网站,基于安全隔离的目的,也建议使用虚拟主机的原理进行站点管理。一个漏洞点端了整个服务器几百个网站的例子太多了,不然源码下载站哪儿来的那么多源码? 言归正传:虚拟主机技术的核心就是通过程序操作windows的api,集中管理iis ftp windows用户和文件夹权限。 说难不难,说简单坑还真不少。 4、为啥最后我停留在c#上了:因为我大多数做的都是windows应用开发,或信息化开发;科学计算类的工作很少。 c#对于windows应用开发简直太香了,自从windows98以后微软提供了WMI协议,开发人员就可以利用这个协议进行一切windows的底层操作,以目前微软提供的各种接口而言,你徒手开发一个windows或office外壳一点问题都没。而别的语言做业务没问题,但要操作windows就没c#那么舒服了。 咱们什么时候才有的前后端分离的概念? 所以啊有时候我觉得思想上的差距才是真的差距。
各位同行道友,还有啥建议欢迎聊聊啊
|