微服务、集群、分布式架构别再搞混了

要讨论微服务、集群、分布式，需要先讲讲“单机架构”，单机架构很常见，比如有一个很小的系统，不用处理很多东西，只需要一台服务器，在上面搭建出自己需要的服务，就可以开始工作。这种架构优点显而易见，方

要讨论微服务、集群、分布式，需要先讲讲“单机架构”，单机架构很常见，比如有一个很小的系统，不用处理很多东西，只需要一台服务器，在上面搭建出自己需要的服务，就可以开始工作。这种架构优点显而易见，方便维护，出了问题解决起来很方便。缺点也很明显，如果处理变多，资源也就不够用了。

单机架构无法满足要求，集群架构就可以提供更好更快的处理，简单来说，集群架构就是把单机架构上面运行的服务，摘出来，然后复制，在多个服务器上面进行部署，这样可以提高工作效率。在集群中，每个服务器都称为节点，每个节点提供不同的服务，比如Database、Web、日志工具。

国外服务器免费测试：https://server.smilefoundat.com/

一、什么是微服务架构?

它是Martin Fowler在2014年首次提出的一个概念,「微服务是一种架构风格,可以说是一种处理问题的思想,通过这种思想可以将原来一个复杂的系统拆分成多个子系统,多个子系统之间是相互独立的」,有自己独立的进程,可以单独部署,每个子系统(微服务)都只关注实现自己的业务功能,这样子就解决了原来所有业务都存放在一个系统上，让系统显得很臃肿，并且难以抽离的问题。

下面开始介绍所谓的微服务。 微服务就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在微服务结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。

1、RPC通信是什么?

这里制作一个简单介绍，想具体了解RPC的，请自行Google。RPC(Remote Procedure Call Procotol)远程过程调用协议，通俗的解释就是：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。阿里巴巴的Dubbo框架，就是运用RPC协议比较好的框架

举个例子，假设需要开发一个在线商城。按照微服务的思想，我们需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目，可以独立运行。如果服务之间有依赖关系，那么通过RPC方式调用。

这样的好处有很多：系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得容易，开发效率大大提升。

系统之间的耦合度降低，从而系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促，下单量可能会大大提升，因此我们可以针对性地提升订单系统、产品系统的节点数量，而对于后台管理系统、数据分析系统而言，节点数量维持原有水平即可。

服务的复用性更高。比如，当我们将用户系统作为单独的服务后，该公司所有的产品都可以使用该系统作为用户系统，无需重复开发。

那么问题来了，当采用微服务结构后，一个完整的系统可能有很多独立的子系统组成，当业务量渐渐发展起来之后，而这些子系统之间的关系将错综复杂，而且为了能够针对性地增加某些服务的处理能力，某些服务的背后可能是一个集群模式，由多个节点构成，这无疑大大增加了运维的难度。微服务的想法好是好，但开发、运维的复杂度实在是太高。为了解决这些问题，阿里巴巴的Dubbo就横空出世了。

2、Dubbo，Dubbo是一套微服务系统的协调者，在它这套体系中，一共有三种角色，分别是：服务提供者(下面简称提供者)、服务消费者(下面简称消费者)、注册中心。

你在使用的时候需要将Dubbo的jar包引入到你的项目中，也就是每个服务都要引入Dubbo的jar包。然后当这些服务初始化的时候，Dubbo就会将当前系统需要发布的服务、以及当前系统的IP和端口号发送给注册中心，注册中心便会将其记录下来。这就是服务发布的过程。与此同时，也是在系统初始化的时候，Dubbo还会扫描一下当前系统所需要引用的服务，然后向注册中心请求这些服务所在的IP和端口号。接下来系统就可以正常运行了。当系统A需要调用系统B的服务的时候，A就会与B建立起一条RPC信道，然后再调用B系统上相应的服务。这，就是Dubbo的作用。

3、具体部署

当我们使用了微服务架构后，我们将一个原本完整的系统，按照业务逻辑拆分成一个个可独立运行的子系统。为了降低系统间的耦合度，我们希望这些子系统能够运行在独立的环境中，这些环境之间能够相互隔离。

在Docker出现之前，若使用虚拟机来实现运行环境的相互隔离的话成本较高，虚拟机会消耗较多的计算机硬件/软件资源。Docker不仅能够实现运行环境的隔离，而且能极大程度的节约计算机资源，它成为一种轻量级的“虚拟机”。

docker具体是什么或者怎么用，这里就不讲解了，自行搜索吧。

当我们使用微服务架构后，随着业务的逐渐发展，系统之间的依赖关系会日益复杂，而且各个模块的构建顺序都有所讲究。对于一个小型系统来说，也许只有几个模块，那么你每次采用人肉构建的方式也许并不感觉麻烦。但随着系统业务的发展，你的系统之间的依赖关系日益复杂，子系统也逐渐增多，每次构建一下你都要非常小心谨慎，稍有不慎整个服务都无法正常启动。而且这些构建的工作很low，但却需要消耗大量的精力，这无疑降低了开发的效率。不过没关系，Jenkins就是来帮助你解决这个问题的。

我们只需在Jenkins中配置好代码仓库、各个模块的构建顺序和构建命令，在以后的构建中，只需要点击“立即构建”按钮，Jenkins就会自动到你的代码仓库中拉取最新的代码，然后根据你事先配置的构建命令进行构建，最后发布到指定的容器中运行。你也可以让Jenkins定时检查代码仓库版本的变化，一旦发现变动就自动地开始构建过程，并且让Jenkins在构建成功后给你发一封邮件。这样你连“立即构建”的按钮也不需要按，就能全自动地完成这一切构建过程。

二、什么是集群架构?

集群搭建出来后，有这样一个角色，负责调度客户端来的请求究竟要到哪一台服务器上去，然后在进行接下来的工作流，这个角色叫做——“负载均衡器”

集群也分为高可用集群，负载均衡集群(可能高并发架构就是负载均衡架构的升级版)。

高可用集群工具常见的有：heartbeat，pacemaker，keepalived

负载均衡器工具常见的有：nginx，lvs，HAproxy

集群架构优点：可扩展性，服务器资源不够用，就可以加一台继续进行工作

缺点：维护起来困难，trouble shoot的时候需要花费时间较多

三、微服务、集群、分布式三者的关系和区别:

1.微服务是将一个复杂系统根据业务或者其他方式拆分成具有不同功能的子系统的思想或者说架构风格,可以说是实现集群或者分布式的前提，毕竟，没有系统的话集群和分布式也就没有作用的对象了。

2.集群则是将按照微服务架构风格拆分出来的同一个业务系统部署到不同的服务器上,这样一个系统就存在多份，保障了系统的高可用性。

3.分布式则是按照微服务架构风格拆分出来的不同业务的系统系统部署到不同的服务器上，可以对分布式上的每一个节点进行集群设置，实现高可用，它是一种工作的方式。

4.简单说，分布式是以缩短单个任务的执行时间来提升效率的,如一个任务由5个小任务组成，处理完一个任务需要1个小时，那么使用一台服务器的话则需要五个小时，如果使用五台服务器则只需要一个小时，这种也是Hadpood中的一种Map/Reduce 分布式计算模型的工作模式。