Arch 类别下的文章

按:此为客座博文系列。投稿人吴朱华,曾在IBM中国研究院从事与云计算相关的研究,现在则致力于研发下一代云计算系统,撰写一些与云计算相关的文章,他的个人站点: PeopleYun.com。(文章版权属于原作者,转载请勿混淆。本篇原文地址)

本文将首先介绍一下多租户的概念和多租户的优缺点,之后会讲解几个常见的多租户模型。

概念

虽然对我们而言,多租户(Multitenancy)可以算是一个非常新颖的概念,但是其实这个概念已经由来已久了。简单而言,多租户指得就是一个单独的软件实例可以为多个组织服务。一个支持多租户的软件需要在设计上能对它的数据和配置信息进行虚拟分区,从而使得每个使用这个软件的组织能使用到一个单独的虚拟实例,并且可以对这个虚拟实例进行定制化。但是要让一个软件支持多租户并非易事,因为不仅对它的软件架构进行相应的修改,而且需要对它的数据库结构进行特殊的设计,同时在安全和隔离性方面也要有所保障。

还有,为了帮助大家进一步理解多租户这个概念,特别选取两个和多租户比较接近的概念来进行进一步的辨析。

多租户和多用户的区别

多用户的关键点在于不同的用户拥有不同的访问权限,但是多个用户共享同一个的实例。而在多租户中,多个组织使用的实例各不相同。

多租户和虚拟化的区别

多租户和虚拟化在概念是比较类似,都是给每个用户一个虚拟的实例,并且都支持定制化,但是它们作用的层次不同:虚拟化主要是虚拟出一个操作系统的实例,而多租户则是主要虚拟出一个应用的实例。

优缺点

多租户的优点:

  • 经济:因为通过一个软件实例被多个组织共享,从而减低了整体资源的消耗,也同时减低应用运行的成本和相应的管理开支。
  • 易于更新和开发:因为所有组织都共享同一套核心代码,所以能够让软件更新和开发更简单。
  • 管理方便:首先,通过使用了多租户架构能减少物理资源和软件资源,这将简化管理。其次。由于多租户软件主要由有经验的云供应商运营,所以能依赖那些非常经验的管理人员来提升效率。

多租户的缺点:

  • 更复杂:由于一个软件需要做出极大地修改,才能支持多租户架构,而且这种修改,往往会增加整个软件在架构方面的复杂性。
  • 不够安全:因为众多组织的应用和数据共享同一套软件和基础设施,如果出现机器宕机,软件出现问题或者大规模的数据被暴露等情况,将会造成更严重的后果,因为影响面更大。

几种模型

在现有的实现中,主要有三种常见的模型,而且区别主要在于采用不同的数据库模式(Database Schema):

  • 私有表(图1-a):它是最简单的扩展模式,就是为每个租户的自定义数据创建一个新表。优点是简单。缺点是涉及到高成本的DDL操作,并且它的整合度不高。
  • 扩展表(图1-b):总体而言,比较类似于私有表,但是一个扩展表会被多个租户共享,所以无论是共享表还是基本表都会有租户栏位。好处是比私有表更高的整合度和更少的DDL操作,但是在架构上比私有表更复杂。
  • 通用表(图1-c): 主要通过一个通用表来存放所有自定义信息,里面有租户栏位和许许多多统一的数据栏位(比如500个)。像这种统一的数据栏位会使用非常灵活的格式让转储各种类型的数据,比如VARCHAR。由于在每一行中的数据栏位都会以一个Key一个Value形式存放所有自定义数据,导致通用表的行都会很宽,而且会出现很多空值,所以通用表这种方式也被称为"Sparse Column"。好处是极高的整合度并避免了DDL操作,但是在处理数据方面难度加大。

multi modes.PNG

图1. 多种模式(图源自参[7])

差异与取舍

