IT架构师经常遇到的一个情况是：随着企业业务的不断发展，组织结构、业务需求和数据种类的不断变革，原有的系统架构不再适应新的需求，必须要做全新的架构重建。这是一个复杂而系统的工程，和日常开发工作中的代码重构相比，全局系统架构重构的难度、成本与风险会高许多，也缺乏普适的方法和成熟的工具的支持。
作为支付宝的***架构师，程立从2004年支付宝建设伊始就服务于该团队，如今，支付宝已从最初的不足十人的技术团队发展为拥有1000余技术人员的大集体，交易笔数也从每天1万笔增长到1000万笔。这样的发展速度和规模对于支付宝的系统架构提出了很高的要求，几年间，支付宝系统也经过了多次的架构重建。
10月23日，在QCon杭州2011全球企业开发大会的《***架构师的架构观》专场上，程立与大家分享了他作为***架构师的一些心得和经验。
架构重构的三个阶段
程立说，架构重构通常会经历三个阶段：“坏味道”驱动的局部架构重构、基于规划驱动的全局架构重构、和关于组织的整体的架构能力的重构。
支付宝现在是以第二阶段“基于规划驱动的全局架构重构”为主，但同时***阶段的工作也在进行。至于“关于组织的整体的架构能力的重构”，难度比较大，仍是他们在探索和努力的方向。
在演讲中，程立首先介绍了识别“架构坏味道”的几个判断标准，包括：研发效率不足，系统不稳定，新业务难以支持等。他同时提供了一些判定的细节依据(具体内容网友可在51CTO下载频道下载程立演讲的PPT和录音http://down.51cto.com/data/270838)。
程立表示，在识别出“坏味道”并决定要做架构重构的时候，架构师应该制定一套机制，以判定新设立的架构方案是否适用。
不过，尽管有了各种评判标准和风险控制措施，基于坏味道的局部重构仍有它的风险，当系统需求达到一定程度之后，就需要来一次全局重构。
理解大规模系统，需要更宏观的架构模型。它需要架构师有对业务、数据、应用、技术的多个视角，能描述多个视角之间的关系，并自顶向下，分而治之。
全局架构的运作对架构团队提出了更高的要求。有时，你会发现原有的组织结构已经不适应这种新的工作方法，这时候，就需要在组织层面进行一些改进，这就是“更深层次的架构重构—架构组织与架构过程重构”。这一过程通常需要企业进行不断的尝试，找到最适合自己的方法。在支付宝，程立介绍说，他们尝试了多种方式之后，最终确定了“架构委员会”的方法来统筹全局架构。“架构委员会”里会分为一个个的小项目运作，原来的“虚拟架构”的方式被弱化了，成为信息交流分享的平台。
架构师和PM是密切协作关系
做架构重构时要非常小心，以免数据遗失造成损失，这是所有架构师都非常明确的一点。然而，有一个问题却常常被忽略，那就是对于数据质量的处理。有一些数据可能并不直接涉及到系统运行，但是一旦你要对系统进行深入的数据挖掘和数据分析，你就会发现它们的重要性。由于遗失他们并不会对系统运行造成影响，有些架构师对此并不重视。从企业发展来看，这是很不利的。那么，如何避免这种现象的发生呢?
在回答51CTO记者提问时，程立表示“数据架构中要完整的考虑所有的问题，不能说运行中的数据才是数据。要看到全局架构组织的重要性，它不是单方面关注，不是只关注现在系统的运行，必须各个方面的人都有”。做全局架构是非常考验架构师“理解力”的一个工作，需要架构团队集思广益，并借助各种工具来分析判断，以免遗漏任何一个关键点。程立说“我们可能有的重构，发现数据仓库的连接中断了，这边变更一个字段那边没有同步更新，这是整个团队一个错误的问题。当你发现这样问题，你必须加到你架构过程里去控制。确保这样的问题不会再出现”。
然而，即使你开始的时候考虑的很周全，随着企业业务的发展，新的需求不断进来，可能一段时间后，你发现原来的架构“又”不够用了那该怎么办呢?程立表示，原有架构跟不上业务需求的发展，这是经常遇到的问题。开始的时候，我们可能通过不断的“打补丁”来解决这一问题，而到一定阶段之后，“补丁”已经不够用了，那就需要再做一次重构。据程立介绍说，在支付宝，这项工作是被架构团队作为一个常规工作存在的，每个季度，自上而下和自下而上都会提出一些架构评估的项目。评价委员会会对这些提议进行评估，看它的价值，看它的风险，确定优先级。如果通过的话就会发起立项。“基本上我们会有30%季度资源会持续放在这个事情上去”，程立说。
据程立介绍，支付宝架构团队实际上只有五六位专职架构师，对于每一次架构建设的协作和进度掌控，都是有架构师团队和PM来共同完成的。“架构师和PM是一个密切协作关系”，程立对51CTO记者说，“大型架构有很多PM来支持这个项目，可能会有一个项目群来掌握架构的进度，整个项目的进度”。针对有的朋友担心架构会不会与系统底层脱节的问题，程立说“架构和底层不脱节，关键是团队不能脱节”。
【编辑推荐】
