Tips: 10 月 9 日我将去南京，参加支付宝 2008 校园招聘 南京大学站。

Cocolog 是日本领先的 Blog 社区，基于 SixApart 的 TypePad 技术框架。运营公司是 NIFTY（最新的调查报告显示，NIFTY 在日本流量排名第 10 ） 。前一段时间看到这篇 Migrating from PostgreSQL to MySQL at Cocolog, Japan's Largest Blog Community ，比较详细的描述了从 PostgreSQL 迁移到 MySQL 的经验，很有参考价值(日本互联网技术特点?)，在这里做一篇学习笔记。

核心系统的支撑软件

• Linux 2.4/2.6
• Apache 1.3/2.0/2.2 & mod_perl
• Perl 5.8+CPAN
• PostgreSQL 8.1
• MySQL 5.0
• Memcached/TheSchwartz/cfengine

都是一些司空见惯的东西, cfengine 是用作软件维护、部署、分发的玩意儿。

初期技术架构示意图

这是我第一次知道 TypePad 除了 SixApart 自己的服务之外还支撑了第三方的站点(孤陋寡闻!)。

初期 PostgreSQL 基本上是用来存储本地注册用户信息。这个阶段数据库分区之前，服务器数量在 10 个以下。

第二阶段

这阶段数据库分区之前，服务器数量在 50 个以下，可以看到 DB 还额外存储了富内容模板等元数据信息。系统各个模块紧耦合，数据库 Schema 变更有些费劲了。

第三阶段

Web API 的引入在一定程度上消除了紧耦合的问题，Memcached 的引入很大程度减轻了 DB 的负担。服务器数量在 200 个以下，未分区之前。

第四阶段

数据库分区之前，服务器数量在 300 个以下，增加对移动互联网的支持能力。这个时候 PostgreSQL 貌似还是单实例的样子。数据超过 100GB，40% 是索引。要忍受比较严重的数据碎片问题，备份是个麻烦事儿。

在此之前，PostgreSQL 服务器在硬件上一直是 Scale Up 的思路，内存从最初的 1GB 扩展到 07 年底迁移前的 16GB，磁盘换到了阵列上，阵列是富士通的 E8000 。国内倒是很少遇到有把 PostgreSQl 扔到企业存储上的案例。

现阶段

这是迁移后的架构示意图。引入了多个 MySQL 实例。从原来的 Scale Up 切换到 Scale Out 的路线上。数据库分区，服务器数量 150 个。

集群软件采用了 NEC 的 ClusterPro 。数据库是共享存储的，不过 I/O 瓶颈应该消除了，因为读的压力分散在每个 MySQL 服务器上，内存承担了大部分工作。写操作的压力在一台存储上，问题不会很大。

实施步骤

• 1. 服务器准备；
• 2. 全局写问题（Global Write）　应对策略：写用户信息到全局 DB 中；
• 3. 全局读问题 应对策略：读、写用户信息在全局 DB 中折腾；
• 4. 迁移序列 　应对策略：全局 DB 承担；
• 5. 用户数据迁移 （User Data Move）　应对策略：移动用户数据到用户分区中；
• 6. 新用户分区 （New User Partition）　应对策略：所有新用户直接保存到新用户分区1中；
• 7. 新用户数据处理策略 　　根据需求设定一个策略；
• 8. 非用户数据迁移。

这几个过程都不难理解，数据迁移的一节倒是值得描述一下：

对上图做个解释(其实也是翻译 PPT 上的注释):

• 1 Job 服务器提交一个新的Schwartz Job 迁移已有的用户数据，用户数据异步迁移；
• 2 迁移中的用户发布的留言保存到 Schwartz ，稍后发布；
• 3 迁移完毕后，所有用户数据存放在用户角色 DB 分区；
• 4 一旦所有用户数据迁移完毕，只有非用户相关数据存在 PostgreSQL 中。

这个迁移的技术细节其实可能不那么重要，但重要的是必须有个迁移流程的制定过程，任何所谓的迁移，如果没有制定详细的计划，无疑会吃苦头。

迁移后的备份示意图：