模型 机制 优点 缺点
私有表 为每个租户的自定义数据创建一个新表 简单 需要DDL操作,低整合度
扩展表 一个扩展表会被多个租户共享 高整合度,少DDL操作 有点复杂
通用表 通过一个通用表来存放所有自定义信息 极高整合度,无DDL操作 实现难度高

在实战中,具体选择那个模型,主要还是看那个模型更适合。

关于多租户的介绍已经基本结束了,下一篇将详细介绍Force.com的多租户架构。

--EOF--


本系列文章列表

按:此为客座博文系列。投稿人吴朱华,曾在IBM中国研究院从事与云计算相关的研究,现在则致力于研发下一代云计算系统,撰写一些与云计算相关的文章,他的个人站点: PeopleYun.com。(文章版权属于原作者,转载请勿混淆。本篇原文地址)

在云计算方面,Salesforce 可以称为业界的领袖,它不仅在产品方面比较成熟,而且在思维方面也是引领潮流的,特别是在SaaS(Software as a Service,软件即服务)和PaaS(Platform as a Service,平台即服务)这个两个领域内。

sf-logo-trans-new.png

图1. Salesforce 商标(图源自Salesforce.com)

首先,简要地介绍一下Salesforce的历史:Salesforce.com在1999年由前甲骨文高管 Marc Benioff 创立,他创办Salesforce的核心理念就是"No Software(消灭软件)",但是其意义并不是排斥所有的软件,而是主要排斥运行在企业数据中心的软件(On-Premise Software),也就是希望让用户能直接通过互联网来诸如CRM等软件服务,并同时让用户无需自己搭建和维护软件所需的硬件和系统等资源。Salesforce的主要产品包括Sales Cloud(CRM)、Service Cloud、Chatter和Force.com等。下面是它的主要发展史:

  • 1999年,Salesforce在美国旧金山成立。
  • 2001年,推出了第一款SaaS应用CRM,同时也受到众多厂商和客户的热议。
  • 2004年,Sunguard成为Salesforce第1000位用户。
  • 2005年,推出了名为"AppExchange"的程序商店,以丰富用户选择。
  • 2006年,推出了首个运行在云计算平台的语言Apex,并在语法上类似Java。
  • 2007年,推出了它的PaaS平台Force.com,来让用户更方便地在Saleforce平台上开发在线应用,同时Salesforce凭借Force.com得到了华尔街日报的科技创新奖(Technology Innovation Award)。
  • 2009年,Salesforce成为首家年收入达到10亿美元的云计算公司,并在年初推出了名为"Service Cloud"在线客户服务应用。
  • 2010年,Salesforce将推出名为"Chatter"的企业级在线SNS服务,类似于企业内部的"LinkedIn",同时其CRM应用已更名为"Sales Cloud"。

Salesforce的整体架构

虽然Salesforce这些产品从表面而言有所不同,但是从全局而言,它们却是一个整体,具体可看下图:

Salesforce Architecture.PNG

图2. Salesforce的整体架构 (图部分源自Salesforce.com)

从这张Salesforce的整体架构图可以看成,Force.com 是 Salesforce 整体架构的核心,因为它首先整合和控制了底层的物理的基础设施,接着给上层的Sales Cloud,Service Cloud,Chatter和基于Force.com的定制应用提供PaaS服务,最后,那些Force.com上层的应用以SaaS形式供用户使用。这样做的好处主要有两方面:其一是关于成本的,因为通过这个统一的架构能极大地整合多种应用,从而降低了在基础设施方面的投入。其二是在软件架构方面,因为使用这个统一的架构,使得所有上层的SaaS服务都依赖Force.com的API,这样将有效地确保API的稳定性并避免了重复,从而方便了用户和Saelsforce在这个平台上开发应用。

虽然Salesforce的"Sales Cloud"等SaaS应用也比较经典,但由于Force.com堪称整个架构的核心,同时也是最值得的学习和借鉴的部分,所以本系列接下来将会把重点对准Force.com。

