Arch 类别下的文章

Microsoft.com 后面的小道消息

微软员工 Jeff Alexander 在 Blog 上写了一篇 Microsoft.com: What's the story? 报料了 Microsoft.com 站点的一些技术架构信息。不料,这篇文章以迅雷不及掩耳盗铃之势被删除了。还好,Google 以迅雷不及掩耳盗铃之势做了快照。

这篇文章有的地方已经做了介绍,题为微软官网Microsoft.com的一些安全防护数据。但还是漏掉了一些信息。

1) 微软的运营团队 Blog。毕竟是官方的运行团队,在 Blog 上介绍了不少经验,非常值得借鉴。

2) HBI 是啥? 才疏学浅,搜索了一下才知道是:High Business Impact 的缩写。很奇怪,很多人看了那片文章而没有对此有疑问,或许大家都已经知道了。我火星。

3)对待杀毒工具( AV,此 AV 非彼 AV,不知道上面翻译的人为啥没提)的态度。众所周知,对于 Windows 服务器的维护来说,病毒问题会让很多人很头疼。微软运营团队的是态度是:只要有可能,还是会进行杀毒的。

另外,我比较好奇的是微软用什么做 Log 解析。Linux + Perl 这一套东西估计他们是不会用的。

最后,我把英文的快照扔到本站临时目录上了,尽可去一窥全豹[请"另存为",然后 IE 观看]。

--EOF--

TechCrunch 前两天报道说 Flickr 针对 Pro 用户新增了一项统计功能。今天有看到 Flickr 的 DBA Dathan Pattishall 描述了一下这个统计功能的实现。

Flickr 统计功能的基本技术信息:

  • 所有的信息统计是实时的
  • 同时用到 MYISAM 与 INNODB 两种引擎
  • 数据因为存储需求跨在 6 个 Cluster 上(12 台服务器,6 台提供服务,6 台做失败接管)
  • 没有用 Memcache

Dathan 提到这是他最耗时的一个项目(似乎有点怨言呀)。因为是实时统计,并且还要不影响整体页面响应速度,所以整个项目非常复杂。一旦 DB 设计搞定后,大部分时间都花在如何创建分布锁上了。

其实就我个人而言,真的不觉得这个功能有什么必要(尤其还是实时统计)。这或许是过度设计的一个例子。Flickr 在被 Yahoo!收购之后,这段时间倒是有点颓势。

说起 Dathan 这老兄,在 MySQL 技术圈子算是大名鼎鼎了。曾先后在 FriendfinderFriendster 做 DBA,并获得国 05、06 两年的 "MySQL Application of the Year Award“。(看他 Blog 的活跃劲儿,估计今年也差不多。)

这老兄加盟了 Flickr 后,一个礼拜解决了 40% 左右的性能问题。从他的简历来看,Flickr 目前每日 DB 的事务超过 10亿,MySQL 运行在 16G 内存、AMD CPU 服务器上,存储采用本地硬盘而没有用 SAN。数据库采用联邦架构,能做到线性扩展,为公司节省成本达 40 万美元(占40%,从而估计 DB 相关硬件成本为 60万美元).

推荐国内每个 Web 2.0 公司的 DBA 持续关注 Dathan 的 Blog,当然,可能大家都已经一直在看了。

--EOF--

PlentyOfFish 网站架构学习

采取 Windows 技术路线的 Web 2.0 站点并不多,除了 MySpace ,另外就是这个 PlentyOfFish。这个站点提供 "Online Dating” 服务。一个令人津津乐道的、惊人的数据是这个只有一个人(创建人Markus Frind)的站点价值 10 亿,估计要让很多人眼热,更何况 Markus Frind 每天只用两个小时打理网站--可操作性很强嘛。

之所以选择 Windows .NET 的技术路线是因为 Markus Frind 不懂 LAMP 那一套东西,会啥用啥。就这样,也能支撑 超过 3000 万的日点击率(从这个数字也能看出来人类对自然天性的渴望是多迫切)。Todd Hoff 收集了很多关于 PlentyOfFish 架构的细节。记录一下感兴趣的部分。

带宽与CPU

PlentyOfFish 比较特殊的一个地方是 几乎不需要 Cache,因为数据变化过快,很快就过期。我不知道这是因为 ASP.NET 的特点带来的架构特点,还是业务就是这个样子的。至于图片,则是通过 CDN 支撑的。对于动态出站(outbound)的数据进行压缩,这耗费了 30% 的 CPU 能力,但节省了带宽资源。我最近才知道,欧美的带宽开销也不便宜。

负载均衡

