当我谈架构的时候，我谈些什么？

过去一年，业务增长迅猛，架构不断改进，但我却看不清楚架构未来的样子，经过思考悟出一些简单的道理，架构是为业务服务的，一切不以业务为指标的架构都是耍流氓。

为什么要谈架构？

先讲讲近一年项目的架构演化，年初的时候，业务单一，基础薄弱，算法朴素。首先，在线上事故的教训下，增加了全面的监控，包括主动监控、被动监控，并且将可监控性作为每一个服务的基本属性，问题检测时间缩短到分钟级，问题排除效率也大大提高；另外，在业务压力的推动下，朴素的广告算法逐步升级成基于大数据的模型，模型数据的实时性也从每日更新，变成每分钟更新，进行一个算法实验变得更加敏捷；在牵一发而动全身的设计困惑下，“大泥团”的架构实体渐渐理顺了层次和关系，分清了主和次。业务也从单一大业务，变成了3个骨干业务+5初创业务的复合服务。

软件架构的蓝图在哪里？

虽然架构一直在进化，新旧问题也不断在被解决，但是对于半年或一年后的架构，依旧无法看透。架构需要不断的优化和改进，但是以什么为指南针，来判定架构改进任务的优先级，如何平衡短期和长期的投入和收益？一直没有悟透这个道理，为此找来了几本书看看。一本是《架构之美》，还有一本是《恰如其分的架构设计》，还有Martin Fowler的一些文章，有了一些启发。

首先对于架构的理解，找到了些共鸣。

大师Grady Booch对于软件架构的定义是“架构是一种设计，但并非所有设计都是架构。架构代表着发展一个系统的重要决定，而这种重要性是通过引入变化的成本来衡量的”。引入变化成本将成为架构决策的重要因素，这与我的想法不谋而合，其实架构的演化就是与业务息息相关。

《恰》里提到“对定一个系统，需要多少专门的架构设计工作？ 一个关键问题是，如果一个项目没有太多的设计风险，说明架构在一个好的状态，不需要太多的架构工作；如果一个系统的设计风险很大，每一个业务实现都需要过多的考虑设计风险，那么说明这个项目的架构需要大力投入了。这就是风险驱动的架构设计。”

架构师和建筑师

架构师和建筑师相同点是都需要负责一些框架，建筑师需要保证建筑的美观，实用和坚固，架构师也需要负责软件架构的简单，实用和可靠。他们之间很大的区别是：架构师随着时间的演化，需要继续对架构进行演化，以支持业务的发展，他比建筑师多一个时间的维度。所以，架构师的角色更像是一个城市的规划师，负责长期的演化工作，应对以后的变化，包括很多未知的可能性。遥想建国初年，梁思成提出来的《梁陈方案》如果能够演化下来，北京的古城保护将会是另外一番景象。

架构师的KPI

好了，搞清楚了架构师的作用之后，如何评定架构师的成绩（OKR或者KPI)、响应时间、并发数量、开发效率、缺陷数量等。这些都是工程师眼中的工程师目标，这些指标到底和业务增长有多少关系呢？ 有些可能是直接相关的，有些可能是间接相关的，并非是面向业务的演化。如果将业务的KPIs作为架构师的KPIs呢，例如营收、用户数、使用时长、留存数等？初想这个问题，感觉很难关联上，但是仔细想想，关联还是非常大的。架构师在系统演化过程中，最重要的技能就是能够平衡好成本、速度、质量和风险，那么在平衡这些因素的时候，总是需要一个基本原则来指导，这就是通常说的True North，用最简单的指标来决定方向。那么，业务的关键指标将是非常重要的。

为什么只选一个关键指标，因为真正的北方只有一个。有一本书叫做《Lean Analytics》里面介绍了一种观点 OMTM(One Metric That Matter)，每个组织都应该找到它的关键指标，这个指标必须简单直接，寻找这个指标也许不容易，但是一旦确定下来，就可以快速迭代、进行优化、周而复始的为之努力。架构的演化也必须找到这个指标。

总结一下，当我谈架构的时候，我谈的是架构需要对业务负责，演化指标必须与业务关联，为情怀而生的架构是难以落地的。

「CSDN 架构师群」，内有SDCC 2015脚骨专场的讲师等诸多知名互联 公司的大牛架构师，如果你想进群交流，请加微信qshuguang2008申请入群，备注姓名+公司+职位。