|
|
一、什么是架構
1. 和架構相關的幾個問題域
架構需要解決的非業務問題域包括如下：
A 系統目標：系統性能，穩定性.
B.項目目標：開發成本，質量
C.項目過程：需求的不確定性和開發過程的團隊協作性
不同的問題域，解決之道也不相同！而同一問題域的不同層次的要求，解決之道也不盡相同。
2. 什么是架構
架構到底是啥，愚以為下面的這段英文描述的很清楚。
That'slike asking, what is culture? Culture is the way you do things in agroup of people. Architecture is the way you do things in a softwareproduct. You could argue by analogy, then, that architecture is to asoftware product as culture is to a team. It is how that team hasestablished and chosen its conventions，
Whichleads us inevitably to the question of “goodness”? How do you know ifan architecture is good? Consider an architecture that isn't builtusing a strong domain model, and instead relies heavily on storedprocedures. That might be OK, or it might not be OK. You could havedecided that part of your architecture is to use a really strong domainmodel and not use stored procedures, right? So an architecture is somereasonable regularity about the structure of the system, the way theteam goes about building its software, and how the software respondsand adapts to its own environment. How well the architecture respondsand adapts, and how well it goes through that construction process, isa measure of whether that architecture is any good.
Thesystem architecture determines how hard or easy it is to implement agiven feature. Good architectures are those in which it is consideredeasy to create the features desired. In that the way to judge whetheran architecture is good is whether the architecture is good for thepurposes to which it is applied.
Thedefinition of goodness has to be related to fitness for purpose. Isthis glove good? I don't know. What are you doing with the glove? Areyou throwing snowballs, cooking barbeques, or playing golf? There's aset of changes that are going to occur to a software system over time.Probably the utilitarian or most useful definition of goodness is theanswer to this question: are the changes that will keep this systemsuccessful in this domain in this product line relatively easy? If theyare, then it's probably a good architecture.
3. 架構的背后
為了實現架構的目標涉及到以下三個方面：技術，組織和過程。這里舉例說明。
1) 技術對開發效率和運行性能，以及組織和過程的影響。
案例A．映射的問題。公司產品的一個重要需求是根據客戶輸入，映射到PDF文件上。技術上整體實現需要四個步驟：在PDF文件上畫好所有的數據域，通過讀入一個XML映射文件，獲得運行數據并生成FDF，合并FDF和PDF生成目標文件。后兩步工作都由代碼自動化了，因而實現的主要工作在于前兩步。
在第一個實現版本里，XML映射文件的DTD太簡單，致使一個xml文件至少在4000行左右，同時xml文件太verbose了。這樣的結果直接導致運行系統在峰值時，由于XML消耗了大量內存，1G的內存根本吃不消；同時對XML解析執行使用了CPU的大量時間；導致開發人員需要做大量的工作，開發效率降低了，通常需要盡一周才能完成一個xml文件，員工都不愿意做；也導致開發過程的漫長， 開發部門對于BA部門和ST部門的要求反應變的緩慢。
在第二個版本的實現中，重新實現了DTD，加入了大量的關鍵字同時也消除了verbose，大量的縮小了XML大小，從4000多行減低到900多行。不僅減低了內存使用，提高執行效率；也提高了開發效率，基本只要一天就可以完成一個映射文件。同時對BA部門和ST部門的反應也快了。
案例B：腳本的問題。產品在web層提供了腳本支持，出于方便開發的目的。但是沒有對腳本的環境限制，腳本可以做系統程序的大部分工作。導致開發人員偷懶，在web層混入了大量業務邏輯代碼。最終造成業務邏輯分散而不可控制。
2) 組織結構對技術，開發效率和應變能力的影響。
案例A.部門的分工問題。開發部門根據不同的職責，分成A，B和C等數個小組。大部分開發中互不相干。但也有時候，需要跨組的支持，比如B要實現某個需求，需要A在一定條件在記錄一個或多個信息。因為每個開發人員各自負責一部分工作，導致跨組溝通的困難。同時由于整個開發部采取任務績效，有時間壓力，加上只是一個小的要求。于是在A人員的同意下，B人員直接在A代碼中寫入業務邏輯。每次都是這樣的小改動，不斷的發展后，代碼開發變凌亂。
案例B.開發的歷史問題，當某個開發人員寫下的代碼，有是問題的，接手開發人員由于文檔不全以及沒有測試用例，不愿意承擔變化的代價，選擇小修小補，這個小修小補有可能和有問題的代碼混雜，導致更大的代碼。
3) 過程對開發效率和應變能力，以及組織的影響
案例A.過程的問題。開發部門的上下游部門BA部門和ST部門的合作關系。ST部門的績效考核,考核基于發現錯誤的數量，導致ST為了完成任務，提出一些非正常性要求。PM部門出于部門的方便通常提出一些實現難度比較大要求。開發部門本身又存在時間壓力，導致一些需求的實現本應在低一層的代碼中實現的，卻在高層用蹩足的方式實現。
案例B.幫助系統的問題。幫助系統一開始采用一個個單獨分散的靜態頁面。出于性能的考慮和部門負責考慮。幫助系統不斷改進中，過程缺乏組織性，文件的命名規則隨意，存儲位置隨意，造成了管理的混亂。直接的后果是頁面的入口混亂和各自引用關系混亂。
在幫助系統的第二版，從靜態頁面轉成動態頁面。采取統一分類和命名規則，并統一了入口。同時采取分級管理引用關系，適度冗余。雖然減低了運行性能。但提高了開發效率和可維護性。
二、架構的性能問題解決討論
性能問題——嗯，一個非常神圣而高深的問題的。從我剛剛開始工作的時候，至今依然是。然而我相信，一定存在一個基本的思路和方法，我以為解決性能問題的工作還是在于分解,通過分解來確定問題域。
1. 性能調優的關鍵
性能調優的關鍵是：發現性能瓶頸所在，慢是相對概念，評價標準是符合不符合系統要求。調整同時需要考慮維護成本，因為維護成本通常是開發成本的3倍。
2. 性能調優的公式
先介紹三個公式性能問題的公式:
總處理單量 = 總處理時間/ 單筆請求處理時間 * 總并發數
這個公式另一個寫法為:
總處理時間 = 單筆請求處理時間 * 總處理單量 / 總并發數
不同的寫法代表不同的關注點，適合不同類型的業務類型, 一般說前一種寫法代表在線請求的，后一種寫法代表后臺batch;即高并發或大數據量問題.
也有客戶給明確要求系統要支持xxx并發，這個就需要了解客戶的這個并發數是如何計算得來，需要通過分析客戶的業務，而通常是根據總處理單量來確定客戶實際的并發數。
但無論如如何，四個變量中，總處理單量和總處理時間是先被確定的，換句話說需要關注是單筆請求處理時間和并發數，也就是降低單筆請求處理時間或者增加并發數。
對于單筆請求處理時間，其公式為：
單筆請求處理時間 ＝ 數據計算時間 ＋ 數據讀寫時間＋其它技術導致時間消耗
很顯然降低單筆請求處理時間就需要降低三個因素消耗的時間。
1.降低單筆請求處理時間
第一原則是, 只計算一次.緩存計算結果；
第二是，延遲部分計算（在不影響結果的情況下，將部分后續計算延后處理）
第三是，提前部分計算（例如對于年度的batch計算，可以在每個月都計算各自數據，年底匯總即可）
2.降低數據讀取時間,分三種
2.1. Global的,系統啟動時加載
2.2. Long Time, 可采用LRU方式cache
3.2. Per operation. 第一次訪問加載,operation結束后丟棄.
3.降低數據寫入時間
例如文件寫入通過buffer一次flush；對于SQL采用batch提交（hibernate的做法）；對于同一張表數據只做一次更新；
4 .改進計算時間，針對不同技術結構采用不同手段。
4.1.讓計算支持并發,提高性能,例如采用MapReduce的方式
4.2.改進算法.例如數據庫中的SQL改進.
4.3.減少不必要計算時間.
5.減少其它技術原因導致的消耗
如JVM的GC導致性能消耗等
對于總并發數，其公式為：
3. 確定改進方案
那么如何確定那些因素需要調整呢，在于兩個方面的分解：
A. 業務層面
業務層面只是指通過業務行為分析, 把性能問題分解為不同的部分,每個部分面臨性能壓力現狀和目標,最終確定需要優化的問題域.
業務層面分解包括4個內容: 功能, 內容,時間和區域.最重要的是前三個.
以eBay為例, ebay對于前端功能劃分劃分為70多個功能,不同的服務器處理不同的功能.
內容是指內容熱點,比如對于search來說,就按體育,數碼,音樂等劃分,不同內容有不同熱點數據,以及不同搜索關鍵匹配.
時間, 時間是一個非常重要的因素,在一些特定時間段,性能的要求會非常高.比如下半夜的訪問點擊量和白天的就有不同.對于一些batch來說, 月末或者年末處理的單量就有明顯的提高,比如分紅險的記息,平時每天只有7000單,而年末會有12w單.
地點劃分,不太常見,不過也有助于分配計算資源.
業務層面的分析不僅是確定問題所在,還是確定優化的策略.比如有一個batch計算,執行時間比較長,而通過業務分析,發現該計算只針對特定的業務, 系統全部有效單量是12w單,而符合計算要求的只有3000單,只要加上一個前置判斷就可以免除無謂的計算,運行時間減少數個小時(大約0.2秒1單).
B. 技術層面
系統建立時技術結構,通常一個系統結構如下:接入網絡,Web服務器,應用服務器,以及數據庫服務器.
在這樣結構下，要小心的分析和驗證系統性能的瓶頸，需要優化Web服務器，或者提高數據庫并發能力等等。這部分網上的資料非常多。
采用并發立刻面臨一個問題,即負載均衡.負載均衡如果無法正常的工作,那么并發也就無法正確的工作.負載均衡可以靜態分布,也要動態分布.這里面涉及的問題比較多.服務器自帶的負載均衡有時不能滿足業務上的需要,要自行開發.
互聯網網站的特點是交易少,事務短和并發高.對于網站這一特點需要做一番分解.網站的計算可以分解為:靜態內容和動態內容,動態內容又可以分為狀態無關(stateless)和狀態有關(stateful).
靜態內容通過負載均衡或者CDN就可以簡單做到.
動態內容特別是狀態有關的就復雜一點.動態內容中涉及到兩大技術:session和cache.
Session技術導致很多問題.負載均衡中導致session復制的難題.解決的方式是:1. 把所有的session數據存儲到數據庫中,這樣通過增加數據庫的IO讀取,換取應用服務器沒有任何session數據問題(另一種做法是把session數據放到cookie或者頁面hidden值中);2. 負載均衡采用Hash法,固定的把同一個請求綁定到同一臺服務器上,這樣通過犧牲一定的負載,換取應用服務器的session數據.
應用session sticky,雖然避免了session的復制,但是依然面臨failover的問題.如果應用程序在session中放入了domain object,在failover就容易出問題.一個解決方法是對session的set和get進行攔截,發現是domain object就只在session中記錄ID+ClassName結構,而把對象放入cache中,failover時session中內容簡單,就通過cache從數據庫加載.(SpringSide對于jBPM的擴展采用相同策略)
Cache技術本事沒有特別的要說的,但它處在負載均衡環境中就會帶來問題:緩存數據失效(版本低).解決的問題有兩種:1. 獨立緩存+廣播通知.一旦數據更新后立刻廣播通知,這樣引發的問題是通知的管理.2. 采用中央緩存,如memcached技術,代價是網絡讀寫.
Center Cache和Cluster Cache的特性比較如下：
Center Cache沒有同步問題，所以，remove/clear的時候，比較有優勢，不需要把通知發送到好幾個計算機上。但是，Center Cache的所有操作，get/put/remove/clear都是Remote操作。而Cluster Cache的get/put都是Local操作，所以，Cluster Cache在get/put操作上具有優勢。
Local get/put在關聯對象的組裝和分拆方面，優勢比較明顯。 關聯對象的分拆是這個意思, 比如，有一個Topic對象，下面有幾個Post對象，每個Post對象都有一個User對象。 Topic對象存放到Cache中的時候，下面的關聯對象都要拆開來，分成各自的Entity Region來存放。
Topic Region -> Topic ID -> Topic Object
Post Region -> Post ID -> Post Object
User Region -> User ID -> User Object
這個時候，put的動作可能發生多次。Remote Put的開銷就比較大。 Get的過程類似，也需要get多次，才能拼裝成一個完整的Topic對象。
三、架構的開發成本以及品質問題解決討論
架構一個重要的關注點在于控制開發成本，這點很重要，因為通常講維護成本是開發成本的3倍。降低開發成本核心，在于提高效率，這也意味著提高了開發對需求的響應時間，而時間對公司來說是重要的。
1. 問題域
問題域可分解為兩種類型，業務上和技術上。（又見分解，分而治之真是老祖宗傳下的靈丹妙藥啊）
1. 業務上。問題域分解為，邏輯的縱向抽象層次，以及邏輯的橫向模塊分解和集成。
2. 技術上。問題域分解為，縱向的技術主題，以及橫向的技術職責的分解和集成。
A. 領域基本問題
所以通常而言，領域模型設計中，模塊分解，抽象分層和職責分層都是重要手段。問題域為：流程，業務實體和計算（包括規則）。
- 對象的抽象分解和集成
- 對象的依賴分解和集成（模塊內和模塊外）
- 流程的分解和集成（頁面流，工作流以及計算流程）
- 進程邊界：用戶請求重定向，以及業務數據持久化等。
it知識庫：軟件架構亂彈——問題域及其解決方法，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
