|NO.Z.00405|——————————|CloudNative|——|KuberNetes&CI/CD.V43|——|Jenkins.v09|SpringCloud_Eureka.v03|

一、到底要不要使用eureka

### --- k8s也是有自己的服务发现机制

~~~     基于DNS的服务发现：
~~~     CoreDNS：通过service实现服务之间的发现，实现东西流量。

### --- 基于环境变量的服务发现

~~~     有一定的代码量才可以实现，在创建serviceb的时候，若是service-b存活的话，
~~~     会发现SERVICE_B_IP=service-b的clusterIP
~~~     若是serviceb存活的话，kubelet会为serviceb自动生成一系列变量：SERVICE_B_IP，
~~~     SERVICE_B_PORT=Service-b的Port
~~~     这种方式是直接serviceB的IP解析出来，然后服务间调用的是后，
~~~     直接通过IP地址去调用的，不用经过coredns解析，减少延迟，这个延迟是非常低的

### --- 若是使用Istio

~~~     也是可以实现服务发现机制，后期可能会向Istio方向发展了
~~~     Istio：服务网格

二、到底还要不要使用eureka

### --- 老项目：

~~~     若是这个项目运行很久了，之前使用的是eureka的服务发现机制，
~~~     这时需要更改服务发现机制的话，开发可能是很不愿意配置；
~~~     使用eureka之后，后期需要接入Istio服务网格机制是很难接入的。
~~~     # 是无法实现：
~~~     流量控制，容灾机制，灰度发布等的高级功能是无法实现的，若是需要使用这种机制，
~~~     需要把eureka去掉，使用k8s的服务发现机制。

### --- 新项目：

~~~     确认好是使用k8s的服务发现，还是eureka服务发现
~~~     若是不使用eureka，就不是使用SpringCloud架构了，
~~~     就是单独的使用了springboot架构的逻辑

四、如何正确部署Zuul和ConfigServer到k8s中

### --- Zuul

~~~     Zuul和ConfigServer编译完成之后就是一个jar包
~~~     只需要使用deployment启动起来即可，配置一个service，前端就可以调用
~~~     Zuul其它服务时不会调用的，只有前端去调用。所以只需要启动一个service即可。
~~~     前端的根到前端，可以提供一个统一的入口叫api到zuul
~~~     其它的路由比如/api/servicea到zuul
~~~     zuul内部实现这种路由。开发来实现
~~~     只需要配置一个 /——>前端，    /api——>zuul    /api/servicea——>zuul
~~~     这个demons就可以工作了
~~~     zuul也可能要配置一个域名，供研发查看zuul的配置信息。

### --- ConfigServer

~~~     本身是无状态的：它的数据是存放在Git，SVN，MySQL上；这些服务是需要做高可用的。
~~~     ConfigServer和zuul只是一个简单的java应用。
~~~     只需要保证ConfigServer不要宕机即可，部署完之后启动多个副本，
~~~     启动一个ConfigServer的service
~~~     若是ConfigServer要上k8s，需要协调其它应用需要连接ConfigServer的时候，
~~~     就连接ConfigServer的service地址即可：http://config-svc
~~~     需要给ConfigServer配置一个ingress，暴露一个域名，
~~~     这个域名是给研发查看ConfigServer的配置的

Walter Savage Landor:strove with none,for none was worth my strife.Nature I loved and, next to Nature, Art:I warm'd both hands before the fire of life.It sinks, and I am ready to depart

——W.S.Landor