Tag Archives: 架构

面向生产环境的SOA系统设计 by 支付宝程立

在刚刚举行的系统架构师大会上,支付宝首席架构师程立分享了《面向生产环境的SOA系统设计》这个技术话题。现在把 PPT 第一时间和大家分享一下。

程立在 SOA 功底深厚。上次在 InfoQ QCon 会议上程立的话题也是有关 SOA。本次演讲内容侧重与上次侧重点不同。只是因为会议时间有限,所以有几页没有完全展开来讲,稍稍有点遗憾。

感谢程立。大家针对该 PPT 有任何问题的话,请留言或者发邮件给我,我将第一时间转给他。

关于 PPT 作者

程立是支付宝公司的首席架构师。他从2004年起参与支付宝与淘宝网的建设,2005年正式成为支付宝人,随着支付宝的业务与技术的成长,从开发工程师、架构师到首席架构师一路走来,全身心投入并见证了支付宝业务与系统发展的完整过程。


支付宝一直在招聘软件架构师,我们是 Java 开发环境。如果您对支付宝感兴趣,并且想让自己做的东西服务于两亿多的用户,不妨联系我们或者直接发简历到: dbanotes@gmail.com 。

EOF

Facebook 架构学习

在 QCon 2008 (旧金山站) 上Facebook 做的这个技术分享有不少值得借鉴的东西。所以,暂停对 QCon 北京的回顾,临时插播一贴。

设计原则

  • 尽可能的使用开源软件,并且在需要优化的时候进行优化
  • Unix 哲学。包括,模块化原则;整合化原则;清晰化原则等
  • 任何组件具备扩展性
  • 最小化故障影响
  • 简化,简化,简化!

架构概览

Facebook 是 LAMP 的坚定支持者,也差不多是用 LAMP (或许用 LAM2P 更适合) 实现的最大的动态站点。

Facebook Arch Overview.png

基础组件加上服务,中间用自己实现的一些工具进行粘合。其中关于运维细节的事情基本不会说出来的,这是很多公司的软实力所在。

PHP 经验

参见《Facebook 的 PHP 性能与扩展性》

MySQL 经验

  • 主要用于做 Key-Value 类型的存储操作,数据随机分布在多台逻辑实例上,访问多数基于全局 ID 。
  • 逻辑实例分散在多台物理主机上(超过1800台),负载均衡在物理层进行。
  • 不做读复制。
  • 尽量不做逻辑数据迁移(成本太高)。
  • 不做 JOIN 操作 (豆瓣在 QCon 上也阐述了这一点)。数据是随机分布的,关联操作反而带来了极大的复杂度。
  • 对于数据访问,主要的操作集中在最新的数据上,针对这部分做优化,旧的数据进行归档。
  • 在中心 DB 绝不存储非静态数据。
  • 使用服务或者 Memcached 进行全局查询。

Memcached 经验

参见我以前的笔记:Facebook 的 Memcached 扩展经验。Facebook 对 Memcached 做了不小的改进。另外,顺便说一下,前两天 Memcached 刚在 1.2.7 发布几天之后又发布了新版本 1.2.8,修正了一些问题。

一个比较有价值的是关于个人页面数据的获取的描述。这个就完全是需要做单页面 Benchmark 的细致活儿了,可能还需要产品经理能够理解工程师的”抵抗”。

  • 获取个人信息数据:通过Cache,隐性通过用户所在的 DB 获取(基于 User-ID 获知 DB)
  • 获取朋友连接信息:通过Cache,否则的话通过DB(基于 User-ID 获知 DB)
  • 并行抓取每个朋友的 10个照片相册 ID ,从Cache抓取,如果失效,再从 DB 抓取(基于相册 ID)
  • 并行抓取最近相册中的照片数据
  • 运行PHP 把整个业务逻辑跑出来
  • 返回数据给用户

然后是对 Facebook 非 LAMP 体系的东西做了一番介绍,基本上也开源了。最后参考两个架构图。

Facebook NewsFeed 的架构示意图
Facebook_NewsFeed_Arch.png
Facebook 搜索功能的架构示意图
Facebook_Search_Arch.png

管中窥豹,盲人摸象而已。

EOF

学习豆瓣好榜样–网站架构

这次的 QCon 会议,《豆瓣网技术架构的发展历程》这个议题差不多是最受关注的。洪强宁在演讲开始告诫大家期望值不要太高,我还是相信不会有人觉得失望的。

豆瓣网首席架构师洪强宁在演讲

