SpringCloud微服务_2 注册中心Eureka基本原理
作者：田超凡
版权所有，转载请注明原作者，仿冒侵权必究法律责任
1.注册中心基本概念
在SOA架构或者微服务架构中，注册中心一直是一个核心存在，注册中心可以理解为是一个容器池，里面装的都是服务，服务和注册中心之间通过RPC远程调用机制实现通信关联。RPC远程调用机制实现方案目前比较成熟的有两种，SOAP和REST，这两种类型的服务调用通信机制通信协议都是基于HTTP，不同点在于传输数据载体不同，SOAP数据载体XML，众所周知XML可扩展标记语言，存在大量冗余标签和数据，并且对于不考虑网络传输速率的情况下（即假设在相同网络环境的情况下），XML格式数据的解析也是效率非常低下的，不论是前台后台解析XML格式数据基本都是采用标签递归迭代的方式解析，这种方式严重拖慢网络传输效率。再来看看REST传输风格，REST传输风格有两种方式实现，一种是经典的URL Restful风格传输，在URL中把参数位置使用占位符替换，后台定义PathVariable接收，一种是基于JSON轻量级数据交换格式进行请求信息传输。服务和注册中心，服务和服务之间的相互依赖和调用机制说白了不还是请求和响应的这一交互方式吗？所以为了达到尽量减少服务调用通信时的网络带宽占用，减少服务器线程阻塞问题发生的可能性，负载均衡优化服务器线程调度，REST传输通信机制在微服务架构体系中得到了更为广泛的使用。
对RPC远程调用机制中的两种数据传输和通信方式进行了简单回顾，那么接下来就细说一下注册中心吧！
注册中心这一概念在面向服务设计的架构中起着举足轻重的作用，不论是在SOA架构还是微服务架构之中，注册中心的作用一句话概括就是存放和调度服务，实现服务和注册中心，服务和服务之间的相互通信。同时由于注册中心自带了Monitor监控机制，可以实时监控注册中心中已经注册的服务运行状态和服务运行的物理路径和逻辑路径。逻辑路径也是serviceid，用于唯一标识注册中心中的每一个服务，serviceid在服务注册时指定，每一个serviceid都映射到一个物理路径，说白了其实指的就是主机ip和端口号。把自身注册到注册中心的服务叫做提供者，从注册中心中直接获取已经存在的服务并进行其他自身操作的服务叫做消费者。比如对于一次服务通信而言，首先服务提供者通过指定serviceid和物理路径把服务注册到注册中心，注册中心通过Monitor始终监视着所有已经发布的服务，服务消费者通过serviceid从注册中心中获取匹配的服务及对应的访问路径，消费者获取到需要调用的服务的物理访问路径之后，就可以在本地客户端通过上次说过的客户端负载均衡器ribbon或者feign远程调用服务实现服务和服务之间的相互调用。在面向服务设计的架构搭建的项目中，第一件事也是重中之重就是搭建注册中心。注册中心就如同整个SOA架构或者微服务架构体系中的心脏，其实也不难理解吧，面向服务的架构主要处理单元就是服务，之前在总结架构演变的时候就已经说过了，面向服务架构体系中，服务和服务之间是完全隔离的，那也就意味着服务的通信，管理，容灾，调度等等都是需要在一个统一的容器池-注册中心进行管理的，如果注册中心都出现了问题，那么整个系统就会出现灾难性并且完全不可逆的情况。但是注册中心如何一直保持正常运作而不出现问题呢？很遗憾，这是谁也无法保证的，注册中心虽是心脏，但是却是一颗十分脆弱的心脏，比如注册中心服务数量逐渐增大，线程并发量大阻塞超时，服务器内存溢出，GC内存泄露等问题都可以直接让一个注册中心瘫痪，就算对注册中心做了再多的性能调优或者把高可用做到了机制，也依然是无法完全保证注册中心在应用发布和运行周期永远正常运作的，这种做法治标不治本，怎么办？如果出现问题就让他直接宕掉吗？与其抱着侥幸心理，不如从源头上解决问题。做过其他容器机制的开发同行比如redis和nosql的都知道甚至不约而同想到一个词吧？对了，那就是搭建集群，多个注册中心形成主从备份的生态圈，这样就算其中一个注册中心出现问题我还有备机呢，这样不就可以最大范围减少注册中心宕机导致整个系统出现灾难性崩溃的可能性吗？其实，这样做也是微服务架构中提出的可伸缩性的一种实现。可伸缩性指的就是无论注册中心出现什么问题都不能让它影响到整个项目全局，允许适当对组件进行主从复制来最大程度提高项目的容灾性。关于注册中心服务搭建方式和注册中心集群实现说明详见下文。
