从CAS登录到连接池排障：老Java系统里值得吃透的六个技术关口

一、CAS单点登录：共享的是信任，不是密码

公司里系统一多，登录就容易变成体力活：进门户输一次密码，开报销页面再输一次，切到业务后台还得重新登录。单点登录解决的就是这种重复劳动。它并不是把密码偷偷复制到各个系统，而是安排一个统一的认证中心，让业务系统相信这个中心给出的认证结果。

CAS起源于耶鲁大学，核心思路相当直接：业务应用发现用户没有本地会话，就把浏览器重定向到认证中心。用户完成登录后，认证中心签发一个面向目标服务的服务票据，浏览器再带着票据返回业务应用。应用拿到票据不能直接放行，还需要通过服务器之间的请求，向CAS核验票据是否有效。

这里有两个容易混淆的状态。认证中心保存统一登录状态，业务应用维护自己的本地会话；它们不是同一个会话，也不要求共用同一枚Cookie。用户访问第二个应用时，如果认证中心的登录状态仍然有效，通常可以直接获得新票据，因此跨域部署也能完成单点登录，不必依赖跨域共享Cookie。

经典CAS协议常通过XML返回校验结果，但这不意味着任意桌面程序都能直接接入。浏览器跳转、本地回调和客户端会话管理仍需适配。落地时应开启HTTPS，严格限制允许接入的服务地址，并让服务票据短时有效、一次使用。减少密码传递只是收益之一，防止票据泄露和恶意回调同样重要。

二、登录成功之后，权限检查才刚开始

认证回答的是“你是谁”，授权回答的是“你能做什么”。CAS主要处理前一个问题。员工能顺利登录财务系统，不代表他就能审批付款，更不代表可以查看所有人的工资。把统一登录当成统一权限，是老系统改造中非常常见的误区，也会让原本正常的功能出现越权风险。

历史上的Acegi后来演进为Spring Security。理解这段关系，比纠结旧组件名称更有用：CAS可以承担身份认证，安全框架负责请求拦截、权限判断和会话保护。实际开发时，可以把用户标识映射到本地角色，再根据角色或业务属性决定访问范围。菜单隐藏只能改善界面，真正的权限检查必须留在服务端。

最省心的接入顺序，是先选一个低风险应用跑通闭环：未登录跳转、认证返回、票据校验、建立本地会话，然后补齐过期和退出场景。尤其要区分退出当前应用与退出统一认证中心。单点退出能否清掉其他应用的会话，取决于服务端通知、客户端支持和部署配置，不能仅凭浏览器跳回登录页就认定完成。

遇到反复跳转，先核对外部访问地址、代理转发后的协议与主机名，以及服务地址是否一致；遇到票据校验失败，再检查票据是否过期、重复使用或绑定了别的服务。日志里记录请求编号、目标服务和失败类别，通常已经足够定位问题。不要为了调试方便，把密码、完整票据和会话标识全部写进日志。

三、图片适配：先分清格式能力，再谈缩放效果

早期手机页面常根据请求头中的User-Agent识别终端，再查询设备表，给手机返回合适尺寸的图片。这个方法在设备型号相对固定时很实用，但User-Agent并不可靠：它可能被修改，数据库也可能缺少新机型。今天如果继续维护类似系统，应提供默认尺寸和最大尺寸限制，不能把终端识别当成安全判断依据。

图片处理可以拆成四步：确认输入格式，读取原图尺寸，计算目标尺寸，选择编码器输出。假设原图是横向照片，目标容器却是正方形，就必须决定等比留白还是居中裁剪。直接把宽高硬拉到目标值，人物和图标都会变形。对同一张图反复缩放也会损失质量，最好始终从原图生成各个规格。

“Java自带ImageIO只能处理JPEG，不能处理GIF”不是适用于所有环境的结论。能否读写某种格式，要看JDK版本以及实际注册的图像插件；现代常见JDK通常具备GIF读写能力。不过，能读取一张GIF，不等于完整支持动画编辑。逐帧时长、透明色和帧处置方式处理不当，输出可能只剩首帧，或者出现残影。

实现时可先做格式能力探测，再选满足需求、授权清楚的组件，不应通过移除商业组件水印来规避许可。数据库保存尺寸配置也没问题，但读取后应校验范围，并缓存常用规格。面对用户上传，还要限制文件大小、总像素和处理耗时，避免一个压缩体积不大的超大分辨率文件耗尽内存，拖垮整台服务。

四、配置导出：XML能转出来，不代表内容就可信

