微服务之服务治理

2017-05-03

服务治理用来实现各个微服务实例的注册与发现，是微服务架构中最关键的基础设施。大多数服务治理框架主要都是实现服务实例的自动化注册和发现。一个服务治理框架一般由以下两部分组成：服务注册和服务发现。

服务注册 #

服务注册是指服务在其网络上声明自己上线的过程，一般是在某种服务或数据库中写入数据，这个服务或数据库一般被称作服务注册中心。

服务注册中心：每个服务实例会向注册中心注册自己的信息，一般包含地址、端口、协议、版本等信息。每种服务会有多个实例副本注册到注册中心，注册中心维护每种服务的多个实例列表。同时，注册中心会以某种机制去检查各个服务实例是否可用，如果某个实例已经失效会将其剔除。在某个服务实例关闭时会自动向注册中心注销自己。

常见的服务注册有两种实现方式：

服务进程内直接包含服务注册模块，即把服务注册的功能写到了服务的源代码中，由服务实例自己完成上线注册和下线注销。这种方式对客户端要求比较高，尤其是众多服务采用不同的语言开发的时候
由一个伙伴进程或一个中间的调度者来帮助处理服务注册

服务发现 #

服务发现即服务客户端在其网络上找到其要调用服务的具体连接信息的过程。例如通过查询服务注册中心得到其所调用服务的具体 IP地址和端口。简单的说，服务发现就是服务或者应用之间互相定位的过程。

服务发现：客户端对服务的调用不再和具体的服务实例地址耦合，需要服务发现机制。常见的服务发现机制如下：

静态配置：这种实现基本上不用考虑，为了实现服务的高可用需要手动维护服务实例副本的列表，显然不适合微服务架构下众多的服务以及服务治理的自动化需求。
服务端负载均衡器：由服务端的负载均衡器通过服务注册中心中服务实例信息动态生成和更新代理和负载均衡配置，一般服务注册中心会在服务上线注册、下线注销、失效剔除时推送信息给服务端负载均衡器。这种方式实际上是在服务端实现的服务发现。
客户端负载均衡器：由客户端的负载均衡器通过服务注册中心中服务实例信息动态生成和更新代理和负载均衡配置。这种方式是在客户端即服务调用方端实现的服务发现。
客户端集成服务发现：一般以SDK的形式集成到客户端进程内

Kubernetes中的服务注册和发现 #

Kubernetes中的一个Service资源对象对应微服务。每个Service有唯一的名字，一个ClusterIP(虚IP)，一个端口。 Kubernetes中的Pod资源对象中运行的容器对应服务实例，通过Pod上的标签Label(如name=xxx-svc)和Service上定义的标签选择器Label Selector(如name=xxx-srv)将Service与Pod映射，通过Service内建的负载均衡机制，对Service的调用将转发到Pod中的容器中。服务的注册是在Pod创建时由调度者Kubernetes完成的，服务发现采用的是服务端负载均衡器，服务注册中心为Kubernetes(后端持久化存储etcd)。

Spring Cloud中的服务注册和发现 #

Eureka是Netflix提供的服务发现方案。Eureka的服务端和客户端都是用Java语言编写。 Eureka可以很好的与Spring Cloud以及Netflix的其他开源项目整合在一起，如果团队所有的服务都是用Java语言编写，那么Eureka是一个不错的服务发现方案。在设计上Eureka以可用性为先，可以在故障期间保证服务发现和注册功能可用，此时会存在一些数据错误，在故障恢复以后按最终一致性进行状态合并。 Spring Cloud很好的整合的Eureka，使之使用十分简单，只需在Spring Boot项目的gradle构建脚本中加入Spring Cloud Eureka的依赖并在代码中加入@EnableEurekaServer注解就可以创建一个EurekaServer。服务的提供者和消费者项目中在gradle中添加Spring Cloud Eureka依赖，并在代码中加入@EnableEurekaClient就可以将自身注册到Eureka Server，并可以使用相关的方法查询其他服务实例的注册信息。另外，还可以结合使用Netflix Ribbon这个客户端负载均衡方案实现负载均衡，Spring Cloud同样对Ribbon做了整合。