微软 Windows 网络负载均衡(Network Load Balancing) 的一个缺陷是不能保持 Session 状态(我没有用过这玩意儿,不能确认),价格也不便宜,而且复杂;网络负载均衡对 Windows 架构的站点又是必须--IIS 的总连接数是有限制的。PlentyOfFish 用的是 ServerIron (Conf Refer),ServerIron 使用简单,而且功能比 NLB 更丰富。

数据库

一共三台 SQL Server,一台作为主库,另外两台只读数据库支撑查询。数据库性能监控用的是“Windows 任务管理器"。因为 Cache没啥用,所以要花大力气优化 DB。每个页面上调用 DB 次数越少越好,越简单越好,这是常识,不过不是每个人都体会那么深而已。

微软好不容易找到了一个宣传案例,所以在 Channel 9 上有一个 PlentyOfFish 的访谈

PlentyOfFish 取自天涯何处无芳草(Plenty of fish in the sea)的意思,还挺有文化的。从这一点上看,比国内那些拉皮条的网站好一些。

--EOF--

性能扩展问题要趁早

与国内的 Web 2.0 Startup 技术人员相比,国外技术人员更乐于分享。分享也是一种更好的宣传手段,如果不是看到了这篇 Scaling an early stage startup, 或许我就不会知道这位 Mark Maunder (他还有个中文名字:马孟德) 以及他的 FeedJet

一般来说,一个刚刚发布的 Web 应用,因为用户量并不多,性能问题可能并不是很明显。可一旦宣传展开,用户增长或许不是线性的而是暴增(从几十个到几万个,相比之下怎不是暴增?),这时候如果遇到性能问题,毫无疑问会影响初期用户的信任。

Maunder 文档中列举了一个扩展过程,相信这些例子也是他实际遇到的。毕竟 Startup 都是一两个人打通关,不可能所有技术都面面俱到的精通。下面记录一点。

错误的设置

数据库服务器的参数配置问题:导致 MySQL 消耗了大量资源。Apache Keepalive 的设置为不合理,修改为 off。我想这个前提应该还是要选择自己最擅长的技术路线。如果错误的选择另一条不熟悉的技术路线,那么遇到技术时解决问题的速度怕是更让用户恼火。对于 Apache 还应该知道 Httpd.Worker 比 Prefork 消耗更多内存 (httperf 来进行 Benchmark) ,内存也是蛮贵的。

尽可能的缓存动态内容

尽可能的利用数据库的 Cache,利用其他 Cache 工具,如 MemCacheD,来减轻对磁盘的 IO 压力。为了节省成本,很多站点都是用的低速大容量的磁盘,所以,充分利用 Cache 是一个网站成功的必然条件。这样的软件BerkeleyDB 的最高事务处理记录是 90000 事务/秒。

剥离图片与CSS 到单独的服务器

说白了,也是为了减轻磁盘的压力。现在很多 Web 2.0 站点都把图片放到 Amazon S3 上,省心了不少。当然,国内还没这样的服务。

阻止内容引用"窃贼"

现在连那些大站点都在阻止图片被第三方引用,小站点更要提防被大站引用,很容易耗光网站的容量。另外一个要注意的是网络爬虫的频率。

在线观看这篇 Scaling an early stage startup。顺便说一下,最近在 Scribd 上看到了不少有意思的文档。

--EOF--

LinkedIn 架构笔记

现在是 SNS 的春天,最近又有消息传言新闻集团准备收购 LinkedIn。有趣的是,LinkedIn 也是 Paypal 黑帮 成员创建的。在最近一个季度,有两个 Web 2.0 应用我用的比较频繁。一个是Twitter,另一个就是 LinkedIn

LinkedIn 的 CTO Jean-Luc Vaillant 在 QCon 大会上做了 ”Linked-In: Lessons learned and growth and scalability“ 的报告。不能错过,写一则 Blog 记录之。

LinkedIn 雇员有 180 个,在 Web 2.0 公司中算是比较多的,不过人家自从 2006 年就盈利了,这在 Web 2.0 站点中可算少的。用户超过 1600 万,现在每月新增 100 万,50% 会员来自海外(中国用户不少,也包括).

开篇明义,直接说这个议题不讲"监控、负载均衡”等话题,而是实实在在对这样特定类型站点遇到的技术问题做了分享。LinkedIn 的服务器多是 x86 上的 Solaris ,关键 DB 用的是 Oracle 10g。人与人之间的关系图生成的时候,关系数据库有些不合时宜,而把数据放到内存里进行计算就是必经之路。具体一点说,LinkedIn 的基本模式是这样的:前台应用服务器面向用户,中间是DB,而DB的后边还有计算服务器来计算用户间的关系图的。

问题出来了,如何保证数据在各个 RAM 块(也就是不同的计算服务器)中是同步的呢? 需要一个比较理想的数据总线(DataBus)机制。