Force.com

Force.com是Salesforce在2007推出的PaaS平台,并且已经有超过47000位企业已经使用了这个平台。Force.com基于多租户的架构,其主要通过提供完善的开发环境等功能来帮助企业和第三方供应商交付健壮的,可靠的和可伸缩的在线应用。

force.com logo.PNG

图1. Force.com 商标(图源自参[3])

总体而言,Force.com主要有五方面功能:

  • 强大的定制功能:在Force.com,不仅UI能够定制,而且诸如Workflow和表格等也能被定制。
  • 提供完善的开发环境:首先,通过Visualforce能方便地使用"Drag & Drop"的方式来设计页面。其次,Salesforce提供基于Eclipse的IDE来快速地开发应用。最后,Salesforce还提供Sandbox来方便用户测试。
  • 支持复杂的事务和流程:通过Force.com专属的APEX语言,能方便地设计和开发复杂的事务和流程。
  • 优秀的整合功能:用户除了可以在AppExchange购买其所需的功能和应用,而且还可以通过Force.com的Web Service接口来和其他应用整合,比如SAP等。
  • 久经考验的基础设施:由于Salesforce除了通过在多个大洲建有数据中心来应对灾难的发生,而且在可用性和安全性等方面也有一定积累,所以在Salesforce能长时间地支持众多服务的正常运行。

下一篇:《多租户的介绍》

--EOF--

本系列文章列表

QCon Beijing 后记

这次参加 QCon Beijing 2010 技术大会稍有点匆忙。23号早晨从杭州赶往北京,中午才到会场。25号下午原计划回杭州,结果因为天气原因没能成行,第二天上午才回来。在会场的时间安排的也比较紧凑,没时间整理,回到家里也是一堆事儿,一直没空出来时间写一下这次参会的感受。

到了会场就遇到不少熟人,也有网上熟悉但素未谋面的朋友,比如创建监控宝郭欣,还遇到来自盛大创新院的不少朋友。每次会议都会结识新朋友,和老朋友叙旧,大家在一起开开玩笑,诉诉苦,也会宣布一下个人的一些动向。

下午在听了一场比较扯淡的演讲之后(据说25号还有一个某大厂更扯淡的广告话题),重点听了一下豆瓣首席架构师洪强宁 (@hongqn)的《Python于Web 2.0网站的应用》 ,这是一次很好的 Python 技术布道,尤其是后半段,由浅入深讲解了好几个应用场景实现的技巧。我后来看了网上的评论,发现不少人忽略了这些案例的重要性,有点惋惜。我在Twitter上说了一句,经过这次的布道,相信明年就会有更多的开发人员用 Python 了。 豆瓣的技术团队对外策略挺有意思,老耿(@flycondor)说"把每个人都打造成技术明星",期待更多豆瓣牛人出来分享。

第一天的技术演讲,偏重语言方面的内容。下午除了观摩老赵 (@jeffz_cn)的主持风格之外,更多时间是和场外的一些朋友进行交流。晚上和几个朋友赶到奇遇花园咖啡馆参加推友聚会,相当的热闹,相当的开心。和技术Geek们在一起就是有趣啊。透漏一下,各个团队似乎都在面临技术人才荒,而且大家都说"钱不是问题"。一个秘密:虽然我在Twitter上花了这么多精力,但是推友聚会还真是头一回参加。

24日起来的稍微晚了一点,只听到了半场 Facebook 的 Marc Kwiatkowski 的演讲,关于 Memcached 的,个人感觉内容较为平淡,可能之前和我大致了解了他要讲解的内容有关吧。然后认真听了一下 Twitter 大牛 Nick Kallen (@nk)的演讲,很过瘾,对 Twitter 的架构设计有了进一步了解。整个演讲几乎是围绕数据的处理场景进行的,符合我的技术胃口。现在能记住的也就是最后 Nick 总结的几个原则了,包括:Twitter 解决扩展问题依赖的是一些通用的技术手段(索引、分区、复制);不要追求完美够用就行;实时查询的数据必须在内存中。具体的细节还要重新看一遍 PPT 与视频才好。

