仔细观察，别试图控制一切

作者：格雷戈尔侯珀（Gregor Hohpe）

我们己经进入分布式、松耦合系统的时代。构建松耦合的系统多少有些麻烦，为什么大家要自讨苦吃呢？我们希望系统足够灵活（flexible）、别因为一点小小的变动就支离破碎。分布式应用只是一小部分受本地控制，其余部分则以分布式服务或第三方软件包的形式存在，由其他部门或软件厂商控制，所以灵活性是分布式系统的重要指标。

看来设计可以随着时间不断灵活变化的系统是个好主意。但这首先意味着系统会不断变化，就像人们常说的“日新月异”，而且记录系统文档将是个大麻烦。一般写下来的文档信息都不是最新的，这点相信大家都有体会。而要描述不断变化的系统，情况只会更糟。此外，灵活的系统意味着更复杂的架构，因而更难描绘出“全局视图”。比方说，如果系统组件是通过可配置的逻辑信道通信的，就得查看所有的信道配置才能了解通信双方的具体情况。在分布式系统里，消息发错信道要比编译错误严重得多，因为每条消息都与用户的利益密切相关。

妄想掌控一切的架构师只能设计出紧耦合的、脆弱的解决方案，这一套己经行不通了。但是放任自流也不行，那只会导致系统混乱。我们必须启用必要的辅助机械。使用仪表飞行（instrument flight）必须有仪表设备，不是吗？有哪些“仪表”可供架构师选用呢？选择其实很多。现在的编程语言己经开始支持反射技术，几乎所有的运行时平台都提供运行时测量标准（runtime metrics）。随着系统的配置越来越灵活，当前的系统配置包含了更多信息，为了便于理，必须从中提取模型。如果你搞清楚了哪个组件负责向逻辑信道发送消息，哪个组件负责接收消息，就应该把组件的通信关系用图表模型记录下来。这件事可以每隔几分钟或几个小时做一次，在系统的变化过程中，记录下最新的、准确的系统模型。不妨把这个过程看成“反向MDA”（Reverse MDA）（译注1）。与模型驱动架构不同，你先构建出灵活的架构，然后再从实际的系统状态中提取模型。

多数情况下，模型很容易画出来，得到系统的全局规划也不困难，但是千万别用巨型广告板把系统中的所有类和依赖关系详细画出来。这张图作为艺术品也许不错，但作为软件模型则太不实用。埃里克·多伦伯格（ErikDoernenburg）己经介绍了正确的做法（译注2），应该采用“一千英尺高”的视图。选择合适的抽象层次能为你提供有效的信息，也方便你用基本的规则检查模型，比如检查依赖图中是不是存在循环依赖（circular dependencies），发送到逻辑信道的消息是不是都有接收方负责接收。

撤手不管是很危险的状态，对系统架构来说也是一样。对21世纪的架构师来说，正确的做法应该是：仔细观察，提取模型，然后检查验证。

译注1：MDA是模型驱动架构（model-driven architecture）的简称。

译注2：请参见本书第28篇《使用“一千英尺高”的视图》一文。