基于SpringCloud-微服務(wù)系統(tǒng)設(shè)計(jì)方案(完整資料）(可以直接使用，可編輯優(yōu)秀版資料，歡迎下載）

微服務(wù)系統(tǒng)設(shè)計(jì)方案基于SpringCloud-微服務(wù)系統(tǒng)設(shè)計(jì)方案(完整資料）(可以直接使用，可編輯優(yōu)秀版資料，歡迎下載）微服務(wù)本質(zhì) 微服務(wù)架構(gòu)從本質(zhì)上說其實(shí)就是分布式架構(gòu),與其說是一種新架構(gòu)，不如說是一種微服務(wù)架構(gòu)風(fēng)格。?簡單來說,微服務(wù)架構(gòu)風(fēng)格是要開發(fā)一種由多個小服務(wù)組成的應(yīng)用。每個服務(wù)運(yùn)行于獨(dú)立的進(jìn)程，并且采用輕量級交互.多數(shù)情況下是一個HTTP的資源AＰI.這些服務(wù)具備獨(dú)立業(yè)務(wù)能力并可以通過自動化部署方式獨(dú)立部署。這種風(fēng)格使最小化集中管理，從而可以使用多種不同的編程語言和數(shù)據(jù)存儲技術(shù)。?對于微服務(wù)架構(gòu)系統(tǒng)，由于其服務(wù)粒度小，模塊化清晰，因此首先要做的是對系統(tǒng)整體進(jìn)行功能、服務(wù)規(guī)劃，優(yōu)先考慮如何在交付過程中，從工程實(shí)踐出發(fā)，組織好代碼結(jié)構(gòu)、配置、測試、部署、運(yùn)維、監(jiān)控的整個過程，從而有效體現(xiàn)微服務(wù)的獨(dú)立性與可部署性。 本文將從微服務(wù)系統(tǒng)的設(shè)計(jì)階段、開發(fā)階段、測試階段、部署階段進(jìn)行綜合闡述。?理解微服務(wù)架構(gòu)和理念是核心。系統(tǒng)環(huán)境名稱版本說明ＪDK１。8SpringBoｏtＳprinｇＦrameｗｏrｋRibｂonkａfkaＲabｂiｔMQ微服務(wù)架構(gòu)的挑戰(zhàn)可靠性:由于采用遠(yuǎn)程調(diào)用的方式,任何一個節(jié)點(diǎn)、網(wǎng)絡(luò)出現(xiàn)問題，都將使得服務(wù)調(diào)用失敗，隨著微服務(wù)數(shù)量的增多，潛在故障點(diǎn)也將增多。也就是沒有充分的保障機(jī)制,則單點(diǎn)故障會大量增加.運(yùn)維要求高: ?系統(tǒng)監(jiān)控、高可用性、自動化技術(shù)分布式復(fù)雜性：??網(wǎng)絡(luò)延遲、系統(tǒng)容錯、分布式事務(wù)部署依賴性強(qiáng):? 服務(wù)依賴、多版本問題性能(服務(wù)間通訊成本高）:? 無狀態(tài)性、進(jìn)程間調(diào)用、跨網(wǎng)絡(luò)調(diào)用?數(shù)據(jù)一致性：? 分布式事務(wù)管理需要跨越多個節(jié)點(diǎn)來保證數(shù)據(jù)的瞬時一致性，因此比起傳統(tǒng)的單體架構(gòu)的事務(wù),成本要高得多。另外，在分布式系統(tǒng)中,通常會考慮通過數(shù)據(jù)的最終一致性來解決數(shù)據(jù)瞬時一致帶來的系統(tǒng)不可用。重復(fù)開發(fā)： ?微服務(wù)理念崇尚每個微服務(wù)作為一個產(chǎn)品看待,有自己的團(tuán)隊(duì)開發(fā)，甚至可以有自己完全不同的技術(shù)、框架，那么與其他微服務(wù)團(tuán)隊(duì)的技術(shù)共享就產(chǎn)生了矛盾，重復(fù)開發(fā)的工作即產(chǎn)生了。?沒有最好的，只有最適合自己的。架構(gòu)設(shè)計(jì)思維設(shè)計(jì)?微服務(wù)架構(gòu)設(shè)計(jì)的根本目的是實(shí)現(xiàn)價值交付，微服務(wù)架構(gòu)只有遵循ＤevOps理念方可進(jìn)行的更順暢，思維方式的轉(zhuǎn)變是最重要的。實(shí)現(xiàn)微服務(wù)技術(shù)架構(gòu)，現(xiàn)有產(chǎn)品需要進(jìn)行技術(shù)上的改進(jìn)以及相關(guān)配套服務(wù)的實(shí)現(xiàn)，采用分階段實(shí)施、以及試點(diǎn)產(chǎn)品優(yōu)先實(shí)施的策略，主要包括如下：?一、技術(shù)上的改進(jìn):?1、前后端分離，web前端通過Hｔtｐ/Ｈttps協(xié)議調(diào)用微服務(wù)的APＩ網(wǎng)關(guān)，由AＰI網(wǎng)關(guān)再經(jīng)過路由服務(wù)調(diào)用相應(yīng)的微服務(wù)?２、不同微服務(wù)之間通過REＳT方式互相調(diào)用?3、微服務(wù)之間通過消息中間件實(shí)現(xiàn)消息交互機(jī)制?二、配套服務(wù)與功能實(shí)現(xiàn): 1、需要進(jìn)行相應(yīng)的自動化服務(wù)實(shí)現(xiàn)，包括自動化構(gòu)建、自動化安裝部署、自動化測試、自動化平臺發(fā)布(Ｄｏｃker實(shí)現(xiàn)）?2、管理服務(wù)，對于微服務(wù)架構(gòu)，必須配套相應(yīng)的監(jiān)控與管理服務(wù)、日志管理服務(wù)等?３、協(xié)作服務(wù),運(yùn)用ＤeｖＯｐs思想提升開發(fā)、測試、運(yùn)維的高效溝通與協(xié)作，實(shí)現(xiàn)開發(fā)與運(yùn)維的一體化微服務(wù)架構(gòu)設(shè)計(jì)?

１、我們把整個系統(tǒng)根據(jù)業(yè)務(wù)拆分成若干個子系統(tǒng)或微服務(wù).

2、每個子系統(tǒng)可以部署多個應(yīng)用,多個應(yīng)用之間使用負(fù)載均衡。

３、需要一個服務(wù)注冊中心Eureka，所有的服務(wù)都在注冊中心注冊，負(fù)載均衡也是通過在注冊中心注冊的服務(wù)來使用一定策略來實(shí)現(xiàn)。? Euｒeka可部署多個,進(jìn)行高可用保證。

4、所有的客戶端都通過同一個網(wǎng)關(guān)地址訪問后臺的服務(wù)，通過路由配置ZＵＵＬ網(wǎng)關(guān)來判斷一個URL請求由哪個服務(wù)處理.請求轉(zhuǎn)發(fā)到服務(wù)上的時候使用負(fù)載均衡Ribbｏｎ。

5、服務(wù)之間采用feigｎ進(jìn)行調(diào)用.

6、使用斷路器hyｓtrix,及時處理服務(wù)調(diào)用時的超時和錯誤，防止由于其中一個服務(wù)的問題而導(dǎo)致整體系統(tǒng)的癱瘓。

7、還需要一個監(jiān)控功能，監(jiān)控每個服務(wù)調(diào)用花費(fèi)的時間等.8、使用SpringＣloudＣｏnfiｇ進(jìn)行統(tǒng)一的配置管理，需要考慮與公司的配置管理平臺如何配合使用。?９、Hyｓｔriｘ，監(jiān)控和斷路器.我們只需要在服務(wù)接口上添加Hｙsｔrix標(biāo)簽，就可以實(shí)現(xiàn)對這個接口的監(jiān)控和斷路器功能。

10、HystrixDａshboaｒd,監(jiān)控面板，他提供了一個界面,可以監(jiān)控各個服務(wù)上的服務(wù)調(diào)用所消耗的時間等。

11、Tｕrbiｎe，監(jiān)控聚合，使用Hystｒｉx監(jiān)控,我們需要打開每一個服務(wù)實(shí)例的監(jiān)控信息來查看。而Tｕrbine可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個地方統(tǒng)一查看。這樣就不需要挨個打開一個個的頁面一個個查看。架構(gòu)的可靠性保證:?在關(guān)鍵節(jié)點(diǎn)做主備、集群部署,防止單點(diǎn)故障.待后續(xù)確認(rèn)問題： １、AcｃessＣontrol：Zuｕl網(wǎng)關(guān)提供了相關(guān)控制功能，與我司ＣAS如何結(jié)合使用?2、ConｆigＳｅrver:ＳprinｇCloud提供了遠(yuǎn)程配置中心，與我司的配置管理平臺如何結(jié)合使用設(shè)計(jì)階段總體設(shè)計(jì) 1、功能規(guī)劃：對產(chǎn)品功能進(jìn)行拆分，拆分為若干個微服務(wù)；一個功能可以創(chuàng)建多個微服務(wù)并部署在多個服務(wù)器節(jié)點(diǎn)上,以便進(jìn)行負(fù)載均衡。 2、設(shè)計(jì)原子服務(wù)層,梳理和抽取核心應(yīng)用、公共應(yīng)用，作為獨(dú)立的服務(wù)下沉到核心和公共能力層,逐漸形成穩(wěn)定的服務(wù)中心,使應(yīng)用能更快速的響應(yīng)多變的客戶需求。?3、為每個服務(wù)設(shè)計(jì)API接口(REST方式)?4、為不同的服務(wù)進(jìn)行分類，不同類型的服務(wù)需要的資源不同，可以配置不同的資源,包括CＰU、內(nèi)存、存儲等。服務(wù)拆分原則?1、粒度微小: ?根據(jù)業(yè)務(wù)功能劃分服務(wù)粒度，總的原則是服務(wù)內(nèi)部高內(nèi)聚，服務(wù)之間低耦合。?2、責(zé)任單一： 每個服務(wù)只做一件事，即單一職責(zé)原則。 ３、隔離性原則： ?每個服務(wù)相互隔離，且不互相影響?４、業(yè)務(wù)無關(guān)優(yōu)先原則: ?基礎(chǔ)服務(wù)，是一些基礎(chǔ)組件，與具體的業(yè)務(wù)無關(guān)。比如:短信服務(wù)、郵件服務(wù).這里的服務(wù)最容易劃分出來做微服務(wù)，也是我們第一優(yōu)先級分離出來的服務(wù)。服務(wù)規(guī)劃 為實(shí)現(xiàn)負(fù)載均衡，允許相同的服務(wù)在多個節(jié)點(diǎn)注冊相同的服務(wù)名，不同的端口.如果沒有前期的規(guī)劃，不同的服務(wù)提供者可能會注冊相同的服務(wù)名，導(dǎo)致消費(fèi)者調(diào)用服務(wù)時產(chǎn)生調(diào)用混亂。?因此，需進(jìn)行服務(wù)名的統(tǒng)一規(guī)劃: 1、規(guī)劃期統(tǒng)一制定每個服務(wù)提供者的服務(wù)名或者模塊標(biāo)示。?2、服務(wù)名的命名規(guī)則:ModuleＮaｍｅ_ＳeｒvｉｃeNamｅ，且所有字符小寫，不同單詞之間以下劃線分隔。如用戶管理模塊提供了獲取用戶信息的服務(wù),則命名為：useｒ_ｇｅｔ＿info。?3、新增服務(wù)名時，需要提出申請,審批通過后方可使用，為減少審批復(fù)雜度,可只審批ＭodｕleNａme,即在模塊內(nèi)部可以自由增加服務(wù)名,不需要進(jìn)行審批。開發(fā)策略?總體原則：不同的微服務(wù)需進(jìn)行物理隔離。?１、ＳVN策略：ＳＶN上創(chuàng)建獨(dú)立的分支,不同微服務(wù)的代碼提交不受相互影響; —-—由配置管理員統(tǒng)一控制。 問題:開發(fā)分支與集成分支,都將增加很多,維護(hù)工作量增加. 2、編譯策略：代碼編譯時，各個微服務(wù)獨(dú)立編譯、打包,杜絕直接的依賴；?３、工程構(gòu)建：代碼開發(fā)時,各微服務(wù)創(chuàng)建獨(dú)立的工程,工程之間不能產(chǎn)生直接依賴 ４、持續(xù)集成:每個微服務(wù)獨(dú)立執(zhí)行持續(xù)集成. 5、版本集成:由統(tǒng)一的集成工具，實(shí)現(xiàn)自動化的版本集成,將所有微服務(wù)集成到統(tǒng)一的版本發(fā)布包中。版本策略?每個微服務(wù)可以獨(dú)立制作版本，伴隨著服務(wù)的增多，SVＮ分支增多,版本也將增多，版本管理的復(fù)雜度將成指數(shù)級增加。在服務(wù)之間依賴較多時,每個服務(wù)的升級或降級都將影響其他服務(wù)的正常運(yùn)行。 因此需執(zhí)行如下策略： １、所有服務(wù)的版本制作交由專業(yè)的版本管理員執(zhí)行. 2、采用自動化的版本制作策略，最大程度的減少人工操作.?３、每個服務(wù)的版本必須有詳細(xì)的版本計(jì)劃、版本說明,對于版本說明要制定模板，明確需要提交的內(nèi)容、版本號、SVN標(biāo)簽等。?4、對項(xiàng)目經(jīng)理的要求提升,需對整體的版本計(jì)劃有嚴(yán)格的制定，尤其是版本之間的依賴關(guān)系要非常明確,版本升級、降級的風(fēng)險(xiǎn)評估需完全充分. ５、接口管理：嚴(yán)格執(zhí)行接口管理制度,任何接口的變更必須進(jìn)行審批、發(fā)公告等流程。數(shù)據(jù)庫挑戰(zhàn)與策略 每個微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫,那么后臺管理的聯(lián)合查詢怎么處理？這應(yīng)該是大家會普遍遇到的一個問題,有三種處理方案。?1）嚴(yán)格按照微服務(wù)的劃分來做，微服務(wù)相互獨(dú)立,各微服務(wù)數(shù)據(jù)庫也獨(dú)立，后臺需要展示數(shù)據(jù)時，調(diào)用各微服務(wù)的接口來獲取對應(yīng)的數(shù)據(jù)，再進(jìn)行數(shù)據(jù)處理后展示出來，這是標(biāo)準(zhǔn)的用法，也是最麻煩的用法。?2)將業(yè)務(wù)高度相關(guān)的表放到一個庫中，將業(yè)務(wù)關(guān)系不是很緊密的表嚴(yán)格按照微服務(wù)模式來拆分,這樣既可以使用微服務(wù)，也避免了數(shù)據(jù)庫分散導(dǎo)致后臺系統(tǒng)統(tǒng)計(jì)功能難以實(shí)現(xiàn)，是一個折中的方案。?3)數(shù)據(jù)庫嚴(yán)格按照微服務(wù)的要求來切分，以滿足業(yè)務(wù)高并發(fā),實(shí)時或者準(zhǔn)實(shí)時將各微服務(wù)數(shù)據(jù)庫數(shù)據(jù)同步到ＮoSQＬ數(shù)據(jù)庫中,在同步的過程中進(jìn)行數(shù)據(jù)清洗，用來滿足后臺業(yè)務(wù)系統(tǒng)的使用，推薦使用MｏｎgｏDB、ＨＢａse等。 第一種方案適合業(yè)務(wù)較為簡單的小公司；第二種方案,適合在原有系統(tǒng)之上，慢慢演化為微服務(wù)架構(gòu)的公司；第三種適合大型高并發(fā)的互聯(lián)網(wǎng)公司。?建議，我們當(dāng)前采用第二種方案。負(fù)載均衡 不再采用一般的增加負(fù)載均衡服務(wù)器的方式進(jìn)行負(fù)載均衡，如F５、Ngｉｎx、LVＳ等，而是把負(fù)載均衡的功能以庫的方式集成到服務(wù)消費(fèi)方的進(jìn)程內(nèi),這種方案稱為軟負(fù)載均衡（SoｆｔLoaｄＢalａnｃｉng)或者客戶端負(fù)載均衡.在SｐriｎgＣlｏuｄ中配合Euｒｅkａ的服務(wù)注冊功能，Ribbon子項(xiàng)目則為RＥST客戶端實(shí)現(xiàn)了負(fù)載均衡。?使用Ribｂｏｎ進(jìn)行負(fù)載均衡，其工作原理可以概括為下面四個步驟:Ribbon首先根據(jù)其所在Zoｎe優(yōu)先選擇一個負(fù)載較少的ＥuｒekaSeｒｖer；定期從EurekａServer更新并過濾服務(wù)實(shí)例列表;根據(jù)指定的負(fù)載均衡策略,從可用的服務(wù)器列表中選擇一個服務(wù)實(shí)例的地址;然后通過ReｓtClient進(jìn)行服務(wù)調(diào)用。Ｒibbon本身提供了下面幾種負(fù)載均衡策略:RoundＲobiｎRｕle:

輪詢策略，Ｒiｂｂon以輪詢的方式選擇服務(wù)器,這個是默認(rèn)值.所以示例中所啟動的兩個服務(wù)會被循環(huán)訪問;RandomRule：

隨機(jī)選擇，也就是說Ribｂｏn會隨機(jī)從服務(wù)器列表中選擇一個進(jìn)行訪問;ＢeｓtＡvaiｌablｅRｕｌe：

最大可用策略,即先過濾出故障服務(wù)器后，選擇一個當(dāng)前并發(fā)請求數(shù)最小的；WeightedRespｏnｓeＴｉｍeRｕle:

帶有加權(quán)的輪詢策略，對各個服務(wù)器響應(yīng)時間進(jìn)行加權(quán)處理，然后在采用輪詢的方式來獲取相應(yīng)的服務(wù)器;AvaｉｌabｉlityFｉlteringRulｅ：

可用過濾策略,先過濾出故障的或并發(fā)請求大于閾值一部分服務(wù)實(shí)例，然后再以線性輪詢的方式從過濾后的實(shí)例清單中選出一個；ZonｅAvoidaｎceRule：

區(qū)域感知策略,先使用主過濾條件(區(qū)域負(fù)載器，選擇最優(yōu)區(qū)域)對所有實(shí)例過濾并返回過濾后的實(shí)例清單,依次使用次過濾條件列表中的過濾條件對主過濾條件的結(jié)果進(jìn)行過濾，判斷最小過濾數(shù)（默認(rèn)1)和最小過濾百分比(默認(rèn)0）,最后對滿足條件的服務(wù)器則使用RｏｕnｄＲobinＲule（輪詢方式）選擇一個服務(wù)器實(shí)例。性能策略 １、網(wǎng)絡(luò)優(yōu)化:優(yōu)化組網(wǎng)結(jié)構(gòu)，提升網(wǎng)絡(luò)間通訊性能; 2、配置優(yōu)化：優(yōu)化SpriｎgCloud組件集以及其他組件的配置信息，使得性能最大化.技術(shù)管理策略?微服務(wù)的架構(gòu)理念中指出各微服務(wù)可以獨(dú)立建設(shè)，可以使用不同的技術(shù)、語言、框架等，以便能更快速的使用新技術(shù)、新框架等響應(yīng)特定客戶需求，解決單體應(yīng)用架構(gòu)更新技術(shù)、更新框架時面臨的困難或阻礙。?但這也同時帶來了諸多問題，如下： 1、各服務(wù)是否可以任意使用自己的技術(shù)、自己的組件、框架呢？如果這樣，勢必帶來更大的管理困難、維護(hù)困難、技術(shù)共享困難。 2、公共的方法如何實(shí)現(xiàn)共享？如格式化時間的一個簡單方法需要共享，也需要封裝為一個服務(wù)接口嗎??管理策略: 1、總體原則：仍然需要進(jìn)行統(tǒng)籌考慮，所有組件統(tǒng)一管理,組件放置在產(chǎn)品倉庫中，每個產(chǎn)品或服務(wù)需要共享組件時,從產(chǎn)品倉庫獲取。?2、特殊情況：特殊服務(wù)需要使用特殊的組件、框架,需提出申請，統(tǒng)籌規(guī)劃后進(jìn)行決策。開發(fā)階段服務(wù)的調(diào)用AIP網(wǎng)關(guān)調(diào)用所有服務(wù)通過Zｕｕl網(wǎng)關(guān)進(jìn)行調(diào)用,不允許直接調(diào)用微服務(wù)提供者。Ｚuul可能會成為系統(tǒng)瓶頸，在項(xiàng)目復(fù)雜時可考慮為Zｕul進(jìn)行主備或負(fù)載均衡處理。同步調(diào)用?采用HTTＰREST方式進(jìn)行調(diào)用，針對業(yè)務(wù)需求可以進(jìn)行負(fù)載均衡，負(fù)載均衡的調(diào)用方式有兩種：?1、FeｉgnClieｎt 2、RestＴｅｍplaｔｅ?建議使用ＦｅｉgnClienｔ方式進(jìn)行服務(wù)調(diào)用。?不管是什么方式，他都是通過REＳT接口調(diào)用服務(wù)的http接口,參數(shù)和結(jié)果默認(rèn)都是通過Ｊackson序列化和反序列化。因?yàn)椋觩ｒingMVＣ的RestＣontrｏｌleｒ定義的接口，返回的數(shù)據(jù)都是通過Ｊackｓon序列化成JSON數(shù)據(jù)。異步調(diào)用?rａbbitMq、kａｆka、SprinｇCｌouｄStream均是可以選擇的方案.SprｉngClｏｕｄStreａm，基于Redis、Rabbit、Kafkａ實(shí)現(xiàn)的消息微服務(wù),簡單聲明模型用以在SprinｇCloud應(yīng)用中收發(fā)消息。服務(wù)間調(diào)用的權(quán)限驗(yàn)證一般我們的API接口都需要某種授權(quán)才能訪問,登陸成功以后，然后通過ｔokｅn或者ｃoｏkie等方式才能調(diào)用接口。使用ＳpringCloudＮetｆix框架的話,登錄的時候,把登錄請求轉(zhuǎn)發(fā)到相應(yīng)的用戶服務(wù)上,登陸成功后，會設(shè)置ｃookie或headertoｋeｎ等。然后客戶端接下來的請求就會帶著這些驗(yàn)證信息，從Zuｕl網(wǎng)關(guān)傳到相應(yīng)的服務(wù)上進(jìn)行驗(yàn)證。Zuｕl網(wǎng)關(guān)在把請求轉(zhuǎn)發(fā)到后臺的服務(wù)的時候，會默認(rèn)把一些heａder傳到服務(wù)端，如：Cｏｏkie、Seｔ－Ｃookiｅ、Authorizatｉｏn.這樣,客戶端請求的相關(guān)headerｓ就可以傳遞到服務(wù)端，服務(wù)端設(shè)置的coｏkie也可以傳到客戶端。但是，如果你想禁止某些heaｄer透傳到服務(wù)端，可以在Zｕul網(wǎng)關(guān)的aｐpｌiｃation.yml配置里通過下面的方式禁用:zuul:?routes:?users：

ｐaｔh：／users／*＊

ｓensiｔｉveHｅａders：Coｏkｉe,Sｅt—Coｏkｉe，Authoｒｉｚaｔion

sｅrvicｅＩd:user剛才說了我們的某個服務(wù)有時候需要調(diào)用另一個服務(wù),這時候，這個請求不是客戶端發(fā)起，他的請求的ｈｅaｄer里面也不會有任何驗(yàn)證信息。這時候,要么，通過防火墻等設(shè)置,保證服務(wù)間調(diào)用的接口，只能某幾個地址訪問；要么，就通過某種方式設(shè)置heaｄeｒ。同時,如果你想在某個服務(wù)里面獲得這個請求的真是IP，（因?yàn)檎埱蟮耐ㄟ^網(wǎng)關(guān)轉(zhuǎn)發(fā)而來，你直接通過ｒｅqｕest獲得ｉｐ得到的是網(wǎng)關(guān)的IP），就可以從heaｄerX-Ｆorwarded—Hosｔ獲得.如果想禁用這個hｅader，也可以:zuuｌ.addProｘyHeadｅｒs=falｓe如果你使用RestTemplate的方式調(diào)用，可以在請求里面添加一個有header的Optiｏns。也可以通過如下的攔截器的方式設(shè)置,它對ＲeｓtTemplate方式和FeignCｌｉenｔ的方式都可以起作用:@Beaｎ?pｕblｉｃRequestIｎterceptorrequｅｓtＩnteｒceptor()｛?returnnｅwReqｕestIntｅrｃepｔor（）{?@Overｒiｄｅ?pｕblicｖoiｄａpply（ReｑueｓtTemplaｔeｔemplatｅ){?StringaｕtｈToｋen=ｇetToken(）；?temｐlａt(yī)e.ｈeadｅｒ（AUTH_ＴO(shè)KEＮ_ＨEＡDER,authToｋeｎ）；?｝

｝;

｝服務(wù)編排?主要的作用是減少項(xiàng)目中的相互依賴。比如現(xiàn)在有項(xiàng)目a調(diào)用項(xiàng)目b，項(xiàng)目b調(diào)用項(xiàng)目c．.．一直到h，是一個調(diào)用鏈,那么項(xiàng)目上線的時候需要先更新最底層的h再更新ｇ．。。更新c更新b最后是更新項(xiàng)目a。這只是這一個調(diào)用鏈，在復(fù)雜的業(yè)務(wù)中有非常多的調(diào)用，如果要記住每一個調(diào)用鏈對開發(fā)運(yùn)維人員來說就是災(zāi)難.有這樣一個好辦法可以盡量的減少項(xiàng)目的相互依賴，就是服務(wù)編排,一個核心的業(yè)務(wù)處理項(xiàng)目,負(fù)責(zé)和各個微服務(wù)打交道。比如之前是a調(diào)用ｂ，b掉用c，c調(diào)用ｄ，現(xiàn)在統(tǒng)一在一個核心項(xiàng)目W中來處理,W服務(wù)使用a的時候去調(diào)用b，使用ｂ的時候W去調(diào)用c。 其實(shí)可以理解為面向?qū)ο蟮脑O(shè)計(jì),減少方法之間的一層層嵌套調(diào)用，而采取一個方法進(jìn)行業(yè)務(wù)流程的串聯(lián)，如方法Ｗ實(shí)現(xiàn)一個完整的業(yè)務(wù)處理，則采取下面方式:?fｕnctｉｏnw(） ｛ ?1、調(diào)用方法a; ２、調(diào)用方法b;?3、調(diào)用方法c；?}服務(wù)的熔斷處理?在服務(wù)之間進(jìn)行調(diào)用時，由于各種原因會導(dǎo)致遠(yuǎn)程服務(wù)不可用或壓力過載等異常導(dǎo)致的故障蔓延，此時需要有一種機(jī)制進(jìn)行保護(hù)處理。SｐrinｇＣloud通過Ｎetflix的Hyｓtｒｉx組件實(shí)現(xiàn)熔斷和降級處理解決此問題。斷路器(CriｃuitBrｅakｅr）是一種能夠在遠(yuǎn)程服務(wù)不可用時自動熔斷（打開開關(guān)），并在遠(yuǎn)程服務(wù)恢復(fù)時自動恢復(fù)(閉合開關(guān)）的設(shè)施,ＳpringCloud通過Netflix的Ｈyｓｔrix組件提供斷路器、資源隔離與自我修復(fù)功能。SprinｇcｌoｕdＨystrｉx熔斷器

?統(tǒng)一日志管理?不同微服務(wù)部署在不同節(jié)點(diǎn)上，登錄每個節(jié)點(diǎn)查看日志是比較麻煩的，同時對于需要關(guān)聯(lián)多個微服務(wù)日志聯(lián)合查看分析的情況將更加麻煩.伴隨節(jié)點(diǎn)數(shù)量的增加，如果沒有合適的管理機(jī)制與工具,定位問題、發(fā)現(xiàn)問題的復(fù)雜性將越來越大，將成指數(shù)級增長，因此需要進(jìn)行統(tǒng)一日志管理。 1、建立統(tǒng)一的日志管理規(guī)范； 2、開發(fā)并使用統(tǒng)一的日志組件,為所有微服務(wù)提供統(tǒng)一的日志服務(wù)，由loｇ4j或Ｂlitｚ4j封裝；?3、在每個服務(wù)節(jié)點(diǎn)上部署日志采集Agｅnt組件，由此Aｇent進(jìn)行日志的采集與轉(zhuǎn)發(fā)；?4、建立統(tǒng)一的日志中心，所有日志寫入日志中心.?說明:上述日志的實(shí)現(xiàn)由公司的“日志管理平臺”進(jìn)行實(shí)現(xiàn),采用的是ELK集合框架.?統(tǒng)一監(jiān)控管理 使用Hｙstｒix組件進(jìn)行服務(wù)的監(jiān)控，使用Nagioｓ進(jìn)行服務(wù)器等資源的監(jiān)控。 １、Hystrix,監(jiān)控和斷路器。我們只需要在服務(wù)接口上添加Ｈystｒｉx標(biāo)簽,就可以實(shí)現(xiàn)對這個接口的監(jiān)控和斷路器功能.

２、ＨysｔrixDashboaｒd，監(jiān)控面板，他提供了一個界面，可以監(jiān)控各個服務(wù)上的服務(wù)調(diào)用所消耗的時間等。

3、Turbｉne，監(jiān)控聚合，使用Ｈyｓtrｉx監(jiān)控,我們需要打開每一個服務(wù)實(shí)例的監(jiān)控信息來查看。而Ｔuｒbine可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個地方統(tǒng)一查看。這樣就不需要挨個打開一個個的頁面一個個查看。統(tǒng)一配置管理?實(shí)現(xiàn)各微服務(wù)的統(tǒng)一參數(shù)配置以及版本管理，可采用公司的配置管理平臺或者ＳｐringＣloｕdＣonｆig配置中心。SprｉｎgＣloudConｆig配置中心

? SprｉngCloudConfig就是我們通常意義上的配置中心.SｐringClｏuｄConfig—把應(yīng)用原本放在本地文件的配置抽取出來放在中心服務(wù)器,本質(zhì)是配置信息從本地遷移到云端。從而能夠提供更好的管理、發(fā)布能力。

ＳprinｇCｌoudCｏnfig分服務(wù)端和客戶端，服務(wù)端負(fù)責(zé)將giｔ(svn）中存儲的配置文件發(fā)布成ＲEＳＴ接口,客戶端可以從服務(wù)端ＲESＴ接口獲取配置。但客戶端并不能主動感知到配置的變化,從而主動去獲取新的配置,這需要每個客戶端通過PＯST方法觸發(fā)各自的／refresh。 為解決配置信息能及時通知到各服務(wù),同時減少每個微服務(wù)處理配置信息更新的復(fù)雜度，為此我們通過消息總線來解決此問題,方案如下:Ｇｉt倉庫、CoｎfｉgServｅr、以及微服務(wù)“ＳerviceA"、“SerｖiｃeＢ"的實(shí)例中都引入了SpriｎｇCｌoｕdBus，所以他們都連接到了RａbbitMQ的消息總線上。從Giｔ倉庫中配置的修改到發(fā)起/bus/reｆrｅｓh的POST請求這一步可以通過Giｔ倉庫的WebＨook來自動觸發(fā)。／bｕs/refresh請求不再發(fā)送到具體服務(wù)實(shí)例上，而是發(fā)送給CoｎfｉgSeｒver，并通過desｔinatｉon參數(shù)來指定需要更新配置的服務(wù)或?qū)嵗Ｓ捎谒羞B接到消息總線上的應(yīng)用都會接受到更新請求,所以在WeｂＨｏoｋ中就不需要維護(hù)所有節(jié)點(diǎn)內(nèi)容來進(jìn)行更新，從而解決了通過WｅbＨｏｏｋ來逐個進(jìn)行刷新的問題。分布式sessｉon?采用Redｉｓ作為緩存組件以及sｅssion的共享組件。 RＥSＴ資源響應(yīng)結(jié)構(gòu) 制定規(guī)范和解析方法.APＩ調(diào)用鏈追蹤?微服務(wù)架構(gòu)上通過業(yè)務(wù)來劃分服務(wù)的，通過ＲEＳT調(diào)用，對外暴露的一個接口，可能需要很多個服務(wù)協(xié)同才能完成這個接口功能，如果鏈路上任何一個服務(wù)出現(xiàn)問題或者網(wǎng)絡(luò)超時,都會形成導(dǎo)致接口調(diào)用失敗。隨著業(yè)務(wù)的不斷擴(kuò)張,服務(wù)之間互相調(diào)用會越來越復(fù)雜。SprｉｎgClｏｕdＳleuｔh主要功能就是在分布式系統(tǒng)中提供追蹤解決方案，并且兼容支持了zipｋiｎ,你只需要在pｏm文件中引入相應(yīng)的依賴即可。單元測試 做微服務(wù)架構(gòu)，進(jìn)行系統(tǒng)測試的復(fù)雜度較大,為保證產(chǎn)品質(zhì)量與開發(fā)、測試效率,單元測試是必不可少的.?可采用Moｃk方式進(jìn)行測試模擬，由持續(xù)集成進(jìn)行自動化單元測試的執(zhí)行以及結(jié)果輸出。代碼調(diào)試 對于單體架構(gòu)系統(tǒng)，可直接本地化調(diào)試，但對于微服務(wù)架構(gòu)，接口間的調(diào)用需采用遠(yuǎn)程通訊的方式，也就是說被調(diào)用的服務(wù)必須啟動后方可被調(diào)用，因此當(dāng)微服務(wù)增多時，你可能需要啟動大量的微服務(wù)或者wｅb服務(wù)器，這給本地化調(diào)用與調(diào)試帶來了困難。?解決方案待研究.測試自動化測試單元測試：??由開發(fā)人員實(shí)現(xiàn)。? 采用Mocｋ方式進(jìn)行測試模擬,由持續(xù)集成進(jìn)行自動化單元測試的執(zhí)行以及結(jié)果輸出.業(yè)務(wù)測試：? 開發(fā)進(jìn)行實(shí)現(xiàn),測試也需考慮如何實(shí)現(xiàn)。 ?將多個服務(wù)或業(yè)務(wù)單元進(jìn)行串聯(lián),測試一個完整的業(yè)務(wù),甚至是不同業(yè)務(wù)之間組成的系統(tǒng)測試，需要采用相關(guān)的自動化測試框架執(zhí)行，如ＲｏbotＦrameworｋ自動化測試框架。依賴測試?也可以稱為接口測試或者契約測試,在微服務(wù)逐漸增多的情況下，如何有效保證服務(wù)之間能夠按照接口的約定正常工作,即符合契約,成為微服務(wù)實(shí)施過程中,測試面臨的主要挑戰(zhàn)。 一、開發(fā)自動化的接口測試工具，?1、檢測接口是否滿足約定 2、檢測接口是否發(fā)生變化?３、檢測接口是否可以正常被調(diào)用。 二、測試方法: 采取基于消費(fèi)者驅(qū)動的契約測試，測試架構(gòu)如下： 其優(yōu)勢如下：從價值實(shí)現(xiàn)的角度定義契約從消費(fèi)者使用契約的角度出發(fā),首先保證消費(fèi)者基于此契約是可以實(shí)現(xiàn)價值的,有了這個前提，再使用契約來驗(yàn)證提供者，如果提供者提供的契約同定義的契約一致，則證明提供者提供的契約是能夠?qū)崿F(xiàn)服務(wù)消費(fèi)者的。通過這種方式,使得更聚焦于如何從價值實(shí)現(xiàn)出發(fā).隔離消費(fèi)者和提供者的測試對于契約的消費(fèi)者和提供者可以分開獨(dú)立測試,有效解決傳統(tǒng)集成測試服務(wù)架構(gòu)的弊端,將微服務(wù)的接口測試成本降到最低。 三、測試工具：?Ｐaｃｔ、Ｊaｎus、Ｐacｔo等。系統(tǒng)測試熔斷測試 1、通過停止微服務(wù)的方式測試服務(wù)路由的正確性?2、通過壓力測試，將某個微服務(wù)產(chǎn)生過載等異常，測試服務(wù)熔斷或降級?3、通過壓力測試，測試負(fù)載均衡策略的正確性性能測試?原有本地化的aｐｉ調(diào)用將會變成REST的遠(yuǎn)程調(diào)用,調(diào)用速度勢必受到影響，因此需要對系統(tǒng)性能進(jìn)行考慮以及性能測試，主要影響因素如下:1、網(wǎng)絡(luò):遠(yuǎn)程調(diào)用時受到網(wǎng)絡(luò)通訊速度的影響，這涉及到網(wǎng)絡(luò)速度、網(wǎng)絡(luò)部署以及系統(tǒng)架構(gòu),有相互依賴的服務(wù)應(yīng)采取就近部署原則。2、服務(wù)器:受到遠(yuǎn)程服務(wù)所在服務(wù)器性能的影響。3、數(shù)據(jù)量：數(shù)據(jù)量這里指的是數(shù)據(jù)大小以及數(shù)據(jù)傳輸?shù)拇螖?shù)以及頻率，此時REＳT調(diào)用方式會產(chǎn)生瓶頸，當(dāng)然，最好的方式是避免此種情況發(fā)生,此種場景采取消息中間件的方式異步通訊。持續(xù)集成?１、持續(xù)集成:每個微服務(wù)獨(dú)立執(zhí)行持續(xù)集成。 2、版本集成:由統(tǒng)一的集成工具,實(shí)現(xiàn)自動化的版本集成，將所有微服務(wù)集成到統(tǒng)一的版本發(fā)布包中。?３、持續(xù)集成可制作多種場景的版本，包括測試環(huán)境、開發(fā)環(huán)境、生產(chǎn)環(huán)境。 4、統(tǒng)計(jì)測試覆蓋率等指標(biāo)數(shù)據(jù). 5、工具:Jenkｉns、Sｏnar等。持續(xù)部署?1、通過持續(xù)集成自動制作發(fā)布版本的Dockｅｒ鏡像;?2、將doｃker鏡像自動上傳到dockeｒ容器中。?運(yùn)維階段遠(yuǎn)程升級?微服務(wù)不斷增加后，意味著部署容器也在同步增加,對于后續(xù)升級維護(hù)的工作量將會逐漸增加,開發(fā)統(tǒng)一管理中心,支持遠(yuǎn)程維護(hù)與升級將可減少運(yùn)維的復(fù)雜度.統(tǒng)一配置中心?使用SpringＣloudConfig或者配置管理平臺進(jìn)行統(tǒng)一的配置管理。統(tǒng)一日志中心?使用日志管理平臺進(jìn)行統(tǒng)一的日志采集、日志分析。目錄1前言 41.1企業(yè)ERP系統(tǒng)的需求描述 41.2ERP技術(shù)及應(yīng)用的發(fā)展趨勢 51.2.1B/S架構(gòu)的ERP已經(jīng)盛行 51.2.2SOA架構(gòu)的引入，使ERP全面升級 5平臺化——ERP的柔性大大增強(qiáng) 5與其它信息系統(tǒng)的集成 6整合業(yè)務(wù)流程的監(jiān)測與評估 72傳統(tǒng)ERP產(chǎn)品技術(shù)架構(gòu) 82.1傳統(tǒng)C/S架構(gòu)的ERP系統(tǒng) 82.2B/S架構(gòu)的ERP系統(tǒng) 82.3C/S架構(gòu)和B/S架構(gòu)的優(yōu)缺點(diǎn)分析 92.3.1C/S系統(tǒng)優(yōu)缺點(diǎn) 92.3.2B/S系統(tǒng)優(yōu)缺點(diǎn) 9結(jié)論 103國內(nèi)外最新ERP產(chǎn)品技術(shù)架構(gòu) 103.1主流ERP產(chǎn)品簡要介紹 103.1.1OracleEBusinessSuite 103.1.2SAPNetWeaver 12用友U9 123.2ERP系統(tǒng)架構(gòu)設(shè)計(jì)的共同特點(diǎn) 13基于互聯(lián)網(wǎng)的三層體系架構(gòu) 14面向服務(wù)架構(gòu)（SOA） 14模塊化和組件化的體系架構(gòu) 144基于SOA架構(gòu)的ERP系統(tǒng) 154.1SOA技術(shù)簡介 154.1.1SOA概念及簡介 15基于SOA技術(shù)的體系結(jié)構(gòu) 164.1.3SOA的實(shí)現(xiàn)方式-WebService 194.2基于SOA的ERP系統(tǒng)架構(gòu)設(shè)計(jì) 224.2.1SOA架構(gòu)基礎(chǔ)技術(shù) 224.2.2SOA架構(gòu)設(shè)計(jì)方案 254.2.3SOA架構(gòu)實(shí)現(xiàn) 264.2.4SOA架構(gòu)的服務(wù)管理組件：ESB 274.3ERP系統(tǒng)架構(gòu)技術(shù)的時間線 305系統(tǒng)實(shí)現(xiàn)的關(guān)鍵技術(shù) 325.1關(guān)鍵技術(shù)框架及工具 32三層分布式架構(gòu) 32基于WEB的B/S架構(gòu)開發(fā)技術(shù) 34統(tǒng)一認(rèn)證技術(shù) 34構(gòu)件開發(fā)技術(shù) 36工作流系統(tǒng) 40權(quán)限管理系統(tǒng) 45表單生成技術(shù) 49插件化開發(fā)框架 515.2系統(tǒng)性能優(yōu)化技術(shù) 52分布式技術(shù)應(yīng)用 525.2.2AJAX局部更新 54預(yù)加載技術(shù) 55數(shù)據(jù)庫查詢優(yōu)化 55數(shù)據(jù)庫讀寫分離 565.3系統(tǒng)運(yùn)營部署設(shè)計(jì) 56服務(wù)器集群技術(shù) 56虛擬化數(shù)據(jù)中心技術(shù) 576應(yīng)用云計(jì)算技術(shù)的ERP系統(tǒng) 616.1云計(jì)算技術(shù)簡介 616.1.1IaaS基礎(chǔ)設(shè)施即服務(wù) 626.1.2PaaS平臺及服務(wù) 656.1.3SaaS軟件即服務(wù) 65云計(jì)算產(chǎn)生背景分析 696.2應(yīng)用云計(jì)算技術(shù)的ERP系統(tǒng) 706.2.1SaaS模式的ERP與傳統(tǒng)ERP的比較 706.2.2SaaS模式的ERP系統(tǒng)架構(gòu)設(shè)計(jì) 706.2.3SaaS模式的ERP系統(tǒng)的應(yīng)用前景 726.3云計(jì)算安全設(shè)計(jì) 73云端數(shù)據(jù)存儲加密 73網(wǎng)絡(luò)數(shù)據(jù)傳輸加密 74數(shù)據(jù)安全管理規(guī)范 74云端加密的利與弊 766.4應(yīng)用物聯(lián)網(wǎng)技術(shù)的ERP系統(tǒng) 76物聯(lián)網(wǎng)技術(shù) 76物聯(lián)網(wǎng)應(yīng)用案例—服裝行業(yè) 796.4.3RFID,無線移動數(shù)據(jù)的收集技術(shù) 806.5應(yīng)用移動技術(shù)的ERP系統(tǒng) 81移動ERP系統(tǒng)介紹 81移動ERP系統(tǒng)結(jié)構(gòu)圖 827總結(jié) 848參考文獻(xiàn) 85前言企業(yè)ERＰ系統(tǒng)的需求描述

EＲP實(shí)施的主體――企業(yè)的需求永遠(yuǎn)是ERP技術(shù)發(fā)展的主動力，由于全球一體化進(jìn)程的加劇，使得企業(yè)所面臨的競爭環(huán)境發(fā)生了巨大的變化,對ERP提出了新的需求，具體表現(xiàn)在[50］:

1）全球化市場的發(fā)展與產(chǎn)業(yè)鏈之間合作經(jīng)營生產(chǎn)方式的出現(xiàn)，使得EＲP能支持異地企業(yè)運(yùn)營、異種語言操作和異種貨幣交易；

２）企業(yè)過程重組及協(xié)作方式的變化使得ＥＲＰ能支持基于全球范圍的可重構(gòu)過程的供應(yīng)鏈及供應(yīng)網(wǎng)絡(luò)結(jié)構(gòu)；

3）企業(yè)需要應(yīng)對新生產(chǎn)與經(jīng)營方式的靈活性與敏捷性使得ERＰ也越來越靈活的適應(yīng)多種生產(chǎn)制造方式的管理模式;

4)由于行業(yè)特性越來越明顯，因此ERＰ的行業(yè)化發(fā)展趨勢越來越明顯；

5）企業(yè)的快速發(fā)展使得ERP的柔性越來越高以適應(yīng)企業(yè)的動態(tài)變化;

6）企業(yè)的低成本策略使得ＥRP可以按需配置、大大縮短實(shí)施周期。

IＴ技術(shù)的發(fā)展是推動EＲP發(fā)展的另一驅(qū)動力，畢竟EＲP應(yīng)用是以“技術(shù)導(dǎo)向”為推動的應(yīng)用技術(shù)，具體表現(xiàn)在,計(jì)算機(jī)新技術(shù)的不斷出現(xiàn)將會為ERP提供越來越靈活與強(qiáng)大功能的軟硬件平臺，多層分布式結(jié)構(gòu)、面向?qū)ο蠹夹g(shù)、中間件技術(shù)與Iｎternet的發(fā)展會使ＥRP的功能與性能迅速提高。圖1.1企業(yè)ERP系統(tǒng)結(jié)構(gòu)圖EＲP技術(shù)及應(yīng)用的發(fā)展趨勢B／S架構(gòu)的ERP已經(jīng)盛行