下午的事情是我这次参会的主要目的:主持人。第二次担任网站架构案例分析(CASE STUDIES)这个分会场的主持人,很有压力啊 :) 之前和演讲嘉宾的沟通没有像去年那么频繁,好在效率有保证,所幸,各位大牛的演讲 PPT 都是经过几次大规模修订,质量没得说。

第一场是潘磊介绍了阿里巴巴国际站架构以及镜像解决方案,以及相关经验。Alibaba.com 是国内少数横跨中美有 多个 IDC 的公司,业务也有其独特的复杂性,印象中这是 Alibaba B2B 第一次对外分享技术经验,潘磊开了一个好头。接着旅游搜索引擎去哪儿(qunar.com)的 CTO 吴永强介绍了监控与虚拟化的实战经验,演讲完了我才知道因为当天凌晨有重要项目发布,老吴4点解决完了问题杀到的会场(创业公司相当辛苦啊),下午结束后就回去休息了。人人网的黄晶介绍了 RenRen.com 的架构经验以及他们的开源项目,演讲结束后的提问可以看出大家对开源项目是相当有兴趣,问题差不多都问到了点子上。最后是来自新浪的杨卫华 (Tim Yang , @xmpp) 介绍可扩展的微博架构,也是相当精彩,和上午 Twitter 的演讲刚好互补。作为主持人,其实最担心自己场地内的人少... 另外的场地同时和这边 PK 的有淘宝章文嵩博士的技术演讲,还好,我偷着去看了一下,两边会场人数平分秋色。Tim 之前的精心准备很值得。

再次利用主持人的便利鼓动大家支持技术图书出版行业,也帮着会场外面的多背一公斤宣传了一下。

说说 24 号晚场的技术沙龙吧。最近自己似乎有转向娱乐圈的趋势,在前一段时间的数据库会议上客串了一次技术沙龙的主持人的活儿,不到一个月,这又硬着头皮做了一回主持人。老实说,做这样的事情对我来说是挺煎熬的。前20分钟,自己也感觉比较平淡;中间阶段互动问答也稍微有点温吞;后半段讨论到各公司的开源项目的时候才真的有感觉了。会上不少公司都非正式的宣布了接下来都会有一些开源项目要回馈给社区,其实也是各家公司对于开放(Open)的认识与认同。要感谢参加沙龙的各位嘉宾以及一起参与互动的各大公司的朋友们! 这是一个美妙的夜晚。

25 号这一天,下午要赶着回去,淘宝赵泽欣(小马,@zhaozexin)的演讲《淘宝网前端应用与发展》没有听完就走了,挺遗憾。这里透漏一个趣事:我在会场里看到小马的时候差不多都是在改进自己的 PPT,可能这也是 UED 人的一个特质吧。

出于技术方向的原因,这次会议也错过了好几场很重要的演讲,像邓草原( @dcaoyuan )大侠布道Scala与Erlang、熊节( @gigix )分享敏捷改造的经验、蔡学镛(@KongXuan)分享复杂事件处理(CEP)等等话题,听多位朋友的反馈都是非常的好。 Douglas Crockford 的压轴演讲据说也是相当的精彩,从 Twitter 上的火爆讨论可见一斑。

恭贺 InfoQ 成功举办了这次技术盛会。600 余技术人济济一堂。感谢泰稳 @taiwen)的努力。

自己的另外一个感慨是,英语交流能力太差了,错过了和国外技术大牛的深入交流。

总算一点点写完了这次 QCon 的流水帐。对于墙内的用户,建议也不妨翻墙搜索一下 Twitter 上 #QCon 的内容,不同人眼中的 QCon 是怎样的,非常有趣。经过我的测试,用 Dabr 的代理似乎搜索 HashTag 快一点(你懂的)。

