集中：
是由一台主机组成的中央节点，数据集中存储在该中央节点，整个系统的所有业务单元都集中在该中央节点，系统的所有功能都集中处理。
集中式系统的最大特点是部署结构简单。 集中式系统往往基于底层性能较好的大型主机，因此无需考虑如何在多个节点部署服务或多个节点之间的分布式协作问题。
集群(集群) :
在多台不同的服务器上部署相同的APP应用程序或服务模块，组成一个集群，通过负载均衡器对外提供服务。
分布式：
是指在多台不同的服务器上部署不同的服务模块，通过远程调用协同工作，对外提供服务。
阿里Dubbo/HSF
京东日本航空
新浪微博
当当网杜博箱
dubbo zookeeper RPC
cloud : eurekezuulfeignrest风格
SOA:面向服务(web服务微服务)
spring cloud :重新设计样式
发现Eureka:服务注册
Ribbon:客户端重置模板负载平衡，默认轮询
Feign:面向界面，类似于web服务，客户端负载均衡
Hystrix:服务器熔断和降级
Hystrixdashboard:服务监视(首先访问被监视的服务) )。
Admin:监视
Zuul:网关
Config:配置中心
我们去了一家小酒店，开始点菜。 是红烧鱼、糖醋排骨、酸土豆泥。 现在我们和这家酒店之间的是用户和系统的关系。 我们希望他给我们做一顿丰盛的晚餐。 我们完全不在乎他的厨师。 如果能在短时间内提供好吃的料理就好了。 在上面，我们对这家酒店提出了两个要求。 料理提供时间短，料理很好吃。 除了这些以外，客人可能还有其他要求。 例如，烹饪要干净卫生，酸土豆泥里多放辣椒等等。 映射到计算机系统后，来自用户的要求如下
烹饪时间短-性能
清洁-安全性
菜里多放辣椒-可扩展性
菜肴美味-可用性
上面说的这家小酒店里，只有一个厨师。 是集中管理系统。
如果酒店里只有一位客人，这几个基本上是可以满足的。 但是到了晚饭的时间，客人突然多了起来，这些客人的要求可能都得不到满足。 如果酒店客满，这家小酒店只有一个厨师，他需要保证所有的菜都好吃卫生，保证所有的菜都能按时准备好，满足不同用户的个性化要求。 这样的挑战极大。 以上，映射到计算机软件上也一样。 随着业务量的增加，网站的高可用性、可扩展性、可扩展性、安全性等目标变得非常困难。 群集部署：
随着酒店的生意越来越好，老板意识到只有一个厨师有很大的问题。 首先，在顾客高峰期，一个厨师不能满足所有顾客的要求。 其次，厨师得了一分。 他不能生病。 一旦生病，整个酒店就不能营业了。 所以再雇几个厨师就行了。
而且，为了提高酒店的接待能力。 上司决定增加几个厨师。 厨师做好几个之后。 店内客人的订单可以分配给厨师的多位厨师来做。
具体怎么分配，这需要一定的战略。 可以选择分配给空闲点的厨师，也可以按顺序分配。
餐厅有多位厨师，但用户不知道这些，他只知道自己的订单需求，只要能满足就好。 他也不用在意是谁给自己做饭的。 除非料理出现了质量问题，否则需要找到指定的厨师来负责问责。 以上，映射到计算机软件上也一样。 集中式系统是只有一台计算机提供服务，集群是多台计算机提供相同的服务。 用户请求通过负载平衡分配给群集中的每台计算机。 整个系统对用户来说就像机器在提供服务一样。 分散配置：
在酒店雇了多位厨师后，酒店的服务能力确实提高了很多。 顾客也在增加。 但是，在最近的店内，如果某道菜的味道和自己至今为止吃的不一样，经常会有人投诉。 老板仔细调查后发现，这家店的厨师除了炒菜外，还需要洗菜、切菜、准备、洗碗。 结果，厨师无法集中精力炒菜。 他会被其他琐事牵着后腿，无法集中精力炒菜，影响烹饪质量。 所以继续雇佣几个厨师、厨师、洗盘子不就行了吗？ 这是分散的思想。 把一件大事分割成多个小事，分别交给别人。 这样学术行业就有了专家，洗菜的人可以把菜洗得更干净，厨师也可以把注意力集中在炒菜上，把菜炒得更美味。 以上，映射到计算机软件上也一样。 除了通过集群部署提高系统功能外，还有通过分散部署的方法。 将大系统划分为多个子系统，每个子系统负责自己的集中，通过网络进行通信和协调，对用户来说就像在访问同一台机器一样。 随着酒店的发展，一个厨师变成了多位厨师，甚至还有厨师、厨师、厨师等很多职位。 这个网站的体系结构也很相似。 在网站初期，只需构建一个集中的单元APP即可。 如果业务量大幅增加，请先考虑增加机器，通过集群部署提高能力。 其次，可以考虑方差。