集成底座是基于IDM、MDM、ESB三个核心产品组合打造的解决方案，主要解决企业信息化建设过程中业务系统打通以及基础业务集成整合问题，通过构建企业技术底座，实现各业务系统间的统一认证，保证业务系统访问的一致性；实现各系统基础数据的同源，保证数据一致性的同时为后续复杂的业务集成、财务集成等提供基础数据支撑。
由于集成底座内部要做产品整合，所以需要基于IDM实现统一认证配置，在近期处理的集成底座项目中，多个项目都出现IDM认证失败的问题，所以基于项目及内部POC环境进行测试，对问题及处理过程进行总结。
1总体说明
本次出现的问题主要是集成底座进行内部产品认证的过程中，出现ESB和MDM通过IDM进行统一认证时认证失败，且ESB和MDM无法登录的问题。
1.1总体说明
目前在集成底座项目中，内部集成都是通过ESB构建集成流程实现数据同步，IDM负责统一认证入口，MDM负责组织、岗位、人员等基础数据管理，而IDM统一认证采用的是CAS认证模式，但在实际项目中出现了认证失败的问题，且只有在多节点（测试、生产环境）中才会出现该问题，所以整体对环境进行检查。
1.2部署架构
集成底座采用云平台的部署方案，采用1-2-2节点方式，即开发环境1个节点，测试、生产环境2个节点。部署架构图如下图所示：
1.3问题描述
通过CAS认证实现内部产品（IDM、MDM、ESB）的统一认证，发现开发环境未产生问题，但是测试与生成环境单点登录时无法登录，每次登录后依然会停留在IDM登录页面，而且在进行问题排查时，发现ESB和MDM的后台均未出现明显的异常信息。
2问题排查
对于产品运行的异常，主要排查内容包括日志、配置以及对应的产品组件Redis、Nginx等信息，由于登录时可以跳转IDM登录页面，且未出现IP异常，说明Nginx的相关配置未出现问题。
2.1检查日志
首先排查产品Server的日志，通过UMC平台打开日志文件，检查日志运行情况，由于是多节点所以排查了每个节点的日志，发现产品日志中都没有明显的异常信息，产品启动时也没有提示报错。而且通过登录检查实时运行日志，发现日志中有执行记录，所以考虑是产品的相关配置文件出现的问题。
2.2检查配置
主要检查产品的相关配置，包括web.xml——CAS认证的相关配置，context.xml——配置集群的Redis连接信息，service.xml——配置tomcat连接池以及Servlet容器。
2.2.1web.xml
首先web.xml由于采用产品的标准配置，且基于标准的CAS认证文档进行调整，并未发现认证相关问题，主要配置如下：
2.2.2context.xml
context.xml是tomcat中预置的配置文件，但是在集群模式下，需要添加Redis集群配置信息，如下图：
其中redisNodes为Redis的连接信息，在云平台模式下，需要配置容器内Redis连接信息：
2.2.3service.xml
service.xml也是tomcat预置的配置文件，主要是配置tomcat相关的Servlet容器以及相关端口、连接池等，在集群模式下需要在Engine标签中添加jvmRoute信息，并且和context.xml中的配置保持一致：
2.3检查组件
组件主要检查Redis组件配置，因为云平台模式下大部分情况下都是使用容器内部的Redis组件，所以需要检查是否由于环境、内存、CPU等原因造成Redis组件异常或停止，如果出现Redis异常，也会影响产品访问。Redis主要检查Redis状态以及测试连接是否正常：
3测试过程
由于在开发环境可以正常访问，而测试和生产环境出现问题，因此可以将环境进行还原对比，包括将测试或生产环境调整成单节点测试，并在内部测试等步骤进行验证。
3.1调整容器
为了进行对比，可以将测试环境调整成单节点：
1)如果测试环境采用单节点可以访问，说明web.xml配置、Redis以及产品本身不存在问题，可以进一步缩小问题排查范围；
2)如果改成单节点依然存在问题，说明测试环境单点登录的配置出现问题，或者产品本身访问出现问题，就需要再仔细检查web.xml以及Redis和产品的log日志。
3.2测试组件
对于Redis组件问题，一般相对比较容易排查，如果Redis测试连接失败或者Redis节点状态不是running，说明Redis集群出现问题，需要重置集群或者检查相应的环境。并且对于Redis的异常，一般比较容易通过Server的运行日志判断：
3.3断点调试
如果通过日志以及相关的配置检查，确定是产品问题，那就需要检查产品代码或是通过断点调试的方式进行处理，云平台环境下UMC预置有断点调试的端口开启配置，可以通过平台开启断点调试：
注意：
1)云平台环境下只允许调试开发环境和测试环境，不允许调试生产环境；
2)UMC只能开启Server的调试端口，如果需要调试还需要在防火墙开放对应的端口，如果是项目环境并且存在网络防火墙的话，还需要开启外部的防火墙端口；
3)通过开发工具断点时的IP地址为断点Server所在的真实服务器IP，而不是虚拟IP，如图需要断点esb-server-767767f776-lxg75容器的ESB，需要断点k8s-master服务器对应的真实IP。
4总结分析
根据本次对于集成底座的IDM认证异常问题的梳理，对于云平台下环境的配置过程以及关键配置内容，产品的部署集成方式进行了梳理，对于云平台下问题的检查与调整进行了总结。
4.1内部测试
在项目上遇到环境问题，如果能基于项目上的配置进行检查处理是最直接的处理方式，也是比较容易排查的一种方式，但由于项目网络、服务器环境的限制，很多时候不容易进行问题排查，那么就可以考虑通过内部测试的方式，即在公司内部环境上还原项目环境，进行问题重现，再基于内部环境进行调试、修改、断点等操作进行问题的定位与排查。
4.2异常抓取
除了通过对比和检查配置文件的方式外，也可以通过抓包的方式进行问题排查，一般常用的抓包工具有Wireshake、Fiddle等，以Wireshake为例，它可以通过监听网卡而获取网络流程，进而分析相应数据包，获取网络访问过程中的输入输出信息，协助排查系统访问时存在的问题。对于Linux服务器，也可以通过tcpdump来进行分析，获取通过tcpdump进行抓包并导出cap文件，再由Wireshake解析成图形化查看。
4.3问题总结
经过排查，本次认证的问题是由于集群模式下web.xml、context.xml以及service.xml配置文件导致的登录异常，所以对各个配置文件中的关键点进行梳理。
1.web.xml：
1)CAS Authentication Filter中有两个地址，第一个为CAS认证的地址，第二个为平台的访问IP，在同一个云平台下两个地址的IP一般是相同的；
2)MDMUserCasFilter（MDM产品的，其他产品类似）是配置CAS认证时用户认证的拦截器，是产品内部的类路径，一般在产品中已预置；
3)CXFServlet的配置是在hotweb框架中扩展的ServiceServlet，注意不是Apache的；
4)DispatchServlet下有一个eventRedisChannel的配置，主要用来处理Redis缓存，注意需要添加，否则容易出现Redis缓存处理的异常：
2.context.xml
context.xml的配置只有一个信息，就是Redis集群的配置，如果产品采用多节点部署（测试、生产环境），注意一定要配置context.xml的Redis信息，不然会出现无法访问的问题。
3.service.xml
service.xml和context.xml一样，在多节点集群模式下需要扩展，在Engine中添加jvmRoute信息，并且需要和context.xml的jvmRouteTag保持一致。
5个人总结
接手IDM以及集成底座相关项目有一段时间了，但对于IDM产品等一系列深层次的应用和实际使用一直没有彻底掌握，通过本次问题的总结分析，加强了个人对于产品、项目的了解。
5.1产品使用
IDM产品基于5A管控体系主要满足企业进行信息化建设过程中的安全管控机制，且伴随着相关项目，IDM产品的功能也逐渐趋于完善。自己对于一些涉及到统一认证、安全策略、分布式部署等方面掌握不透彻，以至于在实际项目中解决问题并不是很熟练，本次IDM认证问题增加了自己对产品的熟练度，日后在工作之余需要多加学习。
5.2工作方式
项目中出现紧急问题，一定要第一时间进行定位，首先检查报错信息，如果能通过报错信息定位问题就快速解决；如果不能则根据报错信息询问同事，看看其他人或其他项目是否有相同问题，参考之前的经验快速解决问题；如果出现之前从而遇到的问题就需要凭借项目、产品的经验进行初步判断，判断大致的问题范围，再通过极限逼近的方式逐渐缩小范围，从而彻底定位、解决问题。
5.3心得体会
本次的问题定位与处理不仅仅是提升了对产品的认知和了解，对于产品、项目的实施方式、日常的工作方式都有了更多地认知。IDM产品本身支持CAS、OAuth、接口等多种认证方式，而目前也只对CAS认证比较熟悉，对于其他认证方式具体实现的了解还需要强化。
由于IDM产品支持的多样性，那么如何在实际项目中，如何根据客户的实际需求选择合适的解决方案以及处理措施对于项目而言是非常重要的，也是决定项目成败的重要因素，只有选择合适的方案，才能加快项目实施的进度，保证实施过程中遇到最少的问题，提升客户对项目的认可程度。
在实际工作中，沟通交互是解决问题和推进工作的重要手段，特别是在遇到问题时，多和同事、领导沟通对于快速解决问题是非常有效的，你没遇到的问题可能其他人遇到甚至解决过，这样就可以拿来进行参考，即使不能解问题，也可以提供大量的解决思路和意见，提高解决效率。
