項目原因：
參與過各種 分布式項目，有 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需要完成的 架構》 中的事情，我可以 完美的 停下自己的業余時間編碼；
>但是，編程作為一種興趣，占據了自己太多的 業余下班時間；我現在很想將更多的業余時間 用到 其他方面；
>於是，本文的設計 並不是 之后編碼的前奏，只是一個思想的備份；本文的設計 我可能 找不到時間 或者 不想 完成了；
>更多的，我想我更願意花點時間 寫幾首情詩，打幾個電話，看幾本書，一切都慢慢來——放下自己有如着魔的編程；