转载

软件架构和鸡窝

什么是软件架构

软件架构是指系统的一个或多个结构，它们由软件元素、元素的外部可见属性、元素之间的关系组成。（出自一本书——《软件架构实践》，强烈建议不要看这本书，因为它跟“实践”没有半毛钱关系，这是一本纯粹的理论的书。除非你一个字的一个字的仔细读否则别指望能看懂。）

这是最为权威、普遍的关于软件架构的定义。所以软件架构师——作为实现软件架构的人，他绝对不是“负责技术选择、设计系统的主体框架结构，并负责搭建实施的人”。我们把定义拆解分析：

软件架构是一种或者多种结构，这里的结构可以理解为“视图”或者叫“角度”（我觉得角度平易近人）。比如常见的B/S系统我们可以从物理部署服务器的角度分析看到的是“数据库服务器”、“应用服务器”、“Web服务器”；从代码的逻辑角度分析看到的是“数据库访问层”、“业务逻辑层”、“Web层”；从业务上分析是“订单模块”、“收藏夹”、“购物车”。（再比如Mysql数据库，从线程角度可以分为“I/O线程”、“redo log 线程”、“data write线程”、“data read线程”；从内存使用角度可以分为“undo page”、“insert buffer page”。）
每个结构由不同的软件元素组成。翻译成人类的语言：每个角度我们看到的系统都是“不一样”的。从部署角度看到的是“xx服务器”；从线程（进程）角度看到的是每个进程的职责；从业务角度看到的是各个功能模块。
软件元素之间是有关系的，这些关系是架构的一部分。翻译成人类的语言：每个角度看到的内容都不是单独存在的，而是相互依存的。从部署角度看到的服务器是多台服务器，每台服务器都有职责，在系统工作的时候会相互通讯；从业务角度看到的各个功能模块也不是完全独立的，它们可能会有相同的依赖（比如都依赖认证模块），也会相互依赖（比如购物车模块依赖订单模块）。

软件架构选择哪种“角度”是一个不太好把握的东西，所以有诸如“Rational的4+1视图”来指导架构师分析。但是这种“定死”的角度往往形成“八股文”，最终流于形式，起不到思考的作用。这一点，软件架构师应该向“大厨”学习。一个优秀的大厨，他会查看自己可以用的食材；分析食客们的口味偏好；琢磨自己要做哪些菜，如何分工；每道菜的荤素搭配。他的每次做大餐的时候都会有不同的思考角度，但是无论如何折腾他们很清楚自己是在解决一个问题——“怎么用这些食材、这些人让大爷们吃好喝好。”所以对于软件架构师来说我们不应该拘泥于某些条条框框，记住我们的目标—— 架构师目标是利用现有的资源来实现系统。 然后尝试用各种手段去实现这个目标。（恩，你可以不择手段）

什么是好的架构

我曾经读到过一段文字：做一个鸡窝的时候我们不需要架构，当盖高楼大厦的时候才需要架构。对此我表示：持有这个观点的人是一个书呆子，他根本不知道设计一个鸡窝有多么“复杂”。我们先看两个设计稿：

高大上的设计

软件架构和鸡窝

恩，被这个牛B的造型震惊吗？造型美观，价格便宜(全木结构)，还采用了独特的阳台设计。

低小下的设计

软件架构和鸡窝这个简直不能用设计来形容，直接就“实现”了，根本没有设计图。

我的评价

你猜对了，“低小下”的设计获胜。

“高大上”的架构师是一个成功的销售，他擅长画漂亮的图，做大家都觉得“正确”的事情。你可以指责他的设计成本高，但是你挑不出其他毛病。这就是一个成功的“销售型架构师”典型代表。但是对于一个真正经历过“战场厮杀”的人来说这个设计有非常明显的错误。

“高大上”的架构师没有意识到鸡是一个恒温动物，根本不怕冷，只怕热。只要不淋成“落汤鸡”，室外多低的温度对它都是无所谓，反而“热”是它最讨厌的事情。
架构师没有意识到，鸡最怕的动物是“黄鼠狼”。基本上出现黄鼠狼的地方鸡必然是“死无葬身之地”，这个设计中“房子”的造型很别致，但是门是开着的，方便了鸡也方便了“狼”。即便修改设计，改成密封的那就更要命了，鸡肯定不会住进去的，因为它们——怕热。结果是住在外面，直接被黄鼠狼连窝端掉。
“高大上”的设计中没有任何“餐厅”，怎么喝水？怎么吃东西？你不会指望鸡满大街跑吧？那要鸡窝还有什么用？

“高大上”犯的错误是隐蔽的，对于“不熟悉业务”的人来说是它是理所当然的。人习惯性的用自己的需求去衡量鸡（鸡需要卧室，怕冷，需要阳台透气）。

再说“低小下”的设计，如果能把四周的纱窗网口做成铁的，高度再提高一点它就是一个完美的方案。四面透风根本不用担心热；顶部的木板是活动的方便喂食，也可以挡雨；四周围的铁网完美的防止黄鼠狼的出现保护了鸡的安全。

高能警告，并不是所有的“低小下”都是优秀的设计。同样是“低小下”style，下面的设计也是属于“销售型架构”(虽然丑了点)