第一个方式是用 Timestamp . 对记录设置一个字段,标记最新更新时间。这个解决方法还是不错的---除了有个难以容忍的缺陷。什么问题?就是 Timestamp 是 SQL调用发起的时间,而不是 Commit 的确切时间。步调就不一致喽。

systimestamp.png

第二个办法,用 Oracle 的 ORA_ROWSCN (还好是 Oracle 10g). 这个伪列包含 Commit 时候的 SCN(System Change Number),是自增的,DB 自己实现的,对性能没有影响。Ora_ROWSCN 默认是数据库块级别的粒度,当然也可做到行级别的粒度。唯一的缺点是不能索引(伪列). 解决办法倒也不复杂:增加一个 SCN 列,默认值"无限大"。然后用选择比某个 SCN 大的值就可以界定需要的数据扔到计算服务器的内存里。

ORA_ROWSCN 是 Oracle 10g 新增的一个特性,不得不承认,我过去忽略了这一点。我比较好奇的是,国内的 Wealink、联络家等站点是如何解决这个关系图的计算的呢?

--EOF--

一点题外话:我的 LinkedIn Profile (Mail : [email protected]). Keep in Touch!。 另外建议正在找工作的同学不妨使用一下这类站点(国内的有联络家若邻)。一般人我不告诉他~~

Yahoo!社区架构

旧金山举行的 QCon 会议带给我们很多新鲜的信息。虽然没机会参加,但是看看各个网站"晒架构"也是个比较过瘾的事情。请参观并收藏这个页面:Architectures you've always wondered about

eBay 的架构和去年相比基本是换汤不换药,倒是 Yahoo! 的 Ian Flint(这位老兄是 Bix 的运营总监. Bix 已被雅虎收购) 这个 PPT Yahoo! Communities Architecture: Unlikely Bedfellows 挺有意思,披露了一些鲜为人知的信息。

Yahoo! 社区包括我们比较熟悉的 del.icio.usFlickr、Yahoo!群组、Yahoo! Mail、Bix等。相当于 Yahoo!把这些属性相近的应用放到一起运营。这个思路倒是和盛大对游戏的运营有些相近。

架构特点

有两点值得注意:1)层次化 2)模块化。这也是大规模作业下的比较经济的途径。

软件架构

首先是操作系统已经从 FreeBSD 逐渐迁移到 RHEL。这怕是雅虎不得已作出来的决定吧。FreeBSD 的开发力量的确不如 Linux,这也是不争的事实。数据库上 MySQL 与 Oracle 都有。Yahoo! 在 DW/BI 用的是 Oracle,构建了一个超大数据库。诸如 yapache、yts(反向代理服务器)、yfor(提供快速失败接管)、 ymon(监控),还有还有ysquid、ypan(cpan的 Yahoo! 克隆) 这些组件都是通过 yinst 来统计部署。关于 Yapache,请参考我以前写的 Yapache-Yahoo! Apache 的秘密

这是 Bix 与 DB 有关的部署架构:
Yahoo_soft_arch.png

数据放在 Netapp NAS 上(所以有的时候应用之慢也可以理解了),通过快照复制到其他数据中心。

Yahoo! Mail 架构:

Yahoo_Mail_arch.png

这里面居然部署了 Oracle RAC,用来存储 Mail 服务相关的 Meta 数据。非常有趣。

运营维护

监控工具主要用的是 Nagios,用以监控集群。使用标准插件,另外也有自行定制的插件。Nagios 这东西太棒了。主动、被动检查的消息转发是通过 Ymon 来做到。网管上针对 SNMP 的解决方案是用 Yahoo!自己 Y 字头的 Ywatch。这些 Y 字头的东西基本上外面都是找不到的。Yahoo!的技术其实并不那么开放。Google 在运营这方面也好不到什么地方去。趋势图用 Drraw 展现。Drraw 是基于 RRDtool 的 Web 展现工具。

Yahoo_ops.png

应用服务器的监控是被动的。整个监控系统模块化部署。Nagios 的警告信息转发到 Ywatch 中心控制台。

Note: 上面所有截图版权都属于 Ian (Image COPYRIGHT@IAN) 。如果去看那个 PDF 文件,你或许比我收获更多。我只是让你知道我的想法而已。

--EOF--

财帮子(caibangzi.com) 定位在”基金理财社区"。是国内访问量最大的基于 Ruby on rails 的 startup 项目。“理财”这个词据说是光大银行发明的,且不去管,不可否认的是,目前国内"理财"是个很有潜力的切入点。财帮子网站潜在用户群还是很大的。

1.创建人员