先说几句题外话,整个演讲听下来,我们会发现豆瓣在发展的过程中也是有点弯路,这些是一个网站发展过程中的宝贵财富,能把自己有周折的地方大大方方的拿出来,是难能可贵的事情。尽管豆瓣批露了很多架构细节出来,也不会(也不可能)有哪个公司一拿到这些东西,就能照猫画虎再做一个豆瓣并且超过豆瓣。从某种程度上来说这体现了豆瓣同学们的气度,这是令国内大多数公司汗颜的。很多公司只愿索取,而不愿奉献哪怕一点点出来,用这样封闭的心态对待技术其实是小家子气,守财奴的思维。技术只有为更多人所用才是大道。

议论说完,再来叙述。写点对豆瓣架构的体会。戏法人人会变,各有巧妙不同。有些东西大家都在用(Nginx),但是有人的用得好,有人用了比不用还差。所以,需要逐渐总结,改进。学习别人的架构设计,不是要照搬,而是借鉴其思想。

技术的选择

一直以来,豆瓣在技术上都给人很前卫的感觉,看起来好像什么新用什么,其实是不是的,他们一直是”用已掌握的技术解决问题”,现有的东西如果够用,那么就没必要一定迁移到新的上面去,而转换往往是为了解决当前问题。另外,换用新的东西,要有足够的驾驭能力,从演讲中得知,豆瓣曾有几次在临上线前发现基础库的Bug(比如 Libmemcached 的一致性哈希相关的Bug),技术团队能在第一时间有进行修复并且提交给开源社区。否则的话,就变成了一种错误决策了。

磁盘转速

小话题。如果可能,直接买 15000 转的磁盘好了。10000 转的磁盘可能省钱,但这东西部署了之后几乎就不太可能升级。所以,如果是初创公司,我的建议就是买高速磁盘,因为业务如果发展快了的话,先前对机器的定位也可能发生变化。

杜绝远程 I/O

在普通的 TCP/IP 网络的环境下,不要进行远程数据写入操作。跨网络操作的延时看似没什么大不了的,但一旦达到临界点就回天乏术。这个事情基本是不撞南墙不回头,有的技术人员总要亲身体验一把才肯罢休。

持续保持 URL 友好风格

演讲中有多次提到一致性 URL ,其实体现了豆瓣对 URL Rewrite 的重视,结构调整,或者应用程序变化的时候,URL 最好做到”用户友好”的。这算是”软技术”,但是应该加以最大的重视。

数据库复制延迟问题

对于 MySQL 复制的环境,如果Slave 上有读取操作,那么有些情况下可能因为 Master 和 Slave 节点数据不一致对用户造成困惑。如果从一致性的角度上考虑,其实也不复杂:,只需要对”知道数据发生了变化的用户”提供一致性就行了(基本上就是发起变更的用户),不知道数据发生变化的用户对数据的不一致有一定的”容忍程度”,当然说着简单,实现起来还是需要技巧和精巧的。

大量小文件同步问题:Merkle tree

关于大量小文件的同步问题,很多上了规模的网站都会遇到,如果设计得不好或者是比较偷懒,用传统的办法(比如 rsync 之类的老模式)很容易触发问题,也浪费资源。DoubanFS 是用 Merkle tree(Hash Tree)的方式进行数据同步的。对这个问题的具体描述可以参见《大量小文件的实时同步方案》。Merkle Tree 是个很精巧的思路,ZFS 在用(refer),Amazon Dynamo 系统也在用。

不会一会儿又有人留言说:我们早就采用这个思路了…… 我这里预先来句回答:拜托,你早点共享啊?

EOF

完整的 PPT 过几天 InfoQ 中文站会发布,我这里就不掠美了。

因为信任,所以简单 –专访支付宝架构师团队 (2)

这是前一段时间《程序员》杂志采访支付宝架构师团队的的稿件。篇幅较长,此为第二部分。。
本周支付宝架构师团队一部分成员将参加 CSDN 上海英雄会,欢迎做些技术或者业务方面的交流,
尤其是支付宝的一些合作伙伴公司和潜在合作伙伴公司。

书接前文

支付宝每时每刻都要应对海量的数据和交易,是否使用了类似于”云计算”的方式进行后台处理?对于业界现在热炒的”云计算”概念,你们团队有什么想法?

的确,支付宝的数据堪称海量,但相比之下,主要的压力还是来自对交易事务的处理上。我们也有一些密集型的后台计算,但相对规模不算特别大,当前的计算能力足以支撑,当然,我们也尽量会想办法用更小的成本提供更强的计算能力。

