Eureka

思维导图如下：

　 前言

　　Eureka是微服务的核心，为注册中心。

　　微服务是一种软件架构和组织的方法，其中软件通过明确定义的api，进行通信的小型独立服务组成。这些服务由小型服务组成，由各个团队独立负责。

　　其中微服务的架构，使得应用程序能够更加易于扩展，以及更快的开发，从而加速创新并缩短新功能上市的时间。

　　上图为整体应用拆分为微服务。

　 特性

　　微服务拥有以下几大特性：

　　1. 自主性：对微服务的每个组件进行开发，部署和运营。每个组件是通过明确的API的组件进行部署的。

　　2. 专用性：每个服务都是对应于专门的应用进行设计的。专注于解决特定问题，有其专用的特点。

　　优势

　　微服务拥有以下几大优势：

　　1. 敏捷性： 每个团队独立于一个应用的开发，各自互不干扰。拥有其敏捷的特点。

　　2. 灵活扩展： 在需求激增的时候，可以通过创建应用，实现灵活的扩展。

　　3. 轻松部署：微服务完美支持持续集成，持续部署，可以实现轻松部署。

　　4. 技术自由：微服务技术上相当的自由，支持团队选择任意一门技术进行部署。

　　5. 可重复使用的代码：每个技术都可以重复性使用代码的某一模块，每个模块可以重复利用，减少了代码量。

　　6. 弹性：通过微服务，每个组件可以任意进行扩展和缩小。

　　简介

　　这里对Eureka进行相关的简介。

　　Eureka 在微服务中的位置为注册中心，注册中心管理的功能有以下几点：

　　1. 服务的注册。

　　2. 服务的发现

　　3. 服务的熔断

　　4. 服务的负载

　　5. 服务的降级

　　按照网站的发展历史来进行说明。

　　最开始，是单体应用，所有的都被封装在一个Spring Boot 中。此时没有注册中心。

　　如下图：

　　后来由于维护不方便等各种原因，开始进行拆分，拆分成为一个个的类，此时依然没有注册中心

　　类与类之间通过new的方法相互调用。

　　伴随着流量的加大，进行应用的拆分。

　　应用之间通过Feign等方式进行远程调用。此时应用之间的关系是消费者，生产者之间的关系。

　　有了注册中心，通过注册中心的方式进行调用。

　　这个时候的调用就变成了，项目A调用项目B的时候，先通过注册中心，找到代理的地址，通过注册中心的代理地址，找到应用B。

　　两者之间相互进行调用。

　　这个时候，各个应用之间，不需要知道各自的ip地址，只需要通过注册中心的方式，由注册中心，代为提供地址。

　　这个时候，注册中心起到代理的作用。

　　到这一步，注册中心，就有了相当多的高级功能，例如服务的注册，服务的发现，服务的负载，服务的降级。

　客户端-服务端的通信方式

　　这里将会主要介绍，服务注册中心的通信方式，客户端-服务端的通信方式。

　　这种通信方式，有两种通信方式，分别为socket通信和Http通信这两种方式。

　　基础知识

　　Socket

　　socket为一种抽象层，应用程序通过其发送和接受数据，使用socket可以把应用程序添加到网络中，与处于同一网络中的应用程序进行通信。

　　具体分为流套接字，和数据报套接字。这两种套接字，分别基于Tcp，和Udp，这两种方式。

　　具体通信模型为

　　 Http

　　Http 分为Post，Get，Delete，Put，这四种通信方式。

　　这四种通信方式，分别描述了对于一个资源的增删查改。

　　用一张表格进行介绍：

　　用一句话进行简单的描述，在Get 请求的时候，取得了该文章的主题，Post 增加了该文章，Put 对文章进行修改，Delete 表示对文章的删除。

　　EurekaServer 与 EurekaClient

　　EurekaServer 与 EurekaClient 之间的关系如下图所示：

　　Service Provider 与 Service Consumer 都为Eureka Client 服务的提供方和服务的消费方都通过Eureka Server 实现相关的交流通信。

