SOA架構(gòu)設(shè)計經(jīng)驗分享—架構(gòu)、職責(zé)、數(shù)據(jù)一致性

1.背景介紹

創(chuàng)新互聯(lián)專注于企業(yè)營銷型網(wǎng)站、網(wǎng)站重做改版、漢陰網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、html5、商城網(wǎng)站制作、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為漢陰等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

最近一段時間都在做系統(tǒng)分析和設(shè)計工作，面對的業(yè)務(wù)是典型的重量級企業(yè)應(yīng)用方向。突然發(fā)現(xiàn)很多以往覺得很簡單的問題變得沒有想象的那么容易，大的問題就是職責(zé)如何分配。論系統(tǒng)架構(gòu)設(shè)計的大的問題，其實也就是職責(zé)的分配，分配的合理，實現(xiàn)起來就會很柔性，反之就會使架構(gòu)很混亂。

軟件的生命周期大概可以歸納為四個基本的過程，分析、設(shè)計、實現(xiàn)、測試，當(dāng)然這僅僅是一個最為粗略的表示而已。不同的方法論有著不同的使用這幾個過程的方式。RUP使用快速迭代的過程，在這個幾個子過程中適當(dāng)?shù)妮敵鲆恍┻^程制品，每次迭代都是進(jìn)行相同的分析、設(shè)計、實現(xiàn)、測試。而在Scrum中，不提倡輸出任何文檔形式的過程制品，也同樣有著上述幾個過程，強(qiáng)調(diào)以人為中心，通過溝通來解決大部分的問題。

不能用好與不好來判斷哪一種方法論，只能根據(jù)目前的實際情況綜合權(quán)衡。RUP的每次迭代中有幾個關(guān)鍵的制品對系統(tǒng)分析、設(shè)計很重要，可以說是非常重要，如：詞匯表、業(yè)務(wù)規(guī)則文檔、用例、領(lǐng)域草圖。這幾個制品對分析、設(shè)計很重要，需要從這幾個制品中提煉出設(shè)計模型最終才能落地。這主要用在業(yè)務(wù)復(fù)雜的應(yīng)用系統(tǒng)中。而Scrum更加的輕量級，可以用在互聯(lián)網(wǎng)項目中，業(yè)務(wù)不是太復(fù)雜的情況下。

其實我為什么要強(qiáng)調(diào)軟件工程及開發(fā)方法論，是因為我最近發(fā)現(xiàn)，做設(shè)計其實是建立在分析的基礎(chǔ)上的，但是這里面又有很多問題。大型企業(yè)級應(yīng)用，并不能通過一次性分析就可以得出準(zhǔn)確和全部的需求，初期階段建立的需求70%都是不準(zhǔn)確的。所以做架構(gòu)需要有分析的能力才行且是建立在適當(dāng)?shù)拈_發(fā)方論上的分析，什么時候該用RUP，什么時候該用Scrum，什么時候該用XP都很有講究。分析與設(shè)計都需要有一個執(zhí)行上下文，不同的上下文對分析、設(shè)計的執(zhí)行有著不同的要求。

有句話我覺得對架構(gòu)者來說很有啟發(fā)：分析就是做正確的事，設(shè)計就是正確的做事。架構(gòu)跟語言跟平臺關(guān)系不大，畢竟架構(gòu)是設(shè)計過程中的子過程，我想如果你的設(shè)計不合理，你用任何語言任何平臺都解決不了問題。(這里的架構(gòu)上下文指：企業(yè)應(yīng)用架構(gòu)不是基礎(chǔ)設(shè)施的系統(tǒng)架構(gòu))

2.SOA的架構(gòu)層次

進(jìn)行SOA類型的架構(gòu)設(shè)計就需要搞清楚SOA架構(gòu)模型才行。并不能想當(dāng)然的對系統(tǒng)進(jìn)行簡單的拆分就行，需要搞清楚SOA的架構(gòu)模型是怎樣的，每一塊是干什么用的，這樣設(shè)計由分析階段輸出的需求時才能正確的劃分職責(zé)。