下一次 QCon 我会以另外的身份参加了。

--EOF--

如果你也是 QCon 参会者且是 Twitter 用户,不妨参加一下这个"QCon Beijing 参会推友小调查"(非官方)

PC 服务器的 RAS 能力

曾经被问过很多次这样的问题:PC 服务器的可靠性到底是怎样的? 能否给出一个可用率数值?

这问题说来话长,而且也算不上是什么好问题,当然这里面有非常值得琢磨的地方,那就是 PC 服务器的 RAS 能力到底如何? 只有弄清楚这一点,才会明白在 PC 服务器计算能力已经如此强大的今天,为什么昂贵的小型机依然有市场。在服务器选型的时候才不会拍脑袋做决策。

我们说到 RAS ,也就是 Reliability 、Availability 以及 Serviceability,实际上很多人会认为前两者是一回事,至少提问的时候可能同时说的是这两者。对于多数 PC 服务器厂商来说,宣传页面上也只会写 Availability 的一些指标,对另外两点则选择性的回避? 为什么? 因为做不到高端服务器的 RAS 能力,而 RAS 能力实际上是需要成本的(硬件冗余成本、专有技术的成本),但这个问题似乎是很多用户选型的时候忽略的一点,很多人更愿意看重性能、性价比之类的指标,当然这也没错。

现在 PC 服务器宣称的卖点主要集中在内存上,比如内存的 ECC 特性(最基本的),Spare Row、ChipKill、Single Device Data Correction (SDDC)等,其中 ChipKill 是 IBM 的专利技术,主要用在高端服务器上。根据 Google 与一些机构的合作研究表明,内存错误率其实比想象中的要高(refer),这是个很有参考价值的信息。实际上,尽管有的 PC 服务器可能提供了很多内存相关的特性,但默认未必是激活的,这一点要注意。

高端设备的 RAS 能力比较,至少要看看 System 级别的 RAS 特性、CPU RAS 特性、内存 RAS 特性、I/O RAS 特性 等方面,如果有虚拟化的需求,还要关注一下 Application/Partition RAS 特性(refer)。这些都是卖点,当然,很少有销售人员懂得如何向用户宣传这一点。

即使是有了最好的设备,如果不能充分利用,其实也和普通 PC 服务器没啥区别。而对于绝大多数互联网应用来说,高端服务器也是高射炮打蚊子。

最后补充一点,充分利用带外管理能力是运维人员应该具备的基本意识。什么是"带外管理"请使用避难到香港的 Google 来搜索。

--EOF--

附:Dell PowerEdge 服务器激活内存 RAS 特性的指导文档

暂缓迷恋 Cassandra

最近 Twitter 和 Digg 的技术团队都放出话来说要从 Mysql + Memcached 的组合迁移到 Cassandra 环境(Refer 12),这些消息又会让不少人跃跃欲试,恨不得也把自家网站迁移到 Cassandra 下面过把瘾,我相信有些公司的团队又要言必称 Cassandra 了。

Twitter 和 Digg 对数据存储引擎的需求相当独特:写操作密集,基本无修改需求,读操作则多数是分散多次读取汇总展示(想象一下你 Twitter页面上同时显示好友们的 Tweet 内容)。对 MySQL 来说,Sharding 后几乎是被当作简单的存储引擎来用的,即使是加上 Memcached ,对数据读取开销相当大(Refer),因为这时候即使是最合理用索引,I/O开销也不是最优的--走的是索引范围扫描嘛。Cassandra 则相当于预存了计算结果,这要得益于其 Flexible schema 特性,按照既定规则写入,读取直接取预排序的范围键值结果(这其实是偏 OLAP 的应用,而非 OLTP)。

