#legoo内核# 准则四：使用配置提高杠杆效应

为什么80%的码农都做不了架构师？>>>   

       现在的计算机发展可谓是一日千里，特别是我在工作中，总是抢计算机的工作，无法让计算机加倍努力工作，让一切都变的自动化，例如在 程序的持续集成方面，至少我还用认为干预的模式，目前有很多持续集成的例子，可惜我都没有很好的去利用。所以，我工作的很大一部分让我觉得是实在浪费时间。让一切都变得自动化，这是软件设计上的一种理想，这种理想的建立是基于一种对代码的高度抽象，剥离可变的环节，从而实现的“人为”意义上的自动化，也就是说，计算机的工作必须通过人们下达指令给他，但这种下达指令的环节不是程序员完成，而是由真实的最终用户自己去完成，从这种意义将，个人觉得架构设计已经达到一种比较产品化的一种路线了，把选择权交给用户而不是固话的一种模式。然而作为实现上述文字的一切，都是建立在可配置化的基础之上，这也就是这边文章所要讨论的命题：如何让配置更好地发挥杠杆效应。

        在开始讨论之前，许多程序员是比较排斥这种做法的，甚至有点对此不屑一顾的态度，在他们看来，配置文件是非程序员技能的体现，能用代码完成的工作为何要用配置化的一种模式去实现呢？这样子对程序的效率会大打折扣。也许有的程序员对配置文件的动态化感到头晕，必经配置的文件一旦达到一定数量就会显的难以维护（加入缺失必须注释的话）。从这种意义来讲，也许是成立的，因为在Java的世界中，配置与代码是很难割舍的，特别是因对一些比较成熟的引擎、容器，更加离不开配置，例如 jbpm 工作流引擎，基于SOA模式一些中间件，都是基于配置完成其工作的，如果没有了配置，这些中间件也失去他魔力般的光环。 我本人其实也是不赞成用大量的配置去代替变化，因为这样的确有点本末倒置的感觉，配置的引入需要一定的经验去积累，例如中国太极的四两拨千斤一样，在合适的位置引入配置，将会为你的框架带来更加灵活的特性，从而支撑更加多变的业务。抑或吧业务的控制权交给用户。

        配置文件一般都是基于XML格式来描述定义，通过程序预先加载抑或运行是动态加载，按照其配置指令顺序进行执行，直到其结果的产生输出，为结束。用一种比较极客的眼光来看待，其实我们写的每一行代码 对于 JDK编译器而言，都是配置，而这种配置是开放给程序员的，而非用户，如此推广，程序员开发的成果，对于用户而言，也可以为用户提供这种配置化编译的过程 ......... 如果作为架构师，你一旦建立这样的一种架构思维，那么你的内核设计，就要向操作系统那样去进军了，摆脱传统的3层架构、四层架构模式，对你而言，所有的都是指令集合，你的内核是对指令进行编译处理，摆脱这种架构分层模式，更多的你要考虑指令编译过程的性能以及指令的分支处理以及指令之间的通信，想我本人也是发展历程，也是从J2EE典型的3架构，过渡到4层架构，到现在，我对分层架构有了更要层次的一种认知，那就是渠道层与服务层、指令层、内核层 （目前先这样划分）
    渠道层：也就是数据采集层，是程序获取外界输入的一种渠道，可以是表单、ftp、email、webservice、socket 。。。。。仅仅是作为一种渠道而存在。
    服务层：是对下一层指令进过配置后的具有业务意义的流程，该流程实现用户的一些业务模式。
    指令层：这一层分布的都是独立、分散、解耦的一个个独立的指令集合。
    内核层：对服务层配置的指令集按照既定的模式去编译执行，直到该流程的结束。

而传统的4层架构是：界面层、控制层、服务层、数据层。贯通这四层的是vojo抑或pojo。如果作为架构师，你是用这四层模式去架构的话，那你很难达到配置杠杆的效应，任何事物他的结构决定他的作用范围。而整个程序的模式也发生了变化：
     用配置模式的编码思维是   思考---->编辑  ----> 测试
     传统模式下的开发模式：思考 ---->编码 ---->编译 ---->测试
      这种两种截然不同的模式，这就是引入配置杠杆后带啦的一系列的连锁反应。问题的核心来了，那就是架构师作为内核代码的编译角色，如何提高对流程指令的编译效率是应该重点去考虑的，至于业务模式如何如何，是项目经理以及非架构角色程序员所要考虑的。让架构师从业务中摆脱出来，到目前为止，依旧很多人用一种怀疑的眼光来看待我，因为我觉得架构师完全可以不了解业务，当然软件架构师可以分 业务架构师与技术架构师 两种，我说的技术架构师这一角色，也就是指令层与内核层 架构而言，是大可不必了解业务，因为在这一层看来只有指令与内核编译，只能做到如此明确的切割，才有可能把事情做到极致，业务架构师是基于 渠道层与服务层，这一层的话，则可能需要了解业务的大概。事项一下，任何一家商业化的SOA中间件 有用户使用的业务考虑吗？没有。数据库的设计只有考虑过用户的业务架构吗？没有。但是他们把这个权利开放给力用户。让用户自己去维护去配置，不知道我的观点是否足够的明确，配置的杠杆效应是从这个角度思维去看待问题的。

      它是建立在指令、编译、指令组装的基础之上的一种配置模式。

     作为XML作为配置文件的不二选择，第一是他的可移植性，另外一个就是他的规范性与可读性，XML可以通过XSD对其进行严格的数据校验，提醒用用既定的配置规则进行配置。
      我们在映射到目前的linux操作系统，他就是一个很好的说明，linux的系统最让人头晕的i就是成千上万的指令，但是正式这些指令的独立性，才给linux带来一种惊奇的灵活性，那就是 shell，shell就是通过一定的规则对指令集的不断调用，而linux内核则是针对shell这种配置的指令不断的进行解析 执行。从而演绎出linu世界的无穷无尽的需求。
      
     现在的技术路线我更加偏向于SOA的模式，也许是我这一年来从事soa的产品架构有点技术倾向了，当然 soa定位是服务，但是大的同样适合小的模式，那就是基于我们普通业务流程一样的soa架构模式。其实  soa的这种架构模式，在工业制造中早已成为一种标准，而在软件行业在是一种 摸索的一个过程，我说的不是soa的标准，而是soa的使用，到目前为止 大部分仅仅停留在一种 因soa而soa的境界，而非总本质上去soa 自家的产品设计。

     // end this ............

    今天外面风和丽日~~~~~~~~~~ 呆在家里 感觉自己多对不起如此美景，决定下去取出去走走，没有目的的散步   最次也可以欣赏一下插肩而过的各种美女  嘿嘿~~~~~~~~~~~ 

转载于:https://my.oschina.net/qfhxj/blog/194176