最后看一下架构概览图(点击可放大)：

Tip：这个架构图中关于 NAS 部分，可能不那么可靠的。

上面引用的图版权归原 PPT 作者所有。转载我这篇流水帐的网站请不要随便给图片打水印。

--EOF--

P.S. 如果你有耐心看完前面的部分，你或许应该提出如下疑问：

• 1）为什么要迁移到 MySQL ? PostgreSQL 也是支持分区的啊 ...
• 2) 这其实就是个数据 Sharding (分片)的问题, 作者为啥不直接说?
• 3) 第五阶段, 服务器数量为什么变少了?
• 4) 迁移全是在线进行的么? 有没有影响用户访问?

如果一个问题都没有, 其实和没看差不多。

又及：PPT 里面提到的监控指标也需要注意一下，你的网站监控了这些内容么?

response time of each post
number of spam comments/trackbacks
number of comments/trackbacks
source IP address of spam
number of entries
number of comments via mobile devices
page views via mobile devices
time of batch completion
amount of API usage
bandwidth usage

Posted by Fenng at 6:36 PM | Permalink | Comments (2)

此文首发在 InfoQ 中文站。作者：明灵(dragon) , Fenng . Note：要转载的朋友请注意注明这篇文章的第一作者!
这篇文章是dragon 朋友来邮探讨后他做的一个总结。在 DB 中排序还是在 应用程序中排序是个很有趣的话题，dragon 第一份邮件中其实已经总结的很好了，我添加了一点建议而已。现在放上来，与大家共享。这篇文章也投稿到了 InfoQ 中文站 。

Q：列出在 PHP 中执行排序要优于在 MYSQL 中排序的原因？给一些必须在MYSQL中排序的实例？

A：通常来说，执行效率需要考虑 CPU、内存和硬盘等的负载情况，假定 MYSQL 服务器和 PHP 的服务器都已经按照最适合的方式来配置，那么系统的可伸缩性（Scalability）和用户感知性能（User-perceived Performance）是我们追求的主要目标。在实际运行中，MYSQL 中数据往往以 HASH tables、BTREE 等方式存贮于内存，操作速度很快；同时 INDEX 已经进行了一些预排序；很多应用中，MYSQL 排序是首选。而在应用层（PHP）中排序，也必然在内存中进行，与 MYSQL 相比具有如下优势：

• 1、 考虑整个网站的可伸缩性和整体性能，在应用层（PHP）中排序明显会降低数据库的负载，从而提升整个网站的扩展能力。而数据库的排序，实际上成本是非常高的，消耗内存、CPU，如果并发的排序很多，DB 很容易到瓶颈。
• 2、 如果在应用层(PHP)和MYSQL之间还存在数据中间层，合理利用，PHP会有更好的收益。
• 3、 PHP在内存中的数据结构专门针对具体应用来设计，比数据库更为简洁、高效；
• 4、 PHP不用考虑数据灾难恢复问题，可以减少这部分的操作损耗；
• 5、 PHP不存在表的锁定问题；
• 6、 MYSQL中排序，请求和结果返回还需要通过网络连接来进行，而PHP中排序之后就可以直接返回了，减少了网络IO。

至于执行速度，差异应该不会很大，除非应用设计有问题，造成大量不必要的网络IO。另外，应用层要注意PHP 的 Cache 设置，如果超出会报告内部错误；此时要根据应用做好评估，或者调整Cache。具体选择，将取决于具体的应用。

列出一些 PHP 中执行排序更优的情况：

• 1、 数据源不在 MYSQL 中，存在硬盘、内存或者来自网络的请求等；
• 2、 数据存在 MYSQL 中，量不大，而且没有相应的索引，此时把数据取出来用PHP排序更快；
• 3、 数据源来自于多个 MYSQL 服务器，此时从多个 MYSQL 中取出数据，然后在PHP中排序更快；
• 4、 除了 MYSQL 之外，存在其他数据源，比如硬盘、内存或者来自网络的请求等，此时不适合把这些数据存入 MYSQL 后再排序；

列出一些必须在 MYSQL 中排序的实例：