B/S模式是一種全新的軟件系統(tǒng)構(gòu)造技術(shù)。隨著Winｄｏws９8/Ｗｉｎｄowｓ2000將瀏覽器技術(shù)捆綁植入操作系統(tǒng)內(nèi)部，這種結(jié)構(gòu)更成為當(dāng)今應(yīng)用軟件的首選體系結(jié)構(gòu)。顯然Ｂ/S結(jié)構(gòu)應(yīng)用程序相對于傳統(tǒng)的C／S結(jié)構(gòu)應(yīng)用程序?qū)⑹蔷薮蟮倪M(jìn)步。

網(wǎng)絡(luò)應(yīng)用系統(tǒng)的發(fā)展正在改變著EＲP系統(tǒng)的開發(fā)及其實(shí)施方法，傳統(tǒng)ＥＲP體系結(jié)構(gòu)逐漸被由客戶、應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器組成的三層B/S結(jié)構(gòu)所替代,并有了統(tǒng)一的通訊協(xié)議TCP/ＩP和統(tǒng)一的基于Web瀏覽器的用戶界面.B/SERＰ把傳統(tǒng)的依賴于郵件、電話、人盯人的管理方式變革為目標(biāo)導(dǎo)向、流程驅(qū)動、智能的電子商務(wù)流程。并且該B／S架構(gòu)的ERP可以把企業(yè)內(nèi)部流程與企業(yè)外部流程連接起來,與客戶、合作伙伴、供應(yīng)商協(xié)同完成供應(yīng)鏈業(yè)務(wù)操作[52］.SOA架構(gòu)的引入,使ERＰ全面升級SＯA（Serviｃe-ＯrieｎtｅdAｒｃhｉｔectｕre面向服務(wù)架構(gòu))的概念是由Gａrtneｒ公司給出的，Ｇartnｅr對SOA的定義為“客戶端/服務(wù)器的軟件設(shè)計(jì)方法,一項(xiàng)應(yīng)用由軟件服務(wù)和軟件服務(wù)使用者組成……ＳＯA與大多數(shù)通用的客戶端/服務(wù)器模型的不同之處,在于它著重強(qiáng)調(diào)軟件組件的松散耦合，并使用獨(dú)立的標(biāo)準(zhǔn)接口。其核心是:

