服务治理
服务治理可以说是微服务架构中最为核心和基础的模块， 它主要用来实现各个微服务 实例的自动化注册与发现。 为什么我们在微服务架构中那么需要服务治理模块呢？微服务 系统没有它会有什么不好的地方吗？
在最初开始构建微服务系统的时候可能服务并不多， 我们可以通过做一些静态配置来 完成服务的调用。 比如，有两个服务 A 和 B, 其中服务 A 需要调用服务 B 来完成一个业务 操作时， 为了实现服务 B 的高可用， 不论采用服务端负载均衡还是客户端负载均衡， 都需 要手工维护服务 B 的具体实例清单。 但是随着业务的发展， 系统功能越来越复杂， 相应的 微服务应用也不断增加， 我们的静态配置就会变得越来越难以维护。 并且面对不断发展的业务， 我们的集群规模、 服务的位置 、 服务的命名等都有可能发生变化， 如果还是通过手 工维护的方式， 那么极易发生错误或是命名冲突等问题。 同时， 对于这类静态内容的维护 也必将消耗大量的人力。
为了解决微服务架构中的服务实例维护问题， 产生了大量的服务治理框架和产品。 这 些框架和产品的实现都围绕着服务注册与服务发现机制来完成对微服务应用实例的自动化管理。
• 服务注册：在服务治理框架中， 通常都会构建一个注册中心， 每个服务单元向注册 中心登记自己提供的服务， 将主机与端口号、 版本号、 通信协议等一些附加信息告 知注册中心， 注册中心按服务名分类组织服务清单。 比如， 我们有两个提供服务A 的进程分别运行于 192.168.0.100:8000和192.168.0.101:8000位置上， 另外还有三个 提供服务B的进程分别运行千192.168.0.100:9000 、 192.168.0.101:9000、 192.168.0.102:9000位置上。 当这些进程均启动， 并向注册中心注册自己的服务之后， 注册中心就会维护类似下面的一个服务清单。 另外， 服务注册中心还需要以心跳的方式去监测清单中的服务是否可用， 若不可用 需要从服务清单中剔除， 达到排除故障服务的效果。
服务名 位置
服务A 192.168.0.100:8000、192.168.0.101:8000
服务B 192.168.0.100:9000、192.168.0.101:9000、192.168.0.102:9000
• 服务发现：由于在服务治理框架下运作， 服务间的调用不再通过指定具体的实例地 址来实现， 而是通过向服务名发起请求调用实现。 所以， 服务调用方在调用服务提 供方接口的时候， 并不知道具体的服务实例位置。 因此， 调用方需要向服务注册中 心咨询服务， 并获取所有服务的实例清单， 以实现对具体服务实例的访问。 比如， 现有服务C希望调用服务A, 服务C就需要向注册中心发起咨询服务请求， 服务注 册中心就会将服务A的位置清单返回给服务C, 如按上例服务A的情况，C便获得 了服务A的两个可用位置 192.168.0.100:8000和192.168.0.101:8000。 当服务C要发起调用的时候， 便从该清单中以某种轮询策略取出一 个位置来进行服 务调用， 这就是后续我们将会介绍的客户端负载均衡。 这里我们只是列举了一种简 单的服务治理逻辑， 以方便理解服务治理框架的基本运行思路。 实际的框架为了性 能等因素， 不会采用每次都向服务注册中心获取服务的方式， 并且不同的应用场景 在缓存和服务剔除等机制上也会有一些不同的实现策略。
Spring Cloud Eureka, 使用Netflix Eureka来实现服务注册与发现， 它既包含了服务端组件，也包含了客户端组件，并且服务端与客户端均采用Java编写，所以Eureka主要适用 于通过Java实现的分布式系统，或是与NM兼容语言构建的系统。但是， 由于Eureka服 务端的服务治理机制提供了完备的RESTfulAPL所以它也支持将非Java语言构建的微服 务应用纳入Eureka的服务治理体系中来。只是在使用其他语言平台的时候，需要自己来实 现Eureka的客户端程序。不过庆幸的是，在目前几个较为流行的开发平台上，都已经有了 一些针对Eureka 注册中心的客户端实现框架， 比如.NET平台的 Steeltoe、 Node.js 的 eureka-js-client等。
Eureka服务端，我们也称为服务注册中心。 它同其他服务注册中心一样，支持高可用 配置。它依托于强一致性提供良好的服务实例可用性，可以应对多种不同的故障场景。 如 果Eureka以集群模式部署，当集群中有分片出现故障时，那么Eureka就转入自我保护模 式。它允许在分片故障期间继续提供服务的发现和注册，当故障分片恢复运行时， 集群中 的其他分片会把它们的状态再次同步回来。以在AWS 上的实践为例， Netflix推荐每个可 用的区域运行一个Eureka服务端，通过它来形成集群。不同可用区域的服务注册中心通过 异步模式互相复制各自的状态，这意味着在任意给定的时间点每个实例关于所有服务的状 态是有细微差别的。