本次的交流重点围绕数据库容器化部署在PaaS平台上难点交流，交流答疑的内容在社区平台上均可看到：https://www.talkwithtrend.com/activity/?id=1659 。

方案资料参考：2020 容器云职业技能大赛架构岗获奖作品：多数据中心高可用数据库容器化部署方案

交流汇总

1、数据库容器化部署在PaaS平台对性能方面的影响？

数据库容器化部署在PaaS平台在性能方面有多大的影响，如何进行性能调优？

回复： 容器化，本质上是对运行在宿主机上的线程（容器本身就是一个线程）限制了CPU/MEM等资源（使用 cgroups），并给它一个隔离空间（用 namespace来实现)，所以只要不特别限制资源上限，基本和非容器化的效果是一样的。
而数据库一般是自身实现数据的一致性保证，也包括一些中间件服务，比如 redis ，kafka 等，所以只要使用本地存储来实现数据一致性、持久化或数据同步就和使用主机部署是一样的。有些数据库如果数据很大的话，建议使用 LocalPV 来做持久卷，如果对性能要求不高的，还可以使用Ceph rbd/CephFS 等网络存储卷。

回复：理论上把数据库容器化，又增加了一层中间层，这个性能肯定是下降的；除非能显著提升资源利用率，或者说叠加很强的多租户需求，使得整机性能显著提升，可能还值得。否则个人感觉，不要没事找事搞数据库容器化，还带来一堆的运维，监控，数据一致性保证等等问题。

2、数据库容器化部署有哪些优缺点？如何保证的系统的性能的高可用性？2、数据库容器化部署有哪些优缺点？如何保证的系统的性能的高可用性？

数据库容器化部署在有哪些优缺点？如何保证的系统的性能的高可用性？

回复：比如TIDB，融合了关系型数据库和非关系型数据库的技术特性，实现了高度兼容MySQL协议和生态、在线水平扩展、强一致分布式事务、多副本数据安全、实时分析等重要特性

回复：使用Docker的好处举些例子：
1.屏蔽底层物理资源
2.提升资源利用率 (CPU、内存)
3.提升运维效率
有问题的地方：
1.数据安全问题
2.相对于物理机性能问题
3.资源隔离方面
所以综合还是要看不同的适用场景，像下面几种可以考虑容器化部署：
1.对数据丢失不敏感的业务(例如用户搜索商品)就可以数据化，利用数据库分片来来增加实例数，从而增加吞吐量。
2.docker适合跑轻量级或分布式数据库，当docker服务挂掉，会自动启动新容器，而不是继续重启容器服务。
3.数据库利用中间件和容器化系统能够自动伸缩、容灾、切换、自带多个节点，也是可以进行容器化的。

3、在数据库容器化部署架构中，如何设计和优化数据库网络？

回复：为了提升数据库容器化时的网络性能，一般可以采用网络性能和宿主机一致的 HostNetwork 方式来实现，如果在某些公司或者公有云环境下，出于安全考虑不允许该模式的话，建议采用 calico 的 BGP 模式，但这个也受限于单个子网段，BGP如果要跨网段通信，由于不是采用传统的 overlay 技术实现，所以需要用路由器打通，在其路由表里直接连接起各网段的 BGP 信息。

回复：不同的方案有不同的优缺点，选择方案的时候还是要根据应用场景去选择。例如考虑使用数据库应用服务器和数据库服务器这间是什么网络连接方式，是docker内直接连接还是在不同的集群甚至是在不同的局域网内。总体还是选择目前主流，官方推荐，较好扩展的方案。

4、容器环境下基于本地高性能存储的MySQL集群节点如何迁移？

某些场景下，容器云平台可能无法使用nas，san等存储，只能使用节点本地的NVMe固态。那么在这种场景下，mysql容器的存储就被限制在了所在节点。当所在节点故障、需要维护，以及因为压力大需要疏散时，就需要考虑mysql容器要如何迁移？

回复：我觉得这个在不是容器环境下也得考虑的问题。说到底还是数据的如何迁移和备份。这种建议使用另外的SAN或NAS云盘备份本地的硬盘数据，出现问题直接从云盘恢复相关数据。

