我所知道的软件架构

——兼谈软件引擎的概念 

 

前一久，跟朋友聊天，他强烈要求我写一些关于软件架构方面的文章，这几天总算有点时间来完成此事，算是给朋友交差吧。

首先声明，我不是软件架构方面的科班出身，也不是这方面的专家，只能算是这个方面的草根。这篇文章只是10多年来我在C/C++编程中摸爬滚打之后的一点经验之谈，谨代表个人观点，或为各位困惑人士提供点小小的参考。如有不同意见的欢迎来拍转。

对于软件架构，我认为这是一个贯穿软件宏观到微观结构的一个整体式的结构概念。甚至还可以说我们写代码的原初目的就是为实现一个架构。依照这种认识，下面我就按照从宏观到微观的一个顺序谈谈每一层次中软件架构的特点和需要关注解决的一些问题。

首先从最宏观的角度讲，一般需要决定一个软件大的架构问题，此时往往还需要了解或制定硬件的架构。这一层主要就是要确定你的整个软件是SOA架构，B/S架构、C/S架构，或者是单机版的问题，有时甚至需要指定为混合架构。此时就需要同时制定出相应的硬件架构，或只提出硬件架构的需求，或了解已有的硬件架构，再来更正架构的选择。

在上面这一层大的架构设定后，接下来就需要制定详细的架构细则了，但这步仍然被认为是宏观的。SOA架构目前比较火，我对他的理解就是把B/S应用分布化，最大限度的重用现有的B/S应用。在这个层次，比如你设定了B/S架构后你就需要制定你是多层的，还是3层的之类的比较具体一些的架构问题了。当然C/S应用也可以指定多层架构，甚至C/S应用也可以支持SOA，但通常有些人也习惯把Client到DBMS的应用成为C/S应用，这个问题值得商榷，我不太赞同这样的架构被称作C/S，但称之为单机应用也不妥，所以我干脆称之为数据库应用架构，暂时归入C/S一类吧。其实真正的C/S结构中，在服务端还需要有软件的，比如目前比较火的各种网络游戏，才是真正意义上的C/S应用。对于单机应用，到这时可以直接指定是基于模块化，还是纯粹面向对象之类的问题了。

在确定了B/S或C/S应用多少层的问题之后，就是细化层中模块或抽象功能的阶段了，我认为这是从宏观架构到微观架构问题的分水岭。这步就是根据具体的业务需要，设置每层需要的模块了，有时还需要制定详细的模块间接口或调用方式了。

到这时我觉得软件引擎的概念也该登场了，比如我们常见的脚本引擎，图形引擎，游戏引擎之类的。一说引擎，很多人都头晕，天天听就是没有一个准确的概念，我认为所谓的软件引擎就是具备一定特定功能的可编程的软件模块。在这个概念中两点值得注意：1、就是具备一定特定功能，比如脚本引擎，它的功能就是执行脚本；2、就是一定是可编程的，比如游戏引擎，很多游戏引擎都是支持脚本方式的编程，你只要写写相应的脚本，画画图片，或做做3D模型，一部游戏也许就可以完成了。（这个地方的游戏引擎例子中，可以广义的认为画图片或制作3D模型也是对引擎的编程。）

这种引擎化的东西其优点是非常显而易见的：首先它暴露一组可以编程的脚本化接口，可以应付各种因业务变化而引起的接口变化，相应的只需改写引擎间相互调用的脚本即可。其次他使得模块级的重用变为了可能（相应的类实现了对象级的重用），比如很多游戏都有可能出自同一款游戏引擎。

目前有很多的第三方免费的脚本引擎可以被使用，著名的有lua、python、tcl等。在windows平台上还有Windows Script引擎可供集成，它支持VCScript和Jscript。这些脚本引擎可以被无缝集成在我们自己的软件模块中，从而使我们自己的软件模块也“引擎化”。而且这些脚本引擎还有很多第三方支持组件和模块，它们中的大多数也都可以免费使用。但是这些免费脚本引擎的一个通病就是不支持UNICODE，本身是ANSI的，如果你的软件是UNICODE化的，那么集成这些脚本引擎就不得不进行频繁的字符集转换。我曾经想改写一个纯粹的UNICODE版LUA引擎出来，但是最终我放弃了这个想法，我发现这比教老外说中文还要困难。

       从另一个角度来理解软件引擎的话，就是可编程的接口（脚本），成为了各个软件模块间最好的粘合剂。使模块间的接口更加灵活并具有智能性（因为脚本就是人类智慧的结晶体）。有时候甚至脚本都成为了用户和软件间的接口。比如知名的AutoCAD软件，就有一套自定义格式的图形命令脚本，高级用户可以直接通过输入命令脚本的方式完成图形的绘制，同时这种输入方式的精确度和输入速度是鼠标操作方式望尘莫及的。

这种引擎化的软件架构我认为是目前最先进最流行最强大的一种模块级的软件架构。如果软件项目比较大并且模块比较复杂时可以考虑使用这种“引擎化”的软件架构，最大限度的提高软件的灵活性和适应性，变被动为主动。必要时甚至可以自定义一套编程脚本语言出来。

在模块这一层次之下，或更细化的一级我认为就该设计模式登场了，也许各种设计模式的铁杆粉丝该朝我扔砖头了，把他们奉为经典的设计模式归为软件架构的范畴，他们肯定是不怎么乐意的。但是不要急，大家都是受过高等教育的，咱们慢慢讲理（什么你是初中程序员？还懂设计模式？你简直是天才，这篇文章不适合你，你还是赶紧去当比尔.盖茨吧！）。如果仔细分析下各种软件设计模式，就不难发现，其实里面就是各种对象的结构以及对象间结构的经典范例。它规定了面向对象设计的一些经典结构，因此我就将他归为软件架构的范畴，因为软件架构本身就是研究软件各个层次中结构问题的。

在往下细分的话，就是各种软件类如何设计和组织的结构问题了，这方面没有什么经典的架构可供参考，但是有很多原则是被提倡的，比如不要使用多继承、保证成员变量的封装性，一切访问通过函数等。当然这些原则并不都是通用的，此时一些经验也许比原则更有用。而我在这一层是不遵从任何原则的，一起都是从实际需要出发，并参考一些设计模式的原则来实现我的类。好用才是硬道理！

再往下细分就到了最后一层，就是具体的函数算法如何组织和实现的结构问题了，算法不用说很多的算法书籍在讲解算法的同时也给出了很好的算法组织结构。而函数的结构就是通过那个被戏称做原始人在山洞的石壁上完成的流程图规定的了。当然很多程序员都情愿直接去写代码也不愿意完成这种原始人的工作，从这个角度讲程序员是严重的退化了，不是吗？

到此我对软件架构的整体理解，以及各个层次要注意的一些架构方面的问题就描述完了，当然这还不是全部的软件架构，这只是软件架构的一个入门，也许入门都不算，只是一个简介。还有很多的架构问题摆在我的面前，而我却没有重视，如果上天给我个机会，让我重来一次的话，……（此处省去若干字。）