1)ＳOA是一種軟件架構(gòu)思想，并不是一種產(chǎn)品。

2）SOA的重點(diǎn)是面向服務(wù)，此服務(wù)包括企業(yè)的內(nèi)部與外部的每一個業(yè)務(wù)細(xì)節(jié)，比如企業(yè)中財(cái)務(wù)應(yīng)收發(fā)票的處理就是一個服務(wù)。SＯＡ的思想是把這些服務(wù)從復(fù)雜的環(huán)境中獨(dú)立出來—-組件化封裝,然后通過標(biāo)準(zhǔn)的接口使不同的服務(wù)之間相互調(diào)用。

3)SOＡ是一種軟件架構(gòu)思想,通過使企業(yè)中一個個細(xì)化的服務(wù)標(biāo)準(zhǔn)化，來達(dá)到企業(yè)的ＩT系統(tǒng)跟隨企業(yè)的動態(tài)變化的目的。平臺化-—EＲＰ的柔性大大增強(qiáng)

在ERP應(yīng)用實(shí)施的過程中，用戶的滿意度一直不高。主要原因是產(chǎn)品更新周期加快、市場響應(yīng)要求提高，對ERＰ的個性化要求越來越高,這是導(dǎo)致ＥＲP實(shí)施成功率不高的重要原因之一.

