Spring-cloud & Netflix 源码解析之Eureka

最近在了解spring cloud + neflix。取了些依赖的netflix和spring-cloud-netflix的源码,先看了服务注册发现服务Eureka部分,整理了一点笔记:

首先功能上:
粗粗的过了下Spring cloud怎么让用户的服务通过一个注解能集成一个eureka的客户端,其实也就是spring自己注入了一个自己的eureka客户端,这个客户端里面使用了netflix原生的eureka client;
再发现spring cloud提供出来给用户(开发人员)的eurak api,服务、实例查询等接口比netflix的要精简很多。这个就算不用spring cloud自己提供,似乎也应该这么干,不应该com.netflix.discovery.EurekaClient的接口全部提供一遍,因为很多他原生的这个client接口不是只给用户开发的服务用的;
跟踪eureka client到server的调用,看到eureka server也是以一种restful的接口提供数据服务,因此一般就部署在任意一个web 容器中就可以,原生的部署好像是要搭个tomcat,放一个war包进去,而在spring cloud中,我们一个SpringApplication.run(EurekaServiceApplication.class, args)其实就是后面又偷偷的给你起了个embed的tomcat;
另外大部分时候访问eureka api获取注册数据,其实都是访问了client的一个本地缓存Appplications,里面包含了所有的server那边的注册的服务和实例信息。Client自己会一直维护这个缓存(这个我们自己做也会这么做吧)。

非功能的东西,从代码上的一点感感受。
第一,Spring cloud就是一种形态,甚至可以认为是netflix对开发人员的一个UI,有些句柄做了wrapper,有些数据结构做了wrapper,使得用户端调用的能简单一点。同时还是spring的那套哲学,不用写代码,只要配一配就能利用java的反射给你生成对象,编制出对象的关系,你要做的就是写配置文件(现在升级成用annotation了),典型的框架的思路,你只要符合约定,就能少写代码。但是对于很多程序员,尤其是老程序员来说,了解这些约定的方便总是感觉是被约束,更主要的是不是自己new出来的东西总是用着感觉不踏实。也是封装的有点与确定吧,spring在这方面算是做到极致了。所以感觉提供给最终用户,要么我们自己能把这部分使用讲的特别清楚,要么就是使用原生的netflix。
第二,从代码上看,只是看eureka这一点,netflix和aws的耦合好像还是挺紧密的。应该原来就是给aws用的。
在netflix最正宗的eureka客户端DiscoveryClient里面,居然需要引入aws相关的包。

discovery_client_import_aws

而且很多方法里,这样if is aws 这样的判断看着还是挺丑的,起码像sping cloud里面的包结构一样,公共的搞个父类,aws的作为一种实现多好。也许原来可能人家就给aws一家用的吧。

非常粗的列出主要过程,看上去都是些非常机械的代码调用。比较干巴,(为了避免大片的贴代码,突出一点主要逻辑,把代码里面异常处理这样的try cath,if判定,日志等都给拿掉了)总的比较粗,细节东西体现较少,期待后面随着投入时间更多,注意力更多,带着具体问题去调查,可以了解的深入一些。

因此,未完待续,目录持续更新。。。

 

原创文章。为了维护文章的版本一致、最新、可追溯,转载请注明: 转载自idouba

本文链接地址: Spring-cloud & Netflix 源码解析之Eureka


, , , , ,

No comments yet.

发表评论