建站
咨詢
售后
建站咨詢
新聞中心
在數(shù)據(jù)庫中，事務(wù)是一組必須被一起執(zhí)行的數(shù)據(jù)庫操作。它們被視為一個單一的工作單元，要么全部成功，要么全部失敗。事務(wù)循環(huán)依賴是指兩個或多個事務(wù)互相依賴，并且被設(shè)計成必須在相互之間執(zhí)行。當(dāng)存在事務(wù)循環(huán)依賴時，會出現(xiàn)難以解決的問題，影響數(shù)據(jù)庫的性能和穩(wěn)定性。本文將分析數(shù)據(jù)庫事務(wù)循環(huán)依賴的影響以及解決方法。
霍城網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)公司！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)公司自2013年創(chuàng)立以來到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運(yùn)維經(jīng)驗，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)公司。
1. 事務(wù)循環(huán)依賴的影響
1.1 數(shù)據(jù)庫性能受到影響
事務(wù)循環(huán)依賴可能導(dǎo)致數(shù)據(jù)的更新和讀取之間的沖突，導(dǎo)致數(shù)據(jù)庫性能下降。循環(huán)依賴會阻止事務(wù)完成并釋放數(shù)據(jù)庫鎖，這可能導(dǎo)致其他事務(wù)在等待時間內(nèi)堵塞。
1.2 數(shù)據(jù)庫安全性受到威脅
事務(wù)循環(huán)依賴可能導(dǎo)致數(shù)據(jù)丟失和數(shù)據(jù)不完整的風(fēng)險。由于互相依賴的事務(wù)的順序無法保證，如果一個事務(wù)的失敗導(dǎo)致系統(tǒng)中的其他事務(wù)一起失敗，數(shù)據(jù)就會處于不一致的狀態(tài)。
1.3 可維護(hù)性變差
事務(wù)循環(huán)依賴要求開發(fā)人員具有更高的技能，難以預(yù)測故障和維護(hù)代碼。當(dāng)軟件代碼中包含循環(huán)依賴關(guān)系時，團(tuán)隊在修復(fù)一個錯誤時可能會意外地影響到其他模塊的功能，所以在日常維護(hù)中是難以實現(xiàn)的。
2. 解決數(shù)據(jù)庫事務(wù)循環(huán)依賴的方法
2.1 分析依賴關(guān)系
在事務(wù)中如果存在循環(huán)依賴關(guān)系，必須首先找到每個循環(huán)并確定在哪個事務(wù)中出現(xiàn)問題。通過仔細(xì)調(diào)查依賴關(guān)系，可以找到數(shù)據(jù)庫變化的原因，從而將這些問題逐一解決。
2.2 優(yōu)化事務(wù)流程
優(yōu)化事務(wù)流程是避免事務(wù)循環(huán)依賴的更好方法之一。事務(wù)流程可以通過優(yōu)化數(shù)據(jù)查詢，避免重復(fù)查詢或在單個事務(wù)中完成多個查詢等方式進(jìn)行優(yōu)化。這將大大減少循環(huán)依賴的危險性。
2.3 采用分布式事務(wù)處理
分布式事務(wù)處理是一種以分散數(shù)據(jù)庫事務(wù)負(fù)載為中心的解決方案。它包含一個處理請求的主服務(wù)器及數(shù)個工作服務(wù)器，將數(shù)據(jù)分片分散到不同的服務(wù)器上，分散事務(wù)負(fù)載。這種方案能夠有效減輕事務(wù)循環(huán)依賴時可能出現(xiàn)的鎖等因素，但是也增加了管理的復(fù)雜性，需要考慮跨服務(wù)器的通訊等問題。
2.4 數(shù)據(jù)庫重構(gòu)
重構(gòu)是一種在不影響現(xiàn)有功能的情況下從根本上修改應(yīng)用程序的方式。這種方法可以解決一個系統(tǒng)中設(shè)計不合理的問題。當(dāng)應(yīng)用程序中存在循環(huán)依賴時，數(shù)據(jù)庫重構(gòu)是解決方法之一。重構(gòu)可能涉及調(diào)整數(shù)據(jù)模型，修改表結(jié)構(gòu)等等方面，需要謹(jǐn)慎考慮。
3.
事務(wù)循環(huán)依賴的問題可能嚴(yán)重影響數(shù)據(jù)庫的性能和穩(wěn)定性，并引起數(shù)據(jù)丟失等情況。本文提供了一些解決方案，包括分析依賴關(guān)系，優(yōu)化事務(wù)流程，采用分布式處理事務(wù)等。重構(gòu)是解決問題的最后手段，但需要謹(jǐn)慎考慮。因此，在數(shù)據(jù)庫設(shè)計和開發(fā)時應(yīng)該務(wù)必避免循環(huán)依賴的問題。
相關(guān)問題拓展閱讀：
- 一篇讓你學(xué)會 11個Spring 失效場景
- 如何運(yùn)用物理識圖，邏輯識圖進(jìn)行軟件架構(gòu)設(shè)計
一篇讓你學(xué)會 11個Spring 失效場景
其實關(guān)于spring事務(wù)失效的場景，網(wǎng)絡(luò)上文章介紹的不少，參差不齊。這里只分享下自己的見解，時長大概10分鐘左右，先上個圖介紹下。
事務(wù)方法需要定義public，非public方法事務(wù)會失效。事務(wù)攔截器TransactionalInterceptor會在執(zhí)行方法前進(jìn)行攔截，通過動態(tài)代理方式如果是cglib就是intercept方法或者jdk的invoke方法間接調(diào)用AbstractFallbackTransactionAttributeSource類的getTransactionAttribute方法獲取配置信息，附上源碼圖：
進(jìn)一步的跟蹤getTransactionAttribute方法，我們就能看到，spring對于非public修飾的方式，返回的事務(wù)對象是null，其中allowPublicMethodsOnly返回的是一個布爾false。
事務(wù)底層使用了aop,那么也就是說通過jdk或者是cglib生成代理類，在代理類中實現(xiàn)的事務(wù)的功能，如果說方法是final修飾的了，那么就會導(dǎo)致代理類中無法重寫該方法，從而導(dǎo)致添加事務(wù)失敗。同樣的如果是static的修飾的話也是無法通過動態(tài)代理變成事務(wù)方法。
簡單來說就是一個方法內(nèi)部調(diào)用另一個方法，但是另一個方式是有事務(wù)的，這樣也會導(dǎo)致事務(wù)失效，因為這個調(diào)用的是this對象的方法，而不是另一個方法持有的對象，可以這里理解。
如果想要在枯禪方法內(nèi)部調(diào)用另一個方法也有事務(wù)的話，就需要新建一個service對象持有。
這樣，通過新建一個service方法，將事務(wù)添加到新建的service方法里就可以了。說到這里可能小伙伴覺得這樣有點(diǎn)麻煩，那么是否有沒有其他的方式不新建一個方法呢，答案是可以的，就是注入自己，利用了spring ioc內(nèi)部的三級緩存的機(jī)制，這里注入自己就很好的保證了也不會出現(xiàn)循環(huán)依賴：
其實到了這一步，還是發(fā)現(xiàn)有點(diǎn)不太雅觀，并不是說上面代碼有什么問題只是覺得，可以讓上面代碼更加好看一點(diǎn)，那么有沒有呢，答案是有的，是什么呢?這就不得不佩服spring強(qiáng)大完善的支持，那就是AopContext.currentProxy(),這個就是創(chuàng)建代理類，在方法調(diào)·調(diào)用前后切入，這個代理類對象是保存在ThreadLocal中的，所以通過這個代理類對象調(diào)用事務(wù)方法就能生效了。
這樣看來，代碼是不是就優(yōu)雅多了，哈哈!!!
這里需要明確一個前提，就是使用spring事務(wù)的前提，就是對象要被spring管理握啟就需要創(chuàng)建bean實例，在開發(fā)中，我們都是通過@Controller,@Service,@Component,@Repository等注解自動的實現(xiàn)依賴注入實例化的功能，但假如說在相應(yīng)的控制層，業(yè)務(wù)層，數(shù)據(jù)層忘記加相應(yīng)的注解，那么也是會失效的。因為沒有交給spring管理，例如：
回沒皮塵想起前幾年配置事務(wù)管理器時，都會有這樣的一段配置：
通過這一段配置也可以知道，其實spring事務(wù)就是通過數(shù)據(jù)庫連接事務(wù)多線程連接會導(dǎo)致持有的connetion不是同一個，從網(wǎng)上找了一張圖，通過這張圖進(jìn)一步理解：
接著附上偽代碼結(jié)合上面的圖進(jìn)一步理解：
事務(wù)add方法中調(diào)用了另一個事務(wù)doOtherThing,但是事務(wù)方法是在另一個線程中調(diào)用的，這樣就會導(dǎo)致兩個方法不在同一個線程中，獲取到的數(shù)據(jù)庫鏈接不一樣，是兩個不同的事務(wù)，一旦doOtherThing發(fā)生異常，add方法也是不可能發(fā)生回滾的.這里需要解釋以下什么是同一個事務(wù)，也就是說只有擁有同一個數(shù)據(jù)庫連接才能同時提交和回滾。如果在不同的線程，拿到的數(shù)據(jù)庫連接肯定是不一樣的，所以是不同的事務(wù)。
這個就沒什么好講的了，也就是innodb和myisam引擎的不同，5版本以前默認(rèn)是myisam引擎，這個引擎是不支持事務(wù)的，5版本以后的innodb是支持事務(wù)的。
這個其實可能也是比較容易忽略的，因為我們印象里好像沒怎么配置過怎么開啟事務(wù)，也確實是這樣哈，為什么?其實原因很簡單，springboot項目通過DataSourceTransactionManagerAutoConfiguration這個類已經(jīng)默默的為我們開啟了事務(wù)。
這個類會加載spring.datasource這個配置文件從而啟動事務(wù)，如果是非springboot項目就需要自己手動在xml文件中配置事務(wù)管理器。
類似這樣的從而開啟事務(wù)。
在使用@Transactional注解時，是可以指定propagation參數(shù)的，該參數(shù)是用來指定事務(wù)的傳播特性，其中只有required,requires_new,nested這三種才會創(chuàng)建新事務(wù)：
像上面的Propagation.NEVER這種類型的傳播特性不支持事務(wù)，如果有事務(wù)則會拋異常。
像這種手動try…catch了異常，又沒有手動拋出，那么sring就會認(rèn)為程序是異常的就不會回滾了。
捕獲了異常又拋出了exception異常，事務(wù)同樣不會回滾，因為spring事務(wù)默認(rèn)情況下只會回滾RuntimeException(運(yùn)行時異常)和Error(錯誤)，對于普通的Exception(非運(yùn)行時異常)，不會回滾，網(wǎng)上找了一張圖：
這里exception里除了分為運(yùn)行時異常和非運(yùn)行時異常(ioException)。
1） 讓checked例外也回滾：
在整個方法前加上 @Transactional(rollbackFor=Exception.class)
2） 讓unchecked例外不回滾：
@Transactional(notRollbackFor=RunTimeException.class)
3）不需要事務(wù)管理的(只查詢的)方法：@Transactional(propagation=Propagation.NOT_SUPPORTED)
這里需要提及的一句是，如果是自定義了的異常，比如說我自定義了DALException異常，那么就應(yīng)該是@Transactional(notRollbackFor=DALException.class)，一旦拋出的異常不屬于DALException異常，那么事務(wù)也是不會生效的。
其實這個就有點(diǎn)像是js里的冒泡事件，可能我只是需要底部，結(jié)果外層窗口事件也觸發(fā)了，聯(lián)想到事務(wù)這里，那么也是一樣的，嵌套多個可能只是想回滾對應(yīng)的事務(wù)，就不用把其他事務(wù)也回滾了，這個可以通過try…catch來處理，將需要處理回滾的事務(wù)放這里面就不會把外層的也會滾了。
如何運(yùn)用物理識圖，邏輯識圖進(jìn)行軟件架構(gòu)設(shè)計
軟件架構(gòu)設(shè)計的目的
對于外包業(yè)務(wù)類型的項目，軟件架構(gòu)設(shè)計的目的與產(chǎn)品類型的項目有所不同，在這里主要討論外包類型項目的軟件架構(gòu)設(shè)計目的。
1、為大規(guī)模開發(fā)提供基礎(chǔ)和規(guī)范，并提供可重用的資產(chǎn)，軟件系統(tǒng)的大規(guī)模開發(fā)，必須要有一定的基礎(chǔ)和遵循一定的規(guī)范，這既是軟件工程本身的要求，也是客戶的要求。架構(gòu)設(shè)計的過程中可以將一些公共部分抽象提取出來，形成公共類和工具類，以達(dá)到重用的目的。
2、一定程度上縮短項目的周期，利用軟件架構(gòu)提供的框架或重用組件，縮短項目開發(fā)的周期。
3、降低開發(fā)和維護(hù)的成本，大量的重用和抽象，可以提取出一些開發(fā)人員不用關(guān)心的公共部分，這樣便可以使開發(fā)人員僅僅關(guān)注于業(yè)務(wù)邏輯的實現(xiàn)，從而減少了很多工作量，提高了開發(fā)效率。
4、提高產(chǎn)品的質(zhì)量，好的軟件架構(gòu)設(shè)計是產(chǎn)品質(zhì)量的保證，特別是對于客戶常常提出的非功能性需求的滿足。
軟件架構(gòu)設(shè)計的原則
軟件架構(gòu)設(shè)計必須遵循以下原則：
1、滿足功能性需求和非功能需求。這是一個喊做軟件系統(tǒng)最基本的要求，也是架構(gòu)設(shè)計時應(yīng)該遵循的最基本的原則。念汪
2、實用性原則，就像每一個軟件系統(tǒng)交付給用戶使用時必須實用，能解決用戶的問題一樣，架構(gòu)設(shè)計也必須實用，否則就會“高來高去”或“過度設(shè)計”。
3、滿足復(fù)用的要求，更大程度的提高開發(fā)人員的工作效率。
軟件架構(gòu)設(shè)計的幾種視圖
我們常常在討論架構(gòu)設(shè)計該做些什么的時候，或是在架構(gòu)設(shè)計評審的會議上，會提出各種各樣的問題，例如開發(fā)人員該如何記錄鄭高衡Log，事務(wù)如何控制？怎樣才能提高我們的開發(fā)人員的工作效率，即在單位時間內(nèi)更有品質(zhì)的完成更多的功能？怎樣滿足客戶的非功能性需求？怎樣讓生產(chǎn)環(huán)境的平臺管理人員更好的維護(hù)系統(tǒng)？
上面這些問題，實際上是軟件系統(tǒng)的不同的干系人站在不同的角度上提出的問題，要回答上面這些問題，我們就得從不同的視角來看待軟件架構(gòu)設(shè)計這項工作。
1、邏輯架構(gòu)視角，從系統(tǒng)用戶的角度考慮問題，設(shè)計出來的軟件架構(gòu)能夠滿足業(yè)務(wù)邏輯的需求，能夠處理現(xiàn)在越來越復(fù)雜的業(yè)務(wù)邏輯需求。
2、開發(fā)架構(gòu)視角，從系統(tǒng)開發(fā)人員的角度來考慮問題，設(shè)計的架構(gòu)要易于理解，易于開發(fā)，易于單元測試，更好做到讓開發(fā)人員可以用最少的代碼行數(shù)完成功能的開發(fā)。
3、運(yùn)行架構(gòu)視角，從系統(tǒng)運(yùn)行時的質(zhì)量需求考慮問題，特別關(guān)注于系統(tǒng)的非功能需求，客戶常常都會要求我們系統(tǒng)的功能畫面的最長響應(yīng)時間不超過4秒，能滿足2023個用戶同時在線使用，基于角色的系統(tǒng)資源的安全控制等。
4、物理架構(gòu)視角，關(guān)注系統(tǒng)安裝和部署在什么樣的環(huán)境上，例如現(xiàn)在更流行的企業(yè)應(yīng)用服務(wù)解決方案IBM Http Server ＋ WebSphere Application Server ＋ DB2，WebLogic + Oracle等。
5、數(shù)據(jù)架構(gòu)視角，如今我們開發(fā)的各類系統(tǒng)，如MIS，ERP，SAP，基本上都是對各類數(shù)據(jù)的操作，把一堆不太好懂的數(shù)據(jù)展現(xiàn)成用戶容易看懂的數(shù)據(jù)，自動處理各類數(shù)據(jù)的運(yùn)算等，所以數(shù)據(jù)的持久化是十分重要的一件事情。
1、分析需求和理解業(yè)務(wù)模型（或領(lǐng)域建模），并選定關(guān)鍵Use case。
軟件的需求，可以分為從用戶視角和開發(fā)人員視角來看，從用戶的角度看，又可以分為功能性和非功能性需求，我們必須從不同的視角和級別去全面的認(rèn)識需求并分析需求，理解業(yè)務(wù)模型。實踐表明，常常被我們忽視的非功能性需求常常會導(dǎo)致整個項目失敗。
理解業(yè)務(wù)需求更好的方式莫過于進(jìn)行領(lǐng)域建模，領(lǐng)域建模與需求分析往往是交替穿叉進(jìn)行的，領(lǐng)域建模主要有以下三個方面的作用：
◆探索復(fù)雜問題，弄清領(lǐng)域知識。Martin Fowler曾經(jīng)說過，他采用面向?qū)ο蠓椒ǜ蟮暮锰幘褪撬兄诮鉀Q更為復(fù)雜的問題。領(lǐng)域建模本身作為輔助思維的工具，幫助我們將注意力始終保持在最為重要的業(yè)務(wù)概念及其關(guān)系上，使我們能夠不斷深入地，系統(tǒng)的對需求進(jìn)行分析和認(rèn)識。領(lǐng)域建模往往是一個從模糊到清晰，從零散到系統(tǒng)的過程。
◆決定功能范圍，影響可擴(kuò)展性。任何模型都是對現(xiàn)實世界某種程序的抽象，這種抽象就會忽略某一些東西，例如忽略對象的屬性和對象間的關(guān)系，而這些忽略往往都是帶有一定的目的性的，這種忽略就決定了功能的范圍。模型揭示了各種功能背后的結(jié)構(gòu)，如果說定義功能相當(dāng)于“拍照片”的話，那么領(lǐng)域建模就相當(dāng)于“做透視”，更加關(guān)注問題領(lǐng)域的內(nèi)在結(jié)構(gòu)，相當(dāng)于對問題領(lǐng)域進(jìn)行了一定的抽象，良好的領(lǐng)域模型不僅能很好的支持現(xiàn)有的功能，而且還可以在一定程度上支持未來可能出現(xiàn)的新需求，體現(xiàn)良好的可擴(kuò)展性。
◆提供交流基礎(chǔ)，促進(jìn)有效溝通。領(lǐng)域建模通常會使用UML圖作為呈現(xiàn)的方式，這樣為我們的溝通提供了方便。當(dāng)然，有時候文字在描述某些特定領(lǐng)域的問題時可能更適合，可以靈活運(yùn)用。
在我們公司的實際軟件開發(fā)流程中，往往領(lǐng)域建模缺少這一環(huán)節(jié)，這可能是在以后的工作中需要進(jìn)一步提高之處。
雖然我們總是期望架構(gòu)設(shè)計師能全面掌握需求，但由于時間和精力的限制，擺在我們面前的現(xiàn)實就是架構(gòu)設(shè)計師沒有時間對所有需求進(jìn)行深入分析，所以我們的策略就是“把好鋼用在刀刃上”，即把大部分時間和精力花在對決定架構(gòu)最重要的關(guān)鍵需求上。在選擇關(guān)鍵需求時要注意：高優(yōu)先級的需求往往是從用戶的角度來看的，可能并不是真正的關(guān)鍵需求。在《RUP實踐者指南》一書中向我們講述了如何確定關(guān)鍵功能需求？A.作為應(yīng)用程序的核心或?qū)崿F(xiàn)了系統(tǒng)的主要接口的功能，B.必須被實現(xiàn)的功能，即如果這些功能不被實現(xiàn)，則開發(fā)出來的軟件就失去了價值，C.覆蓋了系統(tǒng)架構(gòu)的一些方面，但沒有被其他重要的Use case覆蓋到的功能。
2、分別從各個視角來考慮軟件架構(gòu)的方方面面。
軟件的架構(gòu)設(shè)計必須考慮到各方面，根據(jù)前期工作確立的領(lǐng)域模型，關(guān)鍵需求，系統(tǒng)約束等進(jìn)行設(shè)計，必須從系統(tǒng)用戶，開發(fā)人員，系統(tǒng)管理員，部署管理員，數(shù)據(jù)管理員等人員的角度去分析并解決問題。比如說，如果我們的運(yùn)行架構(gòu)采用Cluster方式時，就必須小心Cache和Session等的使用；如果我們的業(yè)務(wù)邏輯要求我們要操作多個數(shù)據(jù)庫時，就要考慮采用支持二階段事務(wù)提交的方式。
只有將這些方方面面的問題都考慮到了，這樣的架構(gòu)設(shè)計才是完整的。至于每一個視圖中，我們應(yīng)該設(shè)計到什么細(xì)節(jié)這一問題，實際上與整個項目的過程定義有關(guān)。例如，如果我們有專門安排數(shù)據(jù)庫概要設(shè)計的活動，那我們在架構(gòu)設(shè)計的過程中就可以只需要關(guān)注更高層次的數(shù)據(jù)庫特性及數(shù)據(jù)庫之間的關(guān)系，而每一張表的數(shù)據(jù)字典可以在后續(xù)的相關(guān)活動中進(jìn)行設(shè)計，但如果沒有這樣的活動，那我們就要細(xì)化到每一張表的每一個欄位，以及表之間的關(guān)系。
3、解決技術(shù)面的重點(diǎn)問題和難題
在軟件架構(gòu)設(shè)計的過程中，我們往往會需要攻克一些技術(shù)面的重點(diǎn)問題和難題，這完全是一項極其需要扎實的理論知識和豐富的實踐經(jīng)驗支撐的工作。例如，我們?nèi)绾翁岣哒麄€系統(tǒng)的性能？如何能很好的導(dǎo)出極其復(fù)雜的“中國式報表”（一般比西方國家產(chǎn)出的報表要復(fù)雜很多，而且很多開源的BI類的框架并不能完全解決問題）？
當(dāng)遇到確實是很困難的問題，可以去百度一下或Google一下，也可以去請教公司的資深技術(shù)人員或?qū)＜遥蛘哒匍_小范圍的技術(shù)專題討論會議，采用腦力激蕩的方法試著找找答案，這樣才能提高工作的效率。
4、召開架構(gòu)設(shè)計評審會議進(jìn)行同行評審。
架構(gòu)設(shè)計評審是極其重要的一環(huán)，我曾將其形容為“七種武器”中的離別鉤，就是因為在會議上，同行們可能會提很多問題或意見，而且很多意見很尖銳，所以一定要虛心接受，并做好記錄，正所謂“良藥苦口利于病，忠言逆耳利于行”。
在評審會議之前，我們要完成很多準(zhǔn)備工作，更好是能準(zhǔn)備一份簡明扼要的電子簡報，把最重要的問題列出來，這樣在進(jìn)行評審會議時，就不會漫無目的，在會議前就將這些資料發(fā)給與會人員，請他們抽空先了解一下，在會議進(jìn)行時，要學(xué)會控制會議的進(jìn)度，提高會議的效率。
5、針對關(guān)鍵Use case在設(shè)計的架構(gòu)上實現(xiàn)功能來驗證架構(gòu)。
對于架構(gòu)設(shè)計的驗證也是一項十分重要的工作，其驗證技術(shù)有很多種，在我們公司通常會采用Sample的形式，即XP中所說的迭代0，RUP中所說的切片。這樣做的好處是既可以從實際的產(chǎn)品角度出發(fā)來有效的驗證架構(gòu)是否滿足要求，又可以比拋棄型原型驗證技術(shù)節(jié)省成本。
這個Sample絕不是我們在解決架構(gòu)設(shè)計中的問題時拿來做實驗的一些代碼的拼湊，而是完整的實現(xiàn)某一關(guān)鍵Use case的符合架構(gòu)設(shè)計和一系列規(guī)范的可交付的代碼及相關(guān)文檔。同時，這個Sample可以作為你在給大家講解或培訓(xùn)架構(gòu)時的教材，也可以作為開發(fā)人員使用此架構(gòu)進(jìn)行開發(fā)的藍(lán)本，甚至是只需要復(fù)制粘貼，加上簡單的修改即可。
6、交付給客戶Review。
這一環(huán)節(jié)，在很多公司可能并不存在，因為他們的軟件架構(gòu)并不一定需要客戶Review，但像我們這種做服務(wù)的公司，最重要的就是客尊，落實到軟件架構(gòu)設(shè)計這一活動，就是讓客戶理解并接受你的架構(gòu)設(shè)計方案，同時，客戶也會起到幫你驗證架構(gòu)的作用。通常，我們的架構(gòu)得到客戶的認(rèn)可后，便可進(jìn)入大規(guī)模的開發(fā)。
在交付給客戶Review時，通?？赡軙詴h的形式進(jìn)行Review，所以我們可以參照評審會議時好的做法來召開會議，在這里就不再冗述。
軟件架構(gòu)設(shè)計的常見誤區(qū)及解決辦法
1、架構(gòu)設(shè)計的常常會“高來高去”。所謂高來高去，實際上就是我們的架構(gòu)設(shè)計僅停留在模型階段，但也絕不是產(chǎn)生之一支樣例程式。
2、架構(gòu)設(shè)計時常常會在某些方面過度設(shè)計（Over engineering）。為了一些根本不會發(fā)生的變化而進(jìn)行一系列復(fù)雜的設(shè)計，這樣的設(shè)計就叫過度設(shè)計，往往會帶來資源的浪費(fèi)并且會增加開發(fā)的工作量或難度。雖然我們必須考慮到系統(tǒng)的擴(kuò)展性，可維護(hù)性等，但切忌過度設(shè)計。有時候或許你并不能判斷出哪些設(shè)計是過度設(shè)計，此時你可以請教你的PM，讓他站在整個項目的高度來幫你決策一下。
3、架構(gòu)（Architecture）不是框架(Framework)，也不是簡單的將幾種框架或技術(shù)的組合，框架本身也是有架構(gòu)的。框架一般是針對于某一方面或領(lǐng)域的重用性和可擴(kuò)展性非常好的半成品，我們可以用一句較為經(jīng)典的話來總結(jié)：框架是軟件，架構(gòu)不是軟件，框架是一種特殊的軟件。我們在工作中通過將許多方面的可重用的工具類，公共類，基礎(chǔ)類等抽象出來，即可形成一些可重用的框架。
4、架構(gòu)設(shè)計絕不是新技術(shù)展示平臺，合適的技術(shù)才是對于項目有利的技術(shù)，必須考慮到開發(fā)人員的能力和維護(hù)人員的能力。作為一名架構(gòu)設(shè)計師應(yīng)該更多的考慮如何平衡業(yè)務(wù)需求，織織運(yùn)作（主要指團(tuán)隊中的協(xié)作）和技術(shù)三者的關(guān)系，而不僅僅是去關(guān)注那些技術(shù)細(xì)節(jié)。
5、架構(gòu)設(shè)計的成功與否決定著系統(tǒng)品質(zhì)的好壞，因為架構(gòu)設(shè)計不好而導(dǎo)致交付的系統(tǒng)Bug過多，無法滿足客戶非功能性需求等問題，從而導(dǎo)致項目取消的案例時有發(fā)生。架構(gòu)設(shè)計不是架構(gòu)設(shè)計師一個人的事情，也不是幾天就能完成的一項工作，必須是架構(gòu)設(shè)計師付出大量辛勤勞動后的成果，其成敗往往與組織、主管、項目經(jīng)理的支持有著密切的關(guān)系。
關(guān)于架構(gòu)設(shè)計的一點(diǎn)通用技巧
1、分層（Layer）規(guī)則。這里的層是指邏輯上的層次（Layer），并非指物理上的層次（Tier）。目前的絕大多數(shù)的企業(yè)級應(yīng)用系統(tǒng)中都分為三層，即表現(xiàn)層，領(lǐng)域?qū)雍蛿?shù)據(jù)層。在對各層次進(jìn)行劃分時，主要可以從以下幾個方面來考慮：A、每一層是一個相對獨(dú)立的部分，可以作為一個整體，無需對其它層了解；B、將層次間的依賴性降到更低，即降低耦合；C、可以從某種程度上替換掉某一層，而對其它層不會產(chǎn)生過多的影響；D，層次并不能封閉所有的東西，假如用戶界面上增加了一個欄位，那么領(lǐng)域?qū)泳鸵黾右粋€數(shù)據(jù)域，數(shù)據(jù)層就要增加一個相應(yīng)的字段。同時，過多的分層可能會對性能造成一定的影響。
2、包（package）之間不要產(chǎn)生循環(huán)依賴。通常包的劃分會先按不同的邏輯層來劃分，在層的包下面再按功能來劃分。避免包間的循環(huán)依賴是一個比較通用的規(guī)則，這樣的規(guī)則一定有其存在的價值和道理，之所以這樣主要是出于以下原因：A、循環(huán)依賴會使分層失去意義；B、循環(huán)依賴會帶來許多潛在的風(fēng)險，如可能會產(chǎn)生嵌套事務(wù)（nested transaction，JavaEE標(biāo)準(zhǔn)中并不支持這種事務(wù)）的現(xiàn)象，我就曾遇到過這樣的問題，在一個項目中，事務(wù)放在業(yè)務(wù)邏輯層統(tǒng)一控制，但由于開發(fā)人員忽視了架構(gòu)中這樣的原則，在持久層調(diào)用了展現(xiàn)層的公用類，形成了回圈的現(xiàn)象，導(dǎo)致了嵌套事務(wù)的發(fā)生。
3、設(shè)計模式的應(yīng)用。在很多人的觀念里，提供設(shè)計模式就等同于GOF的設(shè)計模式，其實設(shè)計模式是個廣泛的概念，比如需求模式、領(lǐng)域模式、反模式等都屬于設(shè)計模式。模式其實是一門工具，是人們對于過去解決某一類問題的經(jīng)驗總結(jié)，所以我們可以在設(shè)計活動中應(yīng)用各種設(shè)計模式，但是在應(yīng)用這些模式之前一定要先分析清楚問題，否則就可能出現(xiàn)“牛頭不對馬嘴”的現(xiàn)象。
成功的項目總有相似之處，失敗的項目卻各有各的失敗之處。好的軟件架構(gòu)設(shè)計必定是成功項目的相似之處，我們有什么理由不把軟件架構(gòu)設(shè)計做好了？
數(shù)據(jù)庫事務(wù)循環(huán)依賴的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關(guān)于數(shù)據(jù)庫事務(wù)循環(huán)依賴,分析數(shù)據(jù)庫事務(wù)循環(huán)依賴的影響與解決方法,一篇讓你學(xué)會 11個Spring 失效場景,如何運(yùn)用物理識圖，邏輯識圖進(jìn)行軟件架構(gòu)設(shè)計的信息別忘了在本站進(jìn)行查找喔。
香港服務(wù)器選創(chuàng)新互聯(lián)，2H2G首月10元開通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）互聯(lián)網(wǎng)服務(wù)提供商,擁有超過10年的服務(wù)器租用、服務(wù)器托管、云服務(wù)器、虛擬主機(jī)、網(wǎng)站系統(tǒng)開發(fā)經(jīng)驗。專業(yè)提供云主機(jī)、虛擬主機(jī)、域名注冊、VPS主機(jī)、云服務(wù)器、香港云服務(wù)器、免備案服務(wù)器等。
分享文章：分析數(shù)據(jù)庫事務(wù)循環(huán)依賴的影響與解決方法(數(shù)據(jù)庫事務(wù)循環(huán)依賴)
鏈接地址：http://m.fisionsoft.com.cn/article/dhopcds.html
