2012中国软件开发者大会(SDCC)于9月8-9日在国家会议中心召开，本次大会由CSDN、《程序员》杂志、ITEye合办。作为年度最具实战的技术盛会，大会云集了来自国内外一线互联网和企业级软件公司的实战专家，就高可用性系统架构、海量数据挖掘、开放平台服务与架构、智能推荐系统、异构计算等话题和参会者进行了深入分享与探讨。
Twitter高级女工程师岳峣解读为来宾带来了题为“Twitter：搭建实时系统平台”的主题演讲。
岳峣表示，Twitter的创意自始至终都非常简单，一开始只是这样一个基本模型，发展了六年还是非常简单，基本上核心业务第一是时间线，所有看到这个内容的顺序就是时间线。第二条内容单位就是推文，第三就是推文所有者以及用户ID。基本来说Twitter所有核心计算都是围绕着这三类基本数据进行的。
它的计算类型，当一个用户生成一条推文的时候必须存储在一个可靠的文件，所以这个步骤是有很高实质性要求的。但是当我所读我所订阅推文的时候，这时候可以读比较早的忽略则新的内容，但是读通路和写通路数据要大的多了，，写通路一秒钟，Twitter大概5000条推文声称，但是可能有几十万条不同请求。读一条可能要用几十条上百条的推文，这个数据量很大，所以读通路和写通路大大不同，读通路需要写通路配合，使得通路获得最新的信息，这个过程会提高写通路的延时。最后一类是用户不容易见到的离线通路，比如说做一个数据统计或者分析，可能会经过一些比较复杂的计算，但是它的时时要求是最迫切的。
摆在Twitter系统工程师面前的问题是我们有不同的计算和不断扩展的应用，系统要搭建一个平或可以扩展的平台，不关心应用是哪一类型的，不管是符合哪种计算类型的服务都要及时开发，有效地利用生产环境提供各项资源。我今天从三个方面来讲，从设计角度来讲，Twitter体系架构有什么样的变迁，第二是新的技术嫁给上怎么做开发，最后讲一下公司早期很容易被忽略的管理成品环境。
刚才说Twitter就是三个基本数据，用户、时间线、推文，很早的时候Twitter确定了对这些基本数据进行存储，所以在存储和数据提取有用户存储、用户交互关系存储、推文的存储。用户对推文有几个所有关系，所以从开始到现在没有特别大的变动。但是对上面的数据处理以及对数据进行渲染，都是有一个基于一个应用完成的，随着Twitter的发展这个应用越来越大。当这个应用大到一定程度，我加入Twitter的时候，Twitter有300个工程师，你想想几十个人在同一个业务上开发很容易发生代码冲突的问题，所以需要把Twitter一些核心功能抽里出来，比如有抽离用户对象服务、处理时间线服务等等，有这些基本服务的时候是不是就可以说把旧有外部请求转移到新的体系上?当你有一个新系统没有经过测试的时候转移是有很大风险的。我们新系统开发是两年前，当时如果转移不成功对Twitter是非常大的打击，所以我们需要有一个非常平稳的旧系统向新系统过渡的过程。当Twitter只有一个应用层的时候非常简单，我爸这个请求按照流量均衡原理发给不同系统，Twitter一年半以前将我们自己写的基于JBM反向代码投入服务使用，这个服务完全是自己写的，里面有很强的过滤支持，可以灵活配置，可以选择将多少外部请求发送到旧有应用，也可以发给新的API中断，还可以发送给新的Web终端，我们到现在还没有百分之百脱离这个应用。这个体系从单篇化变成模块化，从运行环境讲放弃了Ruby，转向了JVM。系统提高了性能，硬件资源利用率提高了，改进了可靠性，缩短了开发周期，明确机构划分。
当我们有了新的体系结构的时候，现在的开发是什么样的，?我首先说一下模块化的利与弊，模块化有很多好处，单位开发缩短了，第二有了系统边界以后，一个系统服务失效发生异常不容易扩散到系统其他部分。另外在资源规划的时候，系统各个部件增长不见得同步，模块化也有些问题，以前在本机上的操作现在可能通过远程调用，网络游复杂性和不确定性，延时上需要考虑。当很多团队同时开发的时候，没有很好的协调开发商有些问题，所以模块需要交互的时候很有可能交互的结果就是不确定的或者不兼容在里边。怎么样更好地发挥它的长处，同时避免一些问题?Twitter对于这个问题给出的答案是及早地构建一个可以复用的基础设施，因为分布系统中所有服务是需要面对的，比如怎么来管理连接，怎么处理并发，这些问题是共同的。所以Twitter就设计了RPC服务框架和工具，把刚才的问题通过一个函数库来支持。Twitter意识到在大型系统中要知道系统是否可靠，很重要的是对系统各个部件进行有效观测，大概两年前Twitter完全从底层开始设计了系统运营数据收集、存储、表达和系统健康状况预警，同时还支持分布式的追踪。分布式系统测往往需要一个驱动器，还有接口生成标准等等。
这么多可复用基础设施，如果写一个新服务的话它长成什么样子，首先你得给它一个名字，指定要执行什么样的协议，同时指定一排服务器响应多少请求，数据收集和分布式把数据发到不同地方去。软件开发者如果发一个新的服务，就是最后一步，当要实体一个服务的时候，或者说你有一个请求做出什么反应，开发商是怎么响应一个请求，这就是这个工具比较强大的一点。通常每一个工具，它还是客户端，你告诉他怎么发现服务的位置，也就是服务的名称，怎么管理他的连接，在连接失效的时候怎么处理宣传失败的状况。现在Twitter比较核心的服务都是基于这样一个结构来设计和实现的，比如时间线服务是最重要核心业务之一，它在使用了框架以后，现在Twitter大约有1.4亿活跃用户，时间线流量大概每秒20万次请求，时间线做99%情况下低于四毫秒做出响应，总得来讲这个服务性能还是非常令人满意的。
分布式追踪看似并不是特别重要，但是对开发者来讲非常非常实用的功能，这是分布式系统给出响应一个时间线服务所做的调用，包括这些调用发生的次序，每次调用所占时间都反映在图表中，这对开发者来说非常重要。
最后讲一讲管理成品环境，成品环境在软件开发早期，人为干涉人为管理的时候在你有成千上万服务器的时候就完全失效了，而且对于一个快速发展的公司来说有一个问题，成品环境的管理是需要很长周期建设的，不是说今天人为管理明天就可以精细化管理，这需要公司有远见及早进行这方面的投资。成品管理有几个目标，第一个是可用性，你的硬件资源还要有效使用，当达到一定规模的时候要是自动化的。Twitter的答案是Mesos，我们一般操作系统中由内核负责资源分配和程序的调用，Mesos就是在一个分布式系统中的新内核。Mesos首先整合资源，就是这些服务器，把它拿过来进行统计，根据不同应用需求，任何应用只要向Mesos请求资源，Mesos都能够给予支持，今天在Twitter开发一个新服务的话，它的调用有可能通过Mesos的布局。它还支持自动的把服务的位置报告给观测者，观测者可以持续对服务健康状况进行观测，这些都是Mesos的好处。我们可以看出它在自动化管理方面起到很大的作用，刚才说的目标还有可靠性和效率，这方面Mesos也有很大的帮助，假设你的服务器是定向的设置，但是现在不巧有50%电源坏了，那么Mesos能够探测到硬件资源失效，他还是尽量满足资源需求，他就把失效机器从资源中分离出去，重新分配相应资源里满足服务资源需求。也就是说不需要人为干涉的情况下保持它的有效性。另外一方面就是效率，Mesos把资源抽象化了所以可以多个应用一个服务器上。
总的来说，Twitter过去两年体系结构的演变吃线了体系结构模块化服务开发抽象画和资源管理抽象化，作为一个系统程序开发者的角度来讲，当我刚刚加入Twitter的时候，Twitter的后台开发基本上没有拜托把已有开源项目放在一起的模式，随着开发能力不断加强，我们通过了项目拿过来改，现在Twitter已经完全有能力向下深入。虽然Twitter和国内很多互联网巨头比起来还是一个后者，但是作为一个系统工程师这些变化是非常令人振奋和激动的，对我来讲是作为系统开发的乐趣所在，所以希望大家关注Twitter开发的进展，对于已经有的开源项目有意见，我们也非常愿意聆听。
