『设计』Slithice 分布式架构设计-支持一体式开发，分布式发布

项目原因：

参与过各种 分布式项目，有 Socket，Remoting，WCF，当然还有最常用的可以跨平台的 WebService。

 

分布式编码的时间浪费：

但是，无一例外的，开发分布式程序的开发遵循 如下规律：

>那就是 得先写服务端代码；

>然后 通过工具生成代理类；（特别浪费时间）

>客户端代码 调用代理类 完成业务；

 

这种编码规律，就有一个问题：

那就是 当我们调试程序时，得先以调试模式启动服务端，再以调试模式启动客户端——然后在调试中找到代码的BUG。 这种调试方式 调试一次 需要 5-10分钟（太浪费时间）；

如果 服务端是 基于 WinService 的话，过程就更麻烦：你得先卸载已经安装的WinService，再安装新的WinService，然后 附加进程，再以调试模式启动客户端。这种调试方式 调试一次 需要 10-15分钟（更浪费时间）

 

于是，针对调试时间的浪费，就有了 一体式开发，分布式发布 的设计（直接右键 调试，就能找到 服务端，客户端 两者的 BUG，最终发布时，只要将编译的程序集 丢到 服务端的目录下，就能直接实现功能）——这种调试方式 调试一次 只需要 0.5-1分钟。

 

分布式通常解决的问题：

>分布式用于解决：让多台机器同时办事，三个臭皮匠，顶个诸葛亮——以实现运行速度的最快速；

>分布式的稳定：当分布式中，一台机器宕机，其他机器依然办事——不会因一台服务器的问题 而影响整个程序的稳定；

但是，如果有如下意外：

>写好的分布式程序，本来用的是 WinService 的 WCF 做服务端，但是最后客户 买不起服务器，只能买个空间——于是我们得将 WinService 改成 WebService，得费多少人力物力；

>分布式中，两台服务器 做同一个事情，调度均衡 也是一个问题：你得让 高配置的服务器多做事，配置低的服务器少做事；少出错的服务器多做事，多处错的服务器少做事——这种调度均衡 恐怕 非专业人士 还得费一番脑经吧；

 

于是，就想  能不能有一种设计：

>一体式开发 分布式发布 的节省编码时间；

>已经编译的程序集 可以轻易丢到 任何类型的 服务端宿主下，随意更换 Socket，Remoting，WCF，WebService；

>而且实现调度均衡，平衡利用服务器资源；

 

设计过程：

>本设计其实在 之前的文章  《『架构』2013需要完成的 架构》 中，有过记录；

>而实际编码 从 2013-02 开始，但是断断续续时间一直并不充分，没有更多业余时间；

>目前的过程，仅停留在 现行Demo阶段（2013-05月左右完成）：实现主要功能，忽略所有细节；

 

相关手稿 和 设计图：

 

 

 

 

 

关于设计图：

>其中，我们看到 客户端>Slithice调度模块>服务端>Action插件调度类；

>于是，我们 基于 Slithice 的内核，只需要实现 插件 就行；

>调试的时候，我们 不用 走 如上的线路，我们只需要  客户端>Action插件调度类； 于是就能轻易实现 一体式开发；发布的时候，将编译程序集 丢到服务端目录，就能实现 分布式发布；

 

 

先行Demo 和 正在进行的整合版：

先行版 的 内核功能已经基本实现：实现核心功能，完成理想主义的运行；

整合版 却还在 编码过程中：实现细节，开始适应各种实际情况，且 还需要一个 集群配置器 的UI界面；

 

最后的简结：

>参与大大小小各种项目；公司的，学校的，个人的；已经五年了；

>当初觉得很难的技术，在今天看来 都不过如此；新的技术总在前方；

>各种项目，各种问题，各种思考，各种灵感 —— 有如泉涌的灵感 在这五年，总是接踵而至；

>五年了，没有自己实现不了的功能；没有自己学不会的技术；没有自己写不了的算法；没有自己攻克不了的技术攻关；

>但这些  功能，技术，算法，技术攻关 也是 无尽的；

>我以为 完成了  《『架构』2013需要完成的 架构》  中的事情，我可以 完美的 停下自己的业务时间编码；

>但是，编程作为一种兴趣，占据了自己太多的 业余下班时间；我现在很想将更多的业余时间 用到 其他方面；

>于是，本文的设计 并不是 之后编码的前奏，只是一个思想的备份；本文的设计 我可能 找不到时间 或者 不想 完成了；

>更多的，我想我更愿意花点时间 写几首情诗，打几个电话，看几本书，一切都慢慢来——放下自己有如着魔的编程；