#legoo內核# 準則四：使用配置提升槓桿效應

       如今的計算機發展可謂是一日千里，特別是我在工做中，老是搶計算機的工做，沒法讓計算機加倍努力工做，讓一切都變的自動化，例如在 程序的持續集成方面，至少我還用認爲干預的模式，目前有不少持續集成的例子，惋惜我都沒有很好的去利用。因此，我工做的很大一部分讓我以爲是實在浪費時間。讓一切都變得自動化，這是軟件設計上的一種理想，這種理想的創建是基於一種對代碼的高度抽象，剝離可變的環節，從而實現的「人爲」意義上的自動化，也就是說，計算機的工做必須經過人們下達指令給他，但這種下達指令的環節不是程序員完成，而是由真實的最終用戶本身去完成，從這種意義將，我的以爲架構設計已經達到一種比較產品化的一種路線了，把選擇權交給用戶而不是固話的一種模式。然而做爲實現上述文字的一切，都是創建在可配置化的基礎之上，這也就是這邊文章所要討論的命題：如何讓配置更好地發揮槓桿效應。

        在開始討論以前，許多程序員是比較排斥這種作法的，甚至有點對此不屑一顧的態度，在他們看來，配置文件是非程序員技能的體現，能用代碼完成的工做爲什麼要用配置化的一種模式去實現呢？這樣子對程序的效率會大打折扣。也許有的程序員對配置文件的動態化感到頭暈，必經配置的文件一旦達到必定數量就會顯的難以維護（加入缺失必須註釋的話）。從這種意義來說，也許是成立的，由於在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 ............     今天外面風和麗日~~~~~~~~~~ 呆在家裏 感受本身多對不起如此美景，決定下去取出去走走，沒有目的的散步   最次也能夠欣賞一下插肩而過的各類美女  嘿嘿~~~~~~~~~~~