canonical

     分布式有幾個核心問題。首先不存在全局的狀態空間，各個節點上的狀態可能不統一，節點之間的通信需要通過序列化等方式跨越狀態空間邊界。一般只有只讀數據 才能做到真正的分布式，因為只有只讀數據才能維持各個節點之間的一致性。第二，節點之間的信息傳遞都是單向的，不存在test_and_set這樣的鎖原 語（test_and_set需要同時信息雙向流)。如果需要建立分布式鎖，必須存在中心協調者,即存在著瓶頸。
     最近很流行的幾個概念涉及到分布式的不同方面。

 。grid技術主要處理分布式節點的自組織結構

。 web service采用xml技術，實現異步分布式調用，并且因為采用xml這種元語言，將人的智能整合到系統調用層面。即遠程調用的可能是一段程序，也可能是通過一個用戶界面接收用戶輸入，然后將用戶輸入作為web service調用結果返回。

。workflow 捕獲自治節點行為之間較為短暫的聯系。存在一些程序步驟之間的“瞬態"關聯，它們沒有穩定到可以抽象出一個程序中的對象，但可以建立一個過程處理模型（整 合的關鍵是無參數調用，或者更準確地說是只存在一個全局變量空間，都從該空間中得到輸入，并輸出到該空間）

     理論物理的優美在于從少量基本原理（如最小作用量原理）出發推導出整個理論大廈。而在軟件設計領域卻充斥著林林總總的"最佳實踐". 太多的規則只會意味著沒有規則。軟件設計領域的現狀說明這個領域還處于非常稚嫩的階段，應該從其他領域借鑒更多的知識。在我前面的blog中已經說明了在 軟件中的一些具體的分析技術。但如何有效的應用這些分析技術，我們還需要一些指導性的理論框架。如果把軟件設計放在更加廣泛的系統工程的背景下，一個合適 的支配性原理應該是最小復雜性原理。即在軟件分析過程中我們所作的一切，無論是面向對象分析，基于工作流的分析等等，其目的都是盡量降低系統構建的復雜 性。只要能夠有效降低系統構建的復雜性，那所采用的方法和所建立的模型就是好的。復雜性是唯一的度量，而不是是否符合某人的觀點，是否采用流行的技術等 （當然，采用流行技術往往意味著降低了和其它系統交互的復雜性）。
     李小龍說：簡單是美。但是否最簡單的就是最好的？科學界對此卻有著否定的結論。關于復雜性的一個很深刻的基本事實是，復雜性是分級的，不同復雜性層次的事 物有著本質的差異，不能期待一個較低復雜性的方法能夠解決一個更高復雜性層次上的問題。所以Einstein說：make everything as simple as possible, but not simpler。復雜性級列的存在意味著，隨著我們獲取到更多的信息量或者因為系統自身的發展，當我們所建立的系統的模型沿著復雜性級列演化的時候，我們 所提出的解決問題的方案也必須作相應的演化。即我們提供的不是一些固定的解決方案(solution),  而必須是一個完整的策略(strategy)。這樣我們就不是孤立的看待一個問題， 而是要看到它的過去，現在和未來。
     在作分析的時候，我們都知道"從一般到特殊，從特殊到一般"，但如何科學的，有步驟的去做呢? 我從等離子體物理的BBGKY Hierarchy中學到了一個基本的分析框架： 級列理論.這個理論首先定義了一個最普適的模型：氣體由N個完全相同的原子組成， 其動力學由N個互相耦合的Newton力學方程來描述。理論的第二步是從最極端的簡化開始，假設所有的原子之間不存在相互作用，即假定原子之間是相互獨立 的。則得到Vlasov方程。理論的第三步考慮系統的復雜性逐漸增加，當氣體密度較高，必須考慮分子之間兩兩碰撞的時候，得到Boltzman方程。當需 要考慮更高階的相互作用的時候，我們得到關聯動理學方程，如此繼續下去建立一個無窮級列。
抽象一些地說，該理論包含如下內容：
. 建立能夠描述所有情況的最廣泛的模型M0, 該模型定義系統的邊界
. 建立一個包含最少假設的最簡單的模型Mn，該模型作為求解的基礎和基本的參照。
. 建立一個從Mn到M0的復雜性逐漸增加的模型級列，確保在每一個復雜性的層次上，都存在著對系統有效的建模，而且在求解高階問題的時候，可以參考較低階問題的解。
   如何從這種無窮級列中做出選擇，必須根據具體應用情景而定，Vapnik在其統計學習理論中詳細描述了這種求解策略：
 綜合代價 = 訓練數據與模型預測之間的偏差 + 模型自身的復雜性
    學習 = minimize[綜合代價]
