软件架构、鸡窝、软件架构师

什么是软件架构

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

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

* 软件架构是一种或者多种结构，这里的结构可以理解为“视图”或者叫“角度”（我觉得角度平易近人）。比如常见的B/S系统我们可以从物理部署服务器的角度分析看到的是“数据库服务器”、“应用服务器”、“Web服务器”；从代码的逻辑角度分析看到的是“数据库访问层”、“业务逻辑层”、“Web层”；从业务上分析是“订单模块”、“收藏夹”、“购物车”。（再比如Mysql数据库，从线程角度可以分为“I/O线程”、“redo log 线程”、“data write线程”、“data read线程”；从内存使用角度可以分为“undo page”、“insert buffer page”。）

* 每个结构由不同的软件元素组成。翻译成人类的语言：每个角度我们看到的系统都是“不一样”的。从部署角度看到的是“xx服务器”；从线程（进程）角度看到的是每个进程的职责；从业务角度看到的是各个功能模块。

* 软件元素之间是有关系的，这些关系是架构的一部分。翻译成人类的语言：每个角度看到的内容都不是单独存在的，而是相互依存的。从部署角度看到的服务器是多台服务器，每台服务器都有职责，在系统工作的时候会相互通讯；从业务角度看到的各个功能模块也不是完全独立的，它们可能会有相同的依赖（比如都依赖认证模块），也会相互依赖（比如购物车模块依赖订单模块）。

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

什么是好的架构

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

高大上的设计

恩，被这个牛B的造型震惊吗？造型美观，价格便宜，还采用了独特的天窗设计。

低小下的设计

这个简直不能用设计来形容，直接就“实现”了，根本没有设计图。

我的评价

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

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

* “高大上”的架构师没有意识到鸡是一个恒温动物，根本不怕冷，只怕热。只要不淋成“落汤鸡”，室外多低的温度对它都是无所谓，反而“热”是它最讨厌的事情。

* 架构师没有意识到，鸡最怕的动物是“黄鼠狼”。基本上出现黄鼠狼的地方鸡必然是“死无葬身之地”，这个设计中“房子”的造型很别致，但是门是开着的，方便了鸡也方便了“狼”。即便修改设计，改成密封的那就更要命了，鸡肯定不会住进去的，因为它们——怕热。结果是住在外面，直接被黄鼠狼连窝端掉。

* “高大上”的设计中没有任何“餐厅”，怎么喝水？怎么吃东西？你不会指望鸡满大街跑吧？那要鸡窝还有什么用？

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

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

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

如何成为架构师

可能你已经意识到了，一个优秀的架构师一定是经历过战场的硝烟的老兵。萌芽于程序员，成长于高级程序员，最终在战火的洗礼下蜕变成一个拥有“广度和深度”知识机构的架构师。（当然你把这个词玩坏了，非要说售前咨询也叫架构师那也没办法，在上面的定义中架构是技术实现而不是夸夸其谈。一个没有参与实现的人没资格讲架构。）

架构师的基础一定是一个程序员，因为架构在很多情况下是一个人或者以一个人为核心的小组完成的（更多的情况是一个人完成的）。架构师服务的是程序员（如果服务的是领导，那么他就是“销售型架构师”）一个完全不懂代码的人很难做到这一点。

架构师的知识结构最重要的是深度和宽度，你看到的是一段代码，他已经看到这段代码在执行，执行的时候如何变成CPU指令，如何使用内存，如何使用网络，网络数据包是什么结构，对端如何解析…………。其次是“判断力”，他们会判断什么时候应该做什么样的设计，永远不会说——“别人是这样的，所以我们也应该是这样”，“这个技术好火，大家都在用，我们也应该用。”

架构师是很尴尬的位置，对他输入的是“理想”，他输出的是“实现”。“理想”往往是美好的，但是资源始终是有限的；在有限的资源下如何平衡“实现理想”是一件既要照顾“理想”，又要照顾“现实”的事情。

欢迎关注公众账号了解更多信息