让架构接地气，不再云里雾里

http://www.csdn.net/article/2015-09-15/2825700

【SDCC讲师专访】蔡学镛：让架构接地气，不再云里雾里

发表于4小时前| 2297次阅读| 来源CSDN| 4 条评论|
作者钱曙光

SDCCSDCC讲师专访蔡学镛架构架构师设计模式

摘要：SDCC 2015中国软件开发者大会将于2015年11月19-21日在北京召开。我们采访了与会讲师，蔡学镛，现任中国平安的首席应用架构师，请他分享他的架构积累、架构师感悟，以及将在本次大会上分享的话题。

CSDN年度技术盛宴“SDCC 2015中国软件开发者嘉年华”将于2015年11月19-21日在北京召开。软件研发频道将采访一些与会讲师，谈谈他们将在会上分享的内容。

本期我们采访的讲师是来自台湾的蔡学镛，现任中国平安的首席应用架构师。



CSDN：请和大家介绍下你和目前所从事的工作，以及是在架构方面的技术经验和积累。

蔡学镛：我目前是中国平安的首席应用架构师，工作主要是架构的指导与协助，框架的设计与开发。我是在六年前开始担任架构师的。这些年来参与了一些项目的设计，培养了一些架构经验。我喜欢总结我的架构经验，这样可以帮助经验留下来，重复使用，而不是随著时间而忘记。

CSDN：你目前最关注哪些技术领域？

蔡学镛：这六年来我离开前端技术，转到后端架构设计。我比较关注领域驱动设计、数据建模、云计算、开放平台。

让架构接地气，不再云里雾里

CSDN：在你看来，架构是什么？是一句话能说明的？

蔡学镛：架构就是「复杂」系统内部的代码「组织」方式与「交互」方式。

CSDN：许多人将「架构」与「设计模式」和「框架」混为一谈，对你怎么看？

蔡学镛：架构是一种设计方法，设计模式是常用的有效设计方法，框架是一种可复用的库。

架构和设计模式关系比较密切，因为都是设计方法，但架构一般指的是「粗粒度」的设计（关注模块），而设计模式一般指的是「细粒度」的设计（关注类）。但如果在设计模式前面冠上架构，变成「架构设计模式」，就是指常用的架构设计方法，而不再指详细设计的方法了。

框架是一种可复用的代码，如果该框架存在的目的是为了帮助某种架构，那么这就是架构性框架。

CSDN：能够简单介绍一下你的架构模型吗？

蔡学镛：这是一个三维的立体模型。分成 XYZ 三个轴。X 轴关注的是业务抽象、Y 轴关注的是业务分割、Z 轴关注的是计算机系统抽象。经过多年的焠炼，这个模型也在不断改进，现在已经演化到 3.0 版。这个版本和前一个版本的最大差异是，我用函数模型取代对象模型，且以数据建模为中心，取代领域建模为中心。因为我体会到这样才能更好地搭配「敏捷开发流程」与「分层架构设计」，以及云平台。

CSDN：你是如何演进你的架构模型的？

蔡学镛：架构模型的演进来自两方面的刺激，一方面是外界的设计模式，另一方面是实际的项目。

心中先有一个架构模型后，再详读各种架构设计模式，我会试图把这些模式一一映射到我的架构模型中，过程会牵涉到两者间阻抗匹配的问题，这又会引发我的思考，致使对架构模式的理解更充分，最终又强化了架构模型，让模型更接地气、更通用。

把架构模式套用在自己设计的框架与系统上，又可能会遇到一些问题。这些问题又会引发我的思考，进而改进我的模型。

苦思很久一个架构设计问题，如果还是没有完美解，可能是自己的火候还不到。但在这个基础之上，经过一段时间以后，更好的解法可能就会出现。

从技术架构设计的经验来看，在两个极端的做法之间摆荡过后，就可以快速地找到中庸之道。两个极端可以让我们最深刻地体会到两者最明确的优缺点，然后就知道如何调适。

CSDN：你认为设计架构时，最困难的地方是什么？

蔡学镛：最困难的是控制问题的复杂度。为了有足够的脑力思考问题，架构师往往必须舍弃细节，先关注大格局的部分。但忽略某些关键细节可能会导致设计出来的架构不可用，因此架构设计至少要有两轮（两个迭代）：第一轮先关注大格局做整体架构的制定，第二轮再关注关键细节做架构的调整（有可能是大幅度的调整）。再后续几轮都只是小修改。

做架构设计时，常常一不小心就同时考虑逻辑架构和物理架构，导致问题的复杂度太高，且往往物理架构变成主导，无法做出好的逻辑架构。... 我认为应该很先做逻辑架构，然后才做物理架构，并进行调整，最后再回到逻辑架构进行审视与调整。

