前言：

　　随着互联网的快速发展和进步，各个行业迎来了飞速发展的机遇，而在这其中Java这门语言在互联网时代中作为中流砥柱，也在不断的革新，而我们的互联网等公司由于越来越复杂的业务和用户需求使我们传统的单机项目越来越难以满足要求，而在这其中诞生出了另一种理念《分布式》，分布式的出现则是为了应对企业持续复杂化的业务和需求。

一、单机项目时代：

　　优势：

　　　　在传统的单机项目时代，我们把项目中功能模块都放在一起，比如：用户管理、产品模块、统计模块等，这在对于一个小团队或者是一个小项目来说，不管是对于项目的维护还是项目的复杂度来说都是有极大的好处的，所以说单机项目特别适合我们一个成立不久的团队初期建设。

　　缺点：

　　　　但是凡事没有绝对性，例如：如果是一个中大型项目，比如电商项目，其中存在非常多的模块、用户模块、支付模块、商户模块、对账模块、统计模块等等，这时候我们来思考一个问题，如果我们把这些所有模块放在一起会出现什么问题?

　　　　比如有一点我们修改了一个用户权利的小BUG，我们要想更新项目，则面临不得不重新部署整个项目的问题，而我们的支付、统计数据都具有实时性，重新部署项目就不得不关闭支付模块，这对于一个公司或者商户来说是极其严重的一个问题。

　　　　再比如有一天我们更新一个新功能，更新到生产环境却出了问题，而这个问题导致了整个项目无法运行，理所当然的支付功能也无法正常支付，想必这个时候公司客服的电话会被打爆，不久老板也会请你喝茶，这时候传统的单机项目就会遇包漏出各种各样的的问题。

二、Maven架构的项目：

　　上面我们了解了一下单机项目的开发存在的优势和缺陷，在随着java不断的更新出现Maven管理项目，我们的开发模式又出现了很大的变化，我们会把上面一个项目拆分成多个子模块，同时多个子模块有继承了一个父模块，父模块则负责项目版本的跟新：

　　优势：

　　　　1：实现了项目业务层的解耦；

　　　　2：可以提高业务层代码的复用性；

　　　　注：这种架构并不是分布式架构，并且也没有实现代码的解耦，因为各个子模块都依赖于其他模块的代码，需要导入其他子模块的jar包，所以并没有实现代码上的解耦；

　　　　上述的架构某种程度上可以解决我们上面单机项目的问题，我们把电商羡慕的支付模块和其他模块独立出来作为一个项目，人如果其中登录模块出了问题，我们只需要更新重启登录模块的项目，而支付模块我们则完全你不用去管；

　　缺点：

　　　　上述架构的项目虽然可以解决单机项目中业务层的解耦，却也存在着一个问题就是它并没有实现我们代码层方面的解耦，我们需要的jar包必须一个不少的导入，才能保证项目的正常运行。

三、分布式架构：

　　在上面我们看了单机项目的架构以及Maven架构的项目（注：并没有这种说法，只是自己理解），它们都在存在一些优点的同时也存在一些缺点，而为了满足我们越来越复杂的业务和臃肿的项目，java开发者们提出了另一种架构《分布式》，分布式的出现就是为了结局上述的架构方式无法满足的业务需求：

　　我们依旧以电商项目举例，例如我们把电商支付模块，定时任务管理模块等其他复用性高模块抽成了一个独立的项目，这个时候我们的不管有多少个系统用到支付或定时任务，我们只需要调用就可以，但是这样也存在一个问题，上面我们也提及到了。

　　例如我们的电商项目不可能仅用到下图中的三个jar，如果这其中涉及到十几或者几十个的jar时，这样会导致我们的主项目非常的臃肿而且难以维护，而这时候我们就要考虑如何在项目中使用这些我们独立出去的模块而且并不引入这些模块的jar，而这就是微服务架构；

　　微服务架构则是在我们的项目和独立除却多个模块之间搭建起一个桥梁，这个桥梁可以使SpringCoiud或Dubbo等，这样我们就不用直接和那些独立出去的模块打交道，直接和中间桥梁打交道，他会自动判断调用的模块，这样就避免了引入过多jar，导致项目臃肿以及难维护的缺点；

　　这时候我们也就知道了什么是微服务，所谓的微服务就是把项目中每个业务拆分，拆分后每一个业务节点都作为一个独立的项目，用户的访问则通过中间件服务的注册与发现来实现，这就是微服务架构；