經(jīng)過多年的積累，人們已經(jīng)總結(jié)出了EＲP系統(tǒng)中業(yè)務(wù)的核心,其架構(gòu)、業(yè)務(wù)模型、標(biāo)準(zhǔn)化高的業(yè)務(wù)處理均是可封裝的,如果我們把這部分封裝起來，再開發(fā)出輔助這個平臺的客戶化工具,就可以形成業(yè)務(wù)化平臺。同樣如此,如果對ＥRP進(jìn)行分析、研究，將ERP的相關(guān)部分封裝起來，再加上工具包，就可以形成平臺化的ERP。

平臺級企業(yè)信息解決方案提供了一個軟件平臺,內(nèi)置多種管理軟件組件和快捷的二次開發(fā)工具,其組件可以通過多種語言來開發(fā)，開發(fā)出一個個的小模塊,然后把每一個小模塊獨(dú)立起來建成一個組件，最后把這些組件組裝起來形成最終的成品。那么對這些組件進(jìn)行調(diào)用，管理和刪減、添加及修改，甚至重新構(gòu)架都可以，而這樣對某一部分的改動根本不會影響到其它功能。這就是平臺帶來的靈活性，易操作性，使它在進(jìn)行小的改動時可以直接通過系統(tǒng)上的某些功能來實(shí)現(xiàn),而不必要通過改源代碼的方式來處理，可以降低企業(yè)信息化軟件的開發(fā)難度，提高開發(fā)效率，提高系統(tǒng)的柔性和可擴(kuò)展性。一方面管理信息化廠商通過平臺提供的組件能很方便地滿足用戶個性化的需求，以及用戶在發(fā)展過程中各種各樣變化的需求.另一方面將應(yīng)用軟件的業(yè)務(wù)邏輯和開發(fā)技術(shù)相對分開,使得應(yīng)用軟件的開發(fā)者可以僅關(guān)注應(yīng)用的業(yè)務(wù)任務(wù)，而不必關(guān)注其技術(shù)的實(shí)現(xiàn)。這使管理與業(yè)務(wù)人員參與應(yīng)用軟件的開發(fā)成為可能。

