研究背景
国际业务未来面临的是来自于全球的用户(买、卖)家，这里面面临几个问题：
1）物理距离即使在光速面前也会有非常"可观的"Latency;
2）地域保护或政治因素往往让某些国家的用户不能畅通的访问全球其它国家部署的网络服务，甚至会有的国家明确要求国外公司的数据中心必须在其国内，或其国内用户的数据不能流出所在国家
3）海量的国际业务要求我们技术上有在全球多地部署的能力。
基于以上几点原因，要求我们技术上有多地部署、就近服务的技术能力，我们提出区域化部署架构，来实现多地部署，就近服务。
相关概念
【区域】：是指地理区域，如欧洲、美国、巴西、亚洲、东南亚
【区域化部署】：实现网站多区域部署；每个区域中部署的网站就近服务这一区域的用户，降低Latency，提升用户体验
【区域化部署架构】：支持区域化部署的技术体系
【ART架构】：ART即Alibaba Regional deploymenT，是区域化部署架构的英文名称
区域化部署架构要求
1）以支持区域化部署(多地部署、就近服务)为目标
2）通用性强，能支持未来新业务形态的引入
3) 立足长远，不被当前技术或业务
架构实现推演过程
1. 解决思路
以区域化部署为目标，立足长远，通用性强的架构能否成功制定，取决于问题域名的有限定义，对问题定义的有效抽象，以及提出抽象的解决方案。
2. 问题域定义
阿里巴巴的网站支持多区域部署，每个区域的用户就近访问阿里巴巴网站。网站系统由功能和数据组成，功能本身是无状态的，只需要在区域中部署起来，就近服务即可；而数据是有状态的，问题可以聚焦于数据如何多地部署，就近读、写。
3. 问题抽象
我们将问题抽象为数据多地存储、用户就近读写。
4. 问题解析与解决
![_]( "_")
直观来说就是把数据多区域部署起来，让用户就近读写区域内的数据，但是面向全球的网络平台往往不是这样的多个孤岛，区域间的用户存在着相互交互，共享数据的情况。因此，需要在多个区域间搭建起数据同步。
![_]( "_")
通过数据同步虽然解决了数据共享问题，但这个共享只能有一方是只读的，这里我们引入单一数据Master原则，一条数据只能在单点发生变更，否则数据多地变更我们无法解决数据一致性问题。在单一数据Master原则下，解决方案只有让其中一个用户直接去变更另一个区域数据，并且如果用户要求读到实时一致的数据，则需要跨区域至数据Master区域去读取。
![_]( "_")
那么当多区域用户需要变更同一条数据记录是，要让那个用户本地变更，其他用户跨区域变更？这里需要引入用户优先级的判断。
![_]( "_")
用户优先级定义方法：
a）依据业务领域的业务情况定义用户类型
b）依据业务领域的业务情况定义用户重要性等级
c）对于电商领域，Latency面前重要性：买家>重要于卖家>重要于小二
d）对于电商领域，如果同是买家的两个用户共同变更同一条数据，谁优先？在成本允许的情况下，通过技术手段解决，如分解数据至不同区域，数据生产者就近变更数据，通过全局事务来保证数据一致性(支付宝预算解决方案)，若成本不允许，则放弃区域化部署功能，实现集中不熟，建议部署在网络条件到所有区域是最好的区域中
e）在成本较高的情况下，将功能和数据集中部署在距离所有用户最近的区域(中心)。
至此，方案看起来完整了，我们来总结下。
![_]( "_")
将用户读写的数据分为三类：只读数据，独享数据，共享数据，解决方案如下：
a）只读数据，判定只读数据用户是不需要读到实时一致数据的，这类数据只需要通过数据异步同步的方式同步到用户区域，用户本地读取
b）独享数据，这类数据只会有一个用户取变更，只需要本地部署，本地读写
c）共享数据，多个用户需要共同变更通一条数据，只有最高优先级的用户区域作为Master，本地读写，数据异步同步至所需区域；非Master区域的用户跨区域写，一致性跨区域读。优先级的判定规则不在累述。若多个最高优先级的用户变更同样一份数据，是成本情况决定是从应用逻辑解决还是集中部署。
至此，我们逻辑上虽然已经走通了，但它还不是一个完整的架构方案，我们只是回复了简单的回复了数据的问题，还没有解决不同种类的应用应该如何部署，让我们从数据的分类作为切入点，从数据生产者角度来详细做数据分类，并对不同种数据的读写应用给出解决方案。这里的数据生产者指所有在数据生命周期过程会对数据进行变更的用户或功能。
![_]( "_")
这里先理解下几个关键词：
a）连接词 "to" 和 "and" 描述的是用户之间的"协作"关系，to的左边指数据的生产者，to的右边是数据的只读消费者。and用在没有只读用户的场景，它的左边和右边都是数据的生产者。
b）one指的是单一一个用户，all指的是全部用户，some介于one与all之间指一部分用户
c）not指用户不是外部用户，与外部用户区分出来是因为非外部用户的功能不需要区域化部署
再来解释各种数据类型：
a）One profile类型的数据指用户自产自销的数据，不需要被这个用户之外的其它用户查看，如Evernote中的笔记就是这类数据
b）One to All类型的数据指用由一个用户产生，所有用户只读的数据类型，博客就是这种类型的数据
c）One to Some类型指一个用户产生，多个用户只读，但不是所有用户都能看的数据类型，旺旺群中的消息就是这一类型
d）Some and Some类型的数据是指数据生产者有多个，但除了数据生产者外没有用户会去读取数据，仿佛是One Profile的放大版，如果我们把Some当成一个整体的话。这个是区域化部署最难解决的问题，这类场景下需要跨区域读写数据
e）Some to All指一些用户作为数据生产者，所有其他用户是只读数据。电商中的商品就是这一种类型，商品数据会被卖家变更，也会被小二变更（禁限售审核），商品数据会被所有的其他用户只读
f）All to All是指所有用户都可以作为数据生产者，所有用户都是数据的消费者。WIKI类的数据就属是这种类型
g）Not to All是指非外部用户产生的数据，但给所有外部用户只读的数据，如电商中的类目数据
h）Not to Some是指非外部用户产生的数据，但是给部分外部用户使用的数据，如针对人群的离线数据
各类数据按的读写应用区域化部署方案为:
![_]( "_")
基于阿里技术体系的区域化部署架构
区域化部署架构总结
- 区域化部署，就近服务
1.1应用区域化部署，就近服务
1.2数据异步同步
- 数据读写
2.1单一数据Master
2.2默认就近读写
2.3低优先级跨区域写
2.4非Master区域一致性读取跨区域
2.5依据业务场景定义数据生产者优先级
对应的技术方案
![_]( "_")
由于区域化部署要解决就近服务的问题，因此需要关注每一个用户所在的最近区域，通过路由表，配置每个用户的就近机房解决，详细的路由表实现方案参考@余俊的文章:
http://www.atatech.org/articles/32169
各层路由的详细技术方案请参考：
http://www.atatech.org/articles/25635第3到6章
各应用部署方案指南
- 依据表格对读写各应用类型进行分类
![_]( "_")
- 各应用类型归类如下，找到应用所对应的归类
![_]( "_")
- 找到归类对应的逻辑区域定义，依据逻辑区域的部署方案进行区域化部署实现。
![_]( "_")
- 各逻辑区域定义的作用是，可以作为区域化部署架构的逻辑单元，未来可以单独针对单元进行管理，比如在某些区域可能单独对RR中的应用进行区域化部署等。类似于淘宝单元化中的单元概念或支付宝LDC中Zone的概念。
