分布式系统部署方案

• 分布式系统的部署

　　日常咱们都说三层架构，我认为它是一个广义的模型，更多层的设计能够合并相邻几层的方式最终回归到三层这个宽泛的概念上来，个人意思是：这些都只是概念，忘记这些概念去实际分析设计会离这些概念更近一些。

　　接下来我要把三层变的更简单点，两层，数据访问层合并到业务层，统称为业务层，由于咱们面对的问题不是分层的问题，而是分布式系统中各层应该怎么部署的问题。在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定时调度系统依赖以下图：

 

       2.2 Dubbo独立服务项目依赖以下图：

 

3.  项目功能部分截图：

 

 

 

 

 

 

 

zookeeper、dubbo服务启动 

 

 

dubbo管控台 

 

 

 

 

 

 

 REST服务平台