平臺化軟件的基本特性如下:

１）軟件架構(gòu)靈活;

2)核心業(yè)務(wù)標(biāo)準(zhǔn)化；

3)接口標(biāo)準(zhǔn)化，具有很好的兼容性；

４)提供客戶化工具包。與其它信息系統(tǒng)的集成１）ERP與客戶關(guān)系管理的進(jìn)一步整合

ERP將更加面向市場和面向顧客,通過基于知識的市場預(yù)測、訂單處理與生產(chǎn)調(diào)度、基于約束調(diào)度功能等進(jìn)一步提高企業(yè)在全球化市場環(huán)境下更強(qiáng)的優(yōu)化能力;并進(jìn)一步與客戶關(guān)系管理CＲM結(jié)合，實(shí)現(xiàn)市場、銷售、服務(wù)的一體化，使CRＭ的前臺客戶服務(wù)與EＲP后臺處理過程集成，提供客戶個性化服務(wù)，使企業(yè)具有更好的顧客滿意度。2）EＲP與電子商務(wù)、供應(yīng)鏈SCM、協(xié)同商務(wù)的進(jìn)一步整合ERP將面向協(xié)同商務(wù)（ColｌaｂoｒativeＣommeｒcｅ）,支持企業(yè)與貿(mào)易共同體的業(yè)務(wù)伙伴、客戶之間的協(xié)作,支持?jǐn)?shù)字化的業(yè)務(wù)交互過程；ＥRP供應(yīng)鏈管理功能將進(jìn)一步加強(qiáng)，并通過電子商務(wù)進(jìn)行企業(yè)供需協(xié)作，如汽車行業(yè)要求ERＰ的銷售和采購模塊支持用電子商務(wù)或ＥＤI實(shí)現(xiàn)客戶或供應(yīng)商之間的電子訂貨和銷售開單過程；EＲP將支持企業(yè)面向全球化市場環(huán)境，建立供應(yīng)商、制造商與分銷商間基于價值鏈共享的新伙伴關(guān)系，并使企業(yè)在協(xié)同商務(wù)中做到過程優(yōu)化、計(jì)劃準(zhǔn)確、管理協(xié)調(diào)。3)ERP與產(chǎn)品數(shù)據(jù)管理的整合產(chǎn)品數(shù)據(jù)管理PDM（ProdｕctＤataMaｎaｇemeｎt）將企業(yè)中的產(chǎn)品設(shè)計(jì)和制造全過程的各種信息、產(chǎn)品不同設(shè)計(jì)階段的數(shù)據(jù)和文檔組織在統(tǒng)一的環(huán)境中.近年來EＲP軟件商紛紛在ERＰ系統(tǒng)中納入了產(chǎn)品數(shù)據(jù)管理ＰDM功能或?qū)崿F(xiàn)與PＤM系統(tǒng)的集成，增加了對設(shè)計(jì)數(shù)據(jù)、過程、文檔的應(yīng)用和管理，減少了ERＰ龐大的數(shù)據(jù)管理和數(shù)據(jù)準(zhǔn)備工作量,并進(jìn)一步加強(qiáng)了企業(yè)管理系統(tǒng)與ＣＡD、CAM系統(tǒng)的集成,進(jìn)一步提高了企業(yè)的系統(tǒng)集成度和整體效率.４）ERP與制造執(zhí)行系統(tǒng)的整合為了加強(qiáng)ERＰ對于生產(chǎn)過程的控制能力,改變ERP"重計(jì)劃,輕控制”的弱點(diǎn)，將進(jìn)一步加強(qiáng)"事前計(jì)劃、事中控制、事后審核"的功能,ERP將與制造執(zhí)行系統(tǒng)MES（ManufactｕringｅxｅcutivｅSystｅｍ）、車間層操作控制系統(tǒng)ＳFC更緊密的結(jié)合，形成實(shí)時化的EＲＰ/ＭES／SFＣ系統(tǒng)。該趨勢在流程工業(yè)企業(yè)的管控一體化系統(tǒng)中體現(xiàn)得最為明顯。5）ERP與工作流管理系統(tǒng)的進(jìn)一步整合全面的工作流規(guī)則保證與時間相關(guān)的業(yè)務(wù)信息能夠自動地在正確時間傳送到指定的地點(diǎn)。EＲP的工作流管理功能將進(jìn)一步增強(qiáng),通過工作流實(shí)現(xiàn)企業(yè)的人員、財(cái)務(wù)、制造與分銷間的集成,并能支持企業(yè)經(jīng)營過程的重組，也使ＥRＰ的功能可以擴(kuò)展到辦公自動化和業(yè)務(wù)流程控制方面。6)EＲP與企業(yè)知識門戶進(jìn)一步整合企業(yè)知識門戶（EnterｐｒisｅＫｎowledｇeＰortａl，EＫP）所關(guān)注的是企業(yè)內(nèi)部員工和信息內(nèi)容，它的核心是知識管理(KＭ）,通過與ERＰ系統(tǒng)的集成，使得企業(yè)內(nèi)任何員工都可以實(shí)時地與工作團(tuán)隊(duì)中的其他成員取得聯(lián)系、尋找到能夠提供幫助的專家或者快速連接到相關(guān)的知識，它的建立和使用可以大大提高企業(yè)范圍內(nèi)的知識共享，并由此提高企業(yè)員工的工作效率。

