如有疑问,请看视频:CAS单点登录(第7版)
高度可用的 CAS 部署是一种提供弹性以响应各种故障模式的部署,以便 CAS 在发生故障时继续提供 SSO 服务。我们提供了一个保举的架构,为规划和实行满足机构性能和可用性要求的 CAS 部署提供了一个起点。它还提供了一个框架,用于明白 HA 留意事项施加的 CAS 软件组件要求。
CAS 的高可用性 (HA) 配置是通过确保有富足的冗余来实现的,这样服务在面对组件故障时是稳健的,并且可以在不绝机服务的环境下完成日常维护。这可以通过多节点实现,在较小程度上可以通过具有高级假造机功能的单节点 CAS 来实现。本文档将重点介绍实现 HA 所需的 CAS 服务器组件。对 HA 配置的更定量分析取决于支持的底子设施和服务,这超出了本文档的范围。
CAS Server 软件在极其可靠方面有着良好的纪录。但是,CAS 服务器只是身份验证必须遍历才气顺遂工作的软件和硬件的一小部分。部署职员通常不但将集群用于负载处理,还用于故障转移。纵然没有发生故障,有时也需要重新启动服务器。比方,如果在使用系统级别安装了严重的安全修复步伐,则应立即重新启动服务器。在 CAS 服务器集群中,纵然在最繁忙的时间,也可以通过滚动重启轻松实现这一点。
传统上,使用单个服务器会将此类重启延迟到不太繁忙的时间,同时运行已知漏洞。然而,近来随着人们对假造机技术及其固有的冗余和容错本事的日益接受,单节点 CAS 已经能够实现雷同的质量。
下图突出体现了高可用性 CAS 部署的重要方面。
值得指出的是此体系布局的一些重要特性:
依赖系统最多可以容忍 N-1 个节点故障。(其中 N 是节点总数。
CAS 本身最多可以容忍 N-1 个节点故障。
丢失缓存节点不会导致复制缓存中 SSO 状态数据(即票证)丢失。
丢失缓存节点可能会导致非复制缓存中的 SSO 状态数据丢失。
SSO 状态数据丢失始终是正常的:用户重新进行身份验证。
在具体讨论保举体系布局的各个方面之前,我们提供了一个规划高可用性部署的引导原则:
以简单为目标
设计满足性能和可用性要求的最简单的解决方案。
经验表明,简单性是乐成且强大的 HA 部署的重要系统特性。力求简单,您将得到很好的服务。
可以通过实行在复杂的假造化环境中运行的单节点 CAS 来实现高可用性。这种高可用性方法很有吸引力,因为它简化了 CAS 服务器配置,但需要的硬件假造化技术可能不存在且不可用。
物理架构
在单节点 VM 体系布局中,CAS 服务器以及须要的先决条件和软件依赖关系部署在单个主机 VM 中。在此部署方案下,默认的内存中票证注册表就富足了,不需要 Servlet 会话复制。这简化了部署配置,如果 VM 底子架构足以满足 HA 和可扩展性需求,则保举使用此方法。
鲁棒性
硬件组件故障/规复是假造化环境的一项功能,因此 CPU、内存或电源的损失不会导致 CAS 服务器故障。
零停机时间维护方法
此配置无法实现真正的零停机时间维护(即对最终用户没有显着影响)。但是,通过使用大多数 VM 底子架构的克隆功能,可以在不绝机的环境下完成维护和升级的暂存。新的 CAS 服务器节点准备就绪后,可以实行短暂的切换,这将有效地竣事所有当前的 SSO 会话。这可以通过在部署新的 cas.war 后,在低流量时段安排 Tomcat 的重新启动来完成。
可扩展性
CAS 本身具有适度的计算要求,因此任何现代企业级服务器硬件都足以在典型部署场景中处理 10,000 个用户。在近来的一次 Client Engagement 负载测试中,单节点部署产生了良好的结果,CAS 以每秒 61 个请求的速率处理 200 个并发用户,这大约相称于每小时 108000 个身份验证事务。这些数字当然具有代表性,任何基准都将高度依赖于当地的底子设施。VM 环境应该能够扩展可用的 CPU 和内存,以满足各种需求。
高可用性 CAS 部署由硬件负载均衡器后面的两个或多个节点构成,处于主动/被动或主动/主动模式。通常,前者提供简单性和富足的故障转移;后者提高了资源使用率并减少了服务中断,但代价是增加了复杂性。主动-被动配置可以在主 CAS 节点发生故障时通过手动或自动故障转移来完成。可以使用聚集票证注册表状态进行主动-主动配置,以便任何可用的 CAS 节点都可以为 CAS 服务器的任何请求提供服务。有许多选项可用于实行具有共享票证状态的主动-主动配置。
可以通过实行在多个 VM 或物理主机上运行的多节点 CAS 部署来实现 HA。这种方法很有吸引力,因为它允许对服务进行真正的零停机时间维护,但代价是部署复杂性略有增加。
多节点 CAS 通常涉及以下内容:
安装 CAS 服务器的多个实例(以便可以烧毁一个或多个服务器,而不会使 CAS 服务变得不可用)
将 CAS 服务器的多个实例配置为共享票证状态(这样,无论用户或服务与哪个 CAS 服务器交互,每个 CAS 服务器的响应都是雷同的。
配置解决方案,以便在聚集 CAS 服务器之间引导流量,以检测组件故障并从服务中删除故障组件
(可选)配置一个解决方案,以便在 CAS 实例之间共享会话状态和会话故障转移(这通常不符合,因为最终用户 CAS 会话往往是短暂的,并且体验更像是请求-响应风格,而不是面向会话的)- 更喜欢短期的粘性(又名长期会话)负载平衡(可能是大型 NAT 部署的一个题目)
订定恰当的应急计划,以便在使用时规复所需的抗故障裕量。(比方,具有三个聚集 CAS 服务器实例,为仅用两个实例即可提供服务的负载提供服务。
物理架构
物理架构可以通过 VM 或物理硬件实现。需要留意的是,在共享票证状态模型(主动/主动模式)中,CAS 服务器节点需要能够在所有节点之间传达票证状态,因此,需要放宽此类节点之间的防火墙限定,以允许票证状态复制。
服务终端节点是在负载均衡器上配置的假造 IP 地点。因此,所有请求都由负载均衡器处理,然后路由到可用的 CAS 节点。
鲁棒性
如果 CAS 节点发生故障,工作负载和身份验证请求可以正确地重新路由到另一个 CAS 节点。通过故障转移方案,某些状态可能会丢失,具体取决于用户在登录流中的位置,因此,一旦请求的重新路由从失败节点到达克隆,用户可能需要再次看到 CAS 登录屏幕。这种故障模式可以通过 Servlet 会话状态复制来消除。
零停机时间维护方法
维护工作,包括升级和应用步伐补丁到软件,可以通过两种一样平常方法进行:
在主动-被动模型中,工作可以在被动 CAS 节点上离线实行。然后,调解负载均衡器以在准备就绪后切换准备好的节点,从而切换主动-被动节点。这会导致所有 CAS SSO 会话被重置,如果在使用率高的时候进行,可能会导致一些票据验证失败。有关此方法的更多具体信息,请参阅下文。
在主动-主动模型中,当至少一个其他 CAS 服务器节点保持运动状态以响应请求时,可以使一个节点脱机。升级过程完成后,服务器可以返回到池,同时从其他运动节点获取票证状态。某些分布式票据注册表模型能够通过从其他节点吸收票据数据来引导自身,而无需任何手动配置或调解。有关此方法的更多具体信息,请参阅下文。
可扩展性
可扩展性是通过向集群添加新的 CAS 节点来实现的。
主动/被动模式
在主动/被动负载均衡配置中,N 个节点中有 1 个在任何给定时间为所有请求提供服务。这简化了票据存储要求,因为无需在多个应用步伐节点之间共享票据状态。
特殊是,将票据存储在内存中的默认票据注册表组件适用于主动/故障转移设置,因为节点故障会导致票据丢失。值得重复的是,票证丢失会导致应用步伐正常失败,用户需要重新向 CAS 进行身份验证以创建新的 SSO 会话;在先前的 SSO 会话下创建的 CAS 客户端会话不会中断或丢失数据。
主动/主动模式
主动/主动模式下的负载均衡器同时向所有 N 个节点提供请求。负载均衡器根据配置的算法选择一个节点来为请求提供服务;通常最不活跃或循环。在这种系统架构中,使用票证存储至关重要,无论哪个 CAS 节点请求票证,都可以找到票证。
讨论此要求的起源是有启发性的。对于来自完全差别的网络源的工单,有两种交互:
用户的 Web 欣赏器联系 CAS 生成工单。
Target 服务使用票证联系 CAS 进行验证。
由于这两个请求从差别的源地点流经负载均衡器,因此无法包管两个请求都由同一个 CAS 节点提供服务。因此,要求无论请求票证的 CAS 节点如何,都可以找到票证。应该清晰为什么内存存储不得当主动/主动部署。
主动-主动架构允许在升级时 CAS 服务器版本之间实现零停机时间转换。可以将一个 CAS 节点实例下线,进行维护,然后重新投入生产。然后,对所有其他 CAS 节点重复雷同的计谋。
主动/主动部署还有进一步的留意事项:会话关联。会话关联性是大多数负载均衡器设备的一项功能,其中设备对传入请求实行状态管理,并在一段时间内将客户端路由到同一节点以处理后续请求。默认环境下不再需要此功能,因为 CAS 能够直接在客户端维护 CAS 登录/注销 Web 流的状态。但是,提供了 additional选项,以允许在须要时将 servlet 容器会话存储与复制选项一起使用。请参阅本指南以相识更多信息。
避免循环 DNS
我们剧烈建议避免使用循环 DNS 作为硬件负载均衡器的经济高效替代方案。客户端缓存过期计谋是完全不可控的,典型的缓存过期时间比节点故障转移的预期时间长得多。反向代理或软件负载均衡器是硬件的保举替代方案。
以下票据存储组件在易用性、可扩展性和容错性之间提供了最佳衡量,适用于主动/被动和主动/主动设置。
存储技术的特定选择应由底子布局和专业知识以及性能和可用性考虑来驱动。拥有一个高性能的存储,而您缺乏在题目总是出现时进行故障清除的专业知识,这几乎是没有代价的。
各种存储组件的技术留意事项值得讨论,因为存在影响可用性和性能特性的显着差别。像 Hazelcast 这样的缓存系统提供了一个分布式缓存,无论联系的节点如何,它都能提供单一、一致的条目视图。分布式缓存依靠复制来提供一致性。这些类型的缓存系统不需要复制,并且通常以牺牲一些长期性为代价提供简单性。
许多基于缓存的票据注册表支持跨网络安全复制票据数据,以便在复制尝试时对票据进行加密和签名,以防止嗅探和窃听。有关更多信息,请参阅本指南。
在 HA 环境中,CAS 集群中的所有节点都必须复制和访问服务定义。通常,这可以通过使用由 JPA、LDAP、MongoDB 等支持的集中式注册表实现来实现。由文件系统支持的注册表需要设计一个过程来确保正确复制文件,无论是手动复制照旧通过后台保卫步伐复制。
我们剧烈建议所有到后端数据存储(如 LDAP 目次和数据库)的 IO 连接尽可能使用连接池。它充实使用了计算资源(尤其是对于 SSL/TLS 连接)和 IO 资源,同时提供了最佳性能特性。
CAS 采用者通常使用使用实践中已使用的工具来监控 CAS 服务的可用性,以监控其他企业 Web 应用步伐。CAS 引入了一个新的适度监控页面,默认环境下,该页面由请求者的remote_address进行身份验证。
通道秘密性(通过 SSL/TLS)是假设的,并且对 CAS 系统的安全状况至关重要。这包括前通道(在用户欣赏器代理和 CAS 服务器之间)和反向通道(在 Web 应用步伐和 CAS 服务器之间)https 流量、负载均衡器或内容过滤器与 CAS 节点之间的任何中间代理流量,以及主身份验证(比方 LDAPS)和属性解析(基于 SSL 的 JDBC)。在任何阶段隐私控制的任何中断都构成了系统的团体安全性。
CAS 服务器升级应通过建议的 WAR 覆盖方法进行。作为一种最佳实践,覆盖方法允许从众所周知的公共存储库中无缝获取预期的 CAS 服务器版本,同时在下载的二进制构件之上放置特定的自定义更改。在 overlay 方法的具体细节中,可能还需要将配置外部化到 cas.war 之外,以便同一 cas.war 文件的属性和日记纪录配置可以在差别层之间有所差别。也就是说,外部化特定于环境的配置允许将雷同的 cas.war 从服务器提升到服务器,从层提升到层,这增加了在生产环境中测试和验证的 Web 应用步伐将像在生产环境中一样运行的信心。
负载测试是确保 CAS 服务器部署已准备好用于黄金时段生产的重要部分。本页概述了可用于对部署运行性能测试并观察结果的许多计谋和工具。
Locust 是一种易于使用的分布式用户负载测试工具。它用于对 Web 站点(或其他系统)进行负载测试,并确定系统可以处理多少个并发用户。有关更多信息,请参阅本指南。
Apache JMeter 是一个很棒的性能测试工具,在 Java 社区中被广泛使用。有关更多信息,请参阅本指南。
Artillery 是一个可扩展、灵活且易于使用的平台,其中包含生产级负载测试所需的工具有关更多信息,请参阅本指南。
Locust 是一种易于使用的分布式用户负载测试工具。它用于对 Web 站点(或其他系统)进行负载测试,并确定系统可以处理多少个并发用户。有关更多信息,请参阅本指南。
Locust 的一个基本功能是您可以在 Python 代码中描述所有测试。不需要鸠拙的 UI 或臃肿的 XML,只需简单的代码。为此,您需要下载 Python。接下来,从这里下载 Locust 测试套件,并配置一个假造环境来安装模块:
1
2
3
| pip3 install virtualenv
virtualenv mylocustenv/
pip3 install -r requirements.txt
| 通过以下方式安装 Locust:
创建一个 credentials.csv 文件,其中包含用于负载测试的 username,password 条目。
1
| echo casuser,Mellon > cas/credentials.csv
| 按如下方式运行脚本:
1
2
3
4
| locust -f cas/casLocust.py --host=https://cas.example.org
...[2017-05-02 16:31:49,742] test/INFO/locust.main: Starting web monitor at *:8089[2017-05-02 16:31:49,744] test/INFO/locust.main: Starting Locust 0.8a2
| 导航到 http://localhost:8089 并继续启动测试召集。
有关其他选项,请使用:
Apache JMeter 是一个很棒的性能测试工具,在 Java 社区中被广泛使用。
下载 JMeter 二进制文件。
将 apache-jmeter-*.tgz 解压缩到您的首选位置
运行 bin/jmeter.sh|bat
请留意: Mac 用户还可以使用流行的 HomeBrew 包管理器来安装 JMeter。
您将在下面找到三种最流行的 CAS 实现风格的三个通用可运行登录脚本。请根据您的需要随意编辑和使用。
尽管这些脚本支持差别的登录方法,但它们确实具有一些共同特性。
用户定义的变量
ThreadCount - 线程数(有点像 Users)。 建议从 100 个用户左右开始。
Duration (持续时间) - 测试应运行多长时间。 通常,线程 (用户) 越多,持续时间应越长
RampUpPeriod - 增加到完整的线程计数集需要多长时间
线程组(或测试):
Loop Count - Number of Loops,或者更准确地说是要运行测试的用户 #。
Count 将与将运行测试的用户总数相关联
Forever 复选框将循环遍历文件并继续运行,直到手动停止或直到到达 “User Defined Variables” 页面的 Duration
CSV 获取用户/暗码:
包含测试用户根据的文件的名称和位置
应采用 User,Password 格式,“User”、“comma”和“Password”之间没有空格
脚本可以从 此处 下载。
测试脚本:CAS_CAS.jmx,用于测试充当 CAS 身份提供商的服务器。
使用标准 CAS 登录过程的 CAS 原版安装
不需要 SP (服务提供商)
用户定义的变量:
IdPHost - CAS 实例的 URL
CasSP - SP(服务提供商)URL,但不必处于运动状态
测试片段:
GET - CAS 登录页面 – 典型 CAS 登录的访问登录页面
POST - 登录凭据 – 将凭据从用户文件发布到 CAS 实例
GET - 使用服务票证的用户信息 - 使用用户登录时生成的 CAS 服务票证获取用户信息
在 Assertion 下,可能需要更新预期的用户结果
GET - 用户注销 – 通过 CAS 注销从 CAS 会话中注销用户
测试脚本:CAS_Oauth.jmx,用于测试充当 OAuth 提供者的服务器。
CAS 支持 OAuth 登录过程
运动 SP 是可选的
脚本反映了 OAuth 的最常见使用方式,即授权代码方法
用户定义的变量:
IdPHost - CAS 实例的 URL
CasSP - SP(服务提供商)URL,但不必处于运动状态
SpClientId - CAS 服务文件中 SP 的 clientId
SpRedirectUri - SP 中将用于吸收“授权码”的端点
SpState - 使用的 CSRF 令牌
SpClientName - 用于身份验证的 OAuth 调用类型
SpResponseType - 正在使用的 OAuth 方法,在本例中为“code”,代表授权代码
SpClientSecret - 在 SP 和 CAS 之间共享的密钥短语或单词
测试片段:
验证服务提供商 – 验证指向 SP 的 URL 是否正确(可选,可以禁用)
启动 CAS 登录过程 – 访问设置了所有参数的 OAuth 的 CAS 登录页面
1a-1d – 发布用户的登录凭据,然后重定向以在 Access Token 中获取代码
由于测试时的编码题目,分为多个进程
GET - 使用访问令牌的用户配置文件 - 调用 CAS 以使用访问令牌获取用户信息
在 Assertion 下,可能需要更新预期的用户结果
GET - 用户注销 – 通过 CAS 注销从 CAS 会话中注销用户
测试脚本:CAS_OIDC.jmx,用于测试充当 OpenID Connect 提供步伐的服务器。
说明和测试序列与 OAuth 工作流程几乎雷同,只是增加了 ID 令牌验证。
测试脚本:CAS_SAML2.jmx,用于测试充当 SAML2 身份提供商的服务器。
CAS 对 SAML2 登录过程的支持
需要运动的 SP。
对于此测试,使用了 SimpleSAMLphp
用户定义的变量:
CasSP - 使用 SAML 注册的 CAS SP 的域
ProviderId - SP 元数据中声明的 SAML 实体 ID
测试片段:
转到 SP 以进行 CAS 登录 – 受 SAML2 保护的 SP 页面将重定向到 CAS 登录端点
POST - 登录用户 – 将用户文件中的凭据发布到 CAS SAML2 登录名
POST - CAS 对 SP 的授权 - 将响应从 CAS 发送到 SP 以进行处理和最终请求用户信息
可能需要更新 Assertion 才气乐成返回用户信息
GET - 用户注销 – 通过 CAS 注销从 CAS 会话中注销用户
将测试脚本生存到系统后,您可以在 JMeterGUI 中或通过命令行运行。剧烈建议使用 GUI 对脚本进行故障清除,以便在您的环境中工作。然后,当您真正开始加载测试时,您可以通过命令行实行此使用。
要激活 JMeter GUI,请从命令行键入:
1
| > /usr/local/bin/jmeter
| 此路径应对应于您选择安装 JMeter 的位置。
通过命令行启动 JMeter 的简单示例:
1
| > /usr/local/bin/jmeter -n -t your_script.jmx
| -n 在非 GUI 模式下运行 JMeter。-t 路径添加到 .jmx 测试文件。
可以在 JMeter 站点上找到更多示例。
负载测试是确保 CAS 服务器部署已准备好用于黄金时段生产的重要部分。Artillery 是一个可扩展、灵活且易于使用的平台,其中包含生产级负载测试所需的工具。
您可以通过 npm 安装 Artillery:
1
2
| npm install -g artillery
artillery --version
| 脚本和场景可以从 此处 下载。
对于每个测试脚本,您可以运行以下命令:
1
2
| cd ./etc/loadtests/artillery
artillery run "${artilleryScript}"
| 服务发现是基于微服务的架构的关键原则之一。本指南旨在介绍内置 CAS 支持的选项,这些选项可用于查找节点以实现负载均衡和故障转移。
Consul Server 发现服务
HashiCorp Consul 具有多个组件,但总的来说,它是一个用于在底子设施中发现和配置服务的工具。它提供服务发现、运行状况检查等关键功能。
更多。。。
Eureka Server 发现服务
Eureka 是一种基于 REST 的服务,由 Spring Cloud Netflix 提供,主要用于查找服务,以实现中间层服务器的负载平衡和故障转移。
更多。。。
HashiCorp Consul 具有多个组件,但总的来说,它是一个用于在底子设施中发现和配置服务的工具。它提供的主要功能:
服务发现:Consul 的客户端可以提供 api 或 mysql 等服务,其他客户端可以使用 Consul 来发现给定服务的提供者。使用 DNS 或 HTTP,应用步伐可以轻松找到它们所依赖的服务。
运行状况检查:Consul 客户端可以提供恣意数量的运行状况检查,这些检查要么与给定服务相关联(“Web 服务器是否返回 200 正常”),要么与当地节点关联(“内存使用率是否低于 90%)”。使用员可以使用此信息来监控集群运行状况,服务发现组件可以使用此信息将流量从运行状况不佳的主机中路由出去。
KV 存储:应用步伐可以将 Consul 的分层键/值存储用于多种用途,包括动态配置、功能标志、调和、向导者选举等。简单的 HTTP API 使其易于使用。
多数据中央:Consul 支持开箱即用的多个数据中央。这意味着 Consul 的用户不必担心构建额外的抽象层以扩展到多个地区。
CAS 提供了一个基于 Spring Cloud Consul 并通过 Spring Cloud 引导的启用 Consul 的服务发现服务器。
要运行 Consul 发现服务器,请参阅本指南以获取安装说明。简单的 Consul 安装可以作为 consul agent -dev -ui 运行
通过 docker search consul 查找符合且相关的现成 Docker 镜像。
部署并采用默认设置后,Consul 仪表板将在以下位置可用:http://localhost:8500/ui。
请留意,Consul 代理客户端必须可用于所有 CAS 服务器节点。默认环境下,代理客户端应位于 localhost:8500。有关如何启动 Agent 客户端的具体信息,请参阅 Agent 文档。
每个单独的 CAS 服务器都能够自动向发现服务器注册自身,条件是提供了指示 CAS 服务器如何查找和连接到发现服务器服务的配置。
通过在 WAR 覆盖中包含以下依赖项来添加支持:
Apache Maven
Gradle
BOM - Spring
BOM - Gradle
资源
1
2
3
4
5
6
7
8
9
10
| dependencies {
/*
The following platform references should be included automatically and are listed here for reference only.
implementation enforcedPlatform("org.apereo.cas:cas-server-support-bom {project.'cas.version'}")
implementation platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
*/
implementation "org.apereo.cas:cas-server-support-consul-client"}
| CAS 配置目次中提供了以下设置和属性:
第三方
笔记
下面列出的配置设置在 CAS 配置元数据中标志为 Third Party(第三方)。此标志表示配置设置不受 CAS 生态系统的控制、拥有或管理,并且会影响第三方库(如 Spring Boot 或 Spring Cloud to CAS)提供的功能。有关更多信息,您可能必须访问第三方泉源以查找更多具体信息。
Show entries
搜索:
| · spring.cloud.config.discovery.enabled=false
指示已启用配置服务器发现的标志(将通过发现查找配置服务器 URL)。
org.springframework.cloud.config.client.ConfigClientProperties$Discovery.
如何配置此属性?
| · spring.cloud.config.discovery.service-id=configserver
Service ID 用于查找 config server。
org.springframework.cloud.config.client.ConfigClientProperties$Discovery.
如何配置此属性?
| · spring.cloud.consul.config.acl-token=
org.springframework.cloud.consul.config.ConsulConfigProperties.
如何配置此属性?
| · spring.cloud.consul.config.data-key=data
如果 format 为 Format.PROPERTIES 或 Format.YAML,则以下字段将用作查找 consul 的 key 以进行配置。
org.springframework.cloud.consul.config.ConsulConfigProperties.
如何配置此属性?
| · spring.cloud.consul.config.default-context=application
org.springframework.cloud.consul.config.ConsulConfigProperties.
如何配置此属性?
| 体现 1 到 5 的 81 个条目
上一页12345...17下一页
要启用其他日记纪录,请配置 log4j 配置文件以添加以下级别:
1
2
3
4
| <Logger name="org.springframework.cloud.consul" level="debug" additivity="false">
<AppenderRef ref="casConsole"/>
<AppenderRef ref="casFile"/></Logger>
| Eureka 是一种基于 REST 的服务,主要用于查找服务,以实现中间层服务器的负载平衡和故障转移。Eureka 既提供发现服务器,也支持 Client 端,这些 Client 端将是池中的各个 CAS 服务器本身。可以将服务器配置和部署为高可用性,每个服务器都将已注册服务的状态复制到其他服务器。
CAS 提供了一个支持 Eureka 的服务发现集成,该集成基于 Spring Cloud Netflix,并通过 Spring Cloud 引导。
每个单独的 CAS 服务器都能够自动向发现服务器注册自身,条件是提供了指示 CAS 服务器如何查找和连接到发现服务器服务的配置。
通过在 WAR 覆盖中包含以下依赖项来添加支持:
Apache Maven
Gradle
BOM - Spring
BOM - Gradle
资源
1
2
3
4
5
6
7
8
9
10
| dependencies {
/*
The following platform references should be included automatically and are listed here for reference only.
implementation enforcedPlatform("org.apereo.cas:cas-server-support-bom {project.'cas.version'}")
implementation platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
*/
implementation "org.apereo.cas:cas-server-support-eureka-client"}
| CAS 配置目次中提供了以下设置和属性:
第三方
笔记
下面列出的配置设置在 CAS 配置元数据中标志为 Third Party(第三方)。此标志表示配置设置不受 CAS 生态系统的控制、拥有或管理,并且会影响第三方库(如 Spring Boot 或 Spring Cloud to CAS)提供的功能。有关更多信息,您可能必须访问第三方泉源以查找更多具体信息。
Show entries
搜索:
| · eureka.client.allow-redirects=false
指示服务器是否可以将客户端请求重定向到备份服务器/集群。如果设置为 false,则服务器将直接处理请求,如果设置为 true,则可能会向客户端发送 HTTP 重定向,并使用新的服务器位置。
org.springframework.cloud.netflix.eureka.EurekaClientConfigBean.
如何配置此属性?
| · eureka.client.availability-zones=
获取此实例地点地区的可用区 (在 AWS 数据中央中使用) 的列表。这些更改在运行时在 registryFetchIntervalSeconds 指定的下一个注册表获取周期生效。
org.springframework.cloud.netflix.eureka.EurekaClientConfigBean.
如何配置此属性?
| · eureka.client.backup-registry-impl=
获取实现 BackupRegistry 的实现的名称,以便仅在 eureka 客户端启动时第一次获取注册表信息作为回退选项。对于需要对注册表信息进行额外弹性的应用步伐,可能需要这样做,没有这些规复本事,它就无法运行。
org.springframework.cloud.netflix.eureka.EurekaClientConfigBean.
如何配置此属性?
| · eureka.client.cache-refresh-executor-exponential-back-off-bound=10
缓存刷新实行步伐指数回退相关属性。它是重试延迟的最大乘数值,以防发生一系列超时。
org.springframework.cloud.netflix.eureka.EurekaClientConfigBean.
如何配置此属性?
| · eureka.client.cache-refresh-executor-thread-pool-size=2
用于初始化 cacheRefreshExecutor 的线程池大小。
org.springframework.cloud.netflix.eureka.EurekaClientConfigBean.
如何配置此属性?
| 体现 1 到 5 的 67 个条目
上一页12345...14下一页
如果配置中的 Eureka 服务器 URL 之一嵌入了根据(curl 样式,如 http://user:password@localhost:8761/eureka),则将自动添加对 HTTP 基本身份验证的支持。
要启用其他日记纪录,请配置 log4j 配置文件以添加以下级别:
1
2
3
4
5
6
7
8
| <Logger name="org.springframework.cloud" level="debug" additivity="false">
<AppenderRef ref="casConsole"/>
<AppenderRef ref="casFile"/></Logger><Logger name="com.netflix" level="debug" additivity="false">
<AppenderRef ref="casConsole"/>
<AppenderRef ref="casFile"/></Logger>
|
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。 |