背景： 由于项目需要，准备将之前的项目搬迁到kubernetes上，项目中使用了一些列组件，其中就包含Eureka注册中心。
Eureka架构一般为：gateway网关+注册中心server+服务编排。
所有服务包括gateway都在注册中心注册，采用Eureka的负载均衡来调用服务。Eureka简单示意图如下：
对于每一个StatefulSets中的每个pod其域名如下：
$(statefulset name)-$(ordinal)$(service name)$(namespace)svcclusterlocal
问题一：为什么要使用StatefulSet？
因为我们部署服务时需要提前知道注册中心的地址，由于Kubernetes物理IP不固定的特性（Pod重启机制），我们没办法知道每一台服务节点的位置，所以需要StatefulSet，创建时是按照{0-N-1}的序号创建的，也就是其域名是确定的。
问题二：为什么不能使用集群IP？
首先集群IP需要提前指定（默认k8s自行分配），但不推荐这样做，一是不利于IP资源的利用（只有有一个固定IP段可使用），二是因为我们尝试过使用ClusterIP，发现不是很稳定，原因后续再定位。
对于具体的生产者（也可能是消费者）服务来说，它们工作的原理是在启动时向EurekaServer端注册信息，有两种方法，一种是域名注册，一种是IP地址注册，因为K8s的Pod可变性，无法使用稳定的域名(另外我们测试过通过域名注册会报Unknownhostexception无法解析主机)，因此采用IP地址注册。可以看出它们不需要提前暴露自己的域名和IP，pod变化时，会重新注册IP地址，因此无需部署service。步骤如下：
在注册过程中存在一个风险的问题，如果我们的Eureka Server的地址无意暴露在外，那岂不是通过Eureka协议创建的任意服务都可以进行注册到该Eureka Server吗？（当然如果你配置了服务器的安全组并且使用内网的IP地址或者主机名方式对外提供服务注册地址几乎不存在这个问题。）本章目标
为Eureka Server穿上安全的外套，我的注册中心更安全。
构建项目
依然使用idea开发工具创建一个SpringBoot项目，在依赖的选择界面我们添加Eureka Server、Security相关依赖，pomxml配置文件如下所示：
开启注册中心安全配置
在添加安全配置之前，我们需要把Eureka Server的配置也一并添加上
配置文件的安全配置
修改applicationyml配置文件内容，添加安全配置信息，如下所示：
开启>Eureka官方教程（一） Eureka一览
Eureka官方教程（二） 配置Eureka
Eureka官方教程（三） Eureka客户端服务器通信
Eureka官方教程（四） 自我保护模式
Eureka官方教程（五） Eureka REST *** 作
Eureka是一种基于REST（Representational State Transfer）的服务，主要用于AWS云，用于定位服务，以实现中间层服务器的负载平衡和故障转移。我们将此服务称为Eureka Server。Eureka还附带了一个基于Java的客户端组件Eureka Client，它使与服务的交互变得更加容易。客户端还有一个内置的负载均衡器，可以进行基本的循环负载均衡。在Netflix，一个更复杂的负载均衡器包含Eureka基于流量，资源使用，错误条件等多种因素提供加权负载平衡，以提供卓越的d性。
在AWS云中，由于其固有的特性，服务器来来去去。与使用具有众所周知的IP地址和主机名的服务器的传统负载均衡器不同，在AWS中，负载均衡在使用负载均衡器注册和取消注册服务器时需要更加复杂。由于AWS尚未提供中间层负载均衡器，因此Eureka填补了中间层负载均衡领域的巨大空白。
AWS Elastic Load Balancer是面向最终用户Web流量的边缘服务的负载平衡解决方案。Eureka满足了中层负载平衡的需求。虽然理论上您可以将您的中间层服务置于AWS ELB之后，但在EC2 classic中，您会将它们暴露给外部世界，从而失去AWS安全组的所有实用性。
AWS ELB也是传统的基于代理的负载平衡解决方案，而使用Eureka则不同之处在于负载平衡发生在实例/服务器/主机级别。客户端实例知道他们需要与哪些服务器通信的所有信息。这是一种祝福或诅咒，取决于你看待它的方式。如果您正在寻找AWS现在提供的基于粘性用户会话的负载平衡，Eureka不提供开箱即用的解决方案。在Netflix，我们更喜欢我们的服务是无状态（非粘性）。这有助于实现更好的可扩展性模型，Eureka非常适合解决这个问题。
使用Eureka将基于代理的负载平衡与负载平衡区分开来的另一个重要方面是，您的应用程序可以适应负载均衡器的中断，因为有关可用服务器的信息会缓存在客户端上。这确实需要少量内存，但可以获得更好的d性。
Route 53是一个命名服务，Eureka可以为中间层服务器提供相同的服务，但相似性在那里停止。Route 53是一种DNS服务，即使对于非AWS数据中心，它也可以托管您的DNS记录。Route 53还可以跨AWS区域执行基于延迟的路由。Eureka类似于内部DNS，与世界各地的DNS服务器无关。Eureka也是区域隔离的，因为它不了解其他AWS区域中的服务器。保存信息的主要目的是在区域内进行负载平衡。
虽然您可以使用Route 53注册中间层服务器并依赖AWS安全组来保护您的服务器免受公共访问，但您的中间层服务器身份仍然会暴露给外部世界。它还具有传统的基于DNS的负载平衡解决方案的缺点，其中流量仍然可以路由到可能不健康或甚至不存在的服务器（在AWS云的情况下，服务器可以随时消失）。
您通常在AWS云中运行，并且您有许多中间层服务，您不希望向AWS ELB注册或暴露来自外部世界的流量。您要么寻找一个简单的循环负载平衡解决方案，要么愿意根据您的负载平衡需求在Eureka周围编写自己的包装器。您不需要粘性会话并在外部缓存（例如memcached）中加载会话数据。更重要的是，如果您的架构适合基于客户端的负载均衡器的模型，Eureka可以很好地适应这种用途。访问 >
在应用启动类上添加@EnableEurekaServer注解，声明为Eureka Server
配置文件applicationyml中添加以下内容：
启动应用，访问 >
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）