云原生的MySQL托管服务架构及读写分离的优化

内容来源：2017 年 08 月 24 日，微软中国首席产品经理宋青见在“ODF 2017开源数据库论坛（北京）”进行《云原生的MySQL托管服务架构及读写分离的优化》演讲分享。IT 大咖说（微信id：itdakashuo）做为独家视频合做方，经主办方和讲者审阅受权发布。

阅读字数：4055 | 11分钟阅读

获取嘉宾演讲视频及PPT：

摘要

在私有数据中心运维MySQL的方式是单机运行、一主一备，甚至是多主复制的集群，为了保证高可用，成本是比较高的。而基于云计算，托管运维大量的用户MySQL实例，如何用Cloud Native的原则，经过沙箱隔离、计算和数据的彻底分离，实现低成本和高扩展的高可用方案？经过开篇分享，使你们更好的理解Cloud RDS的架构精髓。进而经过基于Azure storage的针对MySQL读写分离的优化，比较深刻的分享了一种能够借鉴的主从分离优化技术。

云原生的托管服务架构

云原生的MySQL PaaS服务

咱们的MySQL托管运维并不是直接将数据存储在本地SSD，而是全部的链接都须要通过一层代理（能够理解为无状态的外部服务器），而后由代理将用户的链接转发到某一个虚拟机中的MySQL实例上。每一个虚拟机上有一个Agent用来监控运行的MySQL服务状态，若是其中某个数据库出现问题，就会在其余的虚拟机上恢复该数据库。这种状况下Proxy的好处就显现出来了，由于用户链接是在proxy上，因此当后方数据库出现问题，proxy会将链接从新定位到已恢复的数据库上。

另外咱们将全部数据库的读写操做都从本地移到了网络上，真正作到了计算和存储的分离。全部MySQL的数据文件不是保存在本地硬盘，而是存储在分布式的基于网络的存储框架上，数据在网络上被保存多份，同时严格监控用户的带宽资源消耗。

从节点的管理上来看本地的数据中心若是有上千台的节点就已经算是不小的网络了，而公有云在全球有超过百万的物理节点。面对如此多的节点运维的思路和架构会彻底不一样，咱们在网络和存储方面其实是花费了很大的精力才作到了不一样租户或用户之间的隔离。

若是是单一线程的任务，本地存储确定是比网络要快的，由于网络有着延时，但实际上云计算能够经过高并发来回避在延迟方面的不足。

MySQL PaaS的好处

MySQL PaaS带来了更方便快速的部署，高性价比，高可用性，以及高安全性的全托管服务。缺点在于限制了用户对数据库操做的权力，由于咱们是将多个用户的数据放在一块儿运维，因此对整个环境的安全性要求比较高。

平台支持

咱们当前的架构下只是将MySQL做为一个进程，更多的重点是在MySQL任务监控、快速恢复上。因为架构中有代理、计算和分离，因此能够很容易的作到单点的高可用。这种状况下咱们后台用的DB Engine是MySQL社区版本，支持现有的MySQL客户端和工具。

启动备用库

当前架构下计算和数据分离以后，数据是被存储在Azure storage上，这时虽然单点就能够达到高可用，可是在数据文件较大的时候，因为网络缘由恢复起来须要必定的时间，通过监控发现基本上在3分钟之内。若是用户对时间有要求的话，通常是建议用户再建一个读写分离的从库，主库出现问题的时候手动将从库提高为主库。不过咱们提供了更方便的启用备用库功能，能够将从库自动的提高为主库，从而节省时间，此时故障恢复时间一般在分钟级别（通常在60秒内）。

一体化的数据库运维平台

这是咱们于2017年5月份在全球推出的一体化数据运维平台，MySQL、SQL Database、SQL Database warehouse 、PostgreSQL被统一的放在该平台中。它能够对运维数据进行优化监测并给出建议，可以按需弹性放缩，资源管理。

读写分离的优化

支持基于副本的横向扩展

正常状况下主库和从库之间经过网络创建链接，而后将binlog从主库传输到从库，接着从库将binlog做为一个Relay插入到数据库中。若是主从库都是在MySQL PaaS上，那么MySQL实际就没有打开Replication开关，此时从库会另起一个进程，从Azure Storage上读取主库的binlog，而后解析插入到数据库中。这种架构下支持基于副本的横向扩展，适用于读取压力较大，或读远大于写的业务，从属实例不受限制，不过通常5个足够了。

