理解公司專屬應用程式架構

轉自：http://blog.vsharing.com/sharptoolbox/A580795.html人們總是偏愛“大詞”。一個表達方式，如果聽起來足夠響亮，寫在紙上能夠吸引眼球，那就會變成很多人的新寵。但同樣是這些大詞，經過太多人的傳遞、消費之後，原本的含義反而像硬幣上的圖案一樣被磨損殆盡：幾乎沒有人知道這些說法到底是指什麼了。在IT業界，“平台（platform）”、“架構（framework）”、“構架（architecture）”等等就是這種人見人愛的大詞。幾乎每個廠商都願意請來其中的一位、甚至多位為自己推銷。久而久之，這些說法似乎適用於各個領域、各個層面：所有的軟體系統都是“平台”，所有的開發人員都在自矜於專屬的“架構”。原本有確切意義的“好詞”，經過這一番爭奪和濫用，也只能衰減為所謂的“buzzwords”，供市場營銷人士們玩味了。我想讓這些詞中的一個——“架構”——蕩汙滌垢，重現青春。要完成這樣的任務，必須動用重典才行。軟體業聖經《設計模式》對架構有如下定義：“A framework is a set of cooperating classes that make up a reusable design for a specific class of software（一個架構，就是一組相互協作的類，對於特定的一類軟體，架構構成了一種可重用的設計）”。這個定義雖然主要著眼於物件導向的軟體開發，但已經基本上給出了這個詞的核心含義：架構是軟體系統的設計、開發過程中的一個概念，它強調對以完成的設計、代碼的重複使用，並且，一個架構主要適用於實現某一特定類型的軟體系統。為了更好地說明架構是什麼，也許還應該看看架構不是什麼。架構不是現成可用的應用系統。它仍是一個半成品，等待後來者做“二次開發”，實現為具體的應用系統。架構不是“平台”。後者的概念更加浮泛和模糊——人們說的一個平台，可以是一種作業系統，一種應用伺服器，一種資料庫軟體，一種通訊中介軟體等等，因此“平台”幾乎成了所有系統軟體的統稱。在平台的大家族中，架構的概念可能與近來人們常說的“應用平台”最為接近，但平台主要指提供特定服務的系統軟體，而架構則更側重於設計、開發過程，或者可以說，架構通過調用平台提供的服務而起作用。架構不是工具包（toolkit）/類庫（library） /API。目前流行的很多架構中，就包括了大量的類庫和API，但是調用API並不就是在使用架構開發。僅僅使用API時，開發人員完成系統的主體部分，並不時地調用類庫實現特定任務。而架構構成了通用的、具有一般性的系統主體部分，“二次開發人員”只是像做填空題一樣，根據具體業務，完成特定應用系統中與眾不同特殊的部分。架構不是構架（architecture）。構架確定了系統整體結構、層次劃分、不同部分之間的協作等設計考慮。架構比構架更具體，更偏重於技術實現。確定架構後，構架也隨之確定，而對於同一種構架（比如web開發中的MVC），可以通過多種架構（比如Apache Struts或Apache Velocity）實現。 那麼，在公司專屬應用程式系統開發中，架構具有什麼樣的意義？要闡明這一點，大概要看一看在這個領域裡軟體開發方式的演變。在電腦應用普及之前，只有少數大企業才負擔得起公司資訊系統軟體，這一類的軟體開發也已委託定製（custom-made software）為主。在公司資訊化基礎設施逐步完備之後，多數中、小企業也要在預算不高的前提下實施公司專屬應用程式系統，按照以前的方式逐個定製開發，是這種類型的企業難以承受的。因此，對於一些需求簡明的系統，往往會購買現成軟體（shrink-wrapped software）解決問題。但是各個企業具體業務不同，需求很難統一，現成軟體只能滿足最通用的情況和最一致的操作（比如財會系統、網站內容發布系統等），對於頭緒眾多的業務處理就難以勝任了。如何最大程度地萃取不同公司專屬應用程式系統的共性，重複使用已經完成的設計和代碼，對公司專屬應用程式系統中典型情境給出最佳解決方案——這是一個“一般性”的問題；如何讓一個早先完成的軟體產品貼切地適應極為多變、複雜的企業需求——這是一個“特殊性”的問題。作為對這一組衝突的一種解決方案，不少廠商推出了自己的公司專屬應用程式架構。這些架構往往是從大量的委託項目開發中精選出的系統“不變項”，因此具有很強的普適性和實用性。目前，主流公司專屬應用程式架構中大都包含對以下問題的現成解決方案：* 持久性（persistence）：實現資料存放區處理，資料與對象映射，資料緩衝
* 事務（transaction）：確保一組關聯操作正常、完整的執行。
* 安全性（security）：保證系統的通訊安全、資料安全。
* 負載平衡（load balance）：在大量並發訪問時，保持系統可用。
* 監控（system monitoring/management）：監控系統健全狀態，設定系統參數。
* 日誌（logging）：記錄系統運行情況和異常，記錄特定使用者操作。
* 應用整合 （application integration）：與其他系統、應用程式整合。
* 認證/許可權/組織角色管理（authentication/authorization）：* 業務模型（domain model）：管理系統中業務對象的屬性、欄位。
* 商務邏輯（business logic/rules）：實現商務規則和商務邏輯。
* 工作流程（work flow）：實現多使用者、多環節之間的業務處理流程。
* 檔案管理（file management）：管理文檔，實現系統內部的檔案傳遞。
* 報表/列印（reporting/printing）：實現資料列印，實現報表的定製和輸出。
* 門戶/資訊發布 （portal solution）：提供企業客戶的訪問入口。
* 通訊（communication/messaging）：內部訊息通知，外部介面* 特定行業/領域模組 （business modules）：實現特定行業、流域相關的業務模組。以上諸方面中，除了前四項目前主要由應用伺服器解決之外，其他的部分本身都是專門的軟體開發領域。架構的作用，在於確定上述每種因素的具體技術實現，並規定它們在系統中的組織方式和協作方式，從而給出完整的公司專屬應用程式解決方案。公司專屬應用程式架構的特點首先是，當應用程式框架確定之後，系統的整個構架，也就是主體結構就已經固定。因此架構的選取往往是方案選型的首要問題。其次，人們常常聽信“組件式開發”的一面之詞，認為系統搭建的過程類似於搭積木，好像是用膠水代碼（glue code）拼合現成的組件或模組。其實採用架構開發時，系統的構建過程更類似於填空——系統骨架早已完成，開發人員填寫特定的代碼，由系統來調用。《設計模式》中提到的“好萊塢原則（the Hollywood principle——Don't call us, we'll call you）”，非常符合我們談的這種情況。很多架構還允許下遊廠商開發系統外掛程式（plug-ins），以滿足特定需要——這是另一種形式的“填空”。另外，對於實現具體應用系統的二次開發人員來說，不少任務都無需通過編程實現。比如要給一個業務模型增添一個新欄位，或是要設定一種新的工作流程，這些工作都可以通過簡單的圖形化使用者介面（GUI）操作，或是修改部署描述符（DD），或是編寫指令碼來完成。也就是說，相當多（而不是全部）的開發工作單位是通過聲明/配置的（declarative），而不是編程的（programmatic）的方式實現的。系統往往會在啟動或運行時載入相關的配置，據此實現特定的功能。 公司專屬應用程式架構是菜場裡的半成品。當我們面對要麼自己下廚、要麼去飯館吃飯的選擇時，我們往往會採取這種省時省力的折衷方案。但是選擇之所以為選擇，就因為其中肯定包含對收益和代價的權衡，都隱含著複雜的利弊關係（pros and cons）。下面我們也來檢討一下公司專屬應用程式架構的情況：* 縮短開發週期
毫無疑問，採用架構的開發，要比一切從頭做起快速、高效得多。通過一般化（generalization）和重用（reuse）機制，架構能最大限度地加快一個特定應用系統的實現。* 客戶化
如上所述，基於架構的系統有很多功能通過配置而不是編程實現，這樣也給使用者帶來了一定便利。比如，企業內部的IT人員經過一定培訓，就能夠自己完成一種新的工作流程的設定。這對於不斷變化的業務需求是一個很理想的解決方案。* 不重新發明輪子
架構對於大量典型情境給出了最優的實踐。在具體開發時，與其無視前人的成果，重新構思答案，不如套用這些成熟、穩定的做法。這不僅能加快開發進度，更能夠提升系統的品質和健壯性。* 可維護性/知識共用
完全通過委託開發完成的系統很難由其他廠商維護。架構往往是多個企業、大量開發人員實踐的成果，因此能在一定程度上打破上述壁壘，增進系統的可維護性。當架構使用者形成社區之後，還能實現更高層次上的知識共用。* 太多
半成品總有其代價。超市配好的一包菜裡，老是又我們用不到的調料——但是我們卻不得不為之付費。同樣，為了達到一般性和普適性，架構總比緊湊、貼切的特定應用多出不少內容。二次開發完成後，企業獲得的只是一種特定的實現，卻要為所有的客戶化可能性付費，為所有用不上的功能付費。這是一個相當讓人尷尬的事實。* 太少
架構總是一種限制。就像半成品菜限制了我們的烹調方法，架構也限制了我們實際應用的可能性。當架構本身設計的足夠普適時，我們不太會感到類似的限制。但是，情況往往正好相反——面對一個足夠特殊的需求，二次開發人員總有一種衝破架構的渴望。最後的解決辦法，往往是狡計、妥協和架構補丁的結合體。* 效率
上面說過，基於架構的系統中，具體功能經常是通過配置實現的。與寫入程式碼（hard-coded）的方式相比較，這雖然能提供很大的靈活性，但也往往犧牲了運行時的效率。* 鎖定
一個採用特定架構的系統幾乎肯定被鎖定在這個廠商的產品上。換言之，架構意味著all or nothing式的態度，很難調和兩種不同的架構，各取所長，更難把應用系統從一個架構遷移到另一個——這往往要求系統的全部改寫。* 學習曲線
一種架構也就是一種方言。要精通特定架構的開發，你要熟悉其中的所有的用法、思路和弱點。對於開發人員，這也意味著比較陡峭的學習曲線。 上面談到的種種弊端，還屬於一般開發架構共有的缺陷。對於市面上流行的很多公司專屬應用程式架構來說，更大的問題是架構產品自身的價格過高。我在別處也講過，公司專屬應用程式系統項目往往不能靠運行安裝程式，再作簡單的設定就完成，而是一個複雜、漫長、不斷嘗試/修改的過程，或者說，更近似於一種服務而不是簡單的產品銷售。但是架構廠商的產品（或者說是半成品）價格過高，經常就蠶食了整個系統的大部分開發預算，使方案總價偏重於架構本身而不是後期開發。對於需求不甚符合原有架構，需要大量開發的項目，或是需求本身不夠清晰的項目，這都幾乎肯定會導致整個項目的失敗。 軟體工程宗師F. Brooks曾經表述過這樣一個道理：沒有銀彈（No Silver Bullet/NSB）。那意思是說，沒有一種萬應藥能夠戲劇性地提升軟體開發的效率和品質。最近的很多輿論好像是專門和這個經典論述抬杠，動不動就把一些特殊的解決方案奉為銀彈。對於公司專屬應用程式開發而言，基於架構的開發模式是多種選擇中的一種。在不少情況下，這種選擇是不錯的，但同時應該留意隨之而來的風險，更不該以為，選定了架構就一定能保證項目成功。很多公司專屬應用程式項目的痛點，在於客戶自身缺乏規範的企業管理制度和合格的電腦應用水平。客戶不具備成型的商務程序，也無法明晰表達需求，不知道怎樣的應用形式對自身業務更合理：這種需求不清、或是需求劇烈變更的困境是困擾大量公司專屬應用程式開發項目的癥結。簡言之，公司專屬應用程式項目的成敗經常是“業務”、“技術”、“管理”三種因素共同作用的結果，而單純引入架構，只能解決部分“技術問題”。如果過於樂觀地估計架構在其中的作用，甚至認為它能解決任何項目的任何問題，這對於本領域的各個環節（廠商、項目開發商、企業客戶）都只能起到消極作用。我個人的建議是：在搭建公司專屬應用程式系統時，針對應用情況不同、預算/時限不同、對系統指標要求不同，有多種替代方案可以從中選擇。當需求明確、固定，又有現成產品完全滿足需要時，或者當企業想要以極低預算消除某個業務瓶頸時，應該優先考慮現成產品；在需求明確、固定，但很難被現成產品完全覆蓋時，可以選擇應用程式框架，並由合格開發商完成實施；在需求不夠明確，或者預感到需求會發生劇烈變更時，採用開發源碼的應用程式框架，從而避免高昂的初期投資，並“軟化”架構帶來的種種限制，是另一種可供選擇的思路。還是那個比方，一頓飯怎麼吃，究竟是下館子、買半成品或者全由自己動手，還要視具體情形而定——我也希望，每個企業都能吃上可口順心的應用大餐。