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