项目原因：

参与过各种 分布式项目，有 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需要完成的 架构》  中的事情，我可以 完美的 停下自己的业余时间编码；

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

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

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

SOA分布式架构设计

文件状态： [√] 草稿 [  ] 正式发布 [  ] 正在修改	申明:	此文章为原创文章，只供交流，转载请注明出处谢谢o(∩_∩)o
	当前版本：	V1.0
	作    者：	吴蒋
	完成日期：	2012-2-28

 

目录

0.1 文档目的... 4

0.2 文档范围... 4

0.3 读者对象... 4

0.4 参考文献... 4

0.5 术语与缩写解释... 4

1. 系统概述... 5

2. 设计约束... 5

3. 设计策略... 5

4. 设计详细... 5

5. 设计对应项目的解决方案描述... 8

6. 开发环境的配置... 9

7. 运行环境的配置... 10

8. 测试环境的配置... 10

9. 其他... 10

0. 文档介绍

0.1 文档目的

本文档表述了平台SOA的分布式架构设计，并通过使用多种视图以及模拟项目运营中所需要的解决流量，资源负载的各个主要方面的解决方案，以满足系统的开发需求和文档备案。本文档记录并表述了系统架构的设计人员对系统架构方面做出的重要决策。

开发人员将根据架构定义的构件制定项目的开发过程。另外本文档还使用于指导各构件的实施、集成及测试。

0.2 文档范围

本软件架构说明文档适合总体应用架构。

0.3 读者对象

本文档的预期阅读人员为项目经理、程序设计人员、测试人员和其他有关的工作人员。

0.4 参考文献

无

0.5 术语与缩写解释

缩写、术语	解 释
SOA	服务
js	javascript
WCF	Windows   communication fundation

1. 系统概述

本文档主要说明项目在分布式中的处理解决方案，以及数据库以及文档的存储问题。

2. 设计约束

本文并未涉及到具体的代码实现，所以并无设计约束，如有特殊文内标识。

3. 设计策略

1.设计在大流量的时候的分布式处理

2.保全访问数据的同步性和完成性

3.保全在分布式通信中的安全性

4. 设计详细

由于分布式架构比较抽象所以使用图文加说明的形式来阐述设计，首先看网络架构设计总图4-1-1: 

图 4-1-1 网络分布式部署概要图

以下对上图进行说明，使架构有一个总体的了解。此文段后会对上图的每个部分进行拆分，并进行具体的部署说明以及在运行和软件编程方面进行可行性解决方案说明。本文将整个部署分为服务器调用端(如WEB、手机调用服务端、平板调用服务端等等)、SOA端(提供SOA服务给服务器调用端使用，主要基于SOAP的工业标准，实现跨平台使用)、数据库群集(数据库以及系统级配置文件的存放)、以及服务总线集群(服务总线是处理分布式调配以及处理特殊缓存的服务、以及上传资源的存放)4大块。

现在来模拟流程:

Step1： 服务调用端启动情景

一、         数据库端部署完成，正常启动。

二、         SOA端部署完成，正常启动，从数据库集群获取SOA端和数据库集群的配置文

件并缓存(比如查询当前的SOA服务器对应的数据库提供的表的IP地址)，正常提供服务。

三、         服务总线部署完成，正常启动，从数据库集群获取服务调用端的配置文件并进  

行缓存，总线服务正常提供。

四、         服务调用端项目第一次启动:

1. 发送启动信息至服务总线，通知服务总线本服务端需要提供服务。
2. 服务总线接受到该请求后获取发送端(服务调用端)的IP地址、以及域名、以及使用权限(即付费提供服务功能)，于在服务总线启动时从数据库获取的配置数据进行匹对验证、判定并返回给服务调用端信息(包括是否可访问SOA端，如果验证合法记录日志以及返回被调配到的SOA端的地址，供其调用以此来解决SOA端的负载均衡)。

Step2： 服务调用端启动之后情景

一、         客户端在服务调用端进行操作。

二、         服务调用端根据第一次从服务总线分配的SOA的IP进行对服务的调用和通信。       

（对于服务的部署和开发使用WCF框架来解决，发布地址例如为http://www.XXX.com/adminservice.SVC的服务提供调用）。

    下图4-1-2 是对到此端访问情景的画述:

图4-1-2 服务调用端调用SOA段概述图

三、         接下来表述SOA服务端和数据库的分布式处理。

分布式数据库的分布方式主要是以根据表的操作频率和访问流量来处理分

（例如:资讯表的访问流量非常的大就让这张表分离出来放在一台服务器上进行单独处理，再如若还无法处理流畅运行就进行读写分离处理，办法可查阅http://www.cnblogs.com/daizhj/archive/2010/06/21/dbsnap_master_slave_database.html）。

具体流程见下图:

图 4-1-3 SOA端调用数据库流程图

             可以看到在SOA端第一次启动的时候，会向系统配置数据库获取所有的对应当前SOA服务端IP地址对应的数据库表分布地址缓存在内存中，之后每次的调用数据库表的操作都将通过这些配置的信息获取操作对象。

5. 设计对应项目的解决方案描述

l  SOA服务端

以下是SOA服务端在程序中的主要结构图:

图:5-1-1

其中的.svc是服务文件就是我们对外开放的服务。以下是部署在192.168.0.71上的服务截，当然还可以部署到更多的服务器上实现分布式。图为开发服务情况以及调用的方法示例，该服务是以soap进行通讯的。

图：5-1-2

注意事项:在SOA服务端将不存放太多的缓存，只在Application_Start时候缓存一下数据库表分布配置的数据，以及允许访问的IP以及权限，系统级配置数据。

l  服务总线

以下是服务总线在程序中的主要结构图:

Upload文件夹用以同步用户上传的文件，路径为Upload->1->img

6. 开发环境的配置

类别	标准配置	最低配置
计算机硬件
软件
网络通信
其他

7. 运行环境的配置

类别	标准配置	最低配置
计算机硬件
软件
网络通信
其他

8. 测试环境的配置

9. 其他