如果把SOA的架構(gòu)簡單的理解為是多個子系統(tǒng)之間的整合其實有點太過于簡單，也沒有真正搞清楚SOA的架構(gòu)模型。按照SOA的正確方法論及目標(biāo)模型，其實SOA在實現(xiàn)架構(gòu)落地上，需要考慮到對服務(wù)的組合，不斷的重用現(xiàn)有的服務(wù)，讓企業(yè)應(yīng)用可以逐步集成，快速實現(xiàn)業(yè)務(wù)的迭代。其實這就是本節(jié)要講的服務(wù)的分層，通過分層將服務(wù)按照使用類型進(jìn)行分配，上層服務(wù)對下層服務(wù)的包裝，下層服務(wù)負(fù)責(zé)原子性的操作，上層服務(wù)對下層服務(wù)進(jìn)行業(yè)務(wù)性的組合。

我們來看具體的每一層的作用及主要職責(zé)。

2.1.應(yīng)用服務(wù)(原子服務(wù))

應(yīng)用服務(wù)就是諸如：訂單服務(wù)、倉庫服務(wù)、銷售服務(wù)、客戶管理服務(wù)，這些服務(wù)直接對應(yīng)不同的應(yīng)用系統(tǒng)，直接服務(wù)這些應(yīng)用系統(tǒng)的原子操作。訂單服務(wù)直接原子性的插入訂單，沒有任何跨其他服務(wù)的分支邏輯。倉庫服務(wù)只管自己的倉庫邏輯。同樣其他的應(yīng)用服務(wù)只管好自己的職責(zé)，杜絕對其他服務(wù)的調(diào)用。

圖1：

應(yīng)用服務(wù)位于UI與后臺之間，后臺我們可以認(rèn)為它是一異構(gòu)的系統(tǒng)或者是數(shù)據(jù)庫之類的。應(yīng)用服務(wù)的位置位于前端與后端之間，起到類似一個服務(wù)API的作用，但是SOA中的服務(wù)還遠(yuǎn)遠(yuǎn)不止這一個應(yīng)用服務(wù)，如果我們的SOA架構(gòu)中只有一種類型的服務(wù)，那么這會增加我們系統(tǒng)的耦合程度，因為你沒有對系統(tǒng)的服務(wù)進(jìn)行層次的劃分，你的業(yè)務(wù)功能會直接的落到某一個應(yīng)用線上的服務(wù)，繼續(xù)往下看。

2.2.組合服務(wù)

組合服務(wù)是對應(yīng)用服務(wù)的一個組合,根據(jù)實際項目的規(guī)模大小,不一定非要進(jìn)行物理的隔離,在代碼層面的服務(wù)化也是可以的,在將來的某一天有必要的情況下再進(jìn)行物理的拆分,畢竟物理的拆分有著嚴(yán)重的成本和代價，對系統(tǒng)的穩(wěn)定性帶來很多挑戰(zhàn)。所以經(jīng)驗告訴我們必要的時候在進(jìn)行拆分。”分布式系統(tǒng)設(shè)計的第一個原則就是盡量不要分布式“，這是馬丁.福勒大師說的，現(xiàn)在理解確實感同身受。

圖2：

組合服務(wù)對下層的應(yīng)用服務(wù)進(jìn)行了組合，完成了一個基本的業(yè)務(wù)動作，應(yīng)用服務(wù)中是最基本的基礎(chǔ)性的原子性的操作。但是在復(fù)雜的業(yè)務(wù)需求下大部分業(yè)務(wù)功能都需要跨越多個應(yīng)用線來完成一個最外層的企業(yè)動作。提交訂單可能需要穿過很多應(yīng)用線，訂單管理、倉庫、財務(wù)等等環(huán)節(jié)。所以這里我們還需要一個能在最外層對組合服務(wù)進(jìn)行編排的業(yè)務(wù)服務(wù)。這個編排服務(wù)可以完全是自動化的，通過工作流引擎進(jìn)行組合自動化來完成，這對企業(yè)應(yīng)用的自動化流程很有意義。

2.3.業(yè)務(wù)服務(wù)(編排服務(wù))

