​浅谈架构

今天@Laruence 挖了个坑，我试着来灌点水。纯粹个人观点，不准确也不全面。

架构 (architecture) 这个概念确实不好定义。首先，它很虚，不像代码可以用源文件“自证”。其次，它很泛，好像跟什么都相关，开发、测试、部署甚至运营等各阶段都有其影子。然后，它好像还在变，在计算机发展的各个阶段（Mainframe/PC/Cloud）都感觉不太一样。而且，在不同的领域也都有不同的反映。

所以，一千个人心中有一千个哈姆雷特，一千个工程师眼里也能有一千种架构。在2012年2月1日晚11点左右（向Pkubuntu致敬），我的看法可以用两个例子说明。以建筑为例，设计师想方案，建筑师出图纸，工人施工同时项目管理贯穿始终，那图纸就是架构。如果说到烤鸭，骨头和肉是代码，鸭架子就是架构，而过程管理将其变成烤鸭。

如果要更正式点定义，架构就是model和pattern，从而把code串成system。而其中最重要的就是design principles (设计原则），即为什么这个问题要用这个而非那个。更文艺点，再结合点美学，也可以叫作design philosophy (设计哲学或理念)。

然后我们来看什么是model和pattern，这两个具体的定义我还没想出来。先说一下比较，model偏宏观，而pattern偏微观；model重抽象描述，而pattern重具体实现。比如，你的系统有一个服务端和一个客户端，那么client/server就是model，而client与server之间的交互方式则是pattern，比如RPC/message、同步/异步，比如用滑动窗口来组织请求与应答等等。当然，这和系统的尺度有关。如果你zoom in到服务端，此时的model可能就是模块的组织关系，而pattern则是调用方式，比如用function call还是event等。

具体到领域上，我觉得主要有三类架构问题（不包括硬件）：

1. 软件架构，其典型用例是企业级软件，通过合理的功能抽象，提取出公共组件和通用流程，进行最大化的功能复用 (reuse)。我称其为软件的可维护性问题。

2. 系统架构，其巅峰是OS，重点是解决资源的分配与复用 (multiplexing)。

3. 大规模分布式架构，主要应用在Cloud中，重点是大规模系统的资源整合、快速交付和运维问题。

1有《Design Patterns》一书，2有很多OS、并行程序设计的书可供参考 (或者应该写本《Parallel Patterns》？)，3目前我还不知道有什么书可参考。

那为什么架构会很泛又多变呢？这就牵扯到开发过程了。我们再引入一个方法论 (methodology) 的概念。传统软件工程那一套不必说了，互联网服务常用迭代式的开发方法 (现在又叫敏捷)，这就是方法论。我个人的做法通常有三种：divide and conquer，modeling and iterate，back-of-envelop-calculation and simulation，按问题的规模、难易程度、熟悉程度、项目的组织方式等等选择不同做法。这就又提到架构师这个角色了，找时间再谈。

总而言之，相对于代码和功能这些更实际的东西，以上所说的都是偏虚偏抽象的事情，我称其为开发工艺问题，包括架构和方法论两个层面。不同时代的系统，其组成不同，对开发工艺的要求也不同。在Cloud时代，可归结为三点：软件架构和开发过程支持快速迭代，系统架构与分布式架构支持大规模用户和数据分析，然后由数据分析驱动迭代。