|
|
一、什么是架構(gòu)
1. 和架構(gòu)相關(guān)的幾個(gè)問題域
架構(gòu)需要解決的非業(yè)務(wù)問題域包括如下：
A 系統(tǒng)目標(biāo)：系統(tǒng)性能，穩(wěn)定性.
B.項(xiàng)目目標(biāo)：開發(fā)成本，質(zhì)量
C.項(xiàng)目過(guò)程：需求的不確定性和開發(fā)過(guò)程的團(tuán)隊(duì)協(xié)作性
不同的問題域，解決之道也不相同！而同一問題域的不同層次的要求，解決之道也不盡相同。
2. 什么是架構(gòu)
架構(gòu)到底是啥，愚以為下面的這段英文描述的很清楚。
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. 架構(gòu)的背后
為了實(shí)現(xiàn)架構(gòu)的目標(biāo)涉及到以下三個(gè)方面：技術(shù)，組織和過(guò)程。這里舉例說(shuō)明。
1) 技術(shù)對(duì)開發(fā)效率和運(yùn)行性能，以及組織和過(guò)程的影響。
案例A．映射的問題。公司產(chǎn)品的一個(gè)重要需求是根據(jù)客戶輸入，映射到PDF文件上。技術(shù)上整體實(shí)現(xiàn)需要四個(gè)步驟：在PDF文件上畫好所有的數(shù)據(jù)域，通過(guò)讀入一個(gè)XML映射文件，獲得運(yùn)行數(shù)據(jù)并生成FDF，合并FDF和PDF生成目標(biāo)文件。后兩步工作都由代碼自動(dòng)化了，因而實(shí)現(xiàn)的主要工作在于前兩步。
在第一個(gè)實(shí)現(xiàn)版本里，XML映射文件的DTD太簡(jiǎn)單，致使一個(gè)xml文件至少在4000行左右，同時(shí)xml文件太verbose了。這樣的結(jié)果直接導(dǎo)致運(yùn)行系統(tǒng)在峰值時(shí)，由于XML消耗了大量?jī)?nèi)存，1G的內(nèi)存根本吃不消；同時(shí)對(duì)XML解析執(zhí)行使用了CPU的大量時(shí)間；導(dǎo)致開發(fā)人員需要做大量的工作，開發(fā)效率降低了，通常需要盡一周才能完成一個(gè)xml文件，員工都不愿意做；也導(dǎo)致開發(fā)過(guò)程的漫長(zhǎng)， 開發(fā)部門對(duì)于BA部門和ST部門的要求反應(yīng)變的緩慢。
在第二個(gè)版本的實(shí)現(xiàn)中，重新實(shí)現(xiàn)了DTD，加入了大量的關(guān)鍵字同時(shí)也消除了verbose，大量的縮小了XML大小，從4000多行減低到900多行。不僅減低了內(nèi)存使用，提高執(zhí)行效率；也提高了開發(fā)效率，基本只要一天就可以完成一個(gè)映射文件。同時(shí)對(duì)BA部門和ST部門的反應(yīng)也快了。
案例B：腳本的問題。產(chǎn)品在web層提供了腳本支持，出于方便開發(fā)的目的。但是沒有對(duì)腳本的環(huán)境限制，腳本可以做系統(tǒng)程序的大部分工作。導(dǎo)致開發(fā)人員偷懶，在web層混入了大量業(yè)務(wù)邏輯代碼。最終造成業(yè)務(wù)邏輯分散而不可控制。
2) 組織結(jié)構(gòu)對(duì)技術(shù)，開發(fā)效率和應(yīng)變能力的影響。
案例A.部門的分工問題。開發(fā)部門根據(jù)不同的職責(zé)，分成A，B和C等數(shù)個(gè)小組。大部分開發(fā)中互不相干。但也有時(shí)候，需要跨組的支持，比如B要實(shí)現(xiàn)某個(gè)需求，需要A在一定條件在記錄一個(gè)或多個(gè)信息。因?yàn)槊總€(gè)開發(fā)人員各自負(fù)責(zé)一部分工作，導(dǎo)致跨組溝通的困難。同時(shí)由于整個(gè)開發(fā)部采取任務(wù)績(jī)效，有時(shí)間壓力，加上只是一個(gè)小的要求。于是在A人員的同意下，B人員直接在A代碼中寫入業(yè)務(wù)邏輯。每次都是這樣的小改動(dòng)，不斷的發(fā)展后，代碼開發(fā)變凌亂。
案例B.開發(fā)的歷史問題，當(dāng)某個(gè)開發(fā)人員寫下的代碼，有是問題的，接手開發(fā)人員由于文檔不全以及沒有測(cè)試用例，不愿意承擔(dān)變化的代價(jià)，選擇小修小補(bǔ)，這個(gè)小修小補(bǔ)有可能和有問題的代碼混雜，導(dǎo)致更大的代碼。
3) 過(guò)程對(duì)開發(fā)效率和應(yīng)變能力，以及組織的影響
案例A.過(guò)程的問題。開發(fā)部門的上下游部門BA部門和ST部門的合作關(guān)系。ST部門的績(jī)效考核,考核基于發(fā)現(xiàn)錯(cuò)誤的數(shù)量，導(dǎo)致ST為了完成任務(wù)，提出一些非正常性要求。PM部門出于部門的方便通常提出一些實(shí)現(xiàn)難度比較大要求。開發(fā)部門本身又存在時(shí)間壓力，導(dǎo)致一些需求的實(shí)現(xiàn)本應(yīng)在低一層的代碼中實(shí)現(xiàn)的，卻在高層用蹩足的方式實(shí)現(xiàn)。
案例B.幫助系統(tǒng)的問題。幫助系統(tǒng)一開始采用一個(gè)個(gè)單獨(dú)分散的靜態(tài)頁(yè)面。出于性能的考慮和部門負(fù)責(zé)考慮。幫助系統(tǒng)不斷改進(jìn)中，過(guò)程缺乏組織性，文件的命名規(guī)則隨意，存儲(chǔ)位置隨意，造成了管理的混亂。直接的后果是頁(yè)面的入口混亂和各自引用關(guān)系混亂。
在幫助系統(tǒng)的第二版，從靜態(tài)頁(yè)面轉(zhuǎn)成動(dòng)態(tài)頁(yè)面。采取統(tǒng)一分類和命名規(guī)則，并統(tǒng)一了入口。同時(shí)采取分級(jí)管理引用關(guān)系，適度冗余。雖然減低了運(yùn)行性能。但提高了開發(fā)效率和可維護(hù)性。
二、架構(gòu)的性能問題解決討論
性能問題——嗯，一個(gè)非常神圣而高深的問題的。從我剛剛開始工作的時(shí)候，至今依然是。然而我相信，一定存在一個(gè)基本的思路和方法，我以為解決性能問題的工作還是在于分解,通過(guò)分解來(lái)確定問題域。
1. 性能調(diào)優(yōu)的關(guān)鍵
性能調(diào)優(yōu)的關(guān)鍵是：發(fā)現(xiàn)性能瓶頸所在，慢是相對(duì)概念，評(píng)價(jià)標(biāo)準(zhǔn)是符合不符合系統(tǒng)要求。調(diào)整同時(shí)需要考慮維護(hù)成本，因?yàn)榫S護(hù)成本通常是開發(fā)成本的3倍。
2. 性能調(diào)優(yōu)的公式
先介紹三個(gè)公式性能問題的公式:
總處理單量 = 總處理時(shí)間/ 單筆請(qǐng)求處理時(shí)間 * 總并發(fā)數(shù)
這個(gè)公式另一個(gè)寫法為:
總處理時(shí)間 = 單筆請(qǐng)求處理時(shí)間 * 總處理單量 / 總并發(fā)數(shù)
不同的寫法代表不同的關(guān)注點(diǎn)，適合不同類型的業(yè)務(wù)類型, 一般說(shuō)前一種寫法代表在線請(qǐng)求的，后一種寫法代表后臺(tái)batch;即高并發(fā)或大數(shù)據(jù)量問題.
也有客戶給明確要求系統(tǒng)要支持xxx并發(fā)，這個(gè)就需要了解客戶的這個(gè)并發(fā)數(shù)是如何計(jì)算得來(lái)，需要通過(guò)分析客戶的業(yè)務(wù)，而通常是根據(jù)總處理單量來(lái)確定客戶實(shí)際的并發(fā)數(shù)。
但無(wú)論如如何，四個(gè)變量中，總處理單量和總處理時(shí)間是先被確定的，換句話說(shuō)需要關(guān)注是單筆請(qǐng)求處理時(shí)間和并發(fā)數(shù)，也就是降低單筆請(qǐng)求處理時(shí)間或者增加并發(fā)數(shù)。
對(duì)于單筆請(qǐng)求處理時(shí)間，其公式為：
單筆請(qǐng)求處理時(shí)間 ＝ 數(shù)據(jù)計(jì)算時(shí)間 ＋ 數(shù)據(jù)讀寫時(shí)間＋其它技術(shù)導(dǎo)致時(shí)間消耗
很顯然降低單筆請(qǐng)求處理時(shí)間就需要降低三個(gè)因素消耗的時(shí)間。
1.降低單筆請(qǐng)求處理時(shí)間
第一原則是, 只計(jì)算一次.緩存計(jì)算結(jié)果；
第二是，延遲部分計(jì)算（在不影響結(jié)果的情況下，將部分后續(xù)計(jì)算延后處理）
第三是，提前部分計(jì)算（例如對(duì)于年度的batch計(jì)算，可以在每個(gè)月都計(jì)算各自數(shù)據(jù)，年底匯總即可）
2.降低數(shù)據(jù)讀取時(shí)間,分三種
2.1. Global的,系統(tǒng)啟動(dòng)時(shí)加載
2.2. Long Time, 可采用LRU方式cache
3.2. Per operation. 第一次訪問加載,operation結(jié)束后丟棄.
3.降低數(shù)據(jù)寫入時(shí)間
例如文件寫入通過(guò)buffer一次flush；對(duì)于SQL采用batch提交（hibernate的做法）；對(duì)于同一張表數(shù)據(jù)只做一次更新；
4 .改進(jìn)計(jì)算時(shí)間，針對(duì)不同技術(shù)結(jié)構(gòu)采用不同手段。
4.1.讓計(jì)算支持并發(fā),提高性能,例如采用MapReduce的方式
4.2.改進(jìn)算法.例如數(shù)據(jù)庫(kù)中的SQL改進(jìn).
4.3.減少不必要計(jì)算時(shí)間.
5.減少其它技術(shù)原因?qū)е碌南?span lang="EN-US">
如JVM的GC導(dǎo)致性能消耗等
對(duì)于總并發(fā)數(shù)，其公式為：
總并發(fā)數(shù) ＝ 單機(jī)服務(wù)器并發(fā)能力 * 總并發(fā)服務(wù)器數(shù)
3. 確定改進(jìn)方案
那么如何確定那些因素需要調(diào)整呢，在于兩個(gè)方面的分解：
A. 業(yè)務(wù)層面
業(yè)務(wù)層面只是指通過(guò)業(yè)務(wù)行為分析, 把性能問題分解為不同的部分,每個(gè)部分面臨性能壓力現(xiàn)狀和目標(biāo),最終確定需要優(yōu)化的問題域.
業(yè)務(wù)層面分解包括4個(gè)內(nèi)容: 功能, 內(nèi)容,時(shí)間和區(qū)域.最重要的是前三個(gè).
以eBay為例, ebay對(duì)于前端功能劃分劃分為70多個(gè)功能,不同的服務(wù)器處理不同的功能.
內(nèi)容是指內(nèi)容熱點(diǎn),比如對(duì)于search來(lái)說(shuō),就按體育,數(shù)碼,音樂等劃分,不同內(nèi)容有不同熱點(diǎn)數(shù)據(jù),以及不同搜索關(guān)鍵匹配.
時(shí)間, 時(shí)間是一個(gè)非常重要的因素,在一些特定時(shí)間段,性能的要求會(huì)非常高.比如下半夜的訪問點(diǎn)擊量和白天的就有不同.對(duì)于一些batch來(lái)說(shuō), 月末或者年末處理的單量就有明顯的提高,比如分紅險(xiǎn)的記息,平時(shí)每天只有7000單,而年末會(huì)有12w單.
地點(diǎn)劃分,不太常見,不過(guò)也有助于分配計(jì)算資源.
業(yè)務(wù)層面的分析不僅是確定問題所在,還是確定優(yōu)化的策略.比如有一個(gè)batch計(jì)算,執(zhí)行時(shí)間比較長(zhǎng),而通過(guò)業(yè)務(wù)分析,發(fā)現(xiàn)該計(jì)算只針對(duì)特定的業(yè)務(wù), 系統(tǒng)全部有效單量是12w單,而符合計(jì)算要求的只有3000單,只要加上一個(gè)前置判斷就可以免除無(wú)謂的計(jì)算,運(yùn)行時(shí)間減少數(shù)個(gè)小時(shí)(大約0.2秒1單).
B. 技術(shù)層面
系統(tǒng)建立時(shí)技術(shù)結(jié)構(gòu),通常一個(gè)系統(tǒng)結(jié)構(gòu)如下:接入網(wǎng)絡(luò),Web服務(wù)器,應(yīng)用服務(wù)器,以及數(shù)據(jù)庫(kù)服務(wù)器.
在這樣結(jié)構(gòu)下，要小心的分析和驗(yàn)證系統(tǒng)性能的瓶頸，需要優(yōu)化Web服務(wù)器，或者提高數(shù)據(jù)庫(kù)并發(fā)能力等等。這部分網(wǎng)上的資料非常多。
采用并發(fā)立刻面臨一個(gè)問題,即負(fù)載均衡.負(fù)載均衡如果無(wú)法正常的工作,那么并發(fā)也就無(wú)法正確的工作.負(fù)載均衡可以靜態(tài)分布,也要?jiǎng)討B(tài)分布.這里面涉及的問題比較多.服務(wù)器自帶的負(fù)載均衡有時(shí)不能滿足業(yè)務(wù)上的需要,要自行開發(fā).
互聯(lián)網(wǎng)網(wǎng)站的特點(diǎn)是交易少,事務(wù)短和并發(fā)高.對(duì)于網(wǎng)站這一特點(diǎn)需要做一番分解.網(wǎng)站的計(jì)算可以分解為:靜態(tài)內(nèi)容和動(dòng)態(tài)內(nèi)容,動(dòng)態(tài)內(nèi)容又可以分為狀態(tài)無(wú)關(guān)(stateless)和狀態(tài)有關(guān)(stateful).
靜態(tài)內(nèi)容通過(guò)負(fù)載均衡或者CDN就可以簡(jiǎn)單做到.
動(dòng)態(tài)內(nèi)容特別是狀態(tài)有關(guān)的就復(fù)雜一點(diǎn).動(dòng)態(tài)內(nèi)容中涉及到兩大技術(shù):session和cache.
Session技術(shù)導(dǎo)致很多問題.負(fù)載均衡中導(dǎo)致session復(fù)制的難題.解決的方式是:1. 把所有的session數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)中,這樣通過(guò)增加數(shù)據(jù)庫(kù)的IO讀取,換取應(yīng)用服務(wù)器沒有任何session數(shù)據(jù)問題(另一種做法是把session數(shù)據(jù)放到cookie或者頁(yè)面hidden值中);2. 負(fù)載均衡采用Hash法,固定的把同一個(gè)請(qǐng)求綁定到同一臺(tái)服務(wù)器上,這樣通過(guò)犧牲一定的負(fù)載,換取應(yīng)用服務(wù)器的session數(shù)據(jù).
應(yīng)用session sticky,雖然避免了session的復(fù)制,但是依然面臨failover的問題.如果應(yīng)用程序在session中放入了domain object,在failover就容易出問題.一個(gè)解決方法是對(duì)session的set和get進(jìn)行攔截,發(fā)現(xiàn)是domain object就只在session中記錄ID+ClassName結(jié)構(gòu),而把對(duì)象放入cache中,failover時(shí)session中內(nèi)容簡(jiǎn)單,就通過(guò)cache從數(shù)據(jù)庫(kù)加載.(SpringSide對(duì)于jBPM的擴(kuò)展采用相同策略)
Cache技術(shù)本事沒有特別的要說(shuō)的,但它處在負(fù)載均衡環(huán)境中就會(huì)帶來(lái)問題:緩存數(shù)據(jù)失效(版本低).解決的問題有兩種:1. 獨(dú)立緩存+廣播通知.一旦數(shù)據(jù)更新后立刻廣播通知,這樣引發(fā)的問題是通知的管理.2. 采用中央緩存,如memcached技術(shù),代價(jià)是網(wǎng)絡(luò)讀寫.
Center Cache和Cluster Cache的特性比較如下：
Center Cache沒有同步問題，所以，remove/clear的時(shí)候，比較有優(yōu)勢(shì)，不需要把通知發(fā)送到好幾個(gè)計(jì)算機(jī)上。但是，Center Cache的所有操作，get/put/remove/clear都是Remote操作。而Cluster Cache的get/put都是Local操作，所以，Cluster Cache在get/put操作上具有優(yōu)勢(shì)。
Local get/put在關(guān)聯(lián)對(duì)象的組裝和分拆方面，優(yōu)勢(shì)比較明顯。 關(guān)聯(lián)對(duì)象的分拆是這個(gè)意思, 比如，有一個(gè)Topic對(duì)象，下面有幾個(gè)Post對(duì)象，每個(gè)Post對(duì)象都有一個(gè)User對(duì)象。 Topic對(duì)象存放到Cache中的時(shí)候，下面的關(guān)聯(lián)對(duì)象都要拆開來(lái)，分成各自的Entity Region來(lái)存放。
Topic Region -> Topic ID -> Topic Object
Post Region -> Post ID -> Post Object
User Region -> User ID -> User Object
這個(gè)時(shí)候，put的動(dòng)作可能發(fā)生多次。Remote Put的開銷就比較大。 Get的過(guò)程類似，也需要get多次，才能拼裝成一個(gè)完整的Topic對(duì)象。
三、架構(gòu)的開發(fā)成本以及品質(zhì)問題解決討論
架構(gòu)一個(gè)重要的關(guān)注點(diǎn)在于控制開發(fā)成本，這點(diǎn)很重要，因?yàn)橥ǔＶv維護(hù)成本是開發(fā)成本的3倍。降低開發(fā)成本核心，在于提高效率，這也意味著提高了開發(fā)對(duì)需求的響應(yīng)時(shí)間，而時(shí)間對(duì)公司來(lái)說(shuō)是重要的。
1. 問題域
問題域可分解為兩種類型，業(yè)務(wù)上和技術(shù)上。（又見分解，分而治之真是老祖宗傳下的靈丹妙藥啊）
1. 業(yè)務(wù)上。問題域分解為，邏輯的縱向抽象層次，以及邏輯的橫向模塊分解和集成。
2. 技術(shù)上。問題域分解為，縱向的技術(shù)主題，以及橫向的技術(shù)職責(zé)的分解和集成。
A. 領(lǐng)域基本問題
所以通常而言，領(lǐng)域模型設(shè)計(jì)中，模塊分解，抽象分層和職責(zé)分層都是重要手段。問題域?yàn)椋毫鞒蹋瑯I(yè)務(wù)實(shí)體和計(jì)算（包括規(guī)則）。
- 對(duì)象的抽象分解和集成
- 對(duì)象的依賴分解和集成（模塊內(nèi)和模塊外）
- 流程的分解和集成（頁(yè)面流，工作流以及計(jì)算流程）
- 進(jìn)程邊界：用戶請(qǐng)求重定向，以及業(yè)務(wù)數(shù)據(jù)持久化等。
it知識(shí)庫(kù)：軟件架構(gòu)亂彈——問題域及其解決方法，轉(zhuǎn)載需保留來(lái)源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
