技术相关：我们需要什么样的架构师？

技术相关：我们需要什么样的架构师？
----王珏原创

   架构师，当下流行的一个名词。可是当下对架构师有太多的误解，这种误解来源于对“系统架构”本身的误解。
   
    什么是系统架构？RUP文档中有如下描述：
    在“软件构架简介”中，David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”[ GS93 ]

    但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中 的最高层概念”[IEEE98 ]。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

在 Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

RUP的定义并不太好理解，但在RUP文档却到处能看到架构的内在意义（这些我们回头再说）。我认为系统架构应该包括如下特点：
    1、适合业务需求。－－－RUP的架构视图包括用例视图也是这个意思。
    2、适合现有的条件，包括用户环境和开发环境。－－－RUP的架构视图中包括部署视图也是这个意思。
    3、要有足够的弹性，这主要针对非功能性需求而言。－－－RUP中不断强调要有备选架构也是这个意思。

    当下系统架构有“同质化”倾向，换句话说就是一提到“架构”就是j2ee,然后就是hibernate、struts、spring或者是各种各 样的应用服务器JBoss，Geronimo，GlassFish等等，似乎这就是“架构”。这种思想混淆了“架构定义”和“架构实现”。直接导致的错误 就是：
    1、忽略了“业务需求”，这种“万能”型的架构和业务需求基本没有任何关系了。无论你是开发ERP系统，还是财务系统，银行系统，甚至是“网管系统”都采用这些“万能”型   的架构。业务需求在架构中不能体现，当然架构也无法保证业务需求的顺利达成。
    2、忽略了“现有条件”。架构是要人来实现的，项目组中具备这种技术储备吗？部署的系统是Windows还是Unix，是多CPU系统吗？是64位系统吗？有足够的内存吗？似乎“万能”型架构把这些条件也统统忽略了。
    3、忽略了“性能弹性”，“安全性弹性”。一个最常见的例子就是，由于前期估计不足，或者是错误，当并发数一旦突破某个数值，导致性能严重下降，而由于所谓的“系统架构”的先天不足导致整个项目的失败。

    我们现在常常能见到这样的系统架构师：
    根据对于上述针对架构的说明，我们 不需要 这样的“系统架构师”：
    1、“甩手型”系统架构师。这种架构师在当下最为流行，因为架构师总是那么稀缺，导致他不屑于做编码工作。我们的项目组总是有一个或几个系统架构师，由他 搞出一个概要设计说明书，以及一个所谓的系统架构。然后这位“系统架构师”就被抽调到其他项目组去做“系统架构”工作了。无法落实的架构，是空中楼阁。项目组需要的是好的架构实现，需要的是“结果”。

    2、“技术先锋型”架构师。（暂且不论这些架构师是不是真的技术牛人）这些架构师也在当下大行其道。基本表现就是，现在流行什么技术，就使用什么技术，不断追逐技术潮流。昨天ejb，今天spring，明天Ruby on Rails。昨天tomcat，今天jboss，明天geronimo。反正什么新奇用什么，什么流行用什么，忘记了最最根本的“业务目标”，忘记了项目组开发人员是否能够熟练使用这些新技术，甚至忘记了这些新技术存在的弱点。

    3、“纸上谈兵型”架构师。这种架构师也不在少数，他们在“面试过程中总是能够脱颖而出”继而占据“系统架构师”这个职务，他们根本不去做实验，根据他们 了解来的一些只言片语，就说JBoss集群如何如何好，jdbc连接池效率如何高过普通连接，说某方案如何能达到每秒多少亿次的搜索等等。空说是这些架构 师的基本特点，但他们确实很“吃香”。

    我见过在某架构师在一台有8G内存的PC服务器上按照了32位的Linux，又安装了32位的Oracle，结果那台服务器就只好把内存空闲着了，啥也不能干。
    我也见过某架构师把存在大量“插入事务”的Oracle安装在RAID 5上，结果天天抱怨Oracle慢。
    我同样见过某架构师设计了数据库模型，竟然忘了设计索引。
    最最让人尴尬的事情是，这些架构师根本没有想到过上述问题。而这些看起来最最基本的东西，却实实在在的决定了一个项目的成功与否。


    项目组 需要 这样的架构师：
    首先，此人有深厚的技术背景。系统架构是整个系统的架构，要以能否取得最终结果判断架构是否成功。这个架构师需要知道Unix和Windows的本质区别，知道小型机和PC服务器的差异，知道不同RAID的特点。知识全面远比在某方面有专长对于系统架构更加重要。

    其次，此人要求能够了解业务需求，能够设计出“最简单的方案”来达成业务需求。这个“简单”包括对于当前项目组的人员来说，这个技术足够“简单”，项目组 其他成员能够很容易的开发。这个“简单”包括对于系统的安装部署而言，足够简单，使得在不太损失系统性能的前提下，工程人员能够容易的安装部署。总而言 之，他设计的架构是“权衡各方面利益”的前提下，“最适合”业务需求的技术架构。并且在业务需求发生可预见的变化时候，他的架构依然能够顽强的生存下去 （足够的弹性）。

    最后，这个架构师必须是一个很好的“老师”，他能够把他的思想“教”给项目组的其他同事，把这个架构确实的贯彻下去。不能够贯彻执行的“架构”又有什么用呢？  

王珏原创