【SACC 2015现场报道】2015年10月22日，第七届中国系统架构师大会在北京新云南皇冠假日酒店盛大开幕。从2009年到现在，我们伴随着中国系统架构师大会走过了七个春秋，从最早的500人规模逐年升级到现在的2500人规模，这些年我们目睹了整个IT架构的变迁，也见证了中国IT圈内一波又一波的架构师成长之路。
▲2015中国系统架构师大会直播地址：http://oa.it168.com/topic/2015/10-20/SACC2015/
本届大会有着超过200家知名企业的架构师作为主讲嘉宾，累计有超过10000多名CIO/CTO、IT架构师、技术总监、运维经理与主管、IT系统及网络管理人员参会，累计沉淀了获百万次下载的技术演讲干货素材。本次大会依旧延续了“高人气、高水准、高质量”的属性，汇聚了近百位业界技术领袖，在两大主场和16个分会场中与2500名IT精英济济一堂，共话互联网+下如何重塑IT架构。
每年的双11促销，都是对几大电商的软硬件平台服务能力的一次大考。京东每天的库房记录在十亿个数量级，商品图片总共有几十亿张。这些文件基本上都是KB 级别的，很明显关系型数据库不太擅长处理这些海量小文件。当用户京东上疯狂的进行流畅浏览、搜索、下单的背后，究竟是什么样的设备与架构才能支撑住如此庞大的流量?
在大会第一天备受期待的《存储技术架构》专场中，京东云数据库技术负责人田琪为我们讲述了京东幕后数据库和存储的故事。
▲京东云数据库技术负责人田琪
云数据库服务是云平台不可或缺的重要组成部分，它承载着用户重要关系型数据落地，数据分拆，无缝扩容等重要功能，而RDS(Relation Database Service)服务本身各家都有不同的实现。田琪表示，通常RDS服务提供商对每个用户的数据库申请会为其单独分配一台数据库实例，这个实例也是单独建立在一台或者多台虚拟机上的，这种服务提供方式可以提供相对高性能的解决方案。但是存在一个问题，如果为每个用户的实例背后都是一个或者多个虚拟机的话，必然会导致总体成本的提高，而这种成本上的增加通常也不是必要的。因为大多数中小型的业务是完全可以跑在同一个数据库实例里的。这样也就可以帮助那些中小开发者们大大的节省了成本问题，最终做到一个月几块钱的创业成本。
另外也会存在一部分业务数据量和访问量都比较大，不适合同其他用户一起跑在同一个数据库实例里，这部分用户就比较合适独立一个数据库的实例。京东云数据库考虑到了这两种不同的需求，所以单独开发了共享型云数据库平台，独享型数据库平台两套系统，同时又支持无缝地从一个平台迁移到另一个平台上。
▲Why not MySQL
据田琪介绍，共享型云数据库最大的特点就是低成本，同时又不会牺牲数据库的可用性和可靠性，即使很多个用户共享同一个数据库实例，每个用户也都是有自己单独独立的备份，主从互备等支持。 这种方案的几个技术上的关键点在于如何做到用户资源的有效隔离，数据库的平滑扩容升级等。
京东共享型云数据库架构
1.Shared RDS API对外提供create/delete/describe等管理共享型数据库的接口
2.对于创建数据库Shared RDS API会根据DB资源池负载信息选择一个适合的实例为用户创建数据库，并更新集群路由到JManager
3.JManager管理整个集群路由信息，收到的任何路由变更同步到JProxy路由节点
4.JProxy路由节点对外提供透明的MySQL代理服务，根据路由信息将用户请求发送到用户所在的数据库实例上
5.每个数据库实例根据资源使用情况超过指定阈值，会由JTransfer模块将数据迁移到空闲的实例上
6.Cron模块定时通过RDS API动态为资源池增加空闲资源
此外，京东共享型的云数据库做到了以下关键技术实现：
1. 租户隔离。多个租户共享同一数据库实例必然需要一个有效的隔离方案，防止一个用户的慢查询请求或恶意请求影响其他用户访问。这里的隔离实现方式是通过JProxy层对用户所有的访问进行了拦截，并根据用户访问的数据表索引信息等，对用户执行该请求所需资源进行预判，并拦截掉恶意的请求及影响其他用户的请求。同时为了精确控制每个用户的资源使用，整个系统针对用户使用的连接数，内存占用容量，磁盘空间使用情况，带宽流量等都做了有效的记录和监控并根据用户的配额进行控制。
2. 集群路由信息高一致性保障。整体集群采用经典的弱中心化集群结构，在满足集群高性能的基础上同时具备足够的可控性，JManager管理整个集群路由信息，并通过多个Slave避免单点故障，当路由变更时，JManager首先同步路由变更信息给自己的Slave，然后才会同步所有的JProxy,避免路由变更时JManager挂掉导致路由不一致。
3. 高可用保障。
听完京东的存储故事，让我们再来看看“猫狗大战”的另一方——阿里。花名“缪长风 ”的阿里巴巴高级工程师刘林豆与我们分享了阿里分布式结构化存储的发展历程。
▲阿里巴巴高级工程师刘林豆
开放结构化数据服务(OpenTableService，OTS)是构建在阿里云飞天分布式系统上的NoSQL数据库服务，提供海量结构化数据的存储和实时访问。OTS以实例和表的形式组织数据，通过数据分片和负载均衡技术，实现规模上的无缝扩展。OTS应用在阿里巴巴集团内多个重要的业务场景，每天处理几百亿次请求，数据量达PB级别，目前也已经正式商用对外售卖。
据悉，OTS的产生背景主要是由于用户规模和应用所处理的数据呈现爆炸式增长;服务的高可用性要求;应用的数据库表结构会随着业务的增长而改变;
刘林豆介绍说，传统数据库后台面临以下三个挑战：
1.用户数据的规模和应用所处理的数据规模呈现爆炸式的增长。目前的应用，在互联网的基础上，几千万甚至上亿的用户比较常见。随着用户规模的增长，这些应用所要处理数据的规模和并发量也是会呈指数增长。在这种趋势下，保障应用的性能，访问的体验，这个是非常大的挑战。
2.在大规模用户前提之下，提供一个稳定可靠的后台输出服务，也是一个大挑战。
3.应用的需求随着业务的发展，经常会出现很多的变化，例如用户数据表的列数会动态增加和减少。
而面对这些挑战，阿里OTS的策略是：
1. OTS处理大规模数据。 在OTS的服务里面，表被水平分割成很多数据分区，这些数据分区被自动送到数据节点进行处理，随着业务的发展，一个数据分区变大或者访问越来越多，成为一个热点的时候，系统自动把数据分区分成两个小的，然后再重新进行调度，把它分散到节点，或者新的机器上，达到整个动态能力的扩展。
2. OTS具有高可用的特点。在这样一个系统里面硬件故障是比较普遍一个现象。当一个机器上的处理数据的节点或处理分区的机器发生故障的时候，首先故障被自动侦测，然后机器把失效数据分区移到其他的节点上。为了达到一个高可用特点，除了故障的恢复外，在底层的软件，OTS具有热升级功能，从而确保这些动作对应用不会产生可用性的影响。
3. OTS从容应对表格的SCHEMA动态变化。每一行的属性列，都可以在程序运行过程当中动态增加和动态删除。 这样就做到了对属性列数据要求没有限制，而实际上是使用非常巨大的宽表模型实现。
4. 存储在OTS的数据本身是安全可靠的。首先数据会统一存储在底层分布式的文件系统，分布式文件系统会保证每个数据有多份的拷贝，当拷贝丢失或者损害的时候，系统会自动检测并恢复。其次，每个数据在OTS里面每个是隔离的，这样保证用户的数据是安全可靠的。全托管的服务对用户来讲非常简便，不需要运维。
在刘林豆看来，OTS用户最适合于以下几种场景：
第一，比如移动互联网类的服务，当应用承载的用户基数增大，甚至有上亿用户访问时，这时我们第一个想到就是OTS可以解决这个问题。
第二，今天也有很多企业使用开源的方案自己建立类似的数据库，这个过程非常痛苦，而且成本很高，因为要维护硬件，处理版本升级，甚至有时要在线处理故障。这个场景OTS也可以满足要求，只要把应用的逻辑处理好，服务层面只要交给OTS就可以保障服务的可用性了。