業(yè)務(wù)服務(wù)是最外層的服務(wù)，向下編排了組合服務(wù)。業(yè)務(wù)服務(wù)位于最上層，當(dāng)需要有跨越多個應(yīng)用線來完成的業(yè)務(wù)，這個業(yè)務(wù)就放入業(yè)務(wù)服務(wù)中。比如提交訂單，先檢查庫存、扣減庫存(凍結(jié)庫存)，然后下單，再往后通知財務(wù)，再往后通知物流等等都是一個復(fù)雜的企業(yè)服務(wù)線。這種最外層的業(yè)務(wù)邏輯如果你不進(jìn)行SOA分層然后將其放入最外層的業(yè)務(wù)服務(wù)中，你把它放入任何一個應(yīng)用線都會使系統(tǒng)調(diào)用混亂不堪。所以問題就是需要進(jìn)行縱向的劃分層次。如果進(jìn)行了SOA的層次劃分后就不會出現(xiàn)互相亂用的情況。其實這里可以參考阿里的服務(wù)設(shè)計方法。(李智慧寫的一本大型互聯(lián)網(wǎng)架構(gòu)與實踐里面也講到了服務(wù)要劃分層次)

圖3：

當(dāng)在業(yè)務(wù)服務(wù)中執(zhí)行的業(yè)務(wù)邏輯時，需要跨越多個應(yīng)用線來完成。這部分的邏輯也說是職責(zé)，如果不放入這個位置，放在哪個應(yīng)用線都不合適，放入哪個應(yīng)用線都會使系統(tǒng)調(diào)用出現(xiàn)混亂。其實這里的問題就是我們不能用一個維度來進(jìn)行SOA系統(tǒng)的設(shè)計，本來服務(wù)就具有組合特性，所以適當(dāng)?shù)奶嵘?wù)的層次是有好處的，但是應(yīng)用服務(wù)和組合服務(wù)可以在代碼層面上進(jìn)行構(gòu)建，而業(yè)務(wù)服務(wù)也叫編排服務(wù)是需要進(jìn)行物理隔離的，畢竟考慮到系統(tǒng)復(fù)雜度和穩(wěn)定性問題這是值得的。在排查問題，系統(tǒng)性能、穩(wěn)定性等等方面，物理的隔離有一定的作用，畢竟業(yè)務(wù)服務(wù)本來就是來組合多個應(yīng)用線的，這樣做會使整個系統(tǒng)架構(gòu)很清晰。

3.SOA化的重構(gòu)

進(jìn)行SOA化的實施，大部分情況下都是對現(xiàn)有系統(tǒng)進(jìn)行重構(gòu)后考慮的，初期企業(yè)發(fā)展階段以快速出原形為首要目標(biāo)，只有當(dāng)系統(tǒng)出現(xiàn)瓶頸了才會考慮運用SOA來解決。但是在這個時候有很多歷史包袱無法解決，進(jìn)行SOA化的重構(gòu)其實成本是很高的，而且很危險，對有些復(fù)雜的邏輯說的現(xiàn)實點，是無能為力的。如果都可以通過重構(gòu)這個技術(shù)來解決，那我們就太天真了?！吨貥?gòu)—馬丁.福勒》一書講的是代碼層面的重構(gòu)，跟做系統(tǒng)級重構(gòu)兩個概念。對系統(tǒng)級別的重構(gòu)還沒有太多成熟的方法論支撐。尤其現(xiàn)在新技術(shù)層出不窮的，各有優(yōu)點，能很好的運用這些技術(shù)、方法論、過程來重構(gòu)大型企業(yè)級系統(tǒng)，難度非常大，這需要整個公司投入很多人力、資源成本?；剡^頭來想想，其實在前期適當(dāng)考慮一下還是有必要的，這樣可以減少后期很多技術(shù)債務(wù)。

這里我只總結(jié)我在分析、設(shè)計公司某一塊業(yè)務(wù)系統(tǒng)的時候?qū)ζ溥M(jìn)行SOA化的重構(gòu)思路。重構(gòu)本來就是一個不斷迭代的過程，不可以跨大步。通過很多腳手架支撐，讓系統(tǒng)慢慢的過度到新的SOA架構(gòu)下，既然要實施SOA架構(gòu)，那么很重要的一點就是對遷移的業(yè)務(wù)邏輯適當(dāng)?shù)臍w類，什么業(yè)務(wù)邏輯該放入“業(yè)務(wù)服務(wù)”中，什么邏輯該在代碼層面上放入“組合服務(wù)”中，對基本的操作有如何放入代碼層面的“應(yīng)用服務(wù)”中。

3.1.保留服務(wù)空間，為了將來服務(wù)的組合

