谈软件架构（转）

最近看了下《架构之美这本书》，摘录了部分书中的内容，在摘录书里面内容前先谈谈我自己对架构的看法。架构应该包括了功能性架构和非功能性架构两个方面的内容。我们常说的J2EE，DotNet标准架构框架更多的是非功能性架构的范畴；而谈的子系统，组件划分，接口设计，复用等内容涉及到功能性架构的内容。J2EE架构的标准模板很容易找到和借用，但是并不代表你是一个合格的架构师，架构师必须深入到功能性架构中，真正的做好需求和实现中间的桥梁。正如现在好的PPT模板一大堆，但是并不代表你能够做出好的PPT来，PPT的模板仅仅是术，而PPT内容和思维才是道，而这里又是我们经常讲到的模式的问题，即根据我们的目标如何选择相应的图表和模板来最合理，最简单的展现我们的内容。

从静态分析的角度来考虑，架构的核心即是分解和集成。我们面对的现实业务和需求可能太庞大了，如果不去分解我们的构建根本都无法下手，我们就无法真正理解业务细节。因此子系统和组件划分是分解重要内容，分解重要原则又是高内聚，松耦合。由于分解产生了组件间的交互，因此需要根据关注接口的分析和设计，架构师的一个关键职能就是要屏蔽系统本身复杂性，将复杂性作为一个黑盒控制在自己手里，对外只需要暴露尽可能简单的接口。而在分解的时候又必须要考虑集成，架构师在自己脑海里面已经有了目标系统的样子，他们会很有信心分解的组件能够通过当初定义的接口很好的集成在一起。正如汽车制造一样，所有的零备件都出来了却发现它们根本无法组装成一台汽车，这对架构师是最大的悲哀。系统都还没有出来，而架构师就能够游刃有余的做这些事情，靠的不仅仅是多年的设计和开发实践，更多的则是在实践过程中的抽象思维和模式总结。

从动态分析的角度来考虑，现实世界中的原始需求进入，最终出来的则是满足需求的功能实现，在这个过程中涉及到一系列的内部程序流转流程，前台界面，业务逻辑，数据访问，数据实体，公用组件等，这些层次之间应该怎样去交互是在架构设计中必须要考虑清楚的问题。在这方面我喜欢用架构机制这个词语，机制往往并不是静态词汇，因为要深究机制就必须要搞清楚事件触发，功能调用，访问顺序等一系列问题。简单的讲，架构机制要回答一个重要的问题，即你设计出的分布式框架如何能够满足输入的需求变成最终输出的功能，中间究竟经历了哪些步骤？安全性如何保证？性能如何保证？可扩展性又如何保证？要回答这些问题你都必须给出这些问题的解决方案的运行机制，而只有大家认可了运行机制，或者新出来的模块已经在新架构上运行验证了，才能够讲从架构框架上基本上已经成熟了。

架构本身不是目标，而简单实用并且支持灵活扩展的系统才是我们追求的目标。架构师思维意识里面更加重要的是实用性和经济性而非理想化，由于业务域和问题域的不同没有完全可以照搬的架构，在架构设计上追求一定的可扩展性，要杜绝过度架构和架构理想化的问题。就如何建造一个建筑，如果我们最终得不到一个实用的的建筑物，你再怎么向客户吹嘘你的设计图纸和建造框架如何合理都是徒劳的。

在《人月神话》里面谈到，给我看你的流程图而隐藏起你的表，我将仍然莫名其妙；而给我看你的表，我将不再需要你的流程图，因为它们太明显了。足见架构中静态分析的成分远远的大于了动态分析，而静态分析的重点即我们所说的对象，我需要观察现实世界有哪些对象以及这些对象之间存在的关系，而这些内容通过抽象之后正是我们谈的数据架构。在SOA的参考模型中ESB层面的重点则是通过流程分析和分解后形成的数据集成架构，有了这个才可能进一步的进行基于流程编排的动态架构。即我们先抛开流程，首先通过分解方法来找寻数据形成静态的数据架构，然后再结合流程来观察数据的形成和转化过程。

以下内容摘录自《架构之美》一书:

有人问过我：架构的最主要产出是什么？我的答案是图。这里面有两层含义：一层含义是如同建筑师描绘的蓝图一样，用于引导实施者；另一层含义是架构师头脑中清晰的目标系统。如果架构师头脑中没有清晰的图像，他是没有办法把它画出来的。

架构是一个过程，而非一个结果。架构是架构师洞见内在结构、规律、原则和逻辑的过程。真正的架构师是可以将自己放在系统中去的(例如作为系统中的任何一个角色)，只有清晰地理解系统，才能简洁的描述它。而当架构师拿出了他所描述的作品的时候，架构这个过程就已经结束了。

美丽的架构应尽可能的精益，并且是演进式发展的。当你架构一个支持亿万人同时在线的大规模网站系统的时候，你无法从一开始就提供最完善的解决方案，它应该是随着用户的增长而可扩展的。精益的实现让你避免过度设计，也使架构不断演进并趋于完美。

美丽的架构无法定义，而它却是一种自然的，简单的，可复用的，人文的，甚至是外行人也可以细细品味其思想的。当我看到超市的多个收银台前排满长队，便想到服务器并发处理性能和容量；当我看到十字路口的车辆需要等待转弯的时候，便想到用缓存的思想来提高交通吞吐量。

如何设计出美丽的架构？从代码逻辑到物理网络，从单机到分布式，无数的技术可以供架构师选择；如分层，组件化，服务化，标准化，缓存，分离，队列，复制，冗余，代理等，不过它们仅仅是术的范畴，而何时何处如何恰到好处地使用它们才是道的范畴，比如顿悟变化的道理，在博弈中寻找平衡，以系统化的角度来分析问题，寻找相对与绝对的奥秘，开放的心态。

在软件设计中，设计师需要考虑多方面的关注点。漂亮的架构设计让这些关注点尽可能分离，然后以一种最简单的机制结合在一起，从而得到高内聚，低耦合的系统。爱因斯坦说过，“让它尽可能简单，但不要过于简单”，我们所需要考虑所有必须考虑的关注点，然后用简单漂亮的架构来体现我们的关注点，以体现架构设计的经济性。

架构提供一种共同的方法来解决我们软件开发中面临的实际问题，架构的核心是概念完整性，即一组抽象和规则，在整个系统中尽可能简单的使用他们。好的建筑应该通过美观，坚固和实用三个方面来衡量，而好的架构也正是这三方面的平衡和配合，没有哪一个方面比其它方面更加重要。