对于云计算,我们目前还没找到很合适的应用场景,但整个架构组目前对云计算保持密切的关注,并会投入适当的力量进行一些前瞻性研究。我们实际上更为关注一些解决方案,比如 Hadoop ,并准备在 DW/BI 方面进行一些尝试。

冯大辉曾经在一个访谈中提到:技术架构与产品设计这两者的优劣,会对 Web 应用的发展起到至关重要的作用,那么这二者应该如何平衡?在支付宝进行架构设计和产品设计时,是怎么样进行权衡的?

通常情况下我们的技术架构是可支撑产品设计的多样性需求的,但仍有部分产品设计因市场的差异化需求非常特殊,造成我们的技术架构要支撑这部分产品产生了一定的挑战,这也是因为我们的所处的行业是一个迅速发展的行业有关,一方面我们加强技术架构的灵活性和前瞻性研究,另一方面我们也同时加强对产品设计的规范指导,使其两者达到平衡。

我们在技术架构的发展上做了很多课题性研究,如遇到新产品的设计技术架构无法支撑的情况下我们对产品所带来的收益与需扩展技术架构的投入成本上做出分析权衡.

高性能设计中缓存技术是最常用到的,您们在架构设计中通常怎样考虑缓存问题?

现代大型系统中,Cache 是个非产关键的组件,在具体实践中,我们会依据支付宝自身的数据特点对数据部署缓存策略,支付宝对数据实时性的要求造成Cache的准确性要求极高,而数据的私有性造成提高Cache命中率难度较大。客观地说,目前对于 Cache 的利用应该说还不是很充分,这有待于我们进行更深入的研究。

简单的说几点经验,一个是要合理的选择 Cache 所在的位置. 简单的说,Cache 的位置有几个地方:

Web服务器层 -> 应用服务器层 -> 数据库层

具体使用哪个 Cache 以及在哪个位置来做 Cache,要依据缓存什么、性能要求、数据量、可伸缩性、事务要求、过期特性、一致性要求、可复制性、硬件投资、开发投资多个维度来考虑。如果 Cache 的位置选择不合适,那么系统伸缩性会受到严重影响,每次 Cache 系统实施之前,需要架构师进行充分的论证和评估。

第二点,在Cache 存储的资源粒度,需依据 Cache 资源的特点,比如登录者基本信息,就完全可以一次性缓存起来,对于聚合关系结构的业务对象,在缓存的时候需要考虑业务特点,如果业务上对聚合对象内部的对象访问就很频繁,那么就考虑选择小对象力度缓存,否则考虑大粒度对象。第二点是Cache自身的特点,本地JVM Cache,可以考虑存储大对象,因为此时没有网络访问、数据流量的考虑,那么即使业务上小对象访问比较多,也可以考虑完全缓存整个对象关系;如果是远程 cache,那么就要依据大粒度和小粒度对象访问的频率,然后决定。

Cache 是个非常庞大的话题,如有必要,可以选择另外的时间进行探讨。

分布式是架构设计中最有挑战的任务,您们在分布式设计中主要从什么角度出发?怎样选择按用户拆分和功能拆分?

考虑到支付宝的业务特点, 无论我们做什么应用,安全性、可靠性肯定是排在第一位的。然后我们会重点考虑性能和可扩展性。支付宝现在已经是最大的第三方支付工具,日益增长的交易量给架构师们带来了很大的挑战。我们在具体实践中也从BASE 策略中得到很大参考:

Basically Availble --基本可用
Soft-state --软状态(柔性状态)
Eventual Consistency --最终一致性

目前的拆分原则主要是遵循 SOA 的思路,面向服务进行拆分,这也是基本原则之一。 至于是否按照用户拆分,只要不违背 SOA 即可。

对于开放平台、开放 API、以及SaaS这些互联网的新风潮,支付宝架构团队有什么看法?

开放平台这个词最近确实非常火,好像一夜之间大家都开放了。开放确实是一种趋势,任何一个互联网公司都只是整个互联网生态圈中的一环,只有开放才能让自己更好的融入到整个生态圈中。这是大方向,大方向确定了,剩下的事情就是如何开放,开放什么的问题了,这也是每个互联网公司需要仔细考虑的问题。