在進(jìn)行系統(tǒng)拆分的時候，對當(dāng)前后端的調(diào)用都進(jìn)行適當(dāng)?shù)囊?guī)劃，將其分為兩類，一類是應(yīng)用服務(wù)，一類是組合服務(wù)，這兩個服務(wù)是可以在代碼層面上進(jìn)行抽象。重點是那些調(diào)用其他系統(tǒng)的地方，需要將其放入業(yè)務(wù)服務(wù)中，這塊邏輯比較復(fù)雜，難以抽取，需要適當(dāng)?shù)慕Y(jié)合”數(shù)據(jù)落地“的思路來綜合考慮。有時候把一部分?jǐn)?shù)據(jù)落入本地可以提升系統(tǒng)的整體簡潔度和穩(wěn)定性，但是要考慮數(shù)據(jù)的一個生命周期性質(zhì)。

在遷移的過程中可能還會有一些新的功能并行開發(fā)的，既有新的邏輯需要放入新的SOA服務(wù)中，也會有遷移過來的邏輯，這兩個過程同時進(jìn)行其實很痛苦，盡量避免這樣同時進(jìn)行，但是現(xiàn)實是根本不可能，正常都是一起并行推進(jìn)。如果這兩個過程是同一組團(tuán)隊負(fù)責(zé)其實還好，畢竟對這塊的代碼、業(yè)務(wù)都比較了解。

這一節(jié)目的是想強(qiáng)調(diào)對現(xiàn)在系統(tǒng)進(jìn)行遷移的時候要考慮服務(wù)的層次，不要只進(jìn)行一個簡單的搬移代碼，這個時候是一個對代碼進(jìn)行重構(gòu)的好機(jī)會，該劃分層次的要劃分層次，該讀寫分離的要讀寫分離，要重點考慮那些“業(yè)務(wù)服務(wù)”，需要跨越多個應(yīng)用線的邏輯。

順便說一下，還有一個重點就是遷移的時候還要考慮數(shù)據(jù)存儲方面的遷移，光代碼層面的遷移只是第一步，第二步還需要進(jìn)行數(shù)據(jù)層面的遷移。當(dāng)然這兩個大的步驟都是要通過很多次迭代完成，并且還是一個對業(yè)務(wù)、代碼進(jìn)行很好梳理和整理的好機(jī)會。

在將系統(tǒng)進(jìn)行服務(wù)化的時候要考慮服務(wù)層，如果當(dāng)前沒有業(yè)務(wù)服務(wù)的邏輯那么就保留服務(wù)空間，至少要清楚在服務(wù)層中有這么一個空間是要預(yù)留的，當(dāng)有其他的應(yīng)用線需要與你交互的時候可以順利的進(jìn)入到你的服務(wù)區(qū)，而不是直接到達(dá)你的應(yīng)用。

4.運用DDD+GRASP進(jìn)行分析和設(shè)計(防止主觀的判斷導(dǎo)致錯誤的假設(shè))

做系統(tǒng)設(shè)計時最怕的就是職責(zé)搞錯了，這會使系統(tǒng)的架構(gòu)突然就復(fù)雜了，而且系統(tǒng)架構(gòu)都是很難改變的或者壓根就無法改變的決定。所以我對這塊引起了重視，有時候你對業(yè)務(wù)在了解在熟悉依然會搞錯職責(zé)，對于這塊光憑主觀的判斷是不長遠(yuǎn)的，無發(fā)復(fù)制、無法傳播的，也無法落字成文的。

對DDD我這里就不多做介紹了，這里要強(qiáng)調(diào)是GRASP。運用DDD可以很好的幫助我們來戰(zhàn)略性的觀察企業(yè)所坐立的領(lǐng)域，我還是很提倡DDD在公司實施的，不說DDD中的“戰(zhàn)術(shù)設(shè)計”方法論，就光說它的“戰(zhàn)略設(shè)計”方法論還是有很大作用的，讓我們可以在腦海中建立一個戰(zhàn)略性的模型。具體要不要進(jìn)行代碼層面的落地這就看實際情況了。而且DDD中的很多不錯的思想都可以借鑒過來，包括領(lǐng)域通用語言，有了領(lǐng)域通用語言團(tuán)隊之間的溝通和交流會節(jié)省很多成本。對于新人來說，可以很快的了解公司的一些大概的業(yè)務(wù)，這和“詞匯表”其實還是有區(qū)別的。

上面說了，在劃分職責(zé)的時候很多都是通過經(jīng)驗來主觀的判斷，沒有其他的客觀證據(jù)了。那么有沒有一個不錯的方法論或模式來指導(dǎo)我們進(jìn)行這類問題的解決呢，其實還是有的，因為在國外人家這方面已經(jīng)很成熟。