Twitter 和 Digg 这两家网站的数据结构其实并不复杂,尤其是 Twitter ,相当的简约(当然并不简单)。或许有人说,把 Cassandra 开源的 Facebook 不也在用呢吗 ? Facebook 数据结构不复杂么?没错,Facebook 数据结构很复杂,不过使用 Cassandra 的场景其实和 Twitter / Digg 几乎一致的---只是用在 inbox 这个地方的数据处理而已。

不要迷恋 Cassandra ,如果应用场景不合适,那么对你来说永远都只是个传说。。

--EOF--

来自淘宝的架构经验

日前参加了一场淘宝网架构师黄裳带来的技术分享,在最后他总计了淘宝这几年来的架构经验,这里和大家分享一下:

  • 1、适当放弃一致性
  • 2、备份和隔离解决稳定性问题
  • 3、分割和异步解决性能问题(类似 eBay 的 Asynchrony Everywhere)
  • 4、自动化降低人力成本(类似 eBay 的 Automate Everything)
  • 5、产品化管理

在这里不妨对比一下 eBay 的架构经验:

  • 1、 Partition Everything
  • 2、 Asynchrony Everywhere
  • 3、 Automate Everything
  • 4、 Remember Everything Fails
  • 5、 Embrace Inconsistency
  • 6、 Expect (R)evolution
  • 7、 Dependencies Matter
  • 8、 Be Authoritative
  • 9、 Never Enough Data
  • 10、Custom Infrastructure

关于一致性,可以延伸阅读 Amazon CTO 的大作 Eventually Consistent。此外,强调了"放弃集中的紧耦合处理"的原则。"备份"这里可以理解为"提供可用的副本"。"分割"是说水平拆分。

架构这东西说起来大致原则,其实都是类似的,但是具体如何在一些通用原则上做到运用自如,是很难的事情。前几天我还感慨,很多架构师对与"异步"与"批量处理"所能带来的益处的理解仍然相去甚远。

--EOF--

SmugMug 的架构介绍

本文介绍的 SmugMug 是一家提供付费图片托管服务的站点,在 2002 年由 Chris MacAskill 与 Don MacAskill 父子二人创建,最初提供面向游戏的视频服务,随后转型为现在的模式。网站流量现在是全球 1800 多,盈利能力自称良好。

在 MySQL Conf 2009 上,SmugMug 的 Don MacAskill 做了一次关于SmugMug 网站架构的分享。

SmugMug 整个网站采用 LAMP 架构(其实也有 OpenSolaris),300 多台 4 核(或更多)的服务器(大多是 AMD 的 CPU) ,分散在四个机房,两个运营的人员。SmugMug 充分运用了云计算服务,是 Amazon 的一个大客户,图片和视频总计达到了 PB 级,托管在 Amazon S3 上,图片和视频的处理也在 Amazon EC2 上。使用了 Akamai 的服务做前端的 CDN 加速,主要是 JavaScript/CSS 等文件的加速,此外,DNS 加速也带来了很好的收益。

结构化数据放在 MySQL 中,存储引擎多数用的 InnoDB,数据超过 2TB 的空间,数据库服务器为 4 核或更高配置,内存多达 64GB。缓存方面,用了 Memcached 做加速,有 1TB 的数据在这里面,平均命中率达到 96%。Memcached 里面尽量存放 MySQL 行数据,减小对 DB 的冲击。数据库设计思路是尽量做垂直分区,没有 Sharding。不过在反范式(denormalized)方面做得比较彻底,不用表连接(JOIN)方法者复杂的查询。多数查询依赖主键,更新或者删除数据也是单行,依赖主键。InnoDB 引擎打了 Percona 的 Patch,并发能力也有了很大增强。

