今天我就来说说以下几个关键概念的区别。这些是在构建满足大规模并发的高可用性架构时经常遇到的一些关键概念。
集群和分布式区别和联系
首先说一下集群和分布。这两个概念最容易混淆。下面我们来看看网上对这两个概念的一个基本解释如下：
对于集群，当单个节点的性能不足时，多个节点组合起来满足外部业务需求。对于分发，当单个节点性能不行时，将业务需求分解成多个子业务，然后将每个子业务部署到不同的节点。
一般来说，集群集中在多个服务器位置，易于统一管理；配送没有具体要求，不管放在哪里，只要通过网络连接就行。
看看知乎上一个形象的比喻如下：
小饭馆里只有一个厨师，切菜，洗菜，准备，全部煮熟。后来客人多了，厨房一个厨师不堪重负，又雇了一个厨师。两个厨师都能炒同一道菜，两个厨师的关系是集群。为了让厨师专心烹饪，把菜品做到最好，还雇了一个装修工来切、做、备菜。厨师和装修工的关系是分配的，一个装修工太忙，就雇了另一个装修工。这两个装饰之间的关系是一个集群。
实际上，您会看到通常有两种方法可以同时满足业务需求。不仅要考虑业务需求本身的分解，还要考虑分解后的子业务，提供多个节点组成集群提供能力。所以你会看到另外一种说法，就是分布式集群的概念。
分布式集群不仅体现了业务需求的拆分，还体现了单个子业务满足时的多节点组合。
HA和Cluster都可以理解为集群，但是HA架构往往有两种场景，一种是两个节点是否同时主动且有能力，或者一个节点在主动和备用模式下只是备用而没有能力。如果都提供功能，那么HA也是最简单的集群。
集群本身有一个关键能力，就是多个节点的冗余增加了可靠性，整个系统不会因为单个节点失效而无法使用。在分布式架构下，当节点分布时，对于有子服务的节点，仍然需要考虑HA或集群架构，以保证高可用性。
对于分发来说，除了通过拆分大任务解决性能问题，另一个关键好处是各个子服务在服务满意度上实现了解耦和高度自治，即子服务B不会受到子服务A故障的影响，提供两个子服务的资源实现了进一步的拆分和隔离。
数据持久性和存储
对于集群架构，一般采用集中存储来解决数据持久化的问题。同时，集中存储也便于相关事务管理，保证数据一致性。
在分布式体系结构中，特别是在像数据库和缓存这样的分布式体系结构中，数据本身的持久存储也是分布式的。同时实现了计算能力和存储能力的分配。每个分布式单元包括计算能力和本地存储能力。
因此，在数据或持久存储被分布之后，需要解决关键的分布式事务问题。同时带来了众所周知的上限定理，以及如何在保证高可用性和高一致性之间进行平衡。
所以简单来说，从应用架构实现的复杂度和后期运维管理的复杂度来看，集群的兼容性和易实现性都相当高。能由集群解决的，尽量由集群解决，不要盲目追求分配。
和负载平衡。
集群和负载平衡也是经常被混淆的概念。简单来说，负载均衡就是实现请求的路由和分发功能。对于集群来说，它会暴露一个外部的集群地址，所以自然具有负载均衡的能力。目前的负载均衡可以是Haproxy或Nginix实现的软负载均衡，也可以是F5、Array等设备实现的硬件负载均衡。
集群有负载平衡的能力，但是负载平衡的能力一般
除了负载平衡之外，集群还必须能够管理集群中的所有节点，监控状态，并维护状态节点的一致性。类似的程序部署、心跳状态检查、配置信息分发、分布式事务协调等。都属于集群管理节点需要的能力。目前可以看到的有etcd，zookeeper等。是常用的分布式集群实现技术。
中心化和去中心化
首先要解释一下集权和分权的概念。
那么，在前面业务需求A和IT系统服务能力提供的场景中，集群和分布式都在考虑能力提供B如何满足A的问题。
然后还有业务需求B、业务需求C等其他需求。业务需求A、B、C需要相互交互，相互配合。这时候有两种合作方式。
第一，ABC之间的合作，ABC和ABC都需要通过能力提供这种转移；第二，ABC之间的点对点合作，场景一是去中心化架构，场景二是去中心化架构。因此，一个架构的集中和分散都是针对ABC之间的协作。而不是在业务需求和功能供应之间。
典型的例子如微服务里面的服务注册中心。一般会说是一个去中心化的架构，也就是微服务A和微服务B之间的调用，这个消息流不需要通过服务注册中心，而是A和B之间直接完成的，那么在这种情况下即使服务注册中心宕机也对接口调用和访问没有影响。
而对于传统ESB这种代理模式即典型的中心化架构，所有的请求流都需要通过ESB总线管道，那么当ESB总线出现宕机的时候所有请求都无法访问。
那么去中心化架构是否彻底去中心化？
在去中心化架构中，对于注册中心来说仍然是一个分布式集群，因为服务注册和发现实现仍然需要有一个统一的管控点，这个管控能力还是需要在注册中心这个分布式集群实现。只是去中心化架构中进一步将控制流和数据流分离。
对于控制流量能力仍然在注册中心，采用传统分布式或集群方式来实现。而对于数据流则是点对点访问，彻底的去中心化，不需要再通过中心化节点中转和代理。
在去中心化架构下有两个关键好处。
其一是所有的数据流都不通过中心节点中转，那么自然访问性能更好。其二就是不会因为中心节点的服务器故障导致ABC之间相互无法访问。
但是去中心化架构本身也带来问题，即ABC之间由于是直接访问，那么相当来说都是可见可访问的，对于传统ESB里面最重要的一个服务代理和位置透明特点没有了。其次就是由于点对点访问导致了数据流不通过中心节点，那么很多类似安全，日志，流控等原来通过消息流拦截很容易实现的内容现在不容易实现。
而在去中心化架构演进过程中。出现了一个新变化即ServiceMesh服务网格思路，将相关管控能力以边车Sidecar或Agent代理组件的方式进一步下沉和部署到各个微服务模块中。这样就能将管控类问题得到很好的解决。
但是代理类和位置透明仍然无法解决，而这个能力可以转移到类似Nginix组件来实现。
两队概念之间的关系和联系
去中心化架构针对的是ABC业务需求之间的访问实现点对点，体现的是控制流和数据流分离，但是控制流仍然需要通过服务组件来提供，这个服务组件的部署仍然需要采用集群模式并结合分布式来实现高可用。
对于各种满足集成需求的中间件往往会出现中心化还是去中心化架构的概念，但是对于应用系统本身满足业务需求这个场景，一般不会出现是不是中心化架构这个概念。应用系统对需求的满足只会出现集群和分布式两个方式，这里的分布式和是否去中心化没有关系。
分布式和集群两者一般会组合使用，分布式实现功能需求解耦优点，而集群实现高可靠性和冗余的优点，而对于大并发性能的满足两种方式都具备具备改能力。
中心化架构的优势是在管控治理上面，通过中心化架构可以通过拦截方式实现各种管控治理能力，但是带来的问题就是引入一个新的中介点，讲解了整个应用的高可靠性。去中心化架构本身提高了高可靠性，但是牺牲了一定的管控治理能力。