整合業(yè)務(wù)流程的監(jiān)測與評估“用于測量成功的業(yè)務(wù)應(yīng)用解決方案是連續(xù)改進(jìn)的關(guān)鍵:財(cái)務(wù)表現(xiàn)的共享，SC效力，知識資本的價值以及顧客的滿意度都是新的評測方法。"――Gartｎer.

傳統(tǒng)ERP產(chǎn)品技術(shù)架構(gòu)傳統(tǒng)Ｃ/S架構(gòu)的ERP系統(tǒng)

信息系統(tǒng)架構(gòu)示意圖：

1)一層架構(gòu)：客戶端、應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器都在同一臺機(jī)器上部署；

２)兩層架構(gòu):數(shù)據(jù)庫服務(wù)和應(yīng)用服務(wù)在同一臺服務(wù)器上部署,客戶端訪問服務(wù)器上的資源或數(shù)據(jù);

3）

三層架構(gòu)：應(yīng)用服務(wù)和數(shù)據(jù)庫服務(wù)分離,分別部署在不同的服務(wù)器上,應(yīng)用服務(wù)采取集群部署,達(dá)到性能上的需求.圖2．１不同分級層次的系統(tǒng)架構(gòu)圖

從企業(yè)信息系統(tǒng)架構(gòu)設(shè)計(jì)看，三層分布式架構(gòu)是一種典型應(yīng)用；甚至可以過渡到多層分布式架構(gòu),如擴(kuò)展出緩存服務(wù)、負(fù)載均衡服務(wù)等；這些都是用戶對系統(tǒng)快速響應(yīng)和系統(tǒng)可靠性的需求。B/S架構(gòu)的ERP系統(tǒng)B/S架構(gòu)的ERP系統(tǒng)的出現(xiàn)使得傳統(tǒng)的ＥRＰ系統(tǒng)成為互聯(lián)網(wǎng)應(yīng)用,用戶借助網(wǎng)絡(luò)的方便快捷,可以隨時隨地辦公,處理業(yè)務(wù)數(shù)據(jù)。現(xiàn)代企業(yè)普通存在多區(qū)域分支機(jī)構(gòu)，或者業(yè)務(wù)人員需要差旅或在家辦公，傳統(tǒng)的C/S架構(gòu)日益不能滿足移動辦公的需要，B／S架構(gòu)的ＥRP系統(tǒng)剛好可以解決這一需要.圖２。２Ｂ/S架構(gòu)的ERＰ系統(tǒng)部署圖C/S架構(gòu)和B/Ｓ架構(gòu)的優(yōu)缺點(diǎn)分析C/S系統(tǒng)優(yōu)缺點(diǎn)C/S模式的優(yōu)點(diǎn)[１]：１）由于客戶端實(shí)現(xiàn)與服務(wù)器的直接相連，沒有中間環(huán)節(jié)，因此響應(yīng)速度快。(當(dāng)數(shù)據(jù)少時，C/S在局域網(wǎng)內(nèi)響應(yīng)快；當(dāng)數(shù)據(jù)超過十萬時,C/S軟件變慢,B／S軟件能維持穩(wěn)定速度)２)操作界面交互性強(qiáng)、控件組件形式多樣,可以充分滿足客戶快速操作的要求。3)Ｃ/Ｓ結(jié)構(gòu)的管理信息系統(tǒng)能實(shí)現(xiàn)的復(fù)雜的數(shù)據(jù)處理操作，不用過多考慮網(wǎng)絡(luò)的不穩(wěn)定性。C／S模式的缺點(diǎn)：1)需要專門的客戶端安裝程序，分布功能弱,針對點(diǎn)多面廣且不具備網(wǎng)絡(luò)條件的用戶群體，不能夠?qū)崿F(xiàn)快速部署安裝和配置。2)兼容性差,對于不同的開發(fā)工具，具有較大的局限性。若采用不同工具,需要重新改寫程序,跨平臺難度大，無法輕易實(shí)現(xiàn)Winｄｏws、Liｎuｘ、iOＳ系統(tǒng)的同時開發(fā)和部署。3）開發(fā)成本較高,需要具有一定專業(yè)水準(zhǔn)的技術(shù)人員才能完成。(就開發(fā)小型企業(yè)管理軟件,針對內(nèi)部使用的系統(tǒng)而言，C／S開發(fā)人員比Ｂ/S開發(fā)人員的成本低了許多）。B/Ｓ系統(tǒng)優(yōu)缺點(diǎn)B/S結(jié)構(gòu)的優(yōu)點(diǎn)：1)是互聯(lián)網(wǎng)應(yīng)用,具有分布性特點(diǎn),可以隨時隨地進(jìn)行查詢、瀏覽等業(yè)務(wù)處理。2)業(yè)務(wù)擴(kuò)展簡單方便，通過增加網(wǎng)頁即可增加服務(wù)器功能。3）維護(hù)簡單方便，只需要改變網(wǎng)頁，即可實(shí)現(xiàn)所有用戶的同步更新.4）開發(fā)簡單，共享性強(qiáng)。

B/S結(jié)構(gòu)的缺點(diǎn):１）操作是以鼠標(biāo)為最基本的操作方式,無法滿足快速操作的要求，尤其是在大量數(shù)據(jù)錄入操作、復(fù)雜交互的情況下，需要提升交互設(shè)計(jì)能力。２)頁面加載刷新時，響應(yīng)速度受網(wǎng)絡(luò)連接的穩(wěn)定性影響。結(jié)論

目前，從架構(gòu)設(shè)計(jì)來看,ERP系統(tǒng)采用B/Ｓ架構(gòu)和Ｃ/S架構(gòu)是并存存在的,B/Ｓ的架構(gòu)的系統(tǒng)更有發(fā)展前景，從長遠(yuǎn)來看，由于互聯(lián)網(wǎng)發(fā)展,網(wǎng)絡(luò)帶寬提升，HＴＭＬ５技術(shù)出現(xiàn)的等因素，B/S的架構(gòu)的系統(tǒng)是將來的發(fā)展趨勢。國內(nèi)外最新ERＰ產(chǎn)品技術(shù)架構(gòu)主流ERP產(chǎn)品簡要介紹OracｌeＥBｕsｉnessSｕiteOrａcleＥBS產(chǎn)品介紹

ＯｒａｃleEBS是OracleE-BusinessＳuite的縮寫,是Orａcle公司的EＲP產(chǎn)品，全球銷量僅次于SAP（另一款ERＰ產(chǎn)品）.OraｃleEBS是一整套企業(yè)級應(yīng)用軟件，包括：采購管理、庫存管理、銷售管理、車間管理、物料清單及工藝管理、生產(chǎn)計(jì)劃、成本管理、應(yīng)付賬款管理、應(yīng)收賬款管理、現(xiàn)金管理、總帳管理、項(xiàng)目會計(jì)、項(xiàng)目制造、客戶關(guān)系管理、供應(yīng)商門戶等模塊。純互聯(lián)網(wǎng)技術(shù)架構(gòu)Oraclｅ電子商務(wù)套件采用標(biāo)準(zhǔn)的100%基于互聯(lián)網(wǎng)的三層體系架構(gòu);無論是數(shù)據(jù)庫層、應(yīng)用層以及最前端的最終用戶操作界面都１00％支持基于JAVA的先進(jìn)互聯(lián)網(wǎng)技術(shù)［37］。

Ｏraｃle電子商務(wù)套件的技術(shù)架構(gòu)特點(diǎn),提供了軟件系統(tǒng)基于數(shù)據(jù)中心運(yùn)行的集中管理基礎(chǔ)。使所有關(guān)于軟件系統(tǒng)的推廣、升級和日常維護(hù)工作可以基于數(shù)據(jù)中心進(jìn)行，從而達(dá)到最大限度地降低客戶端軟硬件和維護(hù)成本,降低服務(wù)器端的軟件維護(hù)工作內(nèi)容。圖3.1Oracle應(yīng)用軟件技術(shù)架構(gòu)模塊化開放架構(gòu)Oraｃｌe電子商務(wù)套件應(yīng)用產(chǎn)品采用模塊化和組件化的先進(jìn)軟件技術(shù)體系架構(gòu),應(yīng)用軟件產(chǎn)品可以細(xì)化成為許多細(xì)粒度的模塊,不同的客戶應(yīng)用可以選擇不同的組件或模塊組合形成適合于企業(yè)需求的軟件平臺方案；基于同一共享數(shù)據(jù)庫和統(tǒng)一數(shù)據(jù)模型的數(shù)據(jù)層面的高度集成架構(gòu),保證各應(yīng)用模塊之間的緊密無縫集成和平滑的業(yè)務(wù)流轉(zhuǎn)［3７］.圖3。2Oracle電子商務(wù)套件的模塊化開放架構(gòu)SAPＮetＷeａverSAPNetWeａvｅr產(chǎn)品介紹

SAＰNｅtWｅaver是SＡP的集成技術(shù)平臺和自從SAPＢusiｎeｓsSuｉte以來的所有SAP應(yīng)用的技術(shù)基礎(chǔ)。SAPＮetWeａver是一個面向服務(wù)的應(yīng)用和集成平臺。SＡＰNetWｅａver為SＡP的應(yīng)用提供開發(fā)和運(yùn)行環(huán)境,也可以用來和其它應(yīng)用和系統(tǒng)進(jìn)行自定義的開發(fā)和集成。SAPNeｔＷｅａver是使用開放標(biāo)準(zhǔn)和事實(shí)上的工業(yè)標(biāo)準(zhǔn)進(jìn)行開發(fā)的，可以用iｃrosoft?NET，Ｓun燡avaＥＥ，和IＢM燱ebSphere等這些技術(shù)平臺進(jìn)行擴(kuò)展和互操作［44]。SAPNeｔWｅaveｒ技術(shù)架構(gòu)

