• Feeds

  • Posts Tagged ‘twitter’


    技术团队的标准化与可复用文化

    一次某用户在使用系统时候碰到一个问题,但不确认是系统的bug,于是问题通过各级的微博@消息反馈到产品与技术团队。在反馈链中,每一个同事都需要确认一下自己是否也出现这个问题,以便确认是否属实以及问题的范围(你可以理解互联网的从业人员为什么那么忙了)。

    当这个@消息最终传递到当事的工程师手里,他也需将描述的问题再测试一遍,如果不能重现,问题就变得更加复杂,工程师需要从一堆海量的日志去定位当时用户出现这种现象的原因。那一次排查到最后,发现原因是某台服务器的返回的数据不对导致,那台服务器可能是由于在某些特殊情况下,启动了一个不同的版本而导致用户的调用不能正常返回。如果你也是一个工程师,是否有几分熟悉的感觉?

    自从工程师键入第一行代码那一时刻起,开发流程中每个环节都存在出错的可能。比如

    • 代码可能未被单元测试覆盖,当然有更多的团队根本没有编写单元测试的习惯;业务流程未被功能测试覆盖;因此当最终用户才发现不正确的问题时(如文首描述的情况),整个技术团队需要更多的时间去解决。
    • 服务之间的调用方式、参数或逻辑不正确;当服务由不同的团队维护时,出错的概率会更大;另外一个团队的服务往往只有几行文字的描述的邮件,很多参数语焉不详,你需要通过以前的代码或者亲自调用一下来推测这些参数的作用。这时候如果你需要的功能刚好能调通,欢呼之外就是接着提交及发布代码了,因为上面已经开始对你联调时间过长有些不满。
    • 发布的版本、配置、顺序、服务器等不正确。尽管大家都觉得有一个上线手册之类的指导文档,但在实际工作中开发与运维的交互可能会是通过IM工具,开发工程师说,今天上线模块的顺序是ABDC,运维工程师虽然对为什么不是ABCD的这样的顺序有些疑惑,但也依照开发的顺序做完了。而下一次上线前,开发工程师没提及上线顺序,运维工程师可能纳闷,到底是ABCD还是ABDC呢?

    上面种种情况,如果每一次代码修改及发布都依赖每一位工程师的细心及考虑周全的话,则高概率的质量问题不可避免。而工程师则很沮丧的发现经常在解决同一类型的问题。而将全流程更多不易变的单元编程标准化,由程序来控制,则可以从源头上减少问题,让软件开发变得简单及享受。在上面例子中,可以将(1)测试过程标准化。(2)在服务化架构中,将更多的单元标准化。(3)发布流程标准化。这些点更多的看各团队工程的成熟程度。团队中标准化程度越高,软件的可靠性就会越好,更多的精力将会从各种不确定性问题中解放出来。

    说下第2点服务标准化的一个例子,Tim所在团队最近几年做的系统密集的使用了消息队列,经过几年的演进,也将各种很复杂的场景实现在系统内,比如多级串联、并联、实时性要求非常高的PUB/SUB,用自定义各种服务池来做任务调度,踩了很多坑也积累了很多经验。但是标准化意识以及抽象能力不足,业务架构与技术架构也缺少分开去考虑,因此大部分系统主要针对自己特定场景的设计去实现,即使有很多有价值的特性,但无法复用到另外的场合。当一些新人去学习Kafka这些系统时,老的架构师也会去反思标准化的问题。当然,3年以上的技术团队才会有这些感悟,年轻的团队通常会沉浸在搭建自己系统的快感中。

    再说另外一个例子,曾经有一篇技术贴说某个美国的工程师Twitter技术面试失败的经历。

    然后我们聊了一小会关于在twitter的生活。
    我挂掉电话的那一秒我意识到了我的答案是错的。
    ……
    现在我扪心自问:在这件事我学到了什么?客观地说——不多。对于面试官没有问我正确的问题来引导我向正确的方向思考,我很难过。当我的解答实际上不正确的时候,我不知道为什么Justin告诉我“这应该有用”。

    从中可以部分感受到硅谷科技公司对工程师的严格要求。但是国内的情况有所区别,由于互联网行业有些过热,合格的人才处于供不应求的情况,因此大部分岗位要求都比上文中描述的要求低。工程师只要具备基本的学习及模仿能力,比如能参考一个现有的软件能够实现相同的功能,那这个工程师基本能进入各个互联网技术岗位(当然表面的工作经历也是需要的)。

    在这种情况下,整个技术群体很难对代码质量形成太多共识。再加上大多团队是业务驱动型(技术驱动的凤毛麟角),企业对于技术的要求局限在按时交付。精心雕琢的软件相比于打补丁修补而成的软件并不会得到更好的价值体现,因此追求高质量软件的风气也不易形成。

    企业里面的软件可复用还有恶性循环的情况,比如某个工程师做了一个公共组件来解决一些公共问题,但是另外一个团队在使用后发现存在一些问题,理想的情况是,反馈的问题得到了及时修复,解决了各个团队共性的需求,公共组件在更多场合得到了推广。但在现实中,具备开发良好公共组件能力的人是非常稀缺的,尽管每个Web开发团队都有开发一套自己的MVC框架,但在做到优雅的业务实现方面尚有不足的情况下,一厢情愿的去做自己的标准组件是较难把握共性的需求及得到使用认可。

    在另外一方面,其他的团队也容易把“那个版本没有很好的满足我们需求”的情况成了自起炉灶的理由,通过各自建设,表面上完成了自己的内部需求,自认为团队内部的认知成本是降低了,但人的精力毕竟有限的,有限的时间只能做好有限的事情,最终各自搭建可能也只能建成一些不可复用的系统,除了短期的自我充实感之外较难有更多的价值。

    应用层的容错与分层设计

    针对在项目中碰到的一些容错设计问题,团队最近进行了一次技术沙龙,讨论了以下话题。

    为什么需要应用层的容错设计?

    一个完整的系统在内部是由很多小服务构成,服务之间以及服务与资源之间会存在远程调用。

    • 每个系统的可用性不可能达到100%
    • 各种网络及硬件问题,如网络拥堵、网络中断、硬件故障……
    • 远程服务平均响应速度变慢

    服务器平均响应速度如果慢下来,慢慢消耗掉系统所有资源,进而导致整个系统不可用。因此在分布式系统中,除了远程服务本身需要有容错设计之外,在应用层的远程调用的环节,需要有良好的容错设计。

    应用层的容错设计有哪些方法?以下是微博团队使用过的一些实践。


    访问MySQL的容错设计

    • 写操作:如果master异常,直接抛异常。
    • 读操作:如果slave有多个,先选择其中一个slave,如果获取连接失败,再选择其他的slave,如果全部不可用,最后选择master。


    访问Memcached/Redis的容错设计

    首先设置so_timeout,避免无限制等待;服务器连接如果IO异常,设置错误标志,一段时间停止访问;出错后定期主动(比如ping Redis)或被动(当被再次访问时)探测服务是否恢复。

    Failover机制:
    如果连接某个node失败, 当前pool启用一致性hash切换到backup node;如果backup node没有数据,则通过另外一个服务池(数据副本)获取数据。


    访问远程HTTP API的容错设计

    设置so_timeout;部分场景:短超时,重试一次;另外由于HTTP service情况的多样性,业务层面还有通用的降级机制。


    访问不同资源使用不同方法存在的问题

    从上面列举的部分场景来看,在访问不同资源时候,每种client访问都有一些相通的原理,但却要使用不同的重复实现。由于各个client独立实现,实现时候由于各个远程服务协议及行为的差异,导致这些容错原理无法直接复用。另外在代码层面,不同的client也使用了不同年代的一些底层库,一些早期client的实现,数据层,连接层,协议层全部耦合在一起,也造成维护成本进一步加大。

    比如之前一些服务开发中碰到的类似如下的问题:

    • hbase-client由于没有实现容错设计,导致访问出现了抖动,影响了同一服务池的其他调用,需要增加类似MySQL client的容错及快速失败策略;
    • MySQL slave流量出现不均衡了,由于多个slave IP之间没有使用公用的负载均衡策略,因此需要重新添加、上线及验证。

    另外目前分布式系统中大部分远程资源都是IO bound而不是CPU bound,而client大部分又是同步调用,造成大部分调用都在等待远程返回,同时也消耗了工作线程资源,以及大量线程context switch。


    有没有可能统一的client?

    这些策略原理上是可以公用的,能否出一个统一的client层来一劳永逸?不过这个需求不是twitter干过吗?

    Finagle,不仅是平时理解的RPC框架,还有目标是想成为一个commons client,从另外一个层面,广义上访问远程资源也都可以理解成RPC,所以Finagle也常称为RPC框架。

    Finagle implements uniform client and server APIs for several protocols, and is designed for high performance and concurrency.

    在Twitter体系,分布式服务可以从future, service, filter三个层次理解,容错、超时、授权、tracing、重试等机制都是体现在filter中;而future则将client从多线程、队列、连接池、资源管理释放出来,从关注控制流到关注数据流。并且默认变成异步方式。

    Finagle的FailFast模块会避免分发请求到出现问题的服务,它通过来记录到每个host的错误来进行标记,当出错以后,Finagle会通过一个后台线程定期重连以检查是否恢复。当host宕机时,相关的service会标记成不可用。


    如果来redisign一个通用的网络client,它应该包括哪些元素?

    • 具有服务的分层设计,借鉴Future/Service/Filter概念
    • 具有网络的分层设计,区分协议层、数据层、传输层、连接层
    • 独立的可适配的codec层,可以灵活增加HTTP,Memcache,Redis,MySQL/JDBC,Thrift等协议的支持。
    • 将多年各种远程调用High availability的经验融入在实现中,如负载均衡,failover,多副本策略,开关降级等。
    • 通用的远程调用实现,采用async方式来减少业务服务的开销,并通过future分离远程调用与数据流程的关注。
    • 具有状态查看及统计功能
    • 当然,最终要的是,具备以下通用的远程容错处理能力,超时、重试、负载均衡、failover……

    Notes about Timelines @ Twitter

    Twitter timeline团队负责人在QCon London上分享了一篇Timelines @ Twitter的演讲,以下是其中一些摘要。

    数据

    1亿活跃用户
    Timeline接口2万QPS
    推送平均1ms,99% 4ms以内
    每天2.5亿条新Tweets,平均3千/秒,峰值1万以上。
    每天260亿次分发,每秒1800万(从中看出平均关注100人)
    投递100万粉丝的时间需要3.5秒,每秒可投递28万

    架构

    材料中以介绍推(fan-out)为主
    对于followers多的用户,从fan-out上采用pipeline的方式并行投递推送,每个任务负责分发4000个粉丝

    fan-out首先投递到timeline cache上(page cache?)
    用户收件箱采用redis存储,Redis只包括活跃用户,冷用户随时间过期
    使用Redis的list数据结构,每个item中还包括tweet ID, user ID及标志位3个字段
    使用Redis RPUSHX来避免写入冷用户
    对于频繁访问用户的timeline, 设置in-process cache(local cache)
    fan-out及fan-in的比较如下

    技术选型与演进

    Redis,使用了Redis来代替之前的memcached来存储vector cache
    Thrift, 内部调用已经基本使用Thrift方式服务化,参看P109
    Scala,内部服务基本使用Scala实现,但搜索模块使用Java实现,视频Q&A中提到
    Finagle,较多篇幅介绍,是一个Scala实现的网络库,基于Netty框架的基础上

    123...Last