即在能夠解決問題的方案中選擇最簡單的一個。

 建立級列理論，首先需要建立最廣泛的模型。在量子力學中，確立了如下基本概念：
 1. 確定性的態。
 2. 所有態構成完備的態空間。
 3. 系綜(即態的集合)的動力學。
   首先，狀態的確定性非常重要。即使在量子力學中，量子態存在幾率詮釋，態函數本身在數學上仍然是確定性的，即在任一時刻，任一地點存在唯一的值。如果我們 的討論沒有一個確定性的基礎，那所有的推演都將變得極為困難（模糊數學目前提供的幫助很少）。而且確定狀態本身就是一個極為重要的簡化過程。因為一般我們 可以建立Markov模型，使得系統的演化只與系統當前的狀態有關，而與系統的歷史狀態無關，因此大大減少系統模型的參數。
   其次，狀態演化的結果必須仍然處在態空間中，否則我們在該空間中建立的理論就存在著"盲點"，存在著失效的可能。
   第三，我們研究的不是單個狀態的演化，而是綜合考慮相鄰的狀態。
   在軟件世界，理論物理的這些真知灼見依然有效，只是在所有的概念前加上了"有限"這個修飾語。有限狀態機(Finite State Machine)正是理論計算機科學研究的基本模型。所有的計算機都可以看作是有限狀態的，因為所有的內存和硬盤能夠表示的狀態數是有限的。目前計算機科 學中幾乎所有重要的理論成果都和有限自動機理論相關。在軟件編制的過程中，我們第一步所要做的也是確定系統的狀態。與物理系統所不同的是，我們認為物理系 統的狀態及其演化規律是客觀存在的，而軟件系統中的規則是由開發者確立的，我們必須盡一切可能使得系統的狀態能夠被確定下來。例如，我們編制getXX ()和toString()等函數來暴露系統的狀態，以確保系統狀態的可觀測性；使用assert斷言來確保函數執行時的狀態；盡量減少函數的副作用來避 免依賴函數調用歷史。軟件世界中態空間不完備的例子最著名的就是Y2K問題。所以很多人說，軟件中最大的bug就是地址空間不足，因為這是任何技術手段都 無法解決的問題。

對象本質上是一種命名技術，即將一組相關的數據和函數放在一起，起一個名字。從業務層面上看，我們需要識別出大量的概念，對應到建立的領域模型，我 們就擁有不同的業務對象。這些業務對象的類型各不相同，可以區分出來。從中間件層面上看，需要從大量業務對象中抽象出共性，并以統一的方式進行處理。即在 中間件層，所有業務對象的類型被弱化下來，實際上喪失了其各自的獨特性，即在中間件層看來，這些不同業務對象的類型是相同的。在中間件層的做法，一般是使 用reflection方法并結合少量全局性的接口。實際上是在結構層面上將對象作為Map來處理。這就象是應用科學與數學的關系。數學在抽象的層面上研 究結構之間的關系，每一個具體學科對相同的數學定理賦予不同的詮釋。
 理論上，一個概念最好能夠自適應的在不同的抽象層面上表現為不同的結構，但 受限于當前的面向對象實現技術，實際采取的技術路線多半為建立唯一的強類型模型==>通過reflection得到弱類型結構。因為java class作為元數據能夠承載的信息量有限，reflection方法可能并不能充分揭示對象的結構，所以一般還要額外補充xml說明文件等。 因為我個人主要的工作都作在中間件層，所以我的做法是盡量使用Map和List等抽象數據結構，結合元數據對象，在需要強類型的時候通過對象封裝來轉化為 強類型。即從弱類型==>強類型。
例如：
class Work{
 public static final String KEY_NAME = "name";
 public static final String KEY_DESCRIPTION = "description";

 Map work;

 public String getName(){
  return (String)work.get(KEY_NAME);
 }

 public String getDescription(){
  return (String)work.get(KEY_DESCRIPTION);
 }

 public void setName(String name){
  work.put(KEY_NAME,name);
 }
...

 public Map toMap(){
  return work;
 }
}