SAP企業(yè)系統(tǒng)架構(gòu)是以SOA架構(gòu)技術(shù)作為基礎(chǔ)框架進(jìn)行開發(fā)的。EＲP，CRM,SCM，SAＰBusiｎessSｕite，SRＭ，PLM系統(tǒng)都是獨(dú)立的子系統(tǒng)，這些系統(tǒng)之間的交互都是通過SOＡ服務(wù)進(jìn)行.圖3.3SＡP企業(yè)系統(tǒng)架構(gòu)用友Ｕ9用友U9產(chǎn)品介紹

用友Ｕ9完全基于SOA架構(gòu)的世界級企業(yè)管理軟件,用友U9面向快速發(fā)展與成長的中大型制造企業(yè)復(fù)雜應(yīng)用，以“實(shí)時企業(yè)、全球商務(wù)”為核心理念，完全適應(yīng)多組織供應(yīng)鏈協(xié)同、多工廠制造協(xié)同、產(chǎn)業(yè)鏈協(xié)同、產(chǎn)品事業(yè)部和業(yè)務(wù)中心的管理模式，更能支持多生產(chǎn)模式的混合生產(chǎn)與規(guī)劃、多經(jīng)營模式的混合管理、精益生產(chǎn)、全面成本、跨國財(cái)務(wù)等深度應(yīng)用，具有高度靈活的產(chǎn)品架構(gòu),幫助企業(yè)快速響應(yīng)變化,支持經(jīng)營、業(yè)務(wù)與管理模式的創(chuàng)新.用友U9技術(shù)架構(gòu)

UFIDAU９完全采用面向服務(wù)架構(gòu)（SＯA）,實(shí)現(xiàn)了全程模型驅(qū)動開發(fā)（ＭDD）模式，達(dá)到降低集成和開發(fā)成本的目的。UＡP使企業(yè)管理軟件具有多項(xiàng)新技術(shù)應(yīng)用特點(diǎn)：企業(yè)信息資源變得可重用、透明化，并且系統(tǒng)具有高可擴(kuò)展性,讓業(yè)務(wù)處理更加高效、簡潔、安全。UAP還提供了統(tǒng)一的集成開發(fā)環(huán)境(IDE)，用戶可以使用包括企業(yè)建模、領(lǐng)域建模、服務(wù)設(shè)計(jì)、ＵI設(shè)計(jì)、報(bào)表設(shè)計(jì)、規(guī)則設(shè)計(jì)、數(shù)據(jù)庫設(shè)計(jì)等全方位的設(shè)計(jì)器，并通過可視化的界面和友好的交互操作,自動生成用戶所需要的各種服務(wù)部件.UAP完全支持企業(yè)級的集成與應(yīng)用協(xié)同,如Offｉｃｅ集成、移動商務(wù)、企業(yè)搜索、智能客戶端等多項(xiàng)領(lǐng)域[３5]。圖3．4用友Ｕ9技術(shù)架構(gòu)ERＰ系統(tǒng)架構(gòu)設(shè)計(jì)的共同特點(diǎn)

通過國內(nèi)外最新ＥRP產(chǎn)品的功能及技術(shù)架構(gòu)比較，得出:基于SＯA架構(gòu)的技術(shù)框架是共同采用的，而且更加強(qiáng)調(diào)了多設(shè)備的支持，完全基于互聯(lián)網(wǎng)模式的系統(tǒng)。產(chǎn)品名稱是否B/S是否SOA架構(gòu)是否模塊化構(gòu)建是否支持移動設(shè)備是否分布式部署OraｃleEBusiｎessＳuitｅ是是是支持是SAPNｅｔWeaver是是是支持是用友U9是是是支持是金蝶ＥAS是是是支持是ＯpｅnＥＲP(開源)是下一版本支持完全模塊化支持是表3。1各主流ERP產(chǎn)品系統(tǒng)架構(gòu)比較基于互聯(lián)網(wǎng)的三層體系架構(gòu)

采用標(biāo)準(zhǔn)的１00%基于互聯(lián)網(wǎng)的三層體系架構(gòu),無論是數(shù)據(jù)庫層、應(yīng)用層以及最前端的最終用戶操作界面都1０0%支持WEB的互聯(lián)網(wǎng)技術(shù)，特別是應(yīng)用層，直接采用互聯(lián)網(wǎng)先進(jìn)技術(shù),不需要任何中間轉(zhuǎn)換過程,在體現(xiàn)先進(jìn)互聯(lián)網(wǎng)技術(shù)的同時,最大限度的減少了中間環(huán)節(jié)，保證了系統(tǒng)處理的高性能和高穩(wěn)定性。面向服務(wù)架構(gòu)(ＳOA)

完全采用面向服務(wù)架構(gòu)(SOA)，實(shí)現(xiàn)了全程模型驅(qū)動開發(fā)（ＭDD）模式，達(dá)到降低更加強(qiáng)調(diào)系統(tǒng)的基礎(chǔ)，采用松耦合，降低系統(tǒng)的耦合度。SＯA的實(shí)現(xiàn)方式都是采用了基于Http協(xié)議的WebＳｅrｖice的技術(shù)，數(shù)據(jù)交換格式采用XML，SＯＡＰ。模塊化和組件化的體系架構(gòu)模塊化和組件化的先進(jìn)軟件技術(shù)體系架構(gòu)，應(yīng)用軟件產(chǎn)品可以細(xì)化成為許多細(xì)粒度的模塊,不同的客戶應(yīng)用可以選擇不同的組件或模塊組合形成適合于企業(yè)需求的軟件平臺方案；基于同一共享數(shù)據(jù)庫和統(tǒng)一數(shù)據(jù)模型的數(shù)據(jù)層面的高度集成架構(gòu),保證各應(yīng)用模塊之間的緊密無縫集成和平滑的業(yè)務(wù)流轉(zhuǎn)。?基于SOＡ架構(gòu)的EＲP系統(tǒng)SOA技術(shù)簡介SOA概念及簡介SOA的基本概念

面向服務(wù)的體系結(jié)構(gòu)(Sｅrviｃe-OｒieｎtedＡrｃhitecture，SOA）是一個組件模型，它將應(yīng)用程序的不同功能單元(稱為服務(wù)）通過這些服務(wù)之間定義良好的接口和契約聯(lián)系起來。接口是采用中立的方式進(jìn)行定義的，它應(yīng)該獨(dú)立于實(shí)現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言。這使得構(gòu)建在各種各樣的系統(tǒng)中的服務(wù)可以使用一種統(tǒng)一和通用的方式進(jìn)行交互［26］。簡介SOＡ(Seｒvｉcｅ-OrｉeｎtedＡrchitｅctｕre），面向服務(wù)架構(gòu)，它可以根據(jù)需求通過網(wǎng)絡(luò)對松散耦合的粗粒度應(yīng)用組件進(jìn)行分布式部署、組合和使用。服務(wù)層是ＳＯＡ的基礎(chǔ)，可以直接被應(yīng)用調(diào)用,從而有效控制系統(tǒng)中與軟件代理交互的人為依賴性。SＯＡ是一種粗粒度、松耦合服務(wù)架構(gòu),服務(wù)之間通過簡單、精確定義接口進(jìn)行通訊,不涉及底層編程接口和通訊模型。SOA可以看作是B/S模型、ＸML／WebＳervice技術(shù)之后的自然延伸。SOA技術(shù)的優(yōu)勢

通過ＳOA思想的引入,使得ERＰ軟件可以做到［50］：

1）支持異構(gòu)集成

所謂異構(gòu)環(huán)境,包括四個層次,硬件平臺、操作系統(tǒng)、數(shù)據(jù)庫、應(yīng)用軟件。如果一套硬件、一套操作系統(tǒng)、一套數(shù)據(jù)庫、一套應(yīng)用軟件能夠面面俱到的解決集團(tuán)企業(yè)的所有管理問題,那是再好不過了.但現(xiàn)實(shí)中是不可能的，更普遍的是,不同的應(yīng)用往往選擇不同的平臺和應(yīng)用系統(tǒng)，以便充分發(fā)揮各個廠商的特長。支持SOA的ERP系統(tǒng)為集團(tuán)企業(yè)的信息化提供了伸縮空間，企業(yè)可以根據(jù)需要選擇最合適的解決方案.

2)降低企業(yè)的IT成本

以往多數(shù)企業(yè)在建設(shè)企業(yè)的ERＰ系統(tǒng)時是從項(xiàng)目的角度出發(fā)的,比如ＥRＰ項(xiàng)目、CＲＭ項(xiàng)目等，事后當(dāng)企業(yè)的IＴ系統(tǒng)越來越多的時候，才會考慮系統(tǒng)的集成問題,但這時候往往集成的難度就很大了.而SOA要求企業(yè)在建設(shè)ＩT系統(tǒng)之初就要考慮這些問題，也就是要考慮服務(wù)之間的接口問題。這樣就會使企業(yè)的IＴ成本大大降低。

同時，SOＡ將改變以往的軟件購買模式。目前，多數(shù)企業(yè)在購買軟件時往往是成熟性軟件，需一個模塊或一個系統(tǒng)的購買，企業(yè)在購買時往往無法將那些企業(yè)不需要的功能剔除出去，這樣，企業(yè)就不得不為此多付出資金、培訓(xùn)成本等許多不必要的成本。而支持SOA的集團(tuán)財(cái)務(wù)軟件則可以幫助企業(yè)實(shí)現(xiàn)真正的按需購買，企業(yè)需要什么功能就購買相應(yīng)的服務(wù),幫助企業(yè)避免不必要的支出。

3）實(shí)現(xiàn)企業(yè)的動態(tài)變革

支持SOA的集團(tuán)財(cái)務(wù)系統(tǒng)使企業(yè)的IT人員不必太多的關(guān)心企業(yè)IT系統(tǒng)的底層技術(shù)，而更多的去考慮集團(tuán)財(cái)務(wù)的業(yè)務(wù)處理以及財(cái)務(wù)業(yè)務(wù)與ＩT的接合。同時，以往企業(yè)在開發(fā)集團(tuán)財(cái)務(wù)系統(tǒng)時，在重復(fù)功能上浪費(fèi)了大量的人力與財(cái)力,同時系統(tǒng)在開發(fā)完成后，如果企業(yè)業(yè)務(wù)變化，系統(tǒng)將很難更改或者更改的成本很高.而SOA面對的是一個個獨(dú)立的服務(wù)，服務(wù)之間可以通過標(biāo)準(zhǔn)接口來相互調(diào)用，這樣企業(yè)在重復(fù)功能上就可以直接通過接口調(diào)用,而不必去重新開發(fā).企業(yè)的業(yè)務(wù)發(fā)生變化時,只需要修改相對應(yīng)的服務(wù)即可，降低了修改的難度與復(fù)雜度，保證了企業(yè)的IT系統(tǒng)的動態(tài)變化。基于ＳＯA技術(shù)的體系結(jié)構(gòu)ＳOA是松耦合的系統(tǒng)

這種具有中立的接口定義（沒有強(qiáng)制綁定到特定的實(shí)現(xiàn)上)的特征稱為服務(wù)之間的松耦合。松耦合系統(tǒng)的好處有兩點(diǎn)：

1)是它的靈活性，當(dāng)組成整個應(yīng)用程序的每個服務(wù)的內(nèi)部結(jié)構(gòu)和實(shí)現(xiàn)逐漸地發(fā)生改變時，它能夠繼續(xù)存在.

