圖2：
組合服務(wù)對下層的應(yīng)用服務(wù)進行了組合，完成了一個基本的業(yè)務(wù)動作，應(yīng)用服務(wù)中是最基本的基礎(chǔ)性的原子性的操作。但是在復(fù)雜的業(yè)務(wù)需求下大部分業(yè)務(wù)功能都需要跨越多個應(yīng)用線來完成一個最外層的企業(yè)動作。提交訂單可能需要穿過很多應(yīng)用線，訂單管理、倉庫、財務(wù)等等環(huán)節(jié)。所以這里我們還需要一個能在最外層對組合服務(wù)進行編排的業(yè)務(wù)服務(wù)。這個編排服務(wù)可以完全是自動化的，通過工作流引擎進行組合自動化來完成，這對企業(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ù)邏輯如果你不進行SOA分層然后將其放入最外層的業(yè)務(wù)服務(wù)中，你把它放入任何一個應(yīng)用線都會使系統(tǒng)調(diào)用混亂不堪。所以問題就是需要進行縱向的劃分層次。如果進行了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)混亂。其實這里的問題就是我們不能用一個維度來進行SOA系統(tǒng)的設(shè)計，本來服務(wù)就具有組合特性，所以適當(dāng)?shù)奶嵘?wù)的層次是有好處的，但是應(yīng)用服務(wù)和組合服務(wù)可以在代碼層面上進行構(gòu)建，而業(yè)務(wù)服務(wù)也叫編排服務(wù)是需要進行物理隔離的，畢竟考慮到系統(tǒng)復(fù)雜度和穩(wěn)定性問題這是值得的。在排查問題，系統(tǒng)性能、穩(wěn)定性等等方面，物理的隔離有一定的作用，畢竟業(yè)務(wù)服務(wù)本來就是來組合多個應(yīng)用線的，這樣做會使整個系統(tǒng)架構(gòu)很清晰。
3.SOA化的重構(gòu)
進行SOA化的實施，大部分情況下都是對現(xiàn)有系統(tǒng)進行重構(gòu)后考慮的，初期企業(yè)發(fā)展階段以快速出原形為首要目標(biāo)，只有當(dāng)系統(tǒng)出現(xiàn)瓶頸了才會考慮運用SOA來解決。但是在這個時候有很多歷史包袱無法解決，進行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行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ù)的組合
在進行系統(tǒng)拆分的時候，對當(dāng)前后端的調(diào)用都進行適當(dāng)?shù)囊?guī)劃，將其分為兩類，一類是應(yīng)用服務(wù)，一類是組合服務(wù)，這兩個服務(wù)是可以在代碼層面上進行抽象。重點是那些調(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ù)中，也會有遷移過來的邏輯，這兩個過程同時進行其實很痛苦，盡量避免這樣同時進行，但是現(xiàn)實是根本不可能，正常都是一起并行推進。如果這兩個過程是同一組團隊負(fù)責(zé)其實還好，畢竟對這塊的代碼、業(yè)務(wù)都比較了解。