DB 的数据完整性与写能力的要求高,而对于读的扩展性还是相对比较好解决。Linux 上的文件系统是 SmugMug 不太满意的地方,备份也成问题。ZFS 倒是能满足相关的需求,可惜不支持 Linux(妈的,早该支持 Linux了)。所以他们迁移到了 OpenSolaris 上。另外,对于复制中可能出现的风险,尝试了第三方提供的一些 Patch (参考 Google 发布的 MySQL Patch)。

采用 OpenSolaris 后,MySQL 放在 Sun Sushi Toro(Storage 7410,这个东西也支持 SSD ) 上,走 NFSv3 协议。写到这里,发现 SmugMug 的解决方案非常不具有通用行,看起来 Sun 是给了他们不小的硬件优惠,否则一般情况下不会有人这么搞的,用 NFS 协议走数据库,除非是测试环境或者是复制(我怀疑只是 Slave 端通过 NFS 走),产品上真的有人跑么?

网站架构的进化,其实也是选定一个方向(比如用开源工具解决),然后一直试错的过程。

--EOF--

Image representing Flickr as depicted in Crunc...

Image via CrunchBase

学习了一下 Flickr 的运维工程师 John Allspaw 的这个Operational Efficiency Hacks 讲座内容。做一点笔记。

现在 Flickr 的数据相比2007年的时候真是有了显著的增长:

  • 24 TB 的 MySQL 数据
  • 每秒钟 MySQL 有 3.2 万次写操作
  • 每秒钟 MySQL 有 12万次读操作
  • 图片容量 6 PB
  • 每天要用掉 10TB 存储
  • 超过 15000 个服务监控点

在 2004 年的时候 ,Flickr 使用 ImageMagick (version 6.1.9)之后转移到 GraphicsMagick,我还以为是因为版权问题,现在知道这样做是因为速度,换用 GraphicsMagick 处理速度提升了 15%,而 ImageMagick 功能尽管强大,但都是 Flickr 用不到的功能。如无必要,勿增实体啊。GraphicsMagick 在并行方面(OpenMP)的支持也很不错(参考)。

除了技术手段的优化,Flickr 充分利用硬件本身的更新换代带来的好处,曾经用 18 台新机器替换掉原来的 67 台 Web 服务器,用 8 台新机器替换掉原来的 23 台图片处理的机器。无论从机架占用还是电力使用都节省了很多,而整理处理能力并没有削弱。我们总说摩尔定律,但是恐怕很少有人真的享受到摩尔定律带来的好处。Flickr 的做法是很值得学习的一个地方。精兵简政,不要只冲着人下手,动手"裁"掉机器,也会省钱嘛...

Flickr 技术团队随着网站的快速发展并没有增加大量人手,个人生产力的产出是相当的高。如何做到的呢?给出了四个非常有趣的原则:

  • 使得机器自动构建 (Teach machines to build themselves)
  • 使得机器自监控(Teach machines to watch themselves)
  • 使得机器自修复(Teach machines to fix themselves)
  • 通过流程减少 MTTR (Reduce MTTR by streamlining)

自动购建上,Flickr 使用了 OpsCodePuppet 以及 System Imager/Configurator 等。或许这几个工具值得我们关注一下。

Flickr 团队内部沟通工具也挺有意思,除了内部的 IRC 用于讨论之外,还利用 Yahoo! Messenger 的 IM Bot 记录更多的系统变化,并且,重要的是,将这些信息弄到搜索引擎里面 ... "信息查找",是国内多数团队交流工具忽视的地方。

最后感慨一下 Flickr 技术团队仍然是非常有活力的团队。最近的另一个消息是国内的 Yupoo.com 原创业团队也即将重装上阵,重新接管 Yupoo 网站,要知道 Flickr 仍然是最有影响力的网站之一,所以,有理由期待 Yupoo 团队的精彩。

--EOF--

1 2 3 4 5 6 7 8 9 10 11 12

关于归档

本页包含 Arch 类别下的所有文章.

Database 为下一类别.

回到 首页 查看最近发表的文章或者查看所有 归档文章.