２)而另一方面，緊耦合意味著應(yīng)用程序的不同組件之間的接口與其功能和結(jié)構(gòu)是緊密相連的，因而當(dāng)需要對部分或整個應(yīng)用程序進(jìn)行某種形式的更改時,它們就顯得非常脆弱。對松耦合的系統(tǒng)的需要來源于業(yè)務(wù)應(yīng)用程序需要根據(jù)業(yè)務(wù)的需要變得更加靈活,以適應(yīng)不斷變化的環(huán)境，比如經(jīng)常改變的政策、業(yè)務(wù)級別、業(yè)務(wù)重點(diǎn)、合作伙伴關(guān)系、行業(yè)地位以及其他與業(yè)務(wù)有關(guān)的因素,這些因素甚至?xí)绊憳I(yè)務(wù)的性質(zhì).我們稱能夠靈活地適應(yīng)環(huán)境變化的業(yè)務(wù)為按需（Onｄemａｎd）業(yè)務(wù),在按需業(yè)務(wù)中,一旦需要，就可以對完成或執(zhí)行任務(wù)的方式進(jìn)行必要的更改.SOA系統(tǒng)原型的一個典型例子是通用對象請求代理體系結(jié)構(gòu)（ＣoｍｍonOｂjectRequestBroｋｅｒAｒchiteｃtuｒｅ，COＲBA），它已經(jīng)出現(xiàn)很長時間了，其定義的概念與SOＡ相似。然而,現(xiàn)在的SＯA已經(jīng)有所不同了，通過使用基于ＸML的語言（稱為Web服務(wù)描述語言（WebServｉcesDefｉnitiｏnLａｎguaｇe，WSDＬ））來描述接口,服務(wù)已經(jīng)轉(zhuǎn)到更加動態(tài)且更靈活的接口系統(tǒng)中，非以前CＯＲＢＡ中的接口描述語言（IntｅrfacｅDefiｎitｉonＬanguaｇe，IDＬ）可比了.SＯA體系結(jié)構(gòu)作用

傳統(tǒng)企業(yè)（數(shù)據(jù)庫）應(yīng)用軟件產(chǎn)品,如MRP、ERP、OＡ系統(tǒng)等,在設(shè)計(jì)或架構(gòu)上都是緊偶合、封閉式、自成體系,屬于一次性投入一次性完結(jié)的產(chǎn)品。這樣的產(chǎn)品很難適應(yīng)或快速響應(yīng)市場或客戶靈活多變的需求，以及后續(xù)的擴(kuò)展.在這樣的市場、及客戶需求下，從而催生了軟件產(chǎn)品一種新的設(shè)計(jì)或架構(gòu)的理念：面向服務(wù)架構(gòu)（SOA架構(gòu)）。

對SOＡ的需要來源于需要使業(yè)務(wù)IT系統(tǒng)變得更加靈活,以適應(yīng)業(yè)務(wù)中的改變。通過允許強(qiáng)定義的關(guān)系和依然靈活的特定實(shí)現(xiàn)，IT系統(tǒng)既可以利用現(xiàn)有系統(tǒng)的功能，又可以準(zhǔn)備在以后做一些改變來滿足它們之間交互的需要。

SOA是一場革命。一個應(yīng)用程序的業(yè)務(wù)邏輯(bｕsinesslogic）或某些單獨(dú)的功能被模塊化并作為服務(wù)呈現(xiàn)給消費(fèi)者或客戶端。這些服務(wù)的關(guān)鍵是他們的松耦合特性。例如，服務(wù)的接口和實(shí)現(xiàn)相獨(dú)立。應(yīng)用開發(fā)人員或者系統(tǒng)集成者可以通過組合一個或多個服務(wù)來構(gòu)建應(yīng)用，而無須理解服務(wù)的底層實(shí)現(xiàn)。舉例來說，一個服務(wù)可以用．NET或J2EE來實(shí)現(xiàn),而使用該服務(wù)的應(yīng)用程序可以在不同的平臺之上,使用的語言也可以不同。讓SOA系統(tǒng)適應(yīng)改變的能力是最重要的部分，對于開發(fā)人員來說，這樣的改變無論是在他們工作的范圍之內(nèi)還是在他們工作的范圍之外都有可能發(fā)生，這取決于是否有改變需要知道接口是如何定義的以及它們相互之間如何進(jìn)行交互.與開發(fā)人員不同的是，架構(gòu)師的作用就是引起對SOA模型大的改變.這種分工,就是讓開發(fā)人員集中精力于創(chuàng)建作為服務(wù)定義的功能單元，而讓架構(gòu)師和建模人員集中精力于如何將這些單元適當(dāng)?shù)亟M織在一起，它已經(jīng)有十多年的歷史了，通常用統(tǒng)一建模語言(UｎiｖｅrsａlＭｏｄeliｎｇLaｎguagｅ，ＵML)，并且描述成模型驅(qū)動的體系結(jié)構(gòu)(Moｄel－DrivｅnＡrｃhiｔectuｒe，ＭDA）。SOA架構(gòu)的定義或特性

SOA架構(gòu)，是一種粗粒度、開放式、松耦合的服務(wù)結(jié)構(gòu),要求軟件產(chǎn)品在開發(fā)過程中，按照相關(guān)的標(biāo)準(zhǔn)或協(xié)議，進(jìn)行分層開發(fā).通過這種分層設(shè)計(jì)或架構(gòu)體系可以使軟件產(chǎn)品變得更加彈性和靈活，且盡可能的與第三方軟件產(chǎn)品互補(bǔ)兼容,以達(dá)到快速擴(kuò)展，滿足或響應(yīng)市場或客戶需求的多樣化、多變性。一個典型的SOA架構(gòu)示意如下：圖４。1SOA架構(gòu)的系統(tǒng)圖示基于SOA技術(shù)架構(gòu)的價值未來企業(yè)的應(yīng)變之道

持續(xù)增長的客戶需求、瞬息萬變的市場和日趨激烈的全球化競爭,使得企業(yè)必須不斷提升自身IT及企業(yè)管理系統(tǒng)的敏捷性和適應(yīng)性.現(xiàn)在，每個企業(yè)都需要把握業(yè)務(wù)流程發(fā)展的變革，預(yù)測業(yè)務(wù)環(huán)境的變化,以便對競爭者做出快速響應(yīng),確保企業(yè)的生存、發(fā)展和快速成長[２7］.

面向服務(wù)架構(gòu)技術(shù)（Sｅｒviｃe—OrｉeｎtｅｄAｒｃhiｔecｔuｒe,SＯA)的出現(xiàn)，標(biāo)志著設(shè)計(jì)、開發(fā)、部署新的企業(yè)應(yīng)用系統(tǒng)，并將其與原有應(yīng)用系統(tǒng)、業(yè)務(wù)流程進(jìn)行集成的方式出現(xiàn)了根本性變化。

采用ＳOA架構(gòu)，可以帶來顯著的商業(yè)和技術(shù)利益：

1）提升商業(yè)決策能力，通過將商業(yè)服務(wù)和信息進(jìn)行聚合成為一系列動態(tài)的、組合的商業(yè)應(yīng)用，企業(yè)決策者可以更便捷地獲得更準(zhǔn)確、更全面、更深入的信息,可以更敏捷地對各種變化做出反應(yīng).

2)獲得更高的員工生產(chǎn)率，SＯA可以改進(jìn)商業(yè)流程，使得員工更加關(guān)注關(guān)鍵性、增值業(yè)務(wù)流程，基于服務(wù)更好地進(jìn)行協(xié)作,通過各種方式訪問和操作業(yè)務(wù)數(shù)據(jù)和信息，大大提升生產(chǎn)率。

3)建立與供應(yīng)商和顧客的更強(qiáng)的聯(lián)系，SOＡ增強(qiáng)了端到端的應(yīng)用模式,跨越企業(yè)組織邊界，更好地集成現(xiàn)有的信息系統(tǒng)，通過服務(wù)的編排和聚合，使其更好地融合在業(yè)務(wù)流程里。

4）可以更快、更節(jié)省地搭建IＴ和業(yè)務(wù)應(yīng)用系統(tǒng)，基于SOA和標(biāo)準(zhǔn)化服務(wù)組件，可以根據(jù)業(yè)務(wù)流程需要,更快地搭建業(yè)務(wù)系統(tǒng);同時，也可以更好地利用原有的IT和業(yè)務(wù)系統(tǒng)的投資，并保證其符合業(yè)務(wù)流程的需要。

５)可以增強(qiáng)ＩT和業(yè)務(wù)系統(tǒng)的可管理性和安全性，通過安全服務(wù)的部署和SOA治理,可以實(shí)現(xiàn)更強(qiáng)的安全性管理和監(jiān)控,確保了整個架構(gòu)置于統(tǒng)籌和管理之下.完全SOA架構(gòu)所帶來的價值

1）確保總體架構(gòu)的合理規(guī)劃，全面整合信息，徹底消除應(yīng)用孤島，全面實(shí)現(xiàn)過程、人員和信息的實(shí)質(zhì)集成、高度協(xié)調(diào),實(shí)現(xiàn)更高的互操作性與協(xié)同、更敏捷的業(yè)務(wù)流程、更全面的信息可見性;

２）企業(yè)的IT及應(yīng)用系統(tǒng)架構(gòu)將更具伸縮性,IＴ價值將得到充分的發(fā)揮，全面提升未來企業(yè)的競爭優(yōu)勢；

3）降低集成成本和風(fēng)險(xiǎn),降低維護(hù)成本：隨著企業(yè)業(yè)務(wù)的發(fā)展，非SＯA應(yīng)用在ＩT和應(yīng)用系統(tǒng)中相互集成的成本和風(fēng)險(xiǎn)日益增大,系統(tǒng)運(yùn)行將變得繁冗和低效；相應(yīng)地，為維護(hù)應(yīng)用孤島及更多的流程接口，甚至是重復(fù)、重疊的業(yè)務(wù)功能系統(tǒng)，企業(yè)IT及應(yīng)用系統(tǒng)維護(hù)成本將不可避免地日益增大。

4）基于SＯＡ架構(gòu)的IT及應(yīng)用系統(tǒng)可以增量部署到位，但毫無疑問，選擇完全SOA架構(gòu)是正確、長遠(yuǎn)和明智的決策。ＳOＡ的實(shí)現(xiàn)方式－WｅbServiｃeWeｂSｅrvice的概念

WebＳe