创建者有三人。Robin Lu(石锅拌饭)Meng Yan ( 孟岩 ) ,还有一位"不写Blog的家伙"。前两位都是技术人员。很早就看过孟岩 的 Blog,那时候他还在 Sun。Robin Lu 的 Blog 也一直在我的订阅列表中的,所以财帮子刚成立我就知道的。倒没有细问第三位是技术人员还是负责商务。(Updated: Robin Lu留言说”财帮子那位不写blog的创建者也是工程师,叫赵路,曾经是 Mozilla 项目accessibility模块的module peer."

2.服务器信息

Web 服务器用的是 Lighttpd ,出于节省成本的目的,服务器是自行组装的。数据库采用的是 MySQL 5,目前还没有使用 Replication. 正准备扩充服务器,服务器数量...暂且保密一下。

3.统计分析及监控

统计分析采用 Google Analytics 和 Awstats 。目前 Alexa 排名是 2 万一点。监控工具用 monit,"以及自己写的一些分析 Proc 的脚本",再有就是 Unix 性能工具等。(Fenng: 服务器处于规模化之前基本上要这个样子)。

4.优化之路

Robbin 在此前的一篇 财帮子性能优化简报披露:“财帮子两个星期以前,遇到严重的性能问题,最终我们采用了相当非主流的部署方案和打了自己补丁的web server,成功度过了难关”,我很好奇这具体是个什么问题。得到的答案是:“Apache的负载均衡是有问题的,算法太简单了,对Ror的应用来说,会造成某一个app instance的阻塞,从而阻塞了所有的request”。

谈及 Cache 的感慨:

Fenng: ... 我个人感觉你们需要Cache服务器, 这一类的站点内容需要 Cache 的太多
Meng Yan: ...Web 2.0网站的 cache 非常重要。我们从Mem的cache,到disk的cache,
再到数据库的cache,架构还不错,否则当前机器撑不住 :)
Fenng: 很多站点扩展作不好,也是Cache没用好
Meng Yan: 是啊,Cache非常重要,非常非常
Fenng: 豆瓣的阿北说他们 Memcached 用的非常爽,命中率非常之高
Meng Yan: 确实,我们的内存cache就是用的memcached,真的很棒

5.挑战

这是就这次采访的最后一个问题。
Fenng:还要采访你一个问题:caibangzi.com 现在运营、开发面临的最大的一个问题是什么? 
Meng Yan:目前可能我们遇到最多的是合作、商务上的事情。真正开发、运营上来说对我们的挑战还不大。

6.后记

这次采访(如果可以说这是采访的话)非常顺利。财帮子从三月底上线,到现在已经积累了一定数量的用户,当然不是十全十美的(我个人就感觉应该提供更多的RSS输出才是,不要太在乎站点流量,流量本身也是开销),网站也还有很长的路要走。真诚希望财帮子能成为更多人的理财工具(至少我已经开始用了)。

这是我第一次写国内 Web 2.0 网站架构技术。感谢 Meng Yan 提供的第一手信息。关于网站架构,我在这个 Blog 上写过不少国外的站点分析。一直想采访一些国内的 Web 2.0 站点并且能披露点技术信息,相对来说,国内站点还是比较保守,各自闷头折腾。为什么不换个角度,分享、借鉴、壮大,这个方式不也不错麽?

BTW: 如果你有 Web 2.0 站点技术信息要报料,联系我!(要写软文就免了)。

--EOF--

eBay 的数据层扩展经验

对于 eBay ,我盲人摸象一样写了好几篇 Blog ,暂列一下:

今天又重新读了一下这篇《The eBay Architecture --Striking a balance between site stablility, feature velocity, performance, and cost》,觉得数据层的扩展经验也很有意思。

通过功能划分不同数据库,然后根据主要访问路径水平分割数据库。这句话太空了,类似 MySQL DB 大家常采用的 Shard 思路。

减小 DB 资源开销

数据库上没有业务逻辑。这包括:不用存储过程; 只有少量比较简单的触发器。 把CPU 开销比较高的工作迁移到应用上。这包扩:参考完整性检查(嗯,检查一下你的 DB 是否再用外键? ); 连接(Join), 排序。
应用服务器尽量 Prepared 语句以及绑定变量的广泛使用。

最小化 DB 事务

自动提交(Commit)大多数主要的数据库写操作。 客户端绝对没有事务(业务逻辑) 。这包括: 单个数据库通过匿名 PL/SQL 块进行事务管理; 没有分布式事务。对于"事务", 相关信息可以从 eBay 首席架构师 Dan Pritchett 的访谈得到确认。没有事务更没有分布式事务这一点比较关键,这也是因为 eBay 的商业逻辑天然性质(否则也不容易做),所以可以做到 Scale Out,而最近了解到 Paypal 则因为交易逻辑比较复杂,只能是 Scale Up. Paypal 的技术信息一向比较封闭,谁能告诉我一点额外的信息呢?

--EOF--

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

关于归档

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

Database 为下一类别.

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