SpringCloud分布式框架从零到一

一、什么是分布式和微服务？

简单的介绍一下，更多的还是看CSDN里面大佬说的更详细。

微服务是什么？

就是将各种模块拆分成一个独立的服务单元并通过接口来实现数据的交互。它的拆分粒度很细，细到每个人仅做一件不可分解的事情，而这些细微的事情不一定每个都放在不同服务器上，一个服务器上可以放很多微服务如A服务，B服务，C服务，另外一台服务器放B服务，C服务，D服务。值得注意的是，所有服务都需要通知一个叫注册中心的地方，可以理解这个为工程项目经理，他来统一协调管理。

分布式是什么？

就是分散部署在不同的机器上的服务，一个服务可能负责几个功能，它是一种面向SOA架构的，服务之间同上也是通过rpc来交互或webservice交互的。

二者之间区别和关系?

简单来说，分布式和微服务的概念比较相似，分布式属于微服务。但是分布式和微服务在架构、作用和粒度上有所区别。因此，两者的关系是既相互联系又相互区别
1、首先它们之间架构是不同的，微服务的设计目的是为了不让某个模块因为升级或BUG等杂七杂八原因而影响现有的系统业务。微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上的，它也可以是同一个服务器。

2、再来是作用不同，分布式都是不同模块部署在不同服务器上的，主要解决的为网站高并发所带来问题。而微服务各服务是可独立应用的，且组合服务也可系统应用。

3、最后是粒度不同，相比分布式服务来说，微服务间粒度更小，服务间耦合度更低，并且因为每个微服务都是由一个独立的小团队负责，所以它的敏捷性会更高，分布式服务最后都会向微服务架构演化，这是一种趋势，不过服务微服务化后带来的劣势也是非常明显的，例如服务粒度小，数量大，后期运维艰难等。

二、分布式架构的几种方式

按理来说，技术人员在自己的领域上应该追寻新技术，并在工作中应用，变成自己实实在在的经验，又或者在自己的闲暇时间，修炼一下也可以

但是在最近我有了解到，很多的程序猿只是知道分布式这个概念，却不知道什么是分布式，怎么去应用分布式，后面在细说架构，现在偷个懒。

1、纯负载均衡形式

在集群前面，前置一个流量分发的组件进行流量分发，整个集群的机器提供无差别的服务，这在常见的 web
服务器中是最最常见的。目前比较主流的方式就是整个集群机器上云，根据实时的调用量进行云服务器弹性伸缩。常见的负载均衡 ribbon、nginx 等。

2、领导选举型

整个集群的消息都会转发到集群的领导这里，是一种 master-slavers，区别只是这个 master 是被临时选举出来的，一旦master 宕机，集群会立刻选举出一个新的领导，继续对外提供服务。使用领导选举型架构的典型的应用有ElasticSearch，zookeeper。

3、区块链型

整个集群的每一个节点都可以进行记录，但是记录的内容要得到整个集群 N 个机器的认可才是合法的。典型的应用有 Bit Coin，以及Hyperledger。

4、master-slaver型

整个集群以某台 master 为中枢，进行集群的调度。交互是这样，一般会把所有的管理类型的数据放到 master 上，而把具体的数据放到slaver 上，实际进行调用的时候，client 先调用 master 获取数据所存放的 server 的 信息，再自行跟 slave进行交互。典型的系统有 Hadoop。集群，HBase 集群，Redis 集群等。

5、规则型一致性Hash

这种架构类型一般出现在数据库分库分表的设计中。按照规则进行分库分表，在查询之前使用规则引擎进行库和表的确认，再对具体的应用进行访问。为什么要用一致性Hash ？其实用什么都可以，只是对于这类应用来说一致性 Hash 比较常见而已。

以上方式摘选自-漫谈分布式架构的几种套路 原文作者/原文公众号：一名叫大蕉的程序员

三、常用组件介绍使用

以下简单介绍一下常用的五大组件

服务发现——Netflix Eureka
客服端负载均衡——Netflix Ribbon
断路器——Netflix Hystrix
服务网关——Netflix Zuul
分布式配置——Spring Cloud Config

1、服务发现-Eureka

Eureka在分布架构中作用为服务注册与发现。 由两个组件组成：Eureka Server和Eureka Client，也就是服务端和客户端。为了便于理解，我们可以将Eureka client再分为Service Provider和Service Consumer。

• Eureka Server 提供服务注册和发现
• Service Provider 服务提供方，将自身服务注册到Eureka，从而使服务消费方能够找到
• Service Consumer服务消费方，从Eureka获取注册服务列表，从而能够消费服务

简单来说就是一个提供服务注册和发现的一个组件，这里可以提一下，zookeeper也可以作为服务注册与发现。那么为什么现在常用的是Eureka，却不是zookeeper呢？下面简单说一下一个CAP原理

• P:Partition tolerance,网络分区容错。类似多机房部署，保证服务稳定性。
• A: Availability，可用性。
• C:Consistency ，一致性。
  CAP定理：CAP三个属性对于分布式系统不同同时做到。如AP/CP/AC。

再来看Zookeepr和Eureka区别

（1）Zookeeper是CP，分布式协同服务，突出一致性。对ZooKeeper的的每次请求都能得到一致的数据结果，但是无法保证每次访问服务可用性。如请求到来时，zookeer正在做leader选举，此时不能提供服务，即不满足A可用性。

（2）Euere是AP，高可用与可伸缩的Service发现服务，突出可用性。相对于Zookeeper而言，可能返回数据没有一致性，但是保证能够返回数据，服务是可用的。

这里有篇文章介绍为什么服务发现使用Eureka，而不是Zookeeper，可以去了解一下。为什么不应该使用ZooKeeper做服务发现

2、负载均衡——Netflix Ribbon

负载均衡，就是指将负载（工作任务）进行平衡、分摊到多个操作单元上进行运行。
它的一些负载均衡策略：

• 简单轮询负载均衡
• 加权响应时间负载均衡
• 区域感知轮询负载均衡
• 随机负载均衡

当然还有一个nginx也是大家熟知的，两者都是做轮询，做负载分发请求。那么他们的区别是什么？

• Nginx是属于服务器端的负载均衡，Ribbon是属于客户端的负载均衡，简而言之，Nginx的客户端发起请求不知道会被负载到哪台服务器上，但是Ribbon发起的请求都是非常明确的，就像调用本地服务一样。
• 更广的范围说：Nginx是进程之间调用时候做的负载均衡，Ribbon是进程内部选择调用时候做的负载均衡。
• 所以微服务架构采用的就是Ribbon，两者还是有一定差距的。
• 可以看做nginx对外，ribbon对内。

3、断路器——Netflix Hystrix

• Netflix Hystrix是SOA/微服务架构中提供服务隔离、熔断、降级机制的工具/框架。
• 在分布式架构中，一个应用依赖多个服务是非常常见的，如果其中一个依赖由于延迟过高发生阻塞，调用该依赖服务的线程就会阻塞，如果相关业务的QPS较高，就可能产生大量阻塞，从而导致该应用/服务由于服务器资源被耗尽而拖垮。另外，故障也会在应用之间传递，如果故障服务的上游依赖较多，可能会引起服务的雪崩效应。就跟数据瘫痪，会引起依赖该数据库的应用瘫痪是一样的道理。

Netflix Hystrix断路器简介与工作原理