回复：我们一般会通过实现自己的 Operator 来保证 Mysql 集群中的数据存储的一致性，这个具体一点就是：
以多节点来实现mysql 的容器化部署，根据现有的场景需要，是主从，主备还是主主，还是一主多从，一主多备，这些场景中，无一不体现数据迁移的保证。在 K8S 中，一般都是通过基于 LocalPV 的挂卷方式来实现，通过 bin log 或者定期备份来保证数据恢复时所需。mysql 备份有逻辑与物理备份方法，比如 INSERT 语句文件的恢复 ， 纯数据文本备份的恢复 ，InnoDB存储引擎备份与恢复，NDB Cluster 存储引擎备份与恢复等等。

5、数据库是否适合容器化部署？系统稳定性是如何保证的是如何保证的？

数据库是否适合容器化部署？系统稳定性是如何保证的是如何保证的？

回复：目前中间件容器化趋势比较明显了，数据库作为主要代表，也适合容器化部署，这个得利于容器的环境集成封装及容器平台为运行于其上的容器的高可用、弹性伸缩的特性。
系统稳定性主要还是通过使用 K8S 的 Operator 技术来实现数据库服务的高可用性来实现。有了 Operator 技术，我们可以自定义数据库容器的运行行为，包括主主、主从、主备或者一主多备等各种场景需求。我们公司目前就通过自己实现 Operator 来定义这些行为来保证业务所需。

6、数据库容器化部署的IO性能如何？如何评估数据库是否适合容器化？

回复：(1)数据库程序与数据分离
如果使用Docker 跑 MySQL，数据库程序与数据需要进行分离，将数据存放到共享存储，程序放到容器里。如果容器有异常或 MySQL 服务异常，自动启动一个全新的容器。另外，建议不要把数据存放到宿主机里，宿主机和容器共享卷组，对宿主机损坏的影响比较大。
(2)跑轻量级或分布式数据库
Docker 里部署轻量级或分布式数据库，Docker 本身就推荐服务挂掉，自动启动新容器，而不是继续重启容器服务。
(3)合理布局应用
对于IO要求比较高的应用或者服务，将数据库部署在物理机或者KVM中比较合适。目前TX云的TDSQL和阿里的Oceanbase都是直接部署在物理机器，而非Docker 。

7、关系型数据就是否适合容器化部署及存在的问题？

我们公司目前目前构建了了一台spring cloud的的微服务微服务开发平台，数据库oracle还得还是是部署部署在虚机上年上面，考虑到到容器适合无状态化部署部署和数据安全性、网络网络方面问题问题，不知道现在现在解决解决的的怎么样或是或是有更好的解决方案，也请各位专家指导指导。

回复：建议从以下几方面去考虑：
· 1、数据安全问题，例如 容器突然崩溃，数据库未正常关闭，可能会损坏数据。另外，容器里共享数据卷组，对物理机硬件损伤也比较大。
· 2、性能问题， 关系型数据库，对IO要求较高。当一台物理机跑多个时，IO就会累加，导致IO瓶颈，大大降低 读写性能。
· 3、网络问题， 要理解 Docker 网络，您必须对网络虚拟化有深入的了解。也必须准备应付好意外情况。你可能需要在没有支持或没有额外工具的情况下，进行 bug 修复。
· 4、状态， 在 Docker 中打包无状态服务是很酷的，可以实现编排容器并解决单点故障问题。但是数据库呢？将数据库放在同一个环境中，它将会是有状态的，并使系统故障的范围更大。下次您的应用程序实例或应用程序崩溃，可能会影响数据库。
· 5、资源隔离， 资源隔离方面，Docker 确实不如虚拟机KVM，Docker是利用Cgroup实现资源限制的，只能限制资源消耗的最大值，而不能隔绝其他程序占用自己的资源。
· 6、运行数据库的环境需求，常看到 DBMS 容器和其他服务运行在同一主机上。然而这些服务对硬件要求是非常不同的。数据库（特别是关系型数据库）对 IO 的要求较高。一般数据库引擎为了避免并发资源竞争而使用专用环境。如果将你的数据库放在容器中，那么将浪费你的项目的资源。因为你需要为该实例配置大量额外的资源。在公有云，当你需要 34G 内存时，你启动的实例却必须开 64G 内存。在实践中，这些资源并未完全使用。

8、在k8s中部署mysql主从问题？

能不能介绍下，在K8S集群中部署mysql主从同步数据一致性的问题，以及主down掉情况下的自动切换，有没有最佳实践？

