在之前我使用的是ssm框架来编写电商工程。对于初学者来说，ssm已经足够简便灵活，可以使我们从数据库的sql语句编写工作中解放出来，专心于工作逻辑的编写。
我们知道ssm框架使用mvc开发模式，创建了views,action,service,dao三个模块将我们的视图和业务逻辑进行了分离。可以说，这是分布式思想的雏形，也是必经之路。但是这只是一个概念上的分层，为什么这样说呢因为这个几个模块都运行在一个工程中，也就是说运行在一个服务器上。这样的工程只能用于初始时的学习，对于淘宝，京东这样大的电商网站来说。这样的工程是不够健壮和安全的，运行这样工程的服务器的性能利用很差而且将会很容易崩溃（因为启动一个工程要将所有的jsp页面和java代码进行加载，这是十分消耗内存的）。
当我们了解了单纯的ssm框架已经不能满足日益增加的访问需求时，我们需要引进一些新的插件。来搭建我们的分布式工程。
什么是分布式工程呢，我想用一个图来解释。
下面我根据这个图进行讲解分布式工程思想。首先我们将后台管理员所需要的jsp页面和后台请求（Controller）放在一个服务器上进行运行。将消费者将要看到的前端页面和进行的请求放在一个服务器上进行运行。
将我们的service（业务逻辑层）和dao（数据库操作层）放在一服务器上进行运行。
那么如何实现前端向后台请求服务呢。这个时候就需要引入插件zookeeper和dubbo框架了。
dubbo是一个框架，和spring框架类似做了一些集成操作，通过xml文件来实现服务的注册和分配（注册是由具体的注册中心完成的）。dubbo只是负责调度服务请求者和服务提供者的一个中介，那么它需要一个代理。那么这个代理就是zookeeper，zookeeper的工作就是在启动时将我们需要注册的服务进行注册。
那么为什么要将后台管理员和普通访问者的jsp页面放在两个工程中呢。原因很简单，后台管理员对服务器的访问量和普通访问者对服务器的访问量显然不是一个数量级。这就是说，对于普通的访问者需要配置更多的服务器。另外一方面，很明显后台管理员对于页面的访问和后台服务的请求和普通访问者来说是不同的，那么他们的功能既然没有交集。完全可以将其放在不同的服务器上各司其职，如果放在一起就像我前面所说会造成内存空间的浪费。
对于service层和dao层，同样的原理，这两个部分主要是后台服务居多。所以专门设置另外的服务器提供服务。实际上，如果我们仔细区分。service层和dao层功能也是明显不同的，一个是负责计算和业务逻辑，一个只是访问数据库。我们实际上可以将其放在不同的服务器上。
综上所述，分布式工程就像是把不同的功能模块放在不同的服务器上，彼此之间看似分离，但是通过一定的框架和插件实现了不同模块的接口连接。多个服务器同时工作，完成各自的功能，从而更好的提高服务器的利用效率和我们的工作效率。所以分布式工程的最大优点就是利用服务器的工作特点，为其分配最适合的工作，最大可能的发挥作用。