IFTTT的数据架构
最近在调研一款神器——IFTTT，发现这个应用用了不少高端的技术，比如说：Docker、微服务架构、Kafka、Amazon云服务、Elasticsearch、机器学习、数据挖掘等。下面开始介绍。
IFTTT简介
IFTTT是什么？
在使用 IFTTT 的过程中，主要就是要创建自己的Recipes (流程) 来为自己服务。一个 If this then that (如果这样就那样) 的工作流程称之为Recipes，可以理解为一个由你自己组合出来的「功能」。如下图：
Recipes的目的是打通「this」和「that」两个网络服务，网络服务在这里称为Channels(频道)，前者称为Trigger Channel (触发器频道)，后者称为Action Channel(动作频道)，当触发器频道满足触发条件，那么就会执行动作频道指定的动作。举个例子，「如果Flickr上传新图片，那么就自动保存到Dropbox」，Flickr就是触发器频道，Dropbox就是动作频道。所以，利用IFTTT创建一个「Recipes 流程」的流程如下：先选择一个触发器频道，设置它的触发条件，再选择一个动作频道，然后设置它要执行的动作就可以了。
目前 IFTTT 所支持的「频道」也算比较丰富，比如FaceBook、Twitter等，总数多达100多个，它们之中大多数既可以当触发器，也能作为动作来使用。每个具体的频道所支持的「条件」和「动作」各不相同，可以根据实际需求来选择。
此外，IFTTT不仅支持互联网服务，还支持手机应用。诸如等手机的联系人、照片、短信、地理位置、通知推送等「频道」。
IFTTT 是国外的产品没有中文版，而且除了支持 Evernote 的国内版印象笔记之外，除了新浪微博以外，其他国内的网络服务支持几乎为零。
开发这个应用的公司比较有前瞻性 ，近年来，更加的关注物联网，增加了很多智能设备的支持。比如说，如果你有parrot这款植物土壤环境检测设备，你可以利用IFTTT来给你发送通知、自动打开浇水、或者打开照明灯。之前它更多地是一个互联网产品互通的工具，而现在它应该说是一个物联网时代的产品互通工具。
国内的模仿者
为了模仿IFTTT，国内也有过一小段时间的尝试。当时是厦门的一群人，以返还网CEO陈方毅为主做了一个叫“如果云”的服务。他们做了一段时间后，发现了一些问题，然后再也没有更新了。2011年他们总结失败的原因如下：
第一， 这类网站的鼻祖IFTTT本身在美国的流行范围也仅限于geek圈，属于曲高和寡的类型。自五月份上线以来，虽然概念很炫很强大，但涉及的面太宽泛，if then看似包罗万象，什么都能做，结果什么都做不好，核心问题在于缺乏一个killer app。在信息过剩的时代，大而全的东西并不能吸引和留住用户，加上缺乏核心应用，一款新产品要迅速积累用户是很困难的。本身在商业逻辑上存在着先天不足，这也导致ifttt在美国发展得并不好，国内这些山寨产品受到影响也就很好理解了。
第二， 与国外相比，国内的开放环境更不理想，类IFTTT服务本身需要基于各大平台的API来做服务，而诸如新浪微博这些平台对同步类应用的管控和封杀，让这类产品失去了大量用户。
第三， 如果云并不是公司的主营业务，只是几位工程师觉得好玩，就做了，公司允许这样小规模的尝试，但不会无限制投入，也不会化太多资源去推广。而最根本的原因在于，通过尝试，发现了IFTTT自身的缺陷。单纯靠一个概念是很难成功的。
除了“如果云”，还有“如果说”(http://www.ruguoshuo.com/)、“如果就”(http://ruguojiu.com/)、“一旦就”(http://yidanjiu.com/)、“假设就”(http://jiashejiu.com/)等这几个国内的模仿者，也最终因为无法提供有价值的服务而纷纷倒闭。
国内的开放平台目前还处于初级阶段，而且总存在相互封杀的现象。比如说，if 我在新浪主页看到一条新闻，then我同步到腾讯微博上，这个是不允许的。即使腾讯做的话，比较有可能做的也是一套内部的开放机制：1）允许腾讯产品间的联动，通过开放接口来解决不同部门技术标准不通的问题；2）允许外部信息向内流动，比如分享告知。
关键技术
Docker
Docker 作为一种开源的Linux应用容器(Linux Container)引擎，允许开发者将他们的应用以及依赖打包到一个可移植的映像中，便于应用的部署和扩展。开发完成后，运维人员开源直接使用这个映像，将其发布到任何装有Docker的机器上。
Docker的基础是Linux容器技术(LXC)。其实Docker用的也不是什么新的技术，用的是Linux内核的namespace和控制组技术，就是在LXC的基础上进行了进一步的封装，让用户不用去关心容器的管理，使得操作更为简便，但是最终却很火，而且很多人都愿意用，这就是它成功的地方。
Docker有3个基本的概念，镜像、容器和仓库。Docker的镜像类似虚拟机的快照，是一个只读的模板。比如说，一个镜像里面可以包含一个完整的Ubuntu操作系统环境，里面仅安装了Apache或用户需要的其他应用程序。Docker运行容器之前需要本地存在对应的镜像，如果镜像不存在本地，Docker会从镜像仓库下载。可以从镜像中创建容器，应用是由容器运行的。Docker利用容器来运行应用。容器是从镜像创建的运行实例，每个容器都是相互隔离的。它们也拥有一个唯一ID和唯一的供人阅读的名字。仓库是集中存放镜像文件的场所，可以把容器看做是一个简易版的Linux环境（包括root用户权限、进程空间、用户空间和网络空间等）和运行在其中的应用程序。
Docker利用LXC技术实现了容器之间的隔离，LXC内部依赖Linux内核的3种隔离机制：chroot、Cgroups和Namespaces。容器之间的隔离主要利用了Kernel的namespace机制，利用uts实现主机名的隔离；ipc实现container进程间通信的隔离；pid进程树的隔离；mnt挂载点的隔离；net网络接入包括接口的隔离；实现权限的隔离控制，保证容器之间彼此互不影响。
微服务架构
微服务是软件架构领域的一个新名词。它的本质就是用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。它提倡将单一应用程序划分成小的服务，服务之间相互协调、相互配合。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。所谓的轻量级通信机制，通常是指语言无关、平台无关的交互方式。对于轻量级通信的格式而言，XML或者Json，它们的解析和使用基本与语言无关、平台无关。对于轻量级通信的协议而言，通常是基于HTTP，能让服务间的通信变得标准化并且无状态化，REST(Representational State Transfer，表述性状态转移)是实现服务间互相协作的轻量级通信机制之一。
在微服务架构中，服务与服务之间是独立的。每个服务都是独立的业务单元，当对某个服务进行改变时，对其他的服务不会产生影响。在单块架构中，整个系统运行在同一个进程中，虽然将应用程序的代码分成逻辑上的三层、四层或者更多层，但它并不是物理上的分层。在微服务的架构中，每个应用程序由多个服务组成，每个服务都是一个具有高度自治的独立业务实体。通常情况下，每个服务都能运行在一个独立的操作系统进程中，这就意味着不同的服务能非常容易地被部署到不同的主机上。综上所述，微服务架构其实是将单一的应用程序划分成一组小的服务，每个服务都是具有业务属性的独立单元，同时能够被独立开发、独立运行、独立测试以及独立部署。
Docker 作为一种开源的Linux应用容器(Linux Container)引擎，允许开发者将他们的应用以及依赖打包到一个可移植的映像中，便于应用的部署和扩展。开发完成后，运维人员开源直接使用这个映像，将其发布到任何装有Docker的机器上。Docker的出现，有效地解决了微服务架构下，服务粒度细、服务数量多所导致的开发环境搭建、部署以及运维成本高的问题。利用Docker的容器化技术，能够实现在一个节点上运行成百甚至上千的Docker容器，每个容器都能独立运行一个服务，所以也就降低了微服务数量增多导致的节点数量增多带来的成本。容器的概念和微服务正好相辅相成，通过Docker封装的应用可以轻松运行在以扩容能力见长的云计算平台上。
Kafka
Kafka(http://kafka.apache.org/)是由LinkedIn开发的一个分布式的消息系统，这项技术是LinkedIn 的“中枢神经系统”，管理从各个应用程序汇聚到此的信息流，这些数据经过处理后再被分发到各处。它使用Scala编写，因具有水平扩展和高吞吐率而被广泛使用。这个项目最初是由LinkedIn公司的3位工程师创立的，后来这三个人拿着这个技术创业去了，由Jay Kreps 带头创立了新公司Confluent，专门为各行各业的公司提供实时数处理服务解决方案，其他两位成员是Neha Narkhede和Jun Rao。该公司已获 Benchmark、LinkedIn、Data Collective 690 万美金的融资。
目前，很多开源分布式处理系统如Apache Storm、Spark都支持与Kafka集成。在对网站的使用情况做报表时会用到一种称为活动流的数据。活动数据包括页面访问量（Page View）、被查看内容方面的信息以及搜索情况等内容。这种数据通常的处理方式是先把各种活动以日志的形式写入某种文件，然后周期性地对这些文件进行统计分析。运营数据指的是服务器的性能数据（CPU、IO使用率、请求时间、服务日志等等数据)。活动和运营数据处理已经成为了网站软件产品特性中一个至关重要的组成部分。
传统的日志分析系统提供了一种离线处理日志信息的可扩展方案，但若要进行实时处理，通常会有较大的延迟。而现有的消息（队列）系统能够很好的处理实时或者近似实时的应用，但未处理的数据通常不会写到磁盘上，这对于Hadoop之类（一小时或者一天只处理一部分数据）的离线应用而言，可能存在问题，Kafka的出现就解决了上述问题。Kafka具有很高的吞吐量，每秒可以生产约25万条消息（50 MB），每秒处理55万条消息（110 MB）。
Kafka有自己独特的设计思路：首先就是 高吞吐量，刚刚的数字已经是一个很直观的证明，它被设计的初衷就是用来处理海量的系统日志数据；其次就是 持久化消息存储，对于海量且安全性不高的消息，为了降低开销代价，Kafka采用本地文件系统的存储方式，而且存储采用了高效的 partition机制；再次，Kafka消费端采用 Pull模型，Kafka采用消费者主动从代理获取消息的“拉”模型消费机制，消费状态保存在消费端，而不是服务端；最后， zookeeper的负载均衡机制，Kafka使用分布式协调服务zookeeper来管理和平衡客户端负载。ElasticSearch
AWS
AWS是Amazon Web Services的简称。亚马逊以Web服务的形式向企业提供IT基础设施服务，即云计算服务。下面介绍的这几个技术在IFTTT中均有应用。
AmazonRDS
Amazon Relational Database Service (Amazon RDS) (https://aws.amazon.com/cn/rds/)
是亚马逊所提供的云服务产品中的一种。RDS是一种建立在关系型数据库上的服务，该服务可以让用户非常容易且方便的安装、操作、维护和管理关系型数据库，从而可以把主要精力投入到软件本身的应用开发和业务上。说得通俗一点，RDS就是一个功能更多、更强悍的关系型数据库，使用这个数据库，很多DBA的工作，比如说数据库安装、物理/逻辑设计、版本升级、备份还原等不需要你来做，或者说做起来很容易。利用RDS能够在云中轻松设置、操作和扩展关系数据库。它在管理耗时的数据库管理任务的同时，可提供经济实用的可调容量。Amazon RDS具有如下特点：
l 部署安装快速
使用RDS，只需要在亚马逊控制台，或者通过亚马逊提供的操作命令行或者其他API，进行简短的几步操作，就可以搭建好一个类似于关系数据库的服务，然后配置数据源，直接使用就可以了。
l 托管
Amazon来帮你管理这些数据库服务器，比如说软件升级、打补丁、备份还原、副本功能等，你可以把精力投入到应用开发以及数据库优化上去。
l 兼容性
Amazon RDS通了三种实例引擎，Amazon Aurora、Oracle、Microsoft SQL Server、PostgreSQL、MySQL 和 MariaDB。可以根据项目需要，选择合适的实例引擎，然后可以像操作本地数据库那样操作关系型数据库，不需要考虑如SQL语法、存储过程的兼容性等问题。
l 扩展性
Amazon RDS可以根据你系统业务量的大小，自动的扩张数据库的存储大小以及实例机型的类型。比如说，项目运行一段时间后，存储不够了，Amazon RDS会给你动态的增大存储；或者由于业务复杂，数据库计算量变大，数据库实例对应的机器CPU计算不过来，它会自动的将你数据库实例升级成更高版本的实例。
l 安全性
RDS安全性设计主要包括访问安全性和数据传输的安全性。对于数据传输安全性，当你的应用大都是通过互联网获得RDS的连接并传输数据时，你在创建对应的RDS实例时，你完全可以通过配置，指定使用相应的协议来传输数据。对于访问安全性，RDS提供了类似于防火墙设置的功能。利用该功能，你完全可以通过配置，指定哪些IP能访问你的RDS，哪些 EC2安全组能访问你的RDS。甚至，你可以使用Amazon的VPC服务，将你的RDS完全隔离在自己的私有云里，这样，只有在你私有云里的IT设施能访问这个RDS。AWSData Pipeline
AWS Data Pipeline 是一种Web服务(https://aws.amazon.com/cn/datapipeline/)。利用 AWS DataPipeline，可以经常访问存储数据的位置，成批转换和处理数据，并高效地将结果传到各种AWS服务。利用AWS Data Pipeline可以迅速定义包含数据源、目的地、预定义或自定义数据处理活动的依赖数据链，称之为管道。它使在AWS云中安排常规数据移动和数据处理活动变得更为简易，能够快速轻松地部署管道，无需分心管理日常数据操作，从而让您能够集中精力从该数据获取所需的信息。
AWS S3
Amazon S3是Amazon Simple Storage Service的简称(https://aws.amazon.com/cn/s3/)，是一种面向Internet的存储服务，为开发人员和IT 团队提供安全、耐久且扩展性高的云存储。它通过提供简单的Web服务接口，可以存储和提取任意数量的数据，这些操作可从Web上的任何位置随时执行。
Amazon Redshift
Amazon Redshift是一种快速、强大且完全托管的PB级数据仓库服务(https://aws.amazon.com/cn/redshift/)。与传统的数据仓库相比，Redshift的性能提高了将近10倍，主要是因为它采用了列式数据存储、高级压缩、大规模并行处理等技术。
下面开始进入正题，结合官网挂出的一张图来介绍IFTTT的数据架构，大部分内容直接翻译的官网的原文。
架构解读
IFTTT利用各网站和应用的开放API，实现了不同服务间的信息关联。IFTTT的服务每天会产生超过数十亿个事件，所以IFTTT的数据框架必须具有高度的可扩展性、稳定性和灵活性等特点。IFTTT的官网上挂出了这张图，下面结合这张图详细说明IFTTT的数据架构。
在说明IFTTT的数据架构之前首先说一下IFTTT的数据来源。IFTTT有3种数据源用于理解用户的行为和Channel的性能。
首先，AWS RDS中的MySQL集群负责维护用户、Channel、Recipe及其相互之间的关系等核心应用。运行在其Rails应用中的IFTTT.com和移动应用所产生的数据就通过AWS Data Pipeline，导出到S3和Redshift中。
其次，用户和IFTTT产品交互时，通过Rails应用所产生的时间数据流入到Kafka中。
最后，为了帮助监控上百个合作API的行为，IFTTT收集在运行Recipe时所产生的API请求的信息。这些包括反应时间和HTTP状态代码的信息同样流入到了Kafka集群中。
IFTTT利用Kafka作为数据传输层来取得数据产生者和消费者之间的松耦合。数据产生者首先把数据发送给Kafka。然后，数据消费者再从Kafka读取数据。因此，数据架构可以很方便的添加新的数据消费者。
由于Kafka扮演着基于日志的事件流的角色，数据消费者在事件流中保留着自己位置的轨迹。这使得消费者可以以实时和批处理的方式来操作数据。例如，批处理的消费者可以利用Secor将每个小时的数据拷贝发送到S3中；而实时消费者则利用即将开源的库将数据发送到Elasticsearch集群中。而且，在出现错误时，消费者还可以对数据进行重新处理。此外，IFTTT为了增加商务智能，将S3中的数据经过ETL平台(一种数据仓库技术)Cranium的转换和归一化后，输出到AWS Redshift中。Cranium允许利用SQL和Ruby编写ETL任务、定义这些任务之间的依赖性以及调度这些任务的执行。Cranium支持利用Ruby和D3进行的即席报告。但是，绝大部分的可视化工作还是发生在Chartio(https://chartio.com/)中。而且，Chartio对于只了解很少SQL的用户也非常友好。在这些工具的帮助下，从工程人员到业务研发人员和社区人员都可以对数据进行挖掘。
机器学习 IFTTT的研发团队利用了很多机器学习技术来保证用户体验。对于Recipe推荐和问题探测，IFTTT使用了运行在EC2上的Apache Spark，并将S3当作其数据存储。
为了实现实时监控和提醒，API事件存储在Elasticsearch中，用于监控和提醒。IFTTT使用Kibana来实时显示工作进程和合作API的性能。在API出现问题时，IFTTT的合作者可以访问专门的Developer Channel，创建Recipe，从而提醒实际行动（SMS、Email和Slack等）的进行。
在Developer DashBoard中，合作者可以在Elasticsearch的帮助下访问Channel健康相关的实时日志和可视化图表。开发者也可以通过这些有力的分析来了解Channel的使用情况。