支持混合云的数据库同步

因为目前混合云的应用仍是比较多的，因此咱们也支持混合云的数据库同步。好比从本地同步数据到Azure上以知足Azure上的应用须要，或者应用平滑迁移到Azure。能够经过管理门户配置同步和查看同步状态。

新一代的架构框架技术

Stateless Services Pattern

咱们这里来回顾下基于云架构开发后台程序的两个Patter，首先是无状态模式。这个模式下存储和前端服务器能够很容易的弹性放缩，问题于中间的业务层，由于业务之间是相互依赖，且用户的数据表明某种状态，要访问这些状态就不可避免的引入排队机制、入锁机制等。面对这些问题常见的作法是使用蓄水池方法，将用户的请求放在queues中，下降无状态服务的复杂度同时还能够达到无线扩展队列的需求。

Stateful Services Pattern

在实际的应用中其实大部分仍是采用有状态模式，这种模式下依赖于有状态中间件，有状态中间件经过分区的方式解决高并发，在分区内使用传统方式保证数据一致性。这种状况下数据的传输过程相对较少，延迟获得了保障。

Traditional Application

传统应用程序的API、UI、引擎等都是整合在一块儿，在编译的时候就能肯定相互之间的依赖关系并可以方便的发现问题。不过因为全部的模块都被整合在一块儿，牵一发而动全身，因此在水平扩展服务能力的时候要付出至关大的代价。

Application composed of microservices

不一样于传统应用，微服务框架中全部的模块都是一个独立的进程，模块之间经过HTTP或者RPC等协议进行沟通。至关于应用中包含多个服务，服务之间经过标准协议调用，不过只有在运行时才能发现错误，而非编译的时候。因为是彻底基于网络的框架，因此必需要考虑到网络延迟的问题。微服务所带来的好处在于可以很方便的升级，模块数据相对来讲容易监控，模块升级也已经可持续。

Service Fabric

Service Fabric是微软的微服务框架。该框架中有一个ApplicationType用来定义App类型，相似于编程中的class。App建立后的实例能够有不一样的名字，能够经过不一样的名字来管理同一个实例。它同时支持有状态和无状态两种服务。其中有状态服务能够声明式的支持多个分区，每一个分区中实例能够建立多个副本，至关于经过分区提升高并发能力，经过副本提供高可用。在多个分区的状况下，每一个有状态的服务自己就能够建立一个状态机，这个状态机能够复制到其余几点的副本中。因为副本的复制可配置，因此可让对有状态数据的访问基于本地节点，以此来下降延迟。

Service Fabric的另外一个特色是对集群上运行的全部任务的自动部署，好比原来有5个节点10个分区，这不一样的应用分区在这5个节点上会被自动分配，当节点扩大的时候，整个任务又会从新分配。这些部分都是自动完成，所以不用程序去显示的关注。

整个Service Fabric提供了一个更好的底层框架，可以实现高可用、可测试、可管理、可缩放。可测试指的是在服务升级的时候能够支持灰度发布，还能够设定某个条件判断升级版本是否有问题，一旦发现问题就会自动的回滚。可管理指的是基于内核级的检查和管理，当某个节点出现问题的时候，该节点上的运行的任务会在其余的节点上被自动的管理恢复。可缩放指的是增长节点的时候，整个任务会被从新分配。

SQL Azure Service architecture

SQL Azure架构中的SQL Server数据库被分解成不少的Service Fabric应用程序。物理集群被分红两部分，一部分做为控制管理的节点集群叫作Control Plane，它更多的作数据库的运维服务，另外一部分用户的数据库任务运行在Data Plane上。他们之间有严格的安全发送机制，用来保证用户和数据库之间的运行环境。

Drawbridge

Drawbridge是微软应用的新的容器技术，它既有虚拟机技术的强隔离性，又具备容器技术的高计算密度。核心是传统的NT Process，有1200多个API，显然这么多API是很难作到严格意义上的绝对安全，所以后续进行了优化。首先是将NT kernel运行在用户态，第二是让用户态的操做系统和真正的操做系统之间只容许不超过15个系统调用。基于这两步NT上出现了一个特殊的进程Picoprocess，它从外部看就是一个空进程，惟一与它有交互的是一个很小的系统内核库。

SQL Server for Linux也应用了Drawbridge技术，这样就能够将原先windows上的SQL Server经过SQLPAL层移植到Linux上。