GRASP就是這樣的一套模式，它可以幫助我們進(jìn)行客觀的設(shè)計職責(zé)。到底該把這塊數(shù)據(jù)放入哪個應(yīng)用中，到底該把這個邏輯放入哪個服務(wù)中，都有指導(dǎo)，包括對對象層面的設(shè)計依然可以。我們可能對“信息專家模式”都有了解，但是以往我們可能都只把它用在對象設(shè)計上，而沒有提升一個系統(tǒng)層面中考慮。那是因為我們以往可能沒有碰見很復(fù)雜的職責(zé)分配場景，只有當(dāng)出現(xiàn)問題時我們才能真正領(lǐng)會某個東西的好壞。

DDD只有結(jié)合GRASP才能客觀準(zhǔn)確的方配某個領(lǐng)域的職責(zé)，不管是戰(zhàn)略設(shè)計層面還是戰(zhàn)術(shù)設(shè)計層面，都是一個很好的平衡標(biāo)準(zhǔn)，不會由于技術(shù)人員主觀的興趣傾向?qū)е乱粋€錯誤的職責(zé)分配決定，而這個錯誤的決定最終是要開發(fā)人員來買單。

5.SOA分布式下的數(shù)據(jù)一致性

傳統(tǒng)分布式系統(tǒng)與當(dāng)代的面向SOA的分布式系統(tǒng)有一定區(qū)別，論概念上來講SOA是以服務(wù)為中心，既然以服務(wù)為中心就會有很多面向服務(wù)的設(shè)計原則。而傳統(tǒng)的分布式系統(tǒng)沒有服務(wù)的概念，也沒有所謂的一切皆是服務(wù)的原則。而當(dāng)代SOA則首要原則就要以服務(wù)為中心，針對服務(wù)的設(shè)計又有了很多服務(wù)設(shè)計原則。

SOA對服務(wù)還進(jìn)行了類型的劃分，按照服務(wù)的應(yīng)用層次來分類：業(yè)務(wù)服務(wù)、組合服務(wù)、應(yīng)用服務(wù)，包裝服務(wù)等。再按照管理與運維的層面來分類：控制服務(wù)、調(diào)度服務(wù)、監(jiān)控服務(wù)等等。傳統(tǒng)的分布式系統(tǒng)是沒有這些的，我們談?wù)摰氖钱?dāng)代SOA的分布式系統(tǒng)，所以我們強(qiáng)調(diào)的是以服務(wù)為中心，以服務(wù)設(shè)計原則為架構(gòu)設(shè)計的指導(dǎo)要求，當(dāng)代SOA是對傳統(tǒng)分布式系統(tǒng)的一個迭代進(jìn)化，不是一個時代的產(chǎn)物，SOA更加強(qiáng)調(diào)了以服務(wù)為首要原則，已經(jīng)提升到了另外一個更加高級的層面。

本節(jié)我們交流一下在當(dāng)代SOA分布式系統(tǒng)中的數(shù)據(jù)一致性問題，在SOA中這主要涉及兩個層面來考慮，一個是服務(wù)層面、一個數(shù)據(jù)持久化層面。再按照一致性的基本要求，可以分為：讀一致性、寫一致性、會話一致性、最終一致性、實時一致性等幾個維度，當(dāng)然還有其他幾個維度的一致性要求。

我們這里重點討論在企業(yè)應(yīng)用中實施SOA時遇到的一些比較棘手的數(shù)據(jù)一致性問題和解決方案，對于剛才提到的幾個維度的一致性要求均具有重要的參考價值。

5.1.分布式事務(wù)(基于DTC的分布式事務(wù))

以往包括目前很多項目還是傾向于使用DTC來處理分布式事務(wù)，這個方案多數(shù)適用于一般的企業(yè)應(yīng)用，業(yè)務(wù)、訪問量、數(shù)據(jù)量要求都不是很高的情況下。用DTC很方便，事務(wù)的自動傳播、事務(wù)的自動感知、事務(wù)的自動回滾和提交，這都是中央DTC幫我們管理好了。

