2018-08-14 14:00
我先跟大家简单介绍一下我自己，我这边也是今年开始才加入到龚总这边的，之前有过一些容器方面的经验，也设计过一些容器方面的产品，这一次从今年年初开始，我帮龚总这边负责北区这边的业务，为大型金融科技公司帮他们建立金融行业云的RDS，用富麦科技的产品。
简单介绍一下，今天的议题分为四部分：第一部分会介绍一下我们做的这个项目的具体的背景，第二就是我跟大家说一下富麦科技这边的DBaaS技术选型的时候有什么样的考虑，第三整个项目过程中的实践路径和规划，第四我们未来长期收益的期望。
简单说一下背景，背景其中有第一个点，想跟大家简单说一下金融行业云公有云和私有云，这些“云”从我最早从业经验来看这些云我都做过，我还算比较了解它们之间不一样的地方。首先区分一下公有云和私有云之间建设的区别，公有云可能更多的是面向相对来说比较原则性的业务，有一些快速增长，没有历史包袱的一些业务，另外就是使用的大量硬件都是非常标准化的，一般公有云都是这条路来走。
私有云是说我要最大化地利用企业现有的数据中心和IT技术资源，这块因为很多企业有很多老的交换机，还有那些以前购买的存储，把这些资源整合起来，给最终使用实现一个整合的交付。 最后如果做私有云这块，会和企业现有的管理机制有一个比较深的融合。
我说一下做金融行业云和做公有云之间的区别，公有云面向的受众更广，解决的都是一些基础性和原则性的一些问题，很少有对特殊场景做一些非常深度的优化。但是行业云和公有云会稍微有一些不一样，因为行业云更多的是因为金融企业，特别是大型的金融企业经历了这么长时间的发展，势必在整个历史过程当中有很多需要在金融行业非常特殊需要考虑的这些点，对安全性、稳定性、连续性的要求就非常高，它是很难突然间直接往互联网业务上迁，只能是一些新业务往互联网的模式上去迁，老的业务还是需要有一些自己的考量。所以在金融行业云的时候在这块会有比较多的关注。
做公有云和私有云的时候有一个地方不太一样，做行业云的时候和这个行业云所定义的全新的运营中心，和运维中心以及和它的整个的云的管理体系会有一个比较深的集成。
项目背景，现在互联网金融被纳入四大行的战略重点，在各方面使用场景上不断地加快，国内首个大型金融科技公司利用现成的云的解决方案，从今年年初开始快速设计、搭建并且上线，前期服务于内部业务，目前正在把以前已有的这种特殊场景的金融方面的一些解决方案融入云产品中。
简单介绍一下DBScale的产品，它是开源数据库的容器云，目标是刚开始专注于开源数据库，我们暂时不会吧复杂性特别高的商业数据库融入到这个产品当中。我们做的是容器云，其实我们在这个地方做容器云的含义是说我们尝试在有状态的服务中我们构建一套数据库的管理模型，通过这套数据库的管理模型去纳入尽可能多的有状态服务，不只数据库，范围扩展到有状态服务，目前已经支持的开源处理服务有MySQL和Redis，未来还会支持Kafka、ElasticSearch，未来会支持MongoDB、PostgreSQL、Couchbase等等。
从产品经理的角度来说，我们考虑的时候我们会发现这些服务都有非常大的共性，这个共性是说我们所有有状态服务都是解决我的数据从哪里来，第二我的数据通过怎样的形式下放到中间通道中，第三通过怎样的业务分片和分流到最终的结果。另外就是我们如何从存储的这些位置极其迅速地把我们的业务读取出来，我们基本上都是解决这两类问题，解决这两类问题，我们整个数据库的架构也是比较清晰的。
DBScale的产品历程，刚刚曾老师已经说过了，在整个银联构建RDS的过程当中，我们起到了一些辅助的作用，从2013年到2018年我们经历了三期的工作，对这个产品有两次的改造，整个的生产规模超过250台物理机，CPU总量超过4000Core，内存超过66T，业务系统超过114个。
从数据库管理模型上，大概我们分为Service Manager，服务管理、集群管理和集群引擎三部分，对产品的抽象是单元、子服务和服务。单元是什么意思？单元就是面向独立的数据库管理的实体，更多的是数据库的进程，在一个进程级别，我们把进程级别抽象成四个模块：第一是进程本身，二是进程所携带的存储，第三是进程接入的网络，第四是数据库本身的托管。
在集群管理这块，我们抽样的第二层是说我们对整个数据库的高可用集群进行抽样，子服务的管理模型是针对数据库的高可用集群或者是故障预警抽样的。最上层的服务是说我们对整个的大的数据库集群，在业务分布或者在接入层的一个。
我们尝试解决的问题，其实我们尝试解决的问题是说在一个相对比较复杂的数据库结构中，我们如何去把数据库的模型到我们DBScale的产品，左边前面解决的是数据入口的问题，中间的解决的是数据如何通过不同的分片落到不同的高科用集群中，下面每一个都是一个高可用集群，对应到刚才那张图，上面的对应的也是子服务的概念，我们可以在上层的服务层对上层的Router的分片进行控制。
给大家说一下当时在选型的时候为什么选容器，曾经我们在虚拟机和容器这块我们对这个方案做过一个调研，首先是在性能上，性能上容器化数据库整体的性能会比较高，容器的虚拟化是在操作系统做的虚拟化，而不像虚拟机会把所有的硬件都虚拟化一遍，整体来讲容器的性能损耗是非常低的，大概基本上能达到90%几的性能，虚拟机可能要30%以上的性能。
第二在运维管理上，容器的出现最大的贡献是解决了一个对程序管理和标准化的一个问题，因为所有的虚拟机管理都是建立在对虚拟机硬件的管理上，加上后期我们处以一定的自动化的方式去处理这个问题，容器让我们直接可以对进程本身进行操控，对进程本身进行操控是什么含义呢？就是我可以对进程本身进行更细密度的起程管理、日志导出、监控，固定接口的监控采集。在运维管理上容器会把更多的管理细节暴露给最终的平台，所以平台收到了这个数据以及管理的手段可能会更为精细一些。
第三点是我们当时考量了容器虚拟机的高可用的对比，这块其实容器的虚拟机可以说差不多，但是虚拟机如果说我们用一些比较深入的技术可能我们在虚拟机层面的高可用上可以做的更好一些。
第四，启动速度，容器启动速度约等于进程的启动速度，虚拟机加上资源准备的时间，相对来说可能会比较长。
第五，弹性供应，其实和刚才的启动速度所描述的点有点像，因为虚拟机是在供应的时候是需要从三个方面去考虑，就是说存储这块以“快”的形式供应，网络这块也需要单独去准备，然后整合成新的硬件，然后从硬件再启动。容器可能在操作系统做一个虚拟化，就直接是进程的启动了。
平台成熟度，KVM发展历史比较久，目前比较稳定，Kubernetes和Swarm如果让它做有状态服务的业务我们需要对底层的网络和系统做一些定制。
当时我们的网络选型，因为在有状态服务中，我们对数据的要求、我们对传输的要求可能比较高，比如网络需要有高可用，我们很难容忍网络数据的丢失，所以我们在这上面必须考虑高可用。第二我们在网络上需要考虑容器性能和延时的问题，在大业务量的情况下，如果我们用一些网络虚拟化，可能我们只能达到物理网卡整体性能的70%左右，但是如果我们用IntelSR-IOV的技术，可以让性能接近于物理网卡性能的90%左右。
这是当时我们测试的一个情况（见图），在存储这块我们做的相对来说比较开放一些，我们做了存储的管理器，我们默认支持本地存储和SAN，但是如果说我们有一些其他的分布存储我们也可以接过来。在这里要简单谈一下行业云和私有云会有一些不一样，在这里私有云更多的会考虑整个业务的稳定性以及对固有资产的一个重复利用，所以说在这里我们会支持企业原有的SAN以及本地存储。
而在行业云这块，我们可能做的会稍微有一些变化，我们可能除了支持SAN以及本地存储以外，我们还会支持在行业云虚拟机使用的分布式存储，因为在这种场景下，我们的容器其实和虚拟机是相当于跑在同一个高可用的层面里面，所以如果出现故障，虚拟机和容器机可能都会受到影响。
我简单说一下我们的时间路径，时间路径是分为两块：第一是我们用产品作为方案的一个方面，第一我们用DBScale的产品迅速帮金融公司搭建一个实验环境，之后快速接入内部系统。第二，我们会融合它的公有云的一些特性，尤其是我们在多租户以及和运营运维平台对接中我们会花比较大的功夫。第三，我们会逐渐地完善RDS的品类，主要是MangoDB、Kafka和ElasticSerch。后期我们会做数据库多地的容灾，分布治理，人工智能运营。
最后，我会说一下长期收益，长期收益第一是说在整体的建设过程中，前两点是我们目前就已经能做到，第一是说我们开源数据库，一般来说就是开源数据库体量会比较小，单独放在物理机上的资源利用率会比较低，所以如果大规模使用会占用比较多的资源，所以现在如果用容器技术我们能有效的提高利用率。
第二是快速供应，之前数据库需要从服务器、操作系统、网络分阶段去实现供应，现在需要自动化一站式敏捷的供应。
第三是业务连续性，后期我们会考虑整个RDS在不同区域的，我们会考虑我们对RDS故障这块会做比较多的考量。
故障这块第一我们目前解决的是通过集群的方式解决本地故障的问题，第二我们考虑整个数据中心挂掉的情况，我们会考虑两地三中心灾备的模式，在这种情况下未来整个的业务连续性会得到比较多的提升。
第四，我们目前做的是说我们把RDS对数据库的运维我们通过一套模型让用户通过界面做一些基础的运维，未来我们会通过监控预测逐步实现智能化的运维。
今天的分享到此为止，谢谢大家。