• 1、 MYSQL 中已经存在这个排序的索引；
• 2、 MYSQL 中数据量较大，而结果集需要其中很小的一个子集；比如 1000000 行数据，取TOP 10；
• 3、 对于一次排序、多次调用的情况，比如统计聚合的情形，可以提供给不同的服务使用，那么在 MYSQL 中排序是首选的。另外，对于数据深度挖掘，通常做法是在应用层做完排序等复杂操作，把结果存入MYSQL即可，便于多次使用。
• 4、 不论数据源来自哪里，当数据量大到一定的规模后，由于占用内存/Cache 的关系，不再适合 PHP 中排序了；此时把数据复制、导入或者存在 MYSQL ，并用 INDEX 优化，是优于 PHP 的。不过，用 Java，甚至 C++ 来处理这类操作会更好。 [有些类似大数据集聚合或者汇总的数据，在客户端排序得不偿失。当然，也有用类似搜索引擎的思路来解决类似应用的情况。]

从网站整体考虑，就必须加入人力和成本的考虑。假如网站规模和负载较小，而人力有限（人数和能力都可能有限），此时在应用层（PHP）做排序要做不少开发和调试工作，耗费时间，得不偿失；不如在 DB 中处理，简单快速。对于大规模的网站，电力、服务器的费用很高，在系统架构上精打细算，可以节约大量的费用，是公司持续发展之必要；此时如果能在应用层(PHP) 进行排序并满足业务需求，尽量在应用层进行。

--EOF--

Posted by Fenng at 6:14 PM | Permalink | Comments (6)

这是前一段时间《程序员》杂志采访支付宝架构师团队的的稿件。篇幅较长，此为第二部分。。
本周支付宝架构师团队一部分成员将参加 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 王学安)

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

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

--EOF--

Posted by Fenng at 12:55 PM | Permalink | Comments (0)

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

Note：提问者：《程序员》杂志郑柯。回答者：支付宝架构师团队。

能否介绍下支付宝架构团队的构成以及各位的知识结构?

支付宝架构团队里的架构师角色可以划分为首席架构师、技术架构师、业务架构师、产品架构师等、数据库架构师等。

• 首席架构师：制定公司的长期技术路线图。是公司技术方向和技术组合的重要决策者。
• 技术架构师：关注整体网站系统架构。通过技术架构对业务架构提供支撑；（系统分析员不是技术架构师，但技术架构师能够胜任系统分析员的职责）
• 业务架构师：关注业务架构。对公司战略、客户需求、内部需求进行抽象、组织、规划。关注业务的敏捷性，能够随着战略的变化而变化。
• 数据架构师：负责数据库相关的架构，数据相关的技术研究、规划、评估等。

此外，我们支付宝架构团队里面还有搜索引擎专家专门负责搜索相关的技术，有业务流程专家制定业务流程制定，流程架构开发指引等，可谓藏龙卧虎。

支付宝的架构师中，一部分是从支付宝与淘宝网的内部一线研发人员中成长起来的，在多年的实战中积累了丰富的大规模分布式互联网系统的设计与开发经验，有扎实的 Java 开发功底，熟悉各种开源系统、框架与工具，熟悉主流的企业中间件。支付宝架构团队也有一部分是来自著名 IT 企业的架构师，他们分别在数据库、高性能计算、企业服务总线、工作流、开发工具等专业领域有多年的积累。

支付宝架构师对电子支付行业知识有相当深入的了解，尤其我们的业务架构师，他同时也是会计与支付行业应用的专家。另外，值得强调的是，每个架构师也都会定期带一到两名徒弟，把经验直接传递下去，满师之后徒弟也会承担比较关键的角色，这也让开发团队的同事有更好的上升空间。

支付宝架构团队对自己的具体定位是什么？

支付宝架构团队的日常工作定位在支付宝系统高层架构的设计与优化，其职责是保障系统与公司的愿景与业务体系一致，达到关键的业务敏捷、可伸缩、高可用、性能与安全指标，具备内在的统一性、协调性与可持续发展性，支持支付宝技术团队高效率地研发高质量的产品。