回复：这个在K8S中，mysql 主从问题是讨论的比较多的，也是在生产中应用的比较多的案例。
说到主从，无非就是数据是以谁为主，主挂的时候，备是否能顶上？主恢复的时候，备是否被换下？
早期业界有两种做法，一种是使用头脑分裂法，在容器的启停时去实现数据的同步及主从切换。这个见官方的使用 statefulset 的做法，见：https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/

还有一种是使用最近比较火的 Operator ，这个也有开源的，比如：https://github.com/oracle/mysql-operator

我是比较推荐使用 Operator的方法，因为这种才是自动化运维 mysql 数据库的绝佳推荐方式，不会担心其他的意外情况发生。

9、面对跑在k8s上的MySQL，中间件如何选型？

MYSQL中间件作为分布式数据库的关键核心组件，承担着分表分库，读写分离，高可用等核心功能，将mysql运行在k8s上，必定面临着如上各种问题，如何选型和结合k8s自由功能进行融合

回复：我觉得中间件就是为了让你屏蔽底层数据库的具体配置实现，而使用k8s也是为了方便数据库集群的高可用性、方便部署等问题，这两部分觉得应该分开的考虑，而不应该耦合在一起考虑。不然只会加大查问题及使用的复杂度，那就没必要使用这种方案了。

10、数据库容器化部署如何保证数据安全性？

数据库容器化部署如何保证数据安全性

回复：传统虚拟化技术与Docker容器技术在运行时的安全性差异主要体现在隔离性方面，包括进程隔离、文件系统隔离、设备隔离、进程间通信隔离、网络隔离、资源限制等。
在Docker容器环境中，由于各容器共享操作系统内核，而容器仅为运行在宿主机上的若干进程，其安全性特别是隔离性与传统虚拟机相比在理论上与实际上都存在一定的差距。
如果要保证容器化的部署，还是建议重源头避免，通过镜像的安全相关扫描避免。

11、容器上面可以部署有持久化数据的应用或者数据库吗？

如果是用了容器云，有持久化数据需求的应用应该如何部署，后端是否只能接nas，是否能在容器上部署oracle数据库，升级oracle数据库时能否直接部署一个新版本的数据库再挂载原有的数据升级数据字典即可，如果可以应该如何规划？是否又成功案例？

回复：1、数据库可以容器化，但一般在开发测试环境，生产环境不建议数据库容器化；
2、有状态应用发布后端存储可以用NAS，也可以使用分布式存储，如ceph、glusterfs等存储，具体需根据业务使用场景，如有业务对性能要求较高，一般的存储可能都不行；
3、oracle可以容器化，主要是拉起来比较快，使用很方便，但oracle的一些高级特性在容器化以后无法使用或者配置很麻烦；

回复：可以是可以，但是不建议。
oracle数据库通常是追求稳定、而且笨重，IO要求也比较高，不太适合容器化部署
因为应用通常是分层的，所以应用服务是可以容器化部署，而数据库尽可能在物理服务器上部署，通过网络访问数据库。
测试环境可以把oracle等部署到容器，为的是敏捷、一致性考虑，容器重部署则状态重置，就不需要每次清理测试数据，对于回归测试等还是很方便的
总的来说，要根据实际考虑合适的技术特性和应用场景，选择合适的方法

回复：一、容器本身是不能做数据持久化，可以加入数据卷的概念，数据卷绑定存储系统，比如nas等，把需要做持久化的数据保存在数据卷中就做到了数据持久化。
二、容器中的应用需要访问Oracle数据库，利用容器编排技术创建jdbc service和jdbc endpoint服务访问外部的Oracle数据库。
三、Mysql数据库可以做成镜像运行在容器中，如果需要做数据持久化，需要把mysql数据库的数据文件保存在数据卷中。

12、不做传统数据库容器化，但应用部署在PaaS平台上，如何去对接数据层和应用层？

回复：（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 工具可以很轻松的帮助用户实现如数据同步，多数据中心同步，数据应急，数据灾备，数据异地多中心同步，数据一致性传递，多数据源一致性同步等等目标，同时这些技术之间的梳理就会变的比以前简单，顺便可以重新梳理原有的分库分表结构，读写分离结构等，更进一步提高原有数据使用质量。

回复：数据库对接没有什么大的变化，对接应用层需要考虑应用IP地址会动态变化的问题。可以使用网关+注册中心的方式