我会使用一个架构参考模型（Model），这是因为套用这个模型可以帮助我降低问题的复杂度。

CSDN：重视架构可以为公司带来什么价值。

蔡学镛：不如我把问题改成「不重视架构，会为公司带来什么伤害？」

不管什么行业，IT 技术已经渐渐成为支撑许多公司产品的骨架，而架构更是其中关键。但多数这些公司的领导对于架构的重视依然不够，没有技术积累。这类公司终究会遭受到短视的后果，最明显的是三点：

架构滞后拖累产品创新的步伐；
系统运营成本居高不下，侵蚀公司获利；
系统不稳甚至故障频发，为公司带来灾难。

CSDN：很多人认为架构是很虚的东西，如何让架构落地？

蔡学镛：架构如果是空的理论，则没有帮助，可以通过「架构性框架」让架构落地。框架虽然好用，但学习难度如果太高，则会让人裹足不前，应该要通过一套开发流程方法（Process），来指导开发的进展。架构+框架+流程，三者若配合得好，可以让系统的开发、测试、和运维更加顺利，也让架构更接地气。

架构师的修炼之道

CSDN：你认为如何当一个有效率的架构师？

蔡学镛：已经有许多作者整理出常用的架构设计模式（Pattern），熟悉它们，就可以在适当时机时直接套用，快速做出设计。

另外，想降低架构设计的难度，提高架构设计的质量，我建议架构师心中要有一个参考用的架构模型。好的参考模型必须具有通用性，只要对它做一些微调，就适用于大多数的状况。我这次会议就会分享一个我设计的架构参考模型。

CSDN：身为一个架构师，应该要具备哪些能力和修养？

蔡学镛：软件架构师一词开始流行，始于 1990 年代末，这跟互联网的流行有很密切的关系。互联网系统的设计，在以往的 C/S 系统设计需求之外，还多了很多其他要求，这些都是架构师在设计系统时必须考虑到的。整体来说，互联网的系统必须做到分布式、高并发、高可用、可伸缩、安全性、成本效益...等特点。上述这几点，其实都是对「云计算」的要求。我认为在 2000 年代末开始，还多了对「数据完整性」和「接口开放性」的要求。

除了上述的设计能力，系统重新工程设计（re-engineering）也相当重要。过去这几年大量不重视架构的系统被开发出来，现在这些系统都遇到严重的瓶颈了，需要拨乱反正，因而有了 re-engineering 的需求。担任架构师，就不免要参与到这样的工作。

简而言之，架构师要让设计出来的系统支持云平台、大数据、开放平台。同时架构师还要有改造旧系统的能力。

CSDN：现在很缺架构师，为什么架构师的养成很困难？

蔡学镛：这是几方面的原因共同造成的：

技术岗位的人做不久；
相关的学习资料难寻；
架构师对技术人的多种特质要求比较高

先说第一点，大家很清楚，国内做技术的人，几年之后通常就会转管理，持续做技术的比例很低。和技术脱节之后，规划出来的东西就往往不靠谱，就无法成为架构师。

关于第二点，你可以看看市面上被归类为架构的书，有的主题讲业务领域建模，有的講网络，有的偏运维，有的偏数据，有的很理论。每本书都只用一个角度看一个局部。偏偏架构师应该是关注全局的，而不是局部的。关注全局且接地气的架构学习资料极少，架构师的学习成长都必须靠自己摸索。

第三点，架构师必须关注技术，也关注业务；关注细节，也关注大局；关注开发，也关注运维。能动手（做事），也能动口（说服）。对人的要求比较高。

CSDN：工程师如何成长为架构师？

蔡学镛：我的建议：

做过几个互联网项目；
做过几个传统企业项目；
多读一些架构的书和文档，试图吸取别人的养分；
多多和他人讨论架构问题，试图获取一些刺激；
总结这些项目、文档、讨论所带来的思维，试图归纳出一套可复用的模型与方法

CSDN：如何科学有效地考核架构师的能力水平呢？

蔡学镛：可以看看架构师具备哪些架构知识。架构知识基本上分成几个层次，由下往上分别是：架构原则、架构设计模式、架构模型、架构风格。了解架构师对每个层次的熟悉程度，大概可以估计出他的架构设计能力。

SDCC 2015

CSDN：您在本次SDCC 2015大会上想分享的话题是？

蔡学镛：这次我会分享我的三维架构模型3.0版，同时介绍一个可以搭配使用的开发流程。希望能够让架构知识更接地气。

CSDN：你最期待在SDCC 2015大会上看到哪些内容？

蔡学镛：我希望看到特殊的，讲师原创的内容，最好对思维有所刺激的内容。