JMX在技術上的需求可以說是將管理功能從功能性接口中分離出來。
例如一個緩存接口
interface ICache{
     Object get(Object key);
     void put(Object key, Object value);
}
但一個具體實現類可能有很多參數可以調整，如緩存的最大尺寸等。這些可配置參數一般與具體實現緊密相關，即與實例相關，而不直接涉及到所要實現的功能。例如實現類可以具有setMaxSize()和getMaxSize()方法。
如 果這些配置方法在功能接口中定義，就會造成功能接口的臃腫和不必要的與實現方法之間的依賴。如果直接調用實現類的方法，只能使用reflection， 但是java class作為元數據所承載的信息量有限，需要外部定義一個規范來補充信息。JMX就是這樣的一種規范。

     分析學的離散形式是分而治之(Divide And Conquer)。 這一思想在軟件設計領域的重要性不言而喻。 大系統分解為小系統，小系統分解為模塊，模塊分解為對象，對象分解為函數，函數分解為增刪改查等動詞和集合/個體等名詞，如此遞歸下來。 在很多關于軟件的"最佳實踐"中，都列舉了這種分解過程中的注意事項，如高內聚，低耦合等。 但是為什么要強調這些概念，誰能保證這個checklist是完整的， 具體實踐過程中又當如何去做？ 我們能否跳出軟件的圈子，利用軟件領域之外的詞語重新表述一下這種思想？將大的系統分解為多個小的系統之后， 因為系統規模變小， 處理起來一般會容易一些， 但這是否就是分析學的全部？
     有一個小故事，說有人問一個科學家，如果地球文明將要毀滅，只有一句話可以傳給后人，那他最想告訴后代的是什么。那個科學家回答：宇宙萬物都是由原子組成 的。分析學的哲學基礎是還原論，原子論可以說是數千年來還原論最輝煌的勝利。原子論也清楚的向我們揭示了分析學的奧秘：千變萬化僅是事物的表象，分解之后 它們都由同質的基元構成。在分解的過程中，問題的規模越來越小，問題的數目似乎越來越多，但當問題空間因為某種原因"塌縮"的時候，分解后的子問題出現大 量的重疊，整個問題的復雜性出現了本質性的降低。FFT和動態規劃算法中所采用的也正是這種從異質到同質的解決方案。
      分解之后，我們希望得到的子系統是低耦合的，那么最好是完全不相關的，我們希望得到的子系統是高內聚的，那么最好是不可分的，在數學上，我們稱之為正交。 還原論最完美的載體是線性世界，而線性代數(或更廣義的群論)說了，線性系統完全由其正交的特征向量所構成的"核"(kernel）來刻畫，那大體上軟件 系統應利用少數可重用的模塊來構建。但線性代數又說了，特征向量的選擇方式是無窮多的，而且完全等價, 那大體上軟件系統的分解方式也是多種多樣的， 多數很難分出優劣。  線性代數還說， 特征向量個數僅由系統的維度（系統復雜性的一種度量）來決定， 那大體上軟件系統無論怎么分解， 總有一個復雜性的下限。過分簡單的架構僅能支持過分簡單的應用。線性代數沒有明說，但潛在的表達著，特征向量的地位是平等的，所以在高內聚，低耦合的基礎 上，軟件分解的原則中至少還要增加一條：對稱性, 以維護系統整體結構的平衡。
      很可惜，現實世界中發現了越來越多的非線性現象，以致于非線性研究本身已經成為了一門獨立的學科。不過，古老的教誨仍然有效，分解可以幫我們找回系統的線 性。在微積分所描繪的極限情形中，外力產生了加速度，然后加速度產生了速度，因與果就這樣實現了分離。（有人說，重整化方法在微觀世界的成功正是因為在極 度糾纏的臨界情況下微積分失效了，也許有些道理)。

      為了在軟件中實施分析學，我們需要一些技術手段。首先，需要一種命名機制，使我們能夠在思想中定義概念，并開始建模。所謂的對象，正是這樣一種機制。可以從以下的級列關系來理解這一點
1. 高級語言規定了數據的類型，使得我們可以為不同的內存塊指定不同的數據類型，從而在概念上對它們作出區分。
2. 當程序變得漸漸復雜起來，C語言提供的Struct結構體，使我們可以創建新的數據類型，可以將一組相關的數據放在一起，起個名字。而如果沒有 結構體，這種相關性就無法直接在程序中得到表達，必須紀錄在文檔中或者程序員的思想中。
3. 對象(Object)是比結構體(Struct)更加強大的命名機制，它可以將一組相關的數據和函數放在一起，起個名字。而且通過封裝和虛擬函數，一個對 象類型所表達的 不僅僅是它自身所代表的概念，它同時表達了它的派生類所具有的特征。即對象所表達的是一個概念的集合而不是一個單獨的概念。
4. 更復雜的程序中，對象之間的相互作用產生了某種確定的特征，出現了設計模式。
5. 這個級列的下一步是什么？

       對象化沒有什么神秘的地方，它只是使我們擁有了一種表述的工具。有時對象化比不對象化更遭，因為我們極有可能犯命名的錯誤。

     在沒有對象的概念的日子里，我們無法命名數據和函數的耦合，一些概念也就無法在軟件設計中得到自然的表達，因為它們在程序的世界中沒有名字！一旦我們能夠 命名系統中所有的概念，一扇門就被打開了，大量的可能性被發掘出來，形成了今天的面向對象技術。這其中最重要的就是軟件中的正交分解技術。首先是繼承。在 早期的C程序中，經常出現如下的代碼：