为了达成这一目标，我们会创建并持续优化支付宝的业务架构与系统架构蓝图与发展路线图、参与各类外部与内部标准与规范的制定、评估与指导重大项目与重大的系统变更、主持设计并实现支付宝系统开发框架与工具、以及辅导与培训支付宝技术团队成员等。

支付宝架构团队同时是支付宝未来发展所需的关键技术的孵化器。我们会根据公司的业务方向与趋势，结合行业与技术的发展状况，产出并维护支付宝的技术愿景、技术研究整体规划与发展路线图，并主持开展前瞻性技术的研究。

支付宝架构团队也是公司决策层的智囊团之一。我们会参与公司的发展决策，站在整体业务与技术架构、技术可行性与最佳技术途径的角度，对公司重要项目的决策提供专业性的参考意见。

补充一下，支付宝架构团队一直在招贤纳士，欢迎更多技术牛人加入(Fenng 补充：另外近期在上海会有招聘会)。

架构团队与开发团队之间的沟通多么？主要集中在哪些方面?

沟通是比较多的，一方面是在项目期间会有比较频繁的沟通，主要集中在产品的系统设计是否合理、技术难点支持等方面，有的时候，架构师也会临时"下放"到项目组，与开发工程师并肩战斗；另一方面在非项目时间经常会针对开发模式、新技术走向、如何做好设计和编码等技术角度做分享与交流。

架构团队内部的小范围沟通也不少，大家经常会就一些难点进行思维碰撞、分享、交流。 我们架构组后面的白板好像很少有干净的时候 - 经常是在讨论中拓扑图画满了整个白板。

支付宝架构团队是否经常与阿里巴巴旗下其他公司的架构团队进行沟通和交流？从其他团队哪里学到的最有价值的东西是什么？

为了促进阿里巴巴旗下的各个子公司之间的技术交流，我们成立了一个集团架构委员会。集团架构委员会每个月会有一次线上交流，每个季度会有一次线下的会议交流，而且每个月末各个子公司都会在邮件列表中报告各个子公司技术研究方向和成果。

如果大家都在研究同一种技术，会成立专门的研究小组，进行针对具体技术场景的研究。通过集团架构委员会，我们可以了解各个子公司的技术方向和研究成果，做到互相促进，互相学习，技术共享。

你们认为支付宝架构最令你们自豪的是什么？为什么?

在过去的三、四年里，随着支付宝业务领域的拓展与业务规模的增长，支付宝系统也一直处于快速的增长与变化中，从最初的单一应用迅速发展成由数十个自主系统构成的高度分布又充分协同的大系统。与此同时，支付宝研发团队的规模也从最初的数人发展到现在超过百人的研发团队。在快速奔跑中保持稳定与平衡，对架构提出了很高的挑战。

因此，我们很早就将支付宝系统建立在了面向服务架构(SOA)之上，确立了面向服务的整体业务架构，围绕着公司的基础业务建设了几大核心服务系统，并且搭建了以 ESB 为骨干、以服务框架为基础的面向服务基础设施。这些核心服务以及基础设施是支付宝系统健壮的后腰，它们的高可靠与高可用性是支付宝系统的整体稳定性的基础，它们的灵活性与可重用性支持前端业务有条不紊地创新、整合与优化，它们的可伸缩性保证了系统能够支撑持续的快速业务增长。

面向服务架构不仅是支付宝的运行系统的基础，而且已经渗透到了支付宝的研发与治理体系中，当前，这个领域仍然是支付宝架构团队的一个研究与应用的重点。

能够介绍一下支付宝的架构中用到了哪些 SOA 的思想?

支付宝从05年开始规划、研究SOA；在06年开始实施第一个SOA项目，同年引入ESB产品，对SOA相关的思想、技术进行验证和探索；经过几个项目的实施，我们完成了第一阶段的规划和目标，实现了几大核心业务的SOA化，构建了一套支撑SOA的技术平台。

从理论到实践上，都积累了丰富的经验，下一阶段，我们将会在深入业务SOA的同时，不断完善和发展我们的SOA技术平台。

在采用SOA思想的过程中，我们从下面2个方面入手：

