作者：人月神話，新浪博客同名

簡介：多年SOA規劃建設，私有雲PaaS平台架構設計經驗，長期從事一線項目實踐

今天這篇文章準備談下從企業集成需求到SOA架構思想，再到ESB集成平台建設方面的内容。本篇文章盡量從最簡單的問題起源将其，從業務場景需求出發來講解接口集成和SOA架構思想。

看完本篇文章可以對SOA，ESB，接口集成，企業常見端到端協同業務有一個完整了解。

首先要理解一個企業有很多業務流程和活動，比如市場和銷售，供應鍊，财務，生産，研發等，這些業務活動共同來支撐企業從獲取到和的需求，到最終交付産品的整個價值鍊全過程。

為了支撐這個過程往往企業也會劃分為不同的業務部門，比如供應鍊部，财務部，生産部，人力資源部等，各個部門上下遊分工協作來完成對整個企業日常經營活動的全部支撐。

從客戶提出需求，到最終交付産品給客戶，這就是一個閉環的端到端流程，從客戶開始到客戶結束。這個端到端流程往往先是銷售接單，轉計劃部門，計劃部門排計劃，需要原材料采購的把采購計劃下發給采購部門采購，生産産品的原材料都齊備後，排生産計劃發送給生産部門，生産部門進行生産，生産後質量檢查，沒問題後出庫發運到客戶手裡面。

這就是一個完整的端到端流程。（要詳細理解這部分内容可以參考ERP和MRP相關的書籍做詳細了解，也可以參考類似業務價值鍊方面的書籍）。

一個端到端流程要完成可以看到跨越了多個業務部門，上下遊協同才能夠完成。

要支撐企業的業務運轉，企業會建立很多的IT系統，一般企業都是圍繞ERP來建立相應的IT系統，即在ERP基礎上擴展了外部支撐的多個系統，比如CRM，SCM，MES，PLM，WMS等業務系統。同時可以看到一般擴展的業務系統會有一個主管認責的業務部門。比如CRM歸口到市場部，而對于MES歸口到生産部，PLM歸口到産品研發部門。

一個完整的端到端流程，業務部門之間要上下遊協同，那麼在實現信息化後就會變成業務部門歸口管理的業務系統之間要上下遊協同，即業務系統之間需要傳遞信息和數據，否則端到端流程無法協同起來。

比如我們在SCM系統裡面建立的采購訂單，但是采購回來的東西收貨是倉儲部管，對應的系統是WMS系統，而WMS系統收貨的時候必須依據采購訂單進行收貨或确認型号和數量。因此我們就需要将采購訂單信息從SCM系統傳遞到WMS系統。而這種信息傳遞就是通過兩個系統之間的接口來完成的。

即我們常說的，端到端流程往往是連貫的，但是我們建設IT系統的時候往往是分散建立的，那麼這些IT系統之間就必須協同起來滿足完整的流程需要。IT系統之間的協同就通過系統間定義的接口進行，一個接口往往是業務系統雙方共同約定好的技術标準，協議，同時約定好傳輸數據的格式。

SCM采購系統要傳遞一個訂單信息給WMS倉儲管理系統，這個就需要通過接口實現。而接口實現的方法有很多，比如：

• 通過數據庫的DBlink直接連接完成，将數據寫到接口表或調存儲過程。
• 通過RPC遠程過程調用類方式來完成。
• 通過Http WS服務來完成，其中包括了SOAP WS也包括了REST WS。
• 通過文件導入和導出來完成，即SCM先導出文件，然後将文件傳遞到WMS系統再導入。
• 通過類似JMS消息來完成，即SCM通過JMS消息機制發送消息給WMS系統。

以上技術實現不明白的可以先放一邊，要說明的就是接口本身的技術實現方式有很多種，都可以用來實現兩個IT系統之間的接口集成，完成數據傳遞工作。

在上面了解清楚後，我們再來看接口實現的幾個關鍵問題。

查詢接口還是導入接口？

任何涉及到兩個系統之間的接口實現都存在兩種方式，即要麼實現為查詢接口，要麼實現為導入接口。還是以上例子來說，SCM要傳遞一個訂單信息給WMS系統，那麼實現方式有兩種。

