今天下面的时间我给大家讲讲我们过去踩过的坑，还有后面我们面临的挑战，以及我们如何解决这些挑战的一些经验。
功能定位
我们整个数据通道的用途和功能定位很明确。因为RDS是一个数据库的集合，我们现在支持MySQL和MSSQL，我们后面有其他数据库的加入。这些东西包括不同的数据库版本，对用户来讲我们不希望这些变化对用户有很大的一个干扰，所以我们第一个比较注重数据通道屏蔽后端的变化。第二个数据通道一定高可用。第三我们做公有云服务的，整个数据通道必须是安全的。因为所有用户不一定是安全专家，他们不一定有安全意识，我们有责任和义务去帮到大家。
第二个整合数据通道。我们希望它能做更多，比如说数据路由。举个例子，我们可以帮助用户区分冷热数据，冷热数据存在不同的介质，这样可以给用户省钱。还有类似的数据操作，今天我们可以做分库分表，对用户是透明的，或者我们今天用Mysql协议接不同的后端，用户对这个没有感知的，数据通道有这个功能定位。
约束
整个数据通道我们可能跑在普通的PC服务器上，跟你们用的PC服务器没有什么区别。
第二个必须高可用，我们知道宕机一秒钟几秒钟对用户意味着什么，有成千上万的用户，每一个成千上万的用户可能服务成千上万他自己的客户，当你一个公有服务不能做到高可用的话，我们知道意义了。
第三个规模。我们规模越来越大的时候我们系统一定是要能够横向拓展。你现在飞机已经启动起来已经飞了，你不可能说等等我把系统调整一下，花一个月时间或者多少时间把它弄得可以用。我们有时候觉得开着飞机换轮胎，在地上一个轮胎几分钟换好了，空中可能换需要一年，所以说特别的痛苦。RDS整个系统是可运维的。如果你今天一个系统不能作为可诊断可自省的，问题都是用户帮你曝出来的，我觉得这个系统可能没有生命力。
三层架构
三层架构图
RDS的数据通道是一个非常经典的三层架构，就跟大家平常看到的Web服务器三层架构一模一样的。WEB服务器一个简单的HTTP服务器，为什么有这么多的中间件，这个是标准的三层架构。今天三层架构为什么这么流行？我不知道大家想过没有，但是这里面肯定有它很重要的一个原因，如果是两层的话你会发现过于简单，层数过多的话你链条太长，三层是刚好，在灵活性跟简单性中间有一个很重要的平衡。所以说我们整个RDS后续的架构就是基于这样一个三层的架构。三层架构业界有很多很多的经验我们可以借鉴的，Web服务器前人积攒几十年的经验我们都可以用。我们整个系统都是基于这样一个架构。把域名算上去有四层的，就是用户如果直接用这个数据库的话，实际上就是这一层，我们加上中间的PROXY加上四层的SLB，前面还有一个域名，每一层的引入对用户都带来非常大的影响。
我举个最简单的例子来讲，域名解释大家觉得有问题吗？今天我们数据库给大家提供一个域名，域名可能对应一个VIP，我们提供域名最基本的想法是说换VIP很容易，但是实际情况不是这样，今天你是公有云的用户，用户对这个系统的支持不尽相同的。很多时候你给他一个域名，他直接要你提供的VIP，还有有些用户主机上设了域名，它绑定起来很长时间不生效，也就是说即使域名这么简单的事情，我们真的切换域名的时候，你发现95%用户是OK的，5%是切不动的。第二个它直接用VIP，这两点把你搞死，我们实际上有这层但是没有办法用。我们第一天想这么一个域名切换很简单，今天连域名简单的事情我们不能切我们用VIP漂移，我们去后端系统怎么变更，我们对用户提供的VIP不变的，极端情况下我们没有办法让它去变。当它用户的规模大，你可以看到各种各样的问题，这些问题都是挑战。