首先，从业务层面入手，用SOA思想梳理业务架构。化解业务敏捷的要求，同时支撑支付宝的开放战略。在此之前，我们在进行业务架构分析的时候，更多的是关注业务的合理性，可行性等，在业务发展的初期，这种做法能够满足我们快速开发系统，及时占领市场的需要。在05年中，我们预见到现有的业务架构，将不能支撑我们公司快速发展的需要，例如：我们的注册会员飞速奔向1亿。此时，我们就开始探讨和规划SOA思想。因此在06年，我们果断的引入SOA思想，用SOA的思想不断重构我们的业务架构。在这个过程中，随着数次公司战略的调整，业务架构都能够灵活应对，达到了业务敏捷化的目的 -- 这也是SOA思想的核心。

业务架构的SOA化，是我们开展技术SOA的一个充要条件，没有这一步，我们将会非常艰难，甚至无从下手。

接着，技术层面的SOA，构建一个适合支付宝的SOA技术平台，来支撑业务SOA化的需要。针对支付宝的业务特点和要求，我们优先考虑实现如下SOA要素：

A：以服务为基本单元。技术平台提供与之对应的组件编程模型，业务层面的每一个服务，都能够方便的封装位技术层面额一个组件，例如：客户系统中的注册、登录等，都对应一个组件，每个组件都是独立的，在部署的时候，我们可以灵活选择和组合,可以依据SLA的要求，做出多种部署策略。

B：基于统一标准。在此，我们选择了ESB产品提供支撑，对外提供SOAP、REST、Hessian等标准的支持；对内统一采用定制的标准。

C：分布的能力。所有的服务都能够透明的分布，为外部消费者使用。

D：鼓励扩展。技术平台提供扩展的能力，例如：客户注册后的业务扩展点，业务部门要求依据客户注册来源、客户所在省、客户年龄等，进行不同的业务处理，而且这些业务点有些要求在事务中，有些要求在事务之外。如果每次新的需求出现，都在原有系统直接进行修改，那么不但可能破坏原有的业务，而且可能导致系统可维护性变差。提供扩展点功能，将把扩展逻辑和主体业务逻辑进行有效的隔离，能够彻底解决上面的问题。

E：支撑业务敏捷。支付宝的交易流具有流程类型多，流程过程繁杂的特点，业务流程每个月都会提出多种新的交易业务，同时我们的业务从单一交易业务流向整合型业务流发展。因此，我们引入了BPM相关的技术和工具，帮助我们方便，灵活的组合服务，定制流程。

--待续--

Posted by Fenng at 10:29 AM | Permalink | Comments (1)

Facebook 其实对待技术的态度其实挺开放的。今天阅读了这篇 Scale Out, 工程师 Jason Sobel 介绍了在对付跨地域 MySQL 复制网络延迟的问题。

Cache 一致性问题解决思路

大量的 MySQL + Memcached 服务器，布署简示：

California (主 Write/Read)............. Virginia (Read Only)

主数据中心在 California ，远程中心在 Virginia 。这两个中心网络延迟就有 70ms，MySQL 数据复制延迟有的时候会达到 20ms. 如果要让只读的信息从 Virginia 端发起，Memcached 的 Cache 数据一致性就是个问题。

1 用户发起更新操作，更名 "Jason" 到 "Monkey" ；
2 主数据库写入 "Monkey"，删除主、从两端 Memcached 中的名字值；
3 在 Virginia 有人查看该用户 Profile ；
4 在 Memcached 中没发现用户名字，从 Virginia  Slave 数据库读取，因为网络延迟，结果读到了 "Jason"；
5 更新 Virginia Memcached 中的该用户名字为 "Jason"；
6 复制追上了，更新名字为 ""Monkey"；
7 又有人读取 Profile 了；
8 在 Memcached 中找到了键值，返回 "Jason" （实际上造成业务冲突了)

解决办法挺有意思，在 SQL 解析层嵌入了针对 Memcached 的操作。