if a then
   a_work_1();
else if b then
   b_work_1();
end
…
if a then
   a_work_2();
else if b then
   b_work_2();
end

通過繼承，我們可以捕獲以上程序中的關聯性，代碼被改寫為如下方式
x = a or b;
x.work_1();
…
x.work_2();

但作為早期最主要的面向對象技術，很快繼承這個概念就不堪重負。通過繼承，系統中的所有關系被組織成了一個樹狀結構。隨著樹的層次越來越深，整個結構變得越來越不穩定，基類的小小變動隨時可能會造成雪崩似的影響。作為一個整體，對象也越來越難以被重用。

       此時，接口(Interface)應天命而生。從簡單的意義上來理解，接口可以被認為是對對象(Object)的正交分解。如果使用繼承，
class CHuman {
 public void eat(){..} // human eat
 public void sleep(){..} // human sleep
}
class CManager extends CHuman {
 public void fireEmployee() { ...} // manager fire employee
};
class CEmployee extends CHuman {…}
   公有繼承大致上對應于"is a" 關系， 即一種包含關系，在數學上稱為偏序(Partial Order)。
偏 序在邏輯上隱含的是一種推理，即我們可以根據基類的行為我們可以推論派生類的行為。所以當我們知道某人是經理（CManager)的時候, 我們可以推論出他是一個人，即他能吃能睡。很可惜，這種微妙的信息泄漏也許并不是我們所希望了解的，畢竟董事會雇傭一個職業經理人來為的是管理而不是吃 飯。
      應用組件技術，我們進行如下建模：
interface IHuman {
 bool eat();
 bool sleep();
};
interface IManager{
 bool fireEmployee();
};
class Manager implements IHuman, IManager{…};

Manager = IHuman + IManager

    接口打破了繼承所構建的僵化的樹狀結構，提倡靈活的網狀結構，使得整個系統結構扁平化，分解的粒度也更小。有了接口，是否就應該忘了繼承呢？不，推理關系仍然是重要的，只是不要濫用。

    最近幾年，面向方面編程(AOP)逐漸興起。從分解技術的角度上看，它代表了一個新的方向：形容詞與動詞的正交分解。例如，我們需要在一個事務中實現轉賬，
 實現轉賬這個功能可以很容易的編寫， "在一個事務中"這一修飾語被抽象出來稱為一個Aspect, 并單獨實現。通過AOP技術，我們將動作與所需要的修飾組合起來，完成所需要的功能。

      最后，談一談Reusablity這個概念.
軟 件設計是從需求領域到軟件技術實現領域的一系列模型映射，在每一個層面上都存在著多種正交分解方式。構建軟件的目的是為了滿足需求，所以整個映射過程應該 向著應用層傾斜。有一個說法叫做Object oriented to user, 我是從科泰世紀的陳榕那里聽來的。 我想這也正強調了從多種分解方式中作出選擇的準則。 可重用的對象意味著它更可能成為構建系統的"特征基元", 同時它的可用性隱含的表達了對應用層用戶的意義。 所以Reusability是一個比Objectlization和Encapsulation更為重要的一個概念。

    最近幾年關于模型的提法突然多了起來，但這個概念到底意味著什么呢。從哲學上說，我們的思想是外部世界結構在主觀意識中的反映，當我們把主觀意識再投射回 外部世界時，就得到關于外部世界的模型。所以，在最廣泛的意義上，模型不過是我們思維中的一組關聯。問題不在于我們是否需要模型或者什么東西是模型而什么 東西不是模型，我們所意識到的一切都是模型，無論它與真實情況的差距有多大。我們所能區分的只是什么是一個"好"的模型，什么是一個"壞"的模型。在面向 對象建模中，經常聽到人說XX是對象，YY不是對象。這是一種錯誤的提法。所有的東西都是對象，都是我們心智中可以操縱的符號。一張紙是對象，當它被撕成 了碎片，每個碎片也是對象。因為受力方式等隨機因素的干擾，信紙碎裂的方式也是隨機的， 最終造成的碎片也是隨機的。我們可以說信紙L這個對象由碎片A,B,C這三個子對象構成，也可以說L由碎片D,E,F構成。定義對象的方式實在是無窮無 盡。

     我們通過比較來認知外部世界。當我們面對一個不熟悉的概念的時候，我們總是在把它分解，重構為我們已經熟悉的概念以后才能真正的理解它。也許，我們只能理 解那些我們已經知道的東西！我們已在這個星球上生存了億萬年，以至于我們總可以將那些"新"的結構與我們的"先驗知識"做比較。只有當面對量子論和相對論 的時候，一個人才能真正意識到自己的知識是多么的貧乏，一種先天的貧乏。Cantor將比較的技術發揮到了極致，他通過比較區分了可數無窮大與不可數無窮 大，結果他瘋了。