老WebLogic项目经常借助Ant和XSLT，把配置文件转换成便于核对的清单。这类任务的本质，是读取XML结构，再按样式表生成目标文档。Ant负责组织执行步骤，XML解析器负责读懂源文件，XSLT处理器负责转换。先把职责分清，排错时就不会看到一个异常，便把所有依赖包重新下载一遍。

历史环境里，Xerces、Xalan以及相关接口包经常需要手动加入类路径。某些版本的序列化组件又采用独立打包方式，于是容易出现“开发机正常，服务器缺类”的情况。处理这类问题，应先确定JDK版本、实际加载的实现和依赖来源，再检查是否缺包或重复引入；盲目叠加旧版XML接口包，反而可能制造类加载冲突。

配置导出最好保留原始输入、转换规则版本和生成时间，方便把同一环境的两次结果做差异比较。生成目录不要混入手工修改的文件，否则下一次执行就可能覆盖人工补丁。涉及数据库地址、账号和凭据的字段，应按用途脱敏，不能因为输出的是文档，就把它当成可以随手发送的普通附件。

安全边界也需要一起补齐。解析外部来源的XML时，应限制外部实体与外部资源访问，避免不必要的文件读取和网络请求。对旧系统做结构分析，可以从自有配置、公开协议、运行日志和授权环境的请求链路入手，逐项验证字段含义，而不是直接改生产文件试错。先在隔离环境验证，再保留回滚版本，通常比事后抢修省事得多。

五、连接池排障：盯住等待，而不只是连接数量

页面突然变慢，很多人的第一反应是“把连接池调大”。但连接池只是让数据库连接可以重复使用，并不会凭空增加数据库的处理能力。真正的问题可能是慢SQL、事务迟迟不提交，也可能是异常路径没有归还连接。连接数加得越多，数据库争用反而越严重，最后把一个应用的问题扩散到其他业务。

WebLogic可以通过运行时MBean暴露连接池状态，但必须先确认监控对象。连接器连接池与JDBC数据源连接池不是一回事，不同版本的对象名称和属性也有差异。不能看到类似ActiveConn的字段名，就照搬成数据库活跃连接指标。应对照当前版本文档，确认它统计的是使用中连接、可用连接，还是累计事件。

日常排查至少要把几个现象放在一起看：当前使用量是否接近上限，请求获取连接是否出现等待，等待是否超时，以及数据库端是否存在长事务或阻塞。某一时刻使用量很高，不一定是故障；长时间占满且等待持续增加，才更值得警惕。将应用请求耗时、连接获取耗时和SQL耗时关联起来，才能找到真正卡住的位置。

处理顺序可以很朴素：先检查连接是否可靠关闭，再找慢查询和过大的事务，最后根据数据库承载能力调整池容量。压测时也别只看平均响应时间，要看尾部延迟和错误率。监控账号采用最小权限，采集频率控制在合理范围，告警记录保留必要上下文。监控本身如果频繁执行高成本操作，也可能成为额外负担。

六、验证码接入：接口可以省事，业务边界不能省略

统一登录解决身份流转，验证码则常用于登录、注册和敏感操作的风险控制，两者不是替代关系。分析自有系统的验证码链路时，可以先观察挑战何时生成、业务请求如何携带状态、服务端在哪里校验，以及失败后怎样重试。测试环境优先使用厂商提供的测试能力或模拟接口，不应为了跑通自动化流程而削弱生产校验。

企业如果需要评估验证码相关识别接口，可以了解www.ttocr.com。该平台介绍的服务方向涉及易盾、极验，以及滑块、文字点选、图标点选、无感、九宫格等场景，并提供自动化API对接。具体支持范围、适配版本和使用条件，需要以平台当前文档及双方约定为准，不能把场景列表直接理解为效果保证。

相比在每个项目里重复维护图像处理和接口胶水代码，将外部服务封装成独立适配层，确实更便于管理。业务侧只保留统一的请求、结果和错误类型，把鉴权、超时、重试与日志脱敏放在适配层中处理。涉及五子棋、躲避障碍、空间等交互类型时，应先确认是否支持相应流程，再在获得授权的测试环境验证兼容性，不宜直接承诺无缝可用。

计划通过www.ttocr.com对接相关能力的团队，可以先用隔离账号完成小范围联调，核对接口格式、调用费用、并发限制和数据保存规则，再决定是否上线。验证码图像和交互数据也可能携带业务信息，应遵循最小化传输原则。外部接口失败时，保留人工验证或受控降级路径，而不是直接放行，才能让接入便利不以安全失守为代价。