1 用户发起更新操作，更名 "Jason" 到 "Monkey" ；
2 主数据库写入 "Monkey"，删除主端 Memcached 中的名字值，但Virginia 端 Memcached 不删；(这地方在 SQL 解析上作了一点手脚，把更新的操作"示意"给远程)；
3 在 Virginia 有人查看该用户 Profile ；
4 在 Memcached 中找到键值，返回值 "Jason"；
5 复制追上更新 Slave 数据库用户名字为 "Monkey"，删除 Virginia Memcached 中的键值；
6 在 Virginia 有人查看该用户 Profile ；
7 Memcache 中没找到键值，所以从 Slave 中读取，然后得到正确的 "Monkey" 。

这里面的一个简单的原则是: 更新后的数据，用户第一次读取要从数据库读，顺便扔一份到 Cache 里，而不是在写入的时候直接更新 Memcached 。避免写事务过大。

而写操作的原则是：一次写入，到处分发。

第二个问题是关于"Page Routing"的 ，也很有参考价值。感兴趣的自己读一下吧。

--EOF--

另推荐一下: 分布式系统中的一致性和可用性，该文是上次在支付宝 QClub 活动的总结之二。

Posted by Fenng at 11:45 AM | Permalink | Comments (4)

又读了一遍这个 PPT： Federation at Flickr: Doing Billions of Queries Per Day ，发现还是值得咀嚼一下，尽管这"甘蔗"已经被吃过了。

针对主机环境的实践参考

Flickr 数据库的硬件配置一般用 16G 内存，6块 15K 硬盘，RAID 10，在 EM64T 下跑 RHEL 4，运行在 Deadline I/O 调度器 模式 。回写 Cache 用控制器电池而不用磁盘的 Cache。Swappiness 设置为 0 . 。

大内存数据库服务器的 Swap 设置问题

上面提到了 Flickr 是把 Swappiness 设置为 0 ，简单的通过:

echo 0 > /proc/sys/vm/swappiness 

个别情况下这样也可能没起作用，因为实际上对 Swap 的调用是由如下的公式计算得到的：

swap_tendency = mapped_ratio/2 + distress + vm_swappiness; 

其中 vm_swappiness 默认值是 60.

Linux Kernel 2.6 的诡异行为，当有大量物理内存空闲的时候，Linux 仍会傻乎乎的调用 Swap 空间，这导致有的时候系统性能很差。有人建议如果是 INNODB 的引擎的话，可以用 O_DIRECT 的方式强制直接调用物理内存。但似乎副作用很大（存疑)。

如果关闭 Swap (swapoff -a)的话，又会遇到 OOM 的问题。这是绝对不推荐的。

还有人用的方式是把 Swap 建立到 RAM 盘上。

Swap 的自动校正其实是个老问题，几年前可能超过 4g 的 Linux 服务器都不多，而现在动辄几十 G 的内存配置，应用场景发生了很大变化，Kernel 的算法思路肯定也要调整一些了吧(尽管几年来不断看到有小的 Patch 出来，可好像 RHEL 的 Kernel 还是老样子)。

我在这里抛砖引玉，大家实际应用中应该也遇到类似问题吧? 有什么建议? 还是干脆就不管? 默认情况下其实也能跑...

--EOF--

Posted by Fenng at 10:45 PM | Permalink | Comments (4)

在上周六的 QClub 上，BASE 成为了一个热点话题，其实除了这个 BASE 之外，还有个 CAP 理论也是值得关注一下的。这个概念也来自 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer ，应该说他 10 年前的那篇 Lessons from Internet Services: ACID vs. BASE 是互联网技术最为重要的一篇文章了。

C: Consistency 一致性 
A: Availability 可用性
P: Tolerance of network Partition 分区容忍性(有翻译为耐受性的，个人觉得不妥)

熊掌与鱼不可兼得，三个目标不能同时满足。如果对"一致性"要求高，且必需要做到"分区"，那么就要牺牲可用性；而对大型网站，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着 A、P 的方向设计，然后通过其它手段保证对于一致性的商务需求。

CAP 不是什么高深的东西，应该说 CAP 只是一个经验理论，切不可钻牛角尖，号称自己做的东西能打破 CAP 理论，那只是无意义的事情罢了。