我觉得随着公司业务的不断发展,开放是一个必然的结果,我们在支付宝创建初期就意识到整个支付市场是非常大的,在服务好淘宝的基础上应该大胆的走出去,去为更多的电子商务平台提供支付服务。所以,我们很早就推出了支付宝商户平台,在这个平台上我们提供了大量的交易、支付服务。通过这几年的运营,我们确实尝到了开放的好处(外部商户为我们的交易量做出了很大贡献),同时我们也积累了很多开放的经验。目前我们正在开发一套新的开放平台,我们希望通过这个平台,可以为我们的合作伙伴提供更多、更好的服务,同时也希望有更多的第三方公司能在我们提供的基础服务之上,创造出新的商业模式。

如果说”面向服务架构”使企业IT系统支持业务敏捷化的话,开放平台则是使互联网大系统支持整个行业生态圈的业务敏捷化。开放平台、是企业追求开放式成长的必然道路,也是SOA原则走出企业系统的狭小圈子、在广袤互联网上的自然延伸。以支付宝的实践来看,在2005年中,支付宝就针对互联网交易提供了API,为互联网上的电子商务提供安全交易与资金流解决方案。随着业务领域不断拓展,原来的从需求->解决方案->产品->API的方式,周期太长,已经难以快速满足大量合作伙伴的需求。因此,支付宝现在正在由产品式的开放转向平台式的开放,通过加强开放基础设施的建设,向合作伙伴提供更基础、更可重用、更体系化的服务,达到与合作伙伴充分协同,建设繁荣、共赢的电子商务生态圈的目标。

同时,开放的业务服务与开放的技术平台也正在推动支付宝的业务与技术架构向前发展,对构建更大规模的分布式系统、更大规模的并行研发模式都带来了积极而深远的影响。

对于有志于成为架构师的开发者,支付宝架构团队有何建议?

技术不是一蹴而就的事情,而是长时间积累的成果。此外,扎实的基本功是做好所有事情的开始!抽象的能力也是作为一名好的程序员必须具备的,我们在考虑问题的时候可能会遇到错综复杂的场景,从这些迷雾中找到一条明路是我们做好程序员的关键。实际抽象能力衍生出来的一点就是需要我们对已学过的知识定期的进行梳理,这样能让你稳固已有的知识,为以后学习的更多的知识做好准备。

实践也是非常重要的一个环节,不要有畏难心里,觉得这个东西非常的难,我无法完成!有时候你去完成一件事情,事情的结果可能会是糟糕的,但是解决这件事情的过程是非常宝贵的,你可以在这个过程中学习到很多东西!最后我还要说一点的是,业务知识非常重要,这个是你实践的关键!(by 胡喜)

架构师在设计系统架构,或者对重大问题进行决策时,必须在全面考虑各种因素、充分前瞻的基础上做出全局最优的选择。这种整体性与发展性的思考模式是一种能力,也是一种习惯,一种态度。作为有志于成为架构师的开发者,应该在日常开发中就养成站在整体、发展的角度去理解、分析、与解决问题的习惯。(by 程立)

再补充三点:

  • 1、从程序员到架构师:是思维提升的一个过程、责任心升华的一个过程、是一楼向楼顶攀爬的一个过程,每一层楼,都要向下、向上、向远处看(注:这个楼顶有多高?没人知道 :) ;
  • 2、读别人的代码、框架,看身边同事做事情,与同事一起讨论问题等,要始终尝试:交换思想的苹果,达到 1 + 1 > 2 ;
  • 3、找一个架构师老师,榨取他身上的每一点优点(别把坏的也给学去了) ;

(by 姚建东)

架构师在成长过程是个顿悟的过程,需要自己注意及时总结,尤其是不可能不犯错误,但是需要自己通过每次所犯的错误进行深刻的总结提升自己。提升的过程是个螺旋式上升的过程,自己以前也做失败过一个案例,至今记忆深刻,通过这次深刻的教训,对自己的成长是很有帮助的。遇到错误不要怕,要坦然面对,能做到:犯错误–>提升–>避免错误就可以了。(by 王学安)

1,架构师往往是领域专家,持续关注领域发展和创新、领域知识,了解领域需求,并将领域需求不断的融入到架构模型里,侧重领域功能布局。
2,架构师往往是技术专家,持续的关注技术知识,架构模式,设计模式以及技术规范等,技术架构关注点可以是,开发高效、复用、安全、可维护可管理、灵活等。
3,实践出真知,持续关注领域、技术,勇于实践。( by 刘明源)

附录:可能有的朋友已经知道支付宝的花名文化,这次接受采访的同事花名可以列一下:鲁肃、苗人凤、西毒、阿玺、邓芝、庞统、夫差、李磊、俊义。(猎头们就别盯着这里看了,做点有技术含量的事儿吧)

EOF