中国领先的IT技术网站
|
|

支付宝程立:解读架构重构的三个阶段

作为支付宝的首席架构师,程立从2004年支付宝建设伊始就服务于该团队,10月23日,在QCon杭州2011全球企业开发大会的《首席架构师的架构观》专场上,程立与大家分享了他作为首席架构师的一些心得和经验。

作者:苏慧来源:51CTO原创|2011-10-25 18:35


IT架构师经常遇到的一个情况是:随着企业业务的不断发展,组织结构、业务需求和数据种类的不断变革,原有的系统架构不再适应新的需求,必须要做全新的架构重建。这是一个复杂而系统的工程,和日常开发工作中的代码重构相比,全局系统架构重构的难度、成本与风险会高许多,也缺乏普适的方法和成熟的工具的支持。

作为支付宝的首席架构师,程立从2004年支付宝建设伊始就服务于该团队,如今,支付宝已从最初的不足十人的技术团队发展为拥有1000余技术人员的大集体,交易笔数也从每天1万笔增长到1000万笔。这样的发展速度和规模对于支付宝的系统架构提出了很高的要求,几年间,支付宝系统也经过了多次的架构重建。

10月23日,在QCon杭州2011全球企业开发大会的《首席架构师的架构观》专场上,程立与大家分享了他作为首席架构师的一些心得和经验。

架构重构的三个阶段

程立说,架构重构通常会经历三个阶段:“坏味道”驱动的局部架构重构、基于规划驱动的全局架构重构、和关于组织的整体的架构能力的重构。

支付宝现在是以第二阶段“基于规划驱动的全局架构重构”为主,但同时第一阶段的工作也在进行。至于“关于组织的整体的架构能力的重构”,难度比较大,仍是他们在探索和努力的方向。

在演讲中,程立首先介绍了识别“架构坏味道”的几个判断标准,包括:研发效率不足,系统不稳定,新业务难以支持等。他同时提供了一些判定的细节依据(具体内容网友可在51CTO下载频道下载程立演讲的PPT和录音http://down.51cto.com/data/270838)。

程立表示,在识别出“坏味道”并决定要做架构重构的时候,架构师应该制定一套机制,以判定新设立的架构方案是否适用。

不过,尽管有了各种评判标准和风险控制措施,基于坏味道的局部重构仍有它的风险,当系统需求达到一定程度之后,就需要来一次全局重构。

理解大规模系统,需要更宏观的架构模型。它需要架构师有对业务、数据、应用、技术的多个视角,能描述多个视角之间的关系,并自顶向下,分而治之。

全局架构的运作对架构团队提出了更高的要求。有时,你会发现原有的组织结构已经不适应这种新的工作方法,这时候,就需要在组织层面进行一些改进,这就是“更深层次的架构重构—架构组织与架构过程重构”。这一过程通常需要企业进行不断的尝试,找到最适合自己的方法。在支付宝,程立介绍说,他们尝试了多种方式之后,最终确定了“架构委员会”的方法来统筹全局架构。“架构委员会”里会分为一个个的小项目运作,原来的“虚拟架构”的方式被弱化了,成为信息交流分享的平台。

架构师和PM是密切协作关系

做架构重构时要非常小心,以免数据遗失造成损失,这是所有架构师都非常明确的一点。然而,有一个问题却常常被忽略,那就是对于数据质量的处理。有一些数据可能并不直接涉及到系统运行,但是一旦你要对系统进行深入的数据挖掘和数据分析,你就会发现它们的重要性。由于遗失他们并不会对系统运行造成影响,有些架构师对此并不重视。从企业发展来看,这是很不利的。那么,如何避免这种现象的发生呢?

在回答51CTO记者提问时,程立表示“数据架构中要完整的考虑所有的问题,不能说运行中的数据才是数据。要看到全局架构组织的重要性,它不是单方面关注,不是只关注现在系统的运行,必须各个方面的人都有”。做全局架构是非常考验架构师“理解力”的一个工作,需要架构团队集思广益,并借助各种工具来分析判断,以免遗漏任何一个关键点。程立说“我们可能有的重构,发现数据仓库的连接中断了,这边变更一个字段那边没有同步更新,这是整个团队一个错误的问题。当你发现这样问题,你必须加到你架构过程里去控制。确保这样的问题不会再出现”。

然而,即使你开始的时候考虑的很周全,随着企业业务的发展,新的需求不断进来,可能一段时间后,你发现原来的架构“又”不够用了那该怎么办呢?程立表示,原有架构跟不上业务需求的发展,这是经常遇到的问题。开始的时候,我们可能通过不断的“打补丁”来解决这一问题,而到一定阶段之后,“补丁”已经不够用了,那就需要再做一次重构。据程立介绍说,在支付宝,这项工作是被架构团队作为一个常规工作存在的,每个季度,自上而下和自下而上都会提出一些架构评估的项目。评价委员会会对这些提议进行评估,看它的价值,看它的风险,确定优先级。如果通过的话就会发起立项。“基本上我们会有30%季度资源会持续放在这个事情上去”,程立说。

据程立介绍,支付宝架构团队实际上只有五六位专职架构师,对于每一次架构建设的协作和进度掌控,都是有架构师团队和PM来共同完成的。“架构师和PM是一个密切协作关系”,程立对51CTO记者说,“大型架构有很多PM来支持这个项目,可能会有一个项目群来掌握架构的进度,整个项目的进度”。针对有的朋友担心架构会不会与系统底层脱节的问题,程立说“架构和底层不脱节,关键是团队不能脱节”。

【编辑推荐】

  1. 土豆网黄冬:衡量用户对带宽流量的体验的三把尺子
  2. 淘宝袁锋:Node.js会令后端人员产生危机感
  3. 百度高级架构师乔梁:DevOps=Culture+Tools
  4. 百姓网:无政府主义编程 每天上线一次
【责任编辑:苏慧 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢
24H热文
一周话题
本月最赞

读 书 +更多

循序渐进Oracle——数据库管理、优化与备份恢复

本书从基础知识入手,详细讨论了Oracle数据库的创建、OEM及iSQL*Plus等工具的使用、Oracle的字符集知识、用户的创建与管理、表空间和数据文...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊
× 学习达标赢Beats耳机