-
分布式系统的部署
平常我们都说三层架构，我认为它是一个广义的模型，更多层的设计可以合并相邻几层的方式最终回归到三层这个宽泛的概念上来，我的意思是：这些都只是概念，忘记这些概念去实际分析设计会离这些概念更近一些。
接下来我要把三层变的更简单点，两层，数据访问层合并到业务层，统称为业务层，因为我们面对的问题不是分层的问题，而是分布式系统中各层应该怎么部署的问题。在CSLA.NET书中也说到业务层和数据访问层放到同一台机器上可以提高性能和容错性。因此他们俩的合并不影响分布式系统的部署。
不过要解释的是数据库系统（CSLA.NET中说的数据存储和管理层）并没有考虑到三层中来，也就是它不包含在数据访问层中，如果把它算进来，那么它是在数据访问层之下单独存在的。
综上，在分布式系统部署角度考虑的分层实际是三层：界面层、业务层（包含数据访问层的业务层）、数据存储层。
下面举例说明可能的部署情景，带阴影的框框表示一台机器，虚线框表示根据使用场合可有可无，虚横线表示从此处划开单独出服务器。在B/S应用中，Web浏览器为客户端，其他全部为服务器。在C/S应用中，处在最上层的界面层+业务层为客户端，其他为服务器。
非分布式系统的部署
单机版
两三台机器
分布式系统的部署
分布式的Web系统
分布式的C/S系统
有几点要说明：
1． 客户端上的验证等业务逻辑是不可信的，因此任何一种部署都需要服务器端包含业务层；2． 为了开发、维护和部署中的高度可伸缩性，图中的各业务层所包含的代码都是一模一样的；3． 因为第2点，所以我遇到了业务层的同一个操作是与其他机器上的业务层通信还是访问数据库这个难题。
解决业务层的数据访问问题
这个问题是关键问题，也就是上面几点说明中的第3个问题，为了解决这个问题我们引入数据门户的概念。
下面以WebService为例说明：界面层访问本机的业务对象的增删改查中的“查”方法时，跳过数据库的查询操作，访问另一台机器中的同一个业务对象类的“查”方法。
以上是向另一台机器发送请求，该请求并不直接调用另一台机器上的业务对象类的“查”方法，而是将要调用的业务对象和方法参数信息转为一个“二进制包”，作为参数去调用另一台机器上通用的“查”方法，另一台机器上的“查”方法再解开这个包，然后去调用解开的包中所表示的业务对象类型，下面的静态图是另一台机器接受到请求后的工作。
又有些说明：
1． 关于原理都已在图中做了描述，不另写大段文字解释了； 2． 上面两个图中，除了“实际业务对象类”以外的部分全部属于架构或者框架部分；3． 如果用OO的思想去审查上面的两个图，你一定会为这糟糕的设计而抱怨，这里只是为了尽可能简单的表述分布式系统的工作原理，你可以采用策略模式使数据门户不改变的情况下适应各种请求响应场合，采用工厂模式实现不同的请求响应场合的切换。
关于数据库的分布
为了解决数据库服务器的负担，我们可能希望把数据分布存储在多个服务器上，我设想的数据库分布方案是，各服务器上的数据库在结构上一模一样，而表里的数据存储到不同服务器上，这样数据访问层在查数据的时候分别向所有数据库服务器发送同样的sql命令，然后数据访问层得到数据后整合，这样减轻每台服务器的工作量。亦或者根据表里的某个代表性的字段（如：省份）分布数据到不同服务器。
项目模块依赖
特别提醒：开发人员在开发的时候可以将自己的业务REST服务化或者Dubbo服务化
2. 项目依赖介绍
2.1 后台管理系统、Rest服务系统、Scheculer定时调度系统依赖如下图：
zookeeper、dubbo服务启动
dubbo管控台
REST服务平台