如果知道 ACID(酸) 、BASE(碱) 在词典中的含义，那么这个 CAP 的辞典含义也很有趣。

--EOF--

最后推荐阅读一下这篇：可伸缩性原则

Posted by Fenng at 9:13 PM | Permalink | Comments (10)

本月 26 日，也就是明天，QClub：当SOA遭遇现实 将如期在支付宝举行。

除了报名参加的杭州本地的众多技术精英，阿里集团各家子公司也都有人参加，淘宝、阿里软件、阿里妈妈都会有资深架构师到现场来。相信这回是一场精彩的思维碰撞，期待。

特邀嘉宾：支付宝首席架构师 程立(花名：鲁肃)

程立，支付宝（中国）网络技术有限公司。2004年开始参与淘宝网与支付宝系统的建设，2005年起进入支付宝，一直从事于互联网电子支付系统的研发工作。现任支付宝首席架构师，专注于电子支付系统的分布式服务架构与开放架构。

一说起 SOA 可能很多人会觉得比较"空"，这也是我们举办会议的目的之一，"来点实在的技术信息" 是这次活动的一个宗旨。

会议地点

文三路、万塘路交汇处，华星时代广场 5 楼。大厅届时会有人指路

友情提示

为便于交流，请尽量携带名片 :) 

--EOF--

Posted by Fenng at 12:35 PM | Permalink | Comments (0)

一直以来，支付宝的技术人员都比较低调，这次总算利用网络侠客行大会的机会，促成了对支付宝首席架构师程立的采访。如果你对支付宝的架构和开发实践感兴趣，请不要错过 InfoQ 中文站 的这次专访：《程立谈架构、敏捷和SOA实践》 。

InfoQ 编辑在 介绍页面中引用程立的这段话我很欣赏：

老子说"道生一、一生二、二生三、三生万物"。在业务愿景的技术实现过程中，
假设"道"为愿景、一为方向、二为战略的话，三就应该是架构了，架构既出，万物化生可矣。

因为支付宝一直以为用户提供良好支付体验为目标，以致于有技术人员误认为简单的支付环节背后的支付宝后台技术也是非常简单的。其实想想看为将近 1 亿用户提供服务，每日交易额几个亿人民币，技术上没有独到之处怎么能做到?

和程立一起共事也有三年多了。我工作这么多年，很少遇到这么功力深厚、勤奋、敬业的技术人，感觉他就像一台自我修正的计算机，能一直朝着既定的目标前进，这一点值得很多技术人员学习。

如果觉得这次采访不过瘾，请关注接下来的 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得。

--EOF--

Posted by Fenng at 3:45 PM | Permalink | Comments (3)

在讨论 eBay 的Scalability最佳实践 的时候，结尾提到了 BASE 机制。现在越来越多的架构师更为关注 BASE 策略 (当然，我不是说 ACID 就不重要了)

BASE 策略是 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer 在 1988 年提出的。这几个缩写词如下定义：

• Basically Availble --基本可用
• Soft-state --软状态/柔性事务
• Eventual Consistency --最终一致性

"Soft state" (SS) 是与 "Hard state"(HS) 对应的。我几乎没找到很清晰的定义。不过用 RFC-1633 中的描述, "Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的，这样就清晰多了。

最终一致性， 也是是 ACID 的最终目的。对于 eBay 这样的大架构，是通过强大的消息总线能力来保证的。

对于 eBay 这样的大架构，另请参考 eBay 的 Dan Pritchett 在 最近的技术的散文：BASE: An ACID Alternative，注意其中提到的的事件驱动(Event-Driven)的架构的说法。

相信在今后几年，BASE 将成为一个技术热词。ACID 当然没过时，只是各自需要合适的应用场景而已。随着互联网技术的开放性，更多的时候，一个架构师需要反复的衡量合适的应用场景。

BTW: "ACID" 英文里面有"酸"的意思，而 "BASE" 有"碱"的意思. 酸碱在一起才能中和啊，哈

--EOF--

Posted by Fenng at 7:13 PM | Permalink | Comments (2)