架构设计—缘起

        汗明见春申君，候闻三月，而后得见。谈卒，春中君大说之。汗明欲复谈，春申君曰：“仆已知先生，先生大蹊矣。”汗明慨焉曰：“明愿有问君而恐固。不审君之圣，孰与尧也？”春申君曰：“先生过矣，臣何足以当尧？”汗明曰：“然则君料臣孰与舜？”春申君曰：“先生即舜也。”汗明曰：“不然，臣请为君终言之。君之贤实不如尧，臣之能不及舜。夫以贤舜事圣尧，三年而后乃相知也。今君一时而知臣，是君圣于尧而臣贤于舜也。”春申君曰：“善。”召门吏为汗先生著客籍，五日一见。

        能像汗明先生这么厉害固然可喜，不过达不到这种高度也尽不可自卑。亦步亦趋，从头收拾，能到自己所到的高度也就足了。在经历了一场从framework到architecture，从SOP到resource poll的对话后，我才发现我的思维是如此的混乱！这里面不仅仅是答非所问的事情，更深切地还是暴漏了自己的思维混乱，理解片段化严重，缺少了一条明显的主线，说的文绉绉一点就是知识没有体系化。

        如果单从技术上来说，现在急切的需要就是对这么多年的经验教训进行一次系统化的组织、表述。或者说是自己对软件设计的整体认识到底是什么，自己的设计理念、设计方式、设计风格是什么！作为一个开发者别人不了解这些当然无所谓，但是作为一个设计者和指导者，那么这些很虚的东西其实很是重要的。思想认识的统一才是齐步走的前提。

        言归正传，架构到底是个什么东西？就自己理解而言，无非就是自己设计理念的一个抽象，是自己对这个事务构成的一个解构，把它用抽象的文字描述出来再用来指导具体的工作，就是所谓的架构。形而下之就是一个人处理问题基本套路和思维定势，或者说是法则也不未过，就好比建筑学中的营造法式一样，在软件中就是那经典的二十二种模式；形而上就是所谓的面向对象、面相过程，面向函数的理念，好比建筑中讲的风水，宜居等理念。这么说架构或许有些偏激了，但是也能八九不离十的表达出笔者对架构的看法。

       我们先从形而上的方式来看架构设计过程中的三个经典步骤，逻辑架构、部署架构和设计架构。

        逻辑架构：从面向对象的观点来看主要是在于识别出当前这个业务的主要参与方，以及这些参与方进行了怎样的活动，从基于对象的观点来看，大部分时候我们是从当前业务的角色去进行区分；从面相过程的观点来看主要是我们目前遇到了或是要处理什么样的问题，这些问题又是由那些子问题组成的，各个问题之间的是怎么相互影响的；从面向函数的观点来看则是这个业务都是那些数据支撑的，这些数据的来源在哪里，都经过了哪些环节，变成了什么样的输出数据。或者我们要拿到一个特定的输出数据需要对原始数据进行怎样的加工处理。他们之间有什么明显的优劣之分么？

        部署架构：如果采用了面向对象的观点来对系统进行物理映射的话，最简单的方式就是每一个对象或者关系密切的一组对象部署在一台物理机上，对象和对象之间同过本地或者远程调用来进行相互协作；如果采用了面向过程的观点来对系统进行物理映射的话，映射到具体物理机上的则是一个或者多个子程序，子程序和主程序之间同本地或者远程调用来进行相互协作 ；如果采用了面向函数的处理方式，映射方式也大同小异，总之就是按照数据源、处理过程、数据终点等元素进行部署。这是不是和所谓的SOA很是相似？实际上无论采用那种方式对业务系统进行结构，当系统的复杂程度超过一定范围后，采用的部署方式都是基本类似的，即通过大规模的并行处理方式来解决。双拳难敌四手，这在物理世界是永远存在的真理。

        设计架构：设计架构在很大的程度上是对逻辑架构在进行重新表述后加上对部署架构的妥协产生的一个折中描述。在这个阶段考虑的最多的是各种限制条件，其实已经和业务本身的关系不大了。比如软件运行的硬软件支撑环境，软件开发者的组成和素质，软件本身的预算成本等客观因素。

        这些形而上的概念，一般来说，作者概括的困难，读者读的也拗口。而从形而下的方式来看架构设计过程中这三个经典步骤的考虑方式也不会轻松很多。但是相对形而上的空泛之谈，形而下的设计及方式可操作性其实是很强的，总的来说就就是对现场业务进行还原，梳理。然后看看和设计模式中的那些模式比较相似，但总体来说，现场实务大都是一组模式的一个复合，需要我们进行分解和二次重组。

        软件设计是一个抽象的事件构建过程，而架构设计本身则是对这个抽象工作进行进一步抽象和还原。缘起里面很空泛，也很抽象。两个原因，一是笔者的文字驾驭能力，而是笔者的理解能力。在后续的章节中笔者将会有一些实际的工程案案例来从不同的角度来分析各种方法的优劣。