• WMS系統作為接口提供方，實現一個訂單導入接口，SCM進行調用。
• SCM系統作為接口提供方，實現一個訂單查詢接口，WMS系統來調用。

這兩種接口實現方式都可以，即如果是在A實現查詢接口，那麼一定就是在B實現導入接口。對于數據源頭方往往是提供查詢接口，對于數據需要方式提供導入接口。

如果是導入接口，那麼SCM系統隻要有新訂單産生就可以實時調用接口将數據導入給WMS系統，但是如果是查詢接口，WMS系統并不清楚SCM系統什麼時候産生了新訂單，所以隻能定時輪詢調用查詢服務，看是否有新訂單産生。因此對于導入接口往往實時性更好。

接口同步還是接口異步？

對于同步還是異步我們來舉個例子來說明。比如你點了美團外賣，在外賣小哥将外賣送到你公司樓下有兩種處理方法。

• 其一是電話告訴你，外面放在前台了你自己去取下；
• 其二是給你電話說在下面等你，直到你去取到外賣再離開。

對于方法1就是異步，對于方法2就是同步。

即在同步場景下，外賣小哥和你建立連接後，這個連接一直要處于等待狀态，直到你取走外賣為止；但是如果是異步場景，外賣小哥隻要将東西放到前台就返回，不需要和你建立長久等待連接，在這種情況下往往就需要一個傳遞媒介(前台）。這就是同步和異步最大的區别點。

那同步和異步究竟各有啥優點呢，簡單來說

• 同步：雖然等待，但是可以完全确保送達，等待最終确認信息。
• 異步：無須等待，即使你當時不在公司（如目标系統宕機）也不影響送達，但是消息傳輸是否成功需要剛才說到的前台（消息中間件）來保證傳遞可靠完成。

再簡單來說，就是在同步場景下，A和B兩個業務系統是直接建立了連接同時連接處于等待狀态，直到接收系統接收成功後返回。而對于異常場景下，A和B不直接建立連接，都是和消息中間件建立連接。

實時和非實時

還是上面的場景，如果接口實現為訂單導入，那麼采購系統一有訂單就馬上調用導入接口，就是實時觸發接口。但是如果采購系統是每2小時處理一次，将這2小時新增加的訂單作為一個批次再調用導入接口進行導入，那麼就是定時接口。

對于查詢類服務同步，如果一個查詢人員信息接口服務，業務系統是實時用人員的時候實時查詢接口獲取最新信息，那麼就是實時接口。但是如果是每隔2小時或1天，調用該接口同步增量數據，那麼就是非實時接口。

從點對點集成到總線式集成

集成平台簡單來說就是将所有業務系統間提供的接口全部統一管理起來的一個平台，舉例來說：

一個辦公室有5台電腦，這5台電腦要連接起來，你可以每台電腦之間通過網線點度點連接，形成一種網狀的連接結果。你也可以将5台電腦全部接入到一個Hub交換機上面，通過交換機來實現5台電腦的連接。同樣有5個業務系統要實現集成，接口可以點對點集成，當然接口也可以全部接入到類似交換機的一個軟件平台上（集成平台）上面，通過集成平台實現類似Hub的總線式集成。

如果有100台電腦，網站集成的話是n*(n-1)/2，可以看到集成關系越來越複雜，越來越難以管理，但是如果采用Hub集成，那麼集成就變得很容易，以很清晰。

對于業務系統間的接口集成也是同樣的道理。

再舉例來說明，比如有四個人，分别講中文，英語，法語和日語。那麼如果4個人要交流就相對麻煩，每個人都需要懂多門外語，或者自己對語言進行翻譯處理。那麼這個時候我們就可以将四個人全部接入到一個統一的翻譯機，中國人要跟英國人交流的時候，中國人将中文發送給翻譯機，翻譯機轉換為英文後再轉發給英國人。那麼對于四個人間的交流就很順暢了。

集成平台實現了總線式集成，除了減少了集成點數量外，重點還做以下幾個方面的事情。

• 對接口傳遞的數據進行協議轉換或數據映射，類似剛才說的語言翻譯操作。
• 對A提供的接口開放給哪些業務系統調用進行控制，即常說的接口安全和訪問授權問題。
• 對于任何業務系統間接口傳遞的日志數據進行記錄，包括輸入了什麼，輸出了什麼，方便後續問題排查。

以WMS提供訂單導入接口為例，在點對點集成的時候，接口調用為：SCM 調用 WMS接口。在WMS将接入注冊到集成平台後，集成平台提供了一個類似的訂單導入接口，過程變化為：

SCM 調用 集成平台 =》 集成平台 轉發去調用WMS =》 WMS返回到集成平台 =>集成平台返回給SCM

即任何一個接口的調用都涉及到三方，A系統，B系統和集成平台。

同時從上面這個圖大家還可以看到，所有接口消費的輸入消息和輸出消息全部會在集成平台管道上進行流轉，也就是說集成平台可以對消息進行攔截和處理。這也是後續集成平台對接口進行安全，日志，協議轉化，數據映射，流量控制等各種管控的基礎。

對于集成平台的使用，除解決原來業務系統之間點對點集成轉變為網址集成的問題外，究竟還能夠解決哪些問題。在集成平台實施過程中，最容易碰到的疑問就是對于業務系統間都全部采用了标準的WS服務作為接口标準，那麼還使用集成平台有什麼樣的必要性？

對于集成平台的使用，還包括了如下幾個方面的優點。

• 接口傳輸日志的記錄和後續審計，如果這個不做，那麼需要各個業務系統都去做。
• 接口的安全管理和訪問控制，可以做到統一管理并可配置化，業務系統不用關心。
• 接口的标準化和适配，即使全部采用WS接口服務，也存在如果對WSDL标準化的問題。
• 消息的1對多分發，消息路由能力，這是個共性能力，往往集成平台可以統一完成。
• 位置透明和服務代理能力，所有服務調用都隻需和集成平台打交道。

當然在采用了集成平台後，也存在一些缺點的地方，比如任何一個接口的集成和實施都涉及到業務系統雙方和集成平台三方協同才能夠完成。其次就是由于消息需要通過集成平台中轉，一定會帶來一定的性能損耗。

接口的數據格式和内容

在業務系統之間定義了一個标準的接口後，就需要對接口的數據格式進行定義，對于SOAP WS有标準的WSDL和XSD接口契約文件定義。包括對于Rest接口，現在也有WADL和RAML設計模型。

對于這塊的内容在這裡先不展開，可以自己搜索SOAP WebService和WSDL相關的文章進行學習。

簡單舉例來說，一個郵遞員通知你到哪裡去取你的包裹這個接口，對于WSDL文件中的是說明了取包裹的具體地點和方法名稱；而對于XSD文件則定義了包裹裡面具體裝了哪些東西，是如何裝的。當然XSD文件也可以完全嵌入在WSDL文件裡面，這樣WSDL文件就一并告訴你去兩件事情。

任何數據一定有數據結構，而對于接口傳遞的數據結構本身就是一個樹狀結構，其一定有一個根節點，在根節點下面有1個或多個子節點，同時子節點項目還可以有子子節點。因此你遇到任何一個數據結構就需要搞清楚這個數據本身是分幾層，是1個父親有兩個兒子這種結構（A場景），還是1個父親有1個兒子，1個兒子又挂了1個孫子這種結構（B場景）。這對理解XSD結構和裡面的Collection結構定義相當重要。

舉例來說，我們定義一個客戶信息，一個客戶往往有客戶銀行賬戶和客戶聯系人，那麼就是上面說的A場景。當然也可以是一個客戶信息，一個客戶聯系人信息，一個客戶聯系電話信息，那麼就是上面說的B場景，即三層遞進結構。這個畫個圖示往往更加容易理解，在這裡先省略掉。

為什麼要先定義接口

對軟件工程有初步理解的就容易理解，在軟件工程中有架構設計，而架構設計中一個重要的工作就是劃分組件，并對組件的接口進行設計。

這樣做的目的就是在接口設計好後，各個組件就可以開始并發開發工作，相互不影響，隻要大家遵循同樣的接口規範文件，那麼最終開發完成的兩個組件就能夠集成到一起。

接口先行的目的就是大家遵循同樣的标準，那麼後續各個組件就能夠無縫的集成到一起。否則接口實現不一緻，那麼後續就無法進行集成，導緻功能和接口變更。如下圖所示：

如果把業務系統比做積木的話，隻要我們提前定義好了接口的标準(WSDL XSD)文件，那麼三個積木就可以完全無縫的組裝和銜接起來，形成一個完整的整體。

• 如果ERP提供接口和集成平台接口不一緻，那麼ERP提供的接口服務注冊到集成平台。
• 如果集成平台接口和SCM接口不一緻，那麼SCM服務消費成功集成平台提供的服務。

當前集成平台本身還有接口或數據的轉換能力，那麼就可能如下圖

即ERP和集成平台間是三角形的接口，但是集成平台和SCM間是三角矩形接口。SCM和ERP間的接口不标準，也不統一，但是通過集成平台轉換和适配，很好地将SCM和ERP兩個積木組裝了起來。這也是上面我們說的集成平台的的另外一個關鍵特點，協議轉換能力和數據轉換能力。

從集成平台到ESB

前面把集成平台，接口的概念講清楚了那麼接着講下ESB服務總線。如何簡單來理解ESB服務總線，如果将業務系統間的接口理解為各個點對點連接的鄉間小路的話，那麼ESB服務總線就是将這些小路聚合和連接在一起的信息高速公路，而每次接口傳遞的數據就是在高速公路上飛馳的汽車。

因此簡單來說，ESB總線就是将業務系統間的接口找到，将接口轉變為服務，然後将服務注冊和接入到ESB總線，然後ESB總線将這個接口服務開放給其它業務系統使用，同時對這個接口服務進行統一的管理（安全，日志，路由等）。

而對于集成平台本身是一個寬泛的概念，即對于傳統的EAI，數據交換平台，ESB服務總線都可以納入到集成平台。從集成的類型來看，文件集成，大數據集成，服務集成（ESB總線）也都可以納入集成平台的概念。

那麼對于ESB和傳統的EAI和數據交換平台的區别究竟在哪裡？

• 對于ESB平台更加強調了接口本身的服務化，不僅僅是WS來實現，更加重要的可重用。
• 對于ESB發布的接口有明确的業務含義，而對于EAI或數據交換平台接口更多是底層數據傳遞。
• 對于EAI平台更多場景數據都是落地的，而對于ESB平台往往可以做到數據不落地
• 對于ESB平台由于服務調用可以更加容易做到實時性，而對于EAI和數據交換平台很難做到

因此在ESB實施時候重點是服務的識别，或者說傳統接口如何轉服務。其次才是服務後期的治理和管控。當前在很多互聯網架構下認為ESB平台偏重，因此也出現了類似OpenAPI平台，服務網關等更加輕量的SOA總線平台。去掉了傳統ESB裡面比較重的協議轉換适配，數據映射，服務可視化編排等能力。

集成平台的實施關鍵内容如何理解？

前面把集成平台和接口的概念理解清楚後，再來理解ESB實施究竟做哪些關鍵的事情就容易了。對于ESB實施，我們可以參考上面的圖來理解，以ERP提供一個導入訂單接口服務給SCM系統消費來說明。

1. 首先是集成平台定義好一個标準的接口服務規範和WSDL文件，接口長什麼樣就全清楚了。
2. 将接口規範下發給SCM，ERP系統，同時集成平台也要使用該規範。
3. SCM和ERP安裝下發的接口規範文件進行接口的開發，ERP開發提供端，SCM開發消費端。
4. ERP在接口開發好後通知集成平台進行服務接入和注冊，将ERP和集成平台兩個積木嵌起來。
5. 集成平台接入ERP服務後，發布一個新的代理服務給SCM系統，并通知SCM系統消費。
6. SCM系統按接口标準對集成平台暴露的接口進行消費，即将SCM和集成平台再串聯和集成起來。

以上說明步驟都完成後，一個接口的需求，設計，開發和測試工作就全部完成了，也就是說大家遵循同樣的接口标準規範定義，将一個接口完全集成起來了。這也是我們常說的從頂向下的接口設計和開發實施方法。

我們可以來看下SOA本身的定義，即：

SOA是一種架構方法，将傳統的單片式應用打破，分解為離散的、自治的業務服務，利用标準提升他們的互操作性，從而可以更好地共享、重用和組裝，快速構建複合的應用從而滿足業務需求的變化。

在面對企業遺留IT系統架構的時候，SOA本身實際也是做兩個重要的事情，其一是找到各個遺留系統共性的可複用的業務能力；其次就是在構建上層業務流程的時候通過服務組裝和編排來完成。這個思想和中台思想完全一緻。

我們來舉個例子詳細說明SOA架構思想：

我們以注冊一家新公司來舉例，可以看到如果我們要注冊一家新的公司，我們需要和銀行，政府部門中的工商，稅務，質量監督等多個業務部門到交道，最終完成新公司注冊的完整過程。

其一：找到可複用服務

而對于各個業務部門就是我們說的業務組件，我們首先就是要看業務組件本身對外提供了什麼标準的服務能力出來，即先把各個組件可共享，能夠複用的能力識别出來。這些業務組件本身提供很多業務服務能力，在這裡我們隻列舉一些和公司注冊相關的能力，如下：

其二：組合和編排服務完成業務

在進行一個新企業的注冊流程中，涉及到核名，辦理驗資報告，領取組織機構代碼證等諸多的業務活動，這些業務活動都需要和上面說的業務部門（業務組件）打交道才能夠完成。

而要完成整個業務流程，就是将上面業務部門暴露的服務能力基于業務活動的流轉進行組裝起來，這樣就完成了一個完整的業務，如下：

可以看到完成整個企業注冊業務流程，本身就是底層的接口服務能力的組合和組裝。

如果注冊流程中增加了一個驗證企業信用要求，那麼我們也很容易在原來的業務流程中增加一個活動節點，該活動節點調用銀行的信用驗證服務能力接口即可。即通過接口服務的靈活組合，組裝，能夠很容易的響應業務流程的變化。

SOA和ESB總線的關系

簡單來說，SOA是一種架構思想，這種架構思想核心是找到服務，組裝編排服務。對于找到的服務我們希望統一進行管理，那麼ESB就是實現服務管理和治理的一個技術平台。

也就是ESB企業服務總線是實現SOA架構思想的一個關鍵平台。

如上圖，找到和管理服務你可以借助ESB服務總線能力來完成，而組裝和編排服務你可以借助BPM管理軟件來完成。而ESB BPM也是我們常說的實現SOA架構思想的關鍵平台。

沒有使用ESB能否叫實現SOA架構？

當然可以，隻是遺留系統暴露的接口服務沒有進行統一的管控和治理，也就是說對于接口服務的治理水平會比較弱，但是隻要你暴露的接口服務是粗粒度和可複用的。同樣可以共享給上層業務系統或應用使用。正如沒有使用BPM，同樣也可以實踐SOA編排思想，隻是你需要通過自己寫代碼去編排服務，而不是通過BPM軟件去可視化編排服務。

反之同樣的道理，不用簡單理解使用了ESB就是SOA架構。

比如你使用了ESB，接入了一堆沒有經過标準化，不符合粗粒度特點的接口，這些接口本身混亂也沒有任何服務價值。上層新業務開發也不能使用這些接口服務，那麼這個時候你的ESB就僅僅是一個接口平台，也沒有實現任何的SOA架構思想。

類似的道理還有我們做微服務也一樣，不要簡單的認為使用了SpringCloud框架就是微服務了，必須要考慮微服務類似輕量交互，松耦合等關鍵思想是否實現。

ESB總線需要同時考慮解決集成和解耦兩類問題

由于當前ESB總線産品很多是由原有的EAI和消息中間件産品發展而來，因此更多的強調的是服務或消息集成，而弱化了SOA更加重要的一個能力即服務共享。

而實際上SOA需要解決服務 集成兩方面的問題。

• 集成：解決的是業務和流程上的協同問題，服務不一定就能複用
• 複用：解決的是底層共有組件模塊提取後能力開放問題，重點是可複用

從上面圖可以看到，對于橫向交互協同的接口，更多的是解決跨系統的集成問題，而對于系統中縱向使用的共享能力接口，在共享能力平台化後，則接口服務可重用，更多的解決就是服務層面的問題。

舉例來說，一個采購系統導采購訂單給ERP系統，這個接口往往并不能複用，但是解決了跨系統集成問題；另外對于MDM主數據提供的供應商查詢接口服務，這個接口服務本身就是數據能力平台化後提供出的共享數據服務能力，這個服務可以被外圍的SCM，ERP，CMS多個業務系統使用，既解決了系統間集成，更重要的解決了服務重用問題。

你也可以理解，對于服務重用問題的解決，更多都是伴随着共性能力下沉産生的。然而當前大部分企業将SOA簡單理解為了ESB和集成平台，更多用SOA去解決集成的問題，而忘記了SOA架構思想的本質仍然是共性業務能力下降，上層應用靈活編排。

前面基本把SOA，集成平台，ESB，接口這些基本概念講清楚了，今天重點還是進一步解釋涉及到SOA和ESB的時候，一些關鍵技術特性。其中包括了粗粒度，無狀态，位置透明等。

粗粒度

當談到服務的時候，我們談的最多的就是粗粒度，這個概念實際上并不容易理解。

我們還是要舉例來進行說明，比如你去辦理出國簽證，你準備好相關申請材料後就到本地公安局的服務窗口，這個服務窗口就是和你到交道的接口，你把申請資料提交過去，2周後你拿到最終的簽證和結果。可以看到和你打交道的這個服務窗口相對粗，相對簡單，一個輸入，一個簡單的輸出完事。但是要辦理完這個事情，公安局内部則需要經過多個部門，多個崗位處理和審核，最終才能夠完成，即内部的工作是相對細的，但是這個細節你不用關心也不用知道。這就是我們說的接口服務的粗粒度，即粗是相對内部實現的細來說的。

如果我們把兩個業務系統中的數據庫表的每個表都作為一個數據同步接口來實現集成，這種數據接口把細節完全暴露了，反而不符合粗粒度接口的定義。即粗粒度接口服務最強調的就是你要什麼我就給你什麼，你不需要知道還有哪些沒給你，也不需要知道我内部如何實現的。

注意，粗粒度服務可能高可複用，也可能不能複用，粗粒度與高可複用性本身沒有必然關系。比如我們做了一個供應商查詢的數據服務接口，這個接口查詢所有供應商字段信息，是一個細粒度接口，但是該接口往往更加容易複用。但是我們也可以做一個基于供應商ID返回供應商信用等級的粗粒度接口，但是這個接口就可能隻有1個業務系統在業務場景中需要使用。

無狀态

對于WS服務無狀态，也是在理解SOA和服務化中的一個關鍵内容。對于無狀态那麼自然就是基于有狀态和狀态保持來說了，因此首先要說明什麼是要有狀态。

舉個例子來說，我們去遊樂園遊玩，進門的時候要檢查我們的門票，進去了後有很多遊樂設施，當我們再玩裡面的每個遊樂設施的時候，就不再需要檢查我們的門票的，也計算管理員默認我們進了大門後我們就是有效的買了票的遊客。這種場景就要有狀态，即一進門我們是有效遊客這個狀态就一直保持着。當然還有另外一種情況，就是我們驗票進門後，在每玩一個遊樂項目的時候，管理員要重新檢查我們的門票，即管理員并不認我們進大門的時候做的檢查，這個狀态信息帶不過來，那麼這種情況下就有無狀态。

對于服務調用，本身就是典型的無狀态，簡單理解就是你上次調用服務輸入或輸出，産生的任何信息都無法帶入到下次服務調用中。比如你上次調服務傳遞了你的身份，但是你下次調用服務的時候還得傳遞，否則就不認。

正因為服務無狀态，我們在進行集成平台集群化部署的時候相對來說更容易，不需要做任何的狀态保持。

位置透明和服務代理

前面我們講過服務網關是ESB服務總線最輕量的一個實現，僅僅實現了服務代理和安全等基礎特性。因此要來理解什麼是服務代理能力。

舉個例子來說，順豐快遞送貨到你們公司，你們公司辦公區占了一棟樓6層，這個時候快遞隻需要将貨送到你們前台就完事，而不需要送到你們實際的辦公位。那麼你們的前台就起到了服務代理的傳輸中介的作用。即本來順豐快遞應該直接點對點面對你們公司1000個員工辦公位，但是現在很簡單了，快遞隻需要面對你們公司的前台一個人即可。

通過服務代理可以看到，1000個員工内部辦公位的分布，構造這些信息對快遞員是不可見的，是透明的，這就叫做位置透明。即使你内部的辦公位分布出現調整也不影響快遞員送貨。同時可以看到通過服務代理，還有一個好處就是内部的構造和邏輯完全對快遞員是黑盒，快遞員也不能随意進入到我們内部辦公場所，這也就是保證了我們内部邏輯和結構的安全性。（也可以進一步解釋為何企業在和外部進行接口服務交互的時候，往往要專門設置一個服務網關，并放置在DMZ隔離區的目的）

高内聚和松耦合

對于松耦合是服務的另外一個關鍵特性，也是我們進行架構設計和組件劃分的一個關鍵特性。松耦合往往不是真的接口來說的，而是針對兩個業務組件來說的，隻是通過WS服務接口兩個業務組件能夠更好的實現松耦合。

當我們在劃分完了業務組件後，如果A和B兩個業務組件之間有100個接口在進行業務和數據交互，那麼這兩個組件就是高度耦合，但是如果兩個組件之間隻有3,5個接口在交互，那麼組件之間就是松耦合。松耦合并不是不耦合，而是指兩個組件之間的耦合程度很低。

松耦合後，兩個組件就不一定必須一起設計，開發和部署，而是可以完全分開設計和部署，然後通過接口服務進行業務協同和交互。因此能夠拆分是松耦合的一個關鍵特性。

其次，對于松耦合的兩個組件，當組件A發生變更，故障或問題的時候，盡量不要影響到組件B。這也是松耦合的另外一個關鍵特性。比如A發送數據給B，當B故障的時候也不要影響到A，這就是徹底的松耦合。但是這種松耦合往往就需要通過消息中間件來完成，通過消息中間件和消息來徹底實現A和B兩個組件的解耦。

今天談下業務，主要還是拿電信行業運營商來舉例說明下，關鍵的業務協同場景。先來說下工程項目的端到端流程，中間可能涉及到的業務系統和關鍵交互接口說明。這裡盡量是把主體流程說清楚，實際的業務比這個當然要複雜的多。

工程項目建設線條

首先當我們要進行工程建設的時候，比如說要在某個省建設5G試點基站和試驗局，那麼首先就要确定投資計劃，并進行項目立項審批和可研。這裡面就涉及到計劃管理系統和項目管理系統，也可能是一個系統。其關鍵就是要形成最終的審批通過的立項項目。後續的所有工作都需要基于立項項目進行。

在項目管理系統中形成了立項項目并審批通過後，項目實際的範圍，具體建設多少個點等，就會涉及到初步的項目WBS分解和項目預算。因此一個完整的項目信息都包括了項目基本信息，項目WBS分解信息和項目預算信息。

項目信息形成後就涉及到實際的後續招标采購工作了，這個應該容易理解。對于招标系統和采購系統在這裡暫且分為兩個系統來說。首先說招标，項目招标最終就是要确定項目如何基于WBS更好的分包，分包後進行相應的招标工作，招标完成後最終形成的就是合格的供應商信息，物料和設備信息，分簽的合同信息。

所以這裡可以看到，招投标完成後往往會形成合格的供應商信息，物料信息，這些信息就需要同步到采購管理系統裡面作為采購用。當然如果有了主數據系統，這些基礎主數據就先在MDM系統裡面形成，然後再分發和同步到采購管理系統裡面。因為采購系統做采購訂單的時候需要選擇供應商和物料。同時我們還需要将招投标結果類信息同步到合同管理系統，合同管理系統根據結果來拟制采購類合同。

這裡再簡單來說，比如5G招标結果已經處理，分為兩個包，華為和中興各中标一個包，其中華為提供交換和傳輸設備給1000台，中興提供基站和東環設備各1000台。然後分别跟兩家供應商拟制供貨合同。

前面事情做完後，就開始在采購系統裡面做采購訂單了。比如向華為下達采購訂單。在這裡先講最簡單的就是一個采購訂單，接收點也一個點。

當我們在做采購訂單的時候，我們就需要選擇供應商信息，選擇物料信息，選擇該訂單對應的項目，選擇該訂單對應的合同，選擇該訂單對應的組織，選擇訂單的接收地點等各種基礎信息。可以看到這些基礎信息就需要從招投标，合同，項目管理，ERP等各個業務系統中同步過來。這些是做一張采購訂單的基本條件。當采購訂單下達給供應商後，就涉及到收貨的事情，在這裡将采購系統和物流系統分開來講，即采購系統隻管采購訂單，而物流系統來管實物和庫存的管理。

采購訂單生效後，需要将訂單同步給物流系統，否則物流系統不清楚按什麼來驗貨。這是采購和物流系統之間最關鍵的一個接口。對于供應商送貨過來後，物流系統就需要進行接收，送檢和入庫三個關鍵操作。在這裡我們簡化為直接做入庫單入庫來進行說明。

物流系統做入庫單，那麼就需要選是根據哪個采購訂單來進行接收入庫，具體的入庫數量是否和采購訂單數量匹配等。在入庫單做好，物資檢查清楚後進行物資入庫操作。一個物資正式入庫，就涉及到物流系統裡面的庫存操作了，比如入庫需要增加對應的物資庫存數量，出庫需要減少數量等。對應物資正式入庫，有個叫法就叫庫存記賬。意思就是庫房正式簽收入庫，承認收到你的東西并合格了，那麼後續就需要依據這個信息給你進行付款。

對應物流系統一般就要管物資的入庫，出庫，調撥，盤點等相關的操作。因為所有這些操作都會影響到實物庫存的變化，而實際實物庫存的變化都會影響到最終的财務成本核算。而企業上了ERP後，實際的财務成本核算，應收，應付和總賬都在ERP系統裡面。因此對于物流系統操作形成的内容，統一叫做庫存事務處理，需要将這個信息同步到ERP的庫存模塊，作為後續财務成本核算使用。

财務線條基礎

物流系統接收到貨後，後面這個貨根據工程建設進度，就需要出庫發到工程項目現場進行設備的安裝和調試，所有的東西安裝調試完成後，整個試驗局就開通了。最終安裝完成的東西就是客戶的資産，因此需要将你所有采購回來的東西形成一個清單（轉資清單），轉變為客戶的資産。即我花了100萬出去，這裡面就應該有100萬全部轉成了我後續的資産，這樣兩邊的賬才是平的。舉更簡單例子來說，公司來個新員工，公司花5000買了台電腦，那麼這5000就要轉成固定資産。這樣兩邊的賬才是平的。

工程項目建設如果驗收通過了，那麼就涉及到要給供應商付款，首先我們就需要提交驗收材料和付款申請，啟動給供應商付款的流程。

對于實際的付款就涉及到前端的報賬平台，我們就需要在報賬平台中提交一張采購類的報銷單。當然你填寫這種報銷單的時候也需要選擇對應哪個項目，哪個合同，哪個訂單，哪次付款，對應的組織，會計科目，業務大小類等很多基礎信息，這些信息都是從ERP，合同，項目管理，采購系統中同步過來，這些同步全部涉及到接口。

這個時候你在系統裡面建立好報賬單，選擇對應哪個采購訂單，對應的采購接收單，對應的供應商開過來的發票，這三者必須要對應上，才說明完全是一緻的，賬實完全相符。這個就叫三單匹配操作。這個完成後走報賬單審批流程，審批通過後，報賬單就會形成應付憑證或叫應付發票（有些付款場景沒有發票）。那麼這個發票信息就需要導入到ERP的應付模塊裡面去。

在報賬平台建報賬單的時候，還涉及到和預算系統打交道，比如我們下個月究竟要報銷哪些費用，每個類别預計多少錢，我們首先要進行預算申報。預算申報完成，審批通過後生效。那麼我們在提交報賬單的時候就要檢查，我們報銷的費用是否超過了預算，如果超過了，或者沒有預算就不允許提供。對于采購類報賬，你報銷的費用一定不能超過了采購合同的總金額，如果超過就不能報銷，必須要先進行預算調整或合同變更才行。

在應付發票信息導入到ERP後，ERP啟動進一步的業務規則和邏輯檢查，确認這張發票是否可以付款了，如果可以付款就會生成付款指令發給資金系統，資金系統進行付款操作。資金系統在進行付款的時候還需要跟銀行打交道，完成實際的付款過程。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!