由于有中央DTC的統(tǒng)一協(xié)調(diào)，看似好像幫我們解決了很多我們需要考慮的問題，但是它也是整個平臺的致命的瓶頸，一旦DTC由于某個問題出現(xiàn)錯誤，而且這種錯誤都是系統(tǒng)層面的錯誤，很多問題我們是無能為力的。如果出現(xiàn)問題，整個應(yīng)用平臺都無法完成任何一個跨服務(wù)的業(yè)務(wù)流程，這其實很危險，你不無法控制系統(tǒng)的穩(wěn)定性。

這里總結(jié)，DTC用于一般的小型企業(yè)應(yīng)用，不建議用在中等規(guī)模的企業(yè)應(yīng)用中，不是說這個東西不好，而是無法控制它。

5.2.事務(wù)補(bǔ)償(提供正向或反向的操作來讓數(shù)據(jù)在業(yè)務(wù)上是一致的)

世界級SOA專家所編寫的書籍里都提到了使用“補(bǔ)償”操作來完成數(shù)據(jù)的不一致性，當(dāng)我們編寫了一個服務(wù)方法A，就需要一個服務(wù)方法A1的補(bǔ)償接口來完成A服務(wù)的補(bǔ)償操作。但是真實的業(yè)務(wù)情況下很難實施這種看起來好像很優(yōu)美很柔性的設(shè)計。沒有實踐就沒有發(fā)言權(quán)，我們公司的技術(shù)團(tuán)隊就實施過這種方案，但是很不理想，這跟技術(shù)本身及技術(shù)團(tuán)隊沒關(guān)系，只是我們的平臺業(yè)務(wù)太復(fù)雜，很難去“補(bǔ)償”一個已經(jīng)做過的操作。

這當(dāng)然也要看你所面對的項目情況，量變引起質(zhì)變，如果你的各種量都上去了，這個“補(bǔ)償”方案不實際，而且很難在數(shù)據(jù)層面進(jìn)行“補(bǔ)償“?？傊@不是一個中長期的方案。

5.3.異步EDA(基于異步事件流來實現(xiàn)柔性的分布式事務(wù))

EDA簡稱”事件驅(qū)動架構(gòu)“。多個系統(tǒng)之間通過傳播”事件“來驅(qū)動整個業(yè)務(wù)的運轉(zhuǎn)。系統(tǒng)之間沒有緊耦合的同步調(diào)用的操作，都是通過發(fā)出異步的“事件”來通知下一個業(yè)務(wù)環(huán)節(jié)。

可能你會有一個疑問，異步操作，是不是系統(tǒng)之間延遲會很長，其實不是，現(xiàn)在有很多成熟的消息中間件在內(nèi)網(wǎng)內(nèi)幾乎是毫秒級別的延遲，至于跨機(jī)房就看物理上的距離了。

異步操作有很多好處，這里我就不浪費大家時間重復(fù)那些好處。使用EDA實現(xiàn)系統(tǒng)之間的一個松散的事務(wù)關(guān)系，要把控好項目的質(zhì)量，對系統(tǒng)的非功能需求、BUG數(shù)等等可能會影響業(yè)務(wù)操作中斷的地方都要建立起適當(dāng)?shù)臋C(jī)制，讓這些問題盡早的在線下解決。比如可以實施UnitTest、持續(xù)集成等一些敏捷的方法論。

6.總結(jié)

同樣一個工具在于什么人用，真正的工匠都是使用很樸實的工具來雕刻無法超越的藝術(shù)品，這就是工匠情懷。最近對工匠情懷感受越來越深，一直以為自己是一個比較喜歡專的人，這是不是偏離了一個大的方向沖進(jìn)了一個小胡同，直到最近我才領(lǐng)悟，這其實是”軟件工匠“的精神。但是這不代表不考慮全局，這只是一種情懷，一種態(tài)度，對于架構(gòu)也是，對于代碼也是，不要認(rèn)為那些看似無關(guān)緊要的問題就忽視它，帶著工匠精神雕刻它。

參考書籍：《SOA實踐指南》、《SOA概念、技術(shù)與設(shè)計》、《精益軟件》、《UML與模式應(yīng)用》、《軟件預(yù)構(gòu)的藝術(shù)》

Via:作者：王清培

當(dāng)前標(biāo)題：SOA架構(gòu)設(shè)計經(jīng)驗分享—架構(gòu)、職責(zé)、數(shù)據(jù)一致性
文章分享：http://www.muchs.cn/article16/sohegg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、云服務(wù)器、網(wǎng)站收錄、電子商務(wù)、網(wǎng)站營銷、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)