SpringCloud微服务架构剖析(一)2种服务治理方式

• .CAP理论（帽子理论）

分布式系统的CAP理论：首先把分布式系统中的三个特性进行了如下归纳：
● 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
● 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
● 分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

1.Eureka

1.1 什么是Eureka？

Spring Cloud Eureka 是 Spring Cloud Netflix微服务套件中的一部分，它基于Netflix Eureka 做了二次封装，主要负责完成微服务架构中的服务治理功能，Spring Cloud 通过为Eureka 增加了Spring Boot风格的自动化配置，我们只需要通过简单引入依赖和注解配置就能让Spring Boot构建的微服务应用轻松的与Eureka服务治理系统进行整合。在服务治理框架中，通常会构建一个注册中心，每个服务单元向注册中心登记自己的服务，将主机与端口号、版本号、通讯协议等一些附加信息告知注册中心。当这些服务都启动并向注册中心注册自己的服务之后注册中心就会维护一个服务的清单，注册中心还会通过心跳来监测清单中的服务是否可用，若不可用需要从服务清单中剔除。

1.2 Eureka的特点：

• 在cap理论中它与zookeeper相比更偏向于可用性和分区容错性(AP)。

1.3 搭建一个简单的注册中心

1.3.1 添加maven依赖

	<dependencies>
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
		</dependency>

		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
		</dependency>
	</dependencies>

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>org.springframework.cloud</groupId>
				<artifactId>spring-cloud-dependencies</artifactId>
				<version>${spring-cloud.version}</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
		</dependencies>
	</dependencyManagement>

1.3.2 配置application.properties文件

server.port=8761

eureka.instance.hostname=localhost
#false代表不像注册中心注册自己
eureka.client.register-with-eureka=false
#false代表不去检索服务
eureka.client.fetch-registry=false
eureka.client.service-url.defaultZone：http=//${eureka.instance.hostname}:${server.port}/eureka/
spring.application.name=localhost

1.3.3 启动类添加@EnableEurekaServer注解

@SpringBootApplication
@EnableEurekaServer
public class RegisterApplication {

	public static void main(String[] args) {
		SpringApplication.run(RegisterApplication.class, args);
	}
}

1.3.4 启动测试

浏览器输入：localhost:8761 得到注册中心管理界面。

2.ZooKeeper

2.1 什么是ZooKeeper？

Zookeeper（业界简称zk）是一种提供配置管理、分布式协同以及命名的中心化服务，这些提供的功能都是分布式系统中非常底层且必不可少的基本功能，但是如果自己实现这些功能而且要达到高吞吐、低延迟同时还要保持一致性和可用性，实际上非常困难。因此zookeeper提供了这些功能，开发者在zookeeper之上构建自己的各种分布式系统。
Zookeeper提供一个多层级的节点命名空间（节点称为znode），每个节点都用一个以斜杠（/）分隔的路径表示，而且每个节点都有父节点（根节点除外），非常类似于文件系统。例如，/foo/doo这个表示一个znode，它的父节点为/foo，父父节点为/，而/为根节点没有父节点。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。Zookeeper为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得Zookeeper不能用于存放大量的数据，每个节点的存放数据上限为1M。
有序性是zookeeper中非常重要的一个特性，所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid（Zookeeper Transaction Id）。而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个zookeeper最新的zxid。

2.2 ZooKeeper的特点：

• 在cap理论中它与eureka相比更偏向于一致性和分区容错性(CP)。
• 顺序一致性
  从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到zookeeper中
• 原子性
  所有事物请求的处理结果在整个集群中所有机器上的应用情况是一致的，即，要么整个集群中所有机器都成功应用了某一事务，要么都没有应用，一定不会出现集群中部分机器应用了改事务，另外一部分没有应用的情况。
• 单一视图
  无论客户端连接的是哪个zookeeper服务器，其看到的服务端数据模型都是一致的。
• 可靠性
  一旦服务端成功的应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直保留下来，除非有另一个事务又对其进行了改变。
• 实时性
  zookeeper并不是一种强一致性，只能保证顺序一致性和最终一致性，只能称为达到了伪实时性。

2.3 SpringCloud+ZooKeeper（注册与发现）

https://blog.csdn.net/Z_Vivian/article/details/101291716