集群、分布式和微服务之间的关系

        集群：
        把同一个应用部署到多个服务器上，每一个服务器就是一个节点，这些节点的集合就是集群。
        举个例子，我们现在有一个学习app，部署到一台服务器上，随着时间的流逝，越来越多的人知道我们的app,从而用户的访问量就会增加，这个服务器承受的压力就会变大。为了减少服务器压力，我们就把这个app复制多份，然后再分别部署到不同的服务器上，如下图。

        也就是每个节点（服务器）都对外提供相应的服务。我们发现，从单个web应用到集群，我们并没有修改任何的代码，而是多部署了几台服务器，使每台服务器运行相同的代码而已，这样一看，集群就是一种物理形态而已。
        集群的特点：
        a，高伸缩性：可以根据实际的需求和负荷动态的调整集群节点的规模，
        b，高可用性：即使集群中某个节点发生故障，整个系统也不会因此不可用，依然可以对外提供服务。

        分布式架构：
        把一个完整的web系统，根据业务功能进行拆分，拆分成一个个独立的子系统，每个子系统能够独立的运行在自己的服务器中，他们之间通过RPC通信机制进行调用。如下图所示：

        那么就产生一个问题了，这些服务之间的关系是不是集群呢？
        答案是否定的，上面刚刚提到集群是把相同的应用部署到不同的服务器上，集群之间执行的功能是相同的。比如学习app中，播放模块点击量比较高，流量比较大，我们就可以把播放服务部署到多个不同的服务器上，这些服务器之间的关系才是集群。

        微服务：
        提到微服务，我们就要追溯到微服务的源头。微服务起源于Martin Fowler（马丁·福勒，微服务的提出者） 所写的一篇文章Microservices （https://martinfowler.com/microservices/）
        就目前而言，对于微服务业界并没有一个统一的、标准的定义(While there is no precise definition of this architecturalstyle)
        但通常而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。