　　 EurekaServer

　　Eureka Server 为微服务的服务提供方，在下方图中为Eureka Server的启动界面。

　　主要有四个主要的信息，分别是系统状态，副本集，以及注册到此服务端的客户端，以及注册中心信息。

　　在这里可以查看到微服务注册中心的一些主要的信息。

　 Eureka Client

　　EurekaClient 为微服务的客户端，分为两个部分，分别为Service Consumer 与 Service Provider，这两种方式。

　　一个为微服务的服务提供方，一个为微服务的服务消费方，这两方共同作用，相辅相成，以Server 为纽带，相互联系。

　　客户端向注册中心注册的时候，会提供一系列的元信息，例如主机，端口，健康检查的URL，主页等，服务会不断的发送心跳信息，进行健康检查，如果某个服务在30s外仍然没有接受到注册中心的信息，将会在注册中心，移除掉该列表内容。

　　最为核心的一点，是健康检查

　 其余主流注册中心

　　注册中心，不单单只有，Eureka，还有其余的注册中心，例如zookeeper，consul，nacos，等。

　　这里进行分别的介绍。

　　Zookeeper

　　Zookeeper是 Apache Hadoop 的一个子项目，为一个树形的目录服务，支持变更推送，适合作为Dubbo的注册中心，工业强度，相当的高，可以用于生产环境。

　　Nacos

　　这里介绍Nacos注册中心。在Nacos中，最核心，最重要的是服务，Nacos几乎支持所有的主流的服务发现，配置和管理。

　　Nacos的关键特性包括以下几种。

　　1. 服务发现和服务健康监测

　　2. 动态配置服务

　　3. 动态 DNS 服务

　　4. 服务及其元数据管理

　　对于Nacos，其思维导图如下。

　　同属于dubbo生态范围下的，

　 Consul

　　Consul也是一个注册中心，包含多个组件，主要包含以下的组件：

　　1. 服务发现Consul的客户端可用提供一个服务,比如 api 或者mysql ,另外一些客户端可用使用Consul去发现一个指定服务的提供者.通过DNS或者HTTP应用程序可用很容易的找到他所依赖的服务.

　　2. 健康检查Consul客户端可用提供任意数量的健康检查,指定一个服务(比如:webserver是否返回了200 OK 状态码)或者使用本地节点(比如:内存使用是否大于90%). 这个信息可由operator用来监视集群的健康.被服务发现组件用来避免将流量发送到不健康的主机

　　3. Key/Value存储应用程序可用根据自己的需要使用Consul的层级的Key/Value存储.比如动态配置,功能标记,协调,领袖选举等等,简单的HTTP API让他更易于使用.

　　4. 多数据中心: Consul支持开箱即用的多数据中心.这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域.

　　 对比

　　这里列一个表格进行对比

　　上方都是简单的介绍，就该到应用的原理部分了。这里进行介绍的原理为CAP原理。即，对于一个分布式系统而言，最为核心的一点为CAP定理。

　　分布式系统CAP

　　CAP定理指的是，对于一个分布式系统而说，不可能同时满足，一致性，可用性，以及分区容错性。

　　这里依次介绍，这三种特性。

　　 一致性

　　所有节点的数据在同一时刻，完全一致。

　　一致性分为强一致性，弱一致性，最终一致性这三种。

　　对于强一致性而言，要求更新过的数据能被后续的访问都能看到

　　对于弱一致性而言，如果能容忍后续的部分或者全部访问不到

　　最终一致性：经过一段时间后要求能访问到更新后的数据

　　 可用性

　　指服务在正常响应时间内一直可用。

　　一般情况下的可用性与分布式数据冗余，负载均衡等有着很大的关联。

　　分区容错性

　　分区容错性指分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。

　　和注册中心的关系

　　注册中心是理论的实践，是CAP定理的最基本的实践。

　　即，总结下来，是理论是基础，注册中心是理论的产物。是工业化生成的结果。