通过DBaaS连接AWS Keyspace(Cassandra)报无对应类型物理数据库404错误

这个报错和你配置的Spring Data Cassandra连接参数没有直接关系，错误出在DBaaS管控层的资源匹配环节：

• DBaaS客户端创建数据库连接前，会先调用DBaaS管控接口查询目标类型的物理数据库路由信息，当前请求要查找cassandra类型的物理库，但DBaaS平台侧根本没有登记任何该类型的可用物理库资源，直接返回404。
• 你配置的SSL、contact-points、本地数据中心、端口、账号密码这些参数，是DBaaS成功匹配到物理库、准备建立实际连接时才会用到的参数，现在请求在DBaaS层找库的阶段就失败了，根本没走到连Cassandra的步骤。
• DBaaS自身Pod日志里出现完全相同的报错，也能证明错误源头在DBaaS服务端，不是微服务侧参数传错导致的。

• 核查DBaaS平台的纳管配置
  登录DBaaS管控后台，先确认已支持的数据库类型列表里有没有cassandra选项。很多DBaaS对接AWS Keyspace的时候不会默认开启Cassandra类型纳管，需要手动开启兼容开关。同时检查你要接入的AWS Keyspace实例有没有在DBaaS里完成入库登记，实例的类型标签有没有标错，比如误标成其他数据库类型，自然会匹配失败。
• 核对类型映射规则
  不少DBaaS给AWS Keyspace设置了单独的类型标识，比如aws-keyspace，不会直接识别cassandra这个类型值。检查微服务里DBaaS客户端配置声明的数据库类型，和DBaaS后台登记的类型值是不是完全一致，大小写、连接符拼写错误都会导致匹配失败。如果是多环境部署，要确认当前访问的环境（生产/测试）有没有配置Cassandra类型的资源，测试环境配置完成但生产环境漏配是非常常见的问题。
• 检查权限配置
  确认微服务使用的DBaaS访问凭证，有没有查询cassandra类型物理库的权限。部分DBaaS的权限控制是按资源类型做隔离的，没有对应权限的时候不会返回403状态码，反而返回404，很容易误导排查方向。
• 连通性验证
  上述DBaaS侧配置修复完成后，先在DBaaS后台直接发起目标Keyspace实例的连通性测试，测试通过后再启动微服务。此时你之前配置的Spring Data Cassandra系列参数才会生效，需要额外核对几个关键点：AWS Keyspace默认SSL端口是9142，不要配成Cassandra默认的9042；local-datacenter要和Keyspace所在AWS区域的编码完全一致；SSL连接用的根证书要正确导入服务信任库，账号密码要和Keyspace中创建的服务账号权限匹配。

内容的提问来源于stack exchange，提问作者Sagar Kulkarni