假設現實有一個結構S, 我們的模型具有結構M。 當S（通過一定的簡化和拓撲變換)能夠與M匹配時，我們就說現實S被理解了。 更一般的， 我們從不同的角度或者在不同的層面上看待同一個事物， 從而形成模型M1, M2, M3,...   我們可以通過一條邏輯途徑M1-->M2-->M3-->S來理解S. 最好的模型應該構成到現實結構S的最短路徑。一個鮮活的例子就是數據庫。在von Neumann體系架構下，計算機能夠直接回答的問題是:存放在0x***地址的值是多少（M1)。而在現實中，我們經常需要回答的問題是：  值大于**的紀錄有那些(M2)。這些問題是關于變量的值的，而不是變量的地址。數據庫的價值正在于通過索引提供了M1->M2的映射。早期的層次 數據庫僅僅提供了一個中間模型H, H->M2的映射還需要程序員來完成，最終難免被淘汰的命運。一個模型就這樣創造了一個產業。
    模型映射的最短路徑意味著我們最好不要去創建那些"聰明"的新結構.在一個良好設計的系統中，我們不應該費力去"發現"什么或去認知什么。設計不等于創 造，一個最好的設計應該是抄襲成功的范例，最好是連改動也沒有，可惜現實的多變總要你多少作些改變。如果需要改變，最好是局部化的改變，在數學上我們稱之 為同態。如果在映射的時候，無法做到局域化，那往往意味著出現了一些本質的困難。例如html語言中的table元素。表格本質上是二維布局，而html 文本是一維的文本流，它們之間存在著深刻的差異。當某個表格單元的rowspan或者colspan屬性需要修改時，對應于界面表現只是一個局部調整，而 反映到html代碼中卻是全局的修正。xml決不是萬能的。
 
    某個事物被清楚的理解了，是因為我們對它已經有了一個完整的模型M，所以對已知的事物建模是相當容易的，因為我們可以從模型M出發，建立一個同態甚或是同 構的模型即可。所有的困難都在于如何對那些我們所知甚少抑或是一無所知的東西建模。按照Laplace的哲學，如果我們不知道什么是最好的選擇，那么所有 的選擇都是等價的。在用迭代法解方程的時候，通常的做法是拋一個隨機的初始解進去，只要控制策略得當，最終會收斂到正確的解上。一切并不在于選擇初始解的 啟發式策略有多么的"聰明", 隨機性才是創造性的根源，因為只有幾率才能打破因果的枷鎖。一個好的初始解一般只是縮短收斂的過程，但并不影響最終收斂的結局。
     一個模型首先提供的是一個術語體系或者說一個詞匯表，一種語言。使得我們能夠以一種一致的方式捕獲那些轉瞬即逝的思想。模型本身是否正確其實并不一定如想 象中的那么重要。一旦初始的模型建立，我們的認知就有了一個不斷發展和積累的基礎，最終就可能得到超越我們最初期望的結果。交流和表達具有根本的意義，優 劣與否只在其次。設計模式提出的時候引起轟動，到今天，當一切塵埃落定，它最大的貢獻也許只是貢獻了一批術語和模式名稱，讓大家可以在模式的框架下討論問 題。恰如陳省身的纖維叢理論。也許這個世界上最成功的建模案例是宗教。通過一次提問，誰干的，就把所有未知的問題一攬子解決了。偉大的簡化！借助宗教的術 語，我們創作了文學，紀錄了思想，傳承了知識，甚至建立了政治秩序。所以如果你不知道從哪里開始的話，那就隨便吧。