3同行回答
我是散修，不会给你做产品介绍，推荐一大堆软件，只讲实际的内容。
（1）你的应用必定在paas，你所指的paas，应该是容器云的tke，就是全托管的kubenetes集群，这在各种公有云现在基本上都提供了。
（2）数据库不在容器云中，这也是必然，数据库软件由于性能问题，必定不会包括在容器云内。而数据库的存储也不可能在容器云内，而分布式存储性能太差。
（3）数据库可以也使用paas平台
全部paas化，降低运维成本，专注于业务。
所以，你要求的这个架构是最最最通常的架构，也就是，目前大家都是这么玩的。对接数据库层和应用层都是标准的做法，可以ip对接，也可以域名对接。
1、通常为了对原有业务的兼容以及容器化改造的简易性，我们容器化的最初阶段都是直接使用原有数据对接模型的。比如仍然使用数据原有连接池，匹配外部数据库连接地址。但如我在PPT内容中谈到的，当应用具备一定规模，这一定会导致原有数据使用压力的增加，因此我们需要在业务的敏态改造中逐步提高数据对接层面的合理性与规划性。
2、为了提高数据对接层面的合理性与规划性，最佳方案是先通过一些技术对数据直连进行隔离。有Kafka就通过Kafka 隔离出读写层，没有 Kafka 可以通过 JBoss Data Virtualization 这样的数据源虚拟化工具进行面向原逻辑的抽象隔离，但需要注意的是 JBoss Data Virtualization 这样的数据源抽象工具对复杂 SQL 使用场景非常容易产生兼容性问题或性能问题。因此将原有的复杂 SQL 这种过程处理逻辑进行一定程度的面向对象改造是很有必要的。
3、如果服务无法完全进行数据源抽象适应，例如无法拆分复杂SQL，那么我们就必须通过一定的开发来实现面向对象数据源改造。此时可以配合Red Hat Data Grid 这样的数据网格技术来实现就近数据源适应的改造了。不要忘记了 Redhat DataGrid 产品可以直接支持 Redis 的所有能力，可以完全兼容 Memcache 使用，因此非常适合将单体数据缓存改为云化适应的数据网格。
4、有了中间的数据隔离技术，Kafka/JBoss Data Grid/JBoss Data Virtulazition 这些技术就可以与原有数据元之间的关系进行梳理。比使用 Redhat Change Data Capture 工具可以很轻松的帮助用户实现如数据同步，多数据中心同步，数据应急，数据灾备，数据异地多中心同步，数据一致性传递，多数据源一致性同步等等目标，同时这些技术之间的梳理就会变的比以前简单，顺便可以重新梳理原有的分库分表结构，读写分离结构等，更进一步提高原有数据使用质量。
收起