在本次的整車工廠專案中，我們部署了SAP S4HANA的伺服器叢集，Oracle service bus的伺服器叢集，

ERP系統服務依然還是各系統的核心，本次匯流排專案共100個介面，ERP系統佔了一半。

在藍圖階段，我們實現了OSB叢集伺服器同SAP伺服器的連線：

OSB同SAP連線的協議是傳統的SAP-RFC，作一些配置後，我們實現上面的架構。它實現了SAP RFC的負載均衡，詳情請見我之前的blog專題描述。這裡有一個問題，SAP伺服器是雙機叢集，ESB的6臺伺服器全部接在SAP的1號機上。當2號機的使用者，使用介面傳出資料時，會無法傳出，這個缺陷在之前專案中並不少見。更要命的是，如果1號機停機了，2號機雖然還在持續提供ERP的服務，但是介面相關的資料是無法傳到ESB中介軟體上。

專案組開始攻堅，嘗試多種解決辦法未果。最後我們把注意力集中在負載均衡裝置上，這個裝置是可以解決這個問題的，但是這個裝置大家都不懂，所以很難把我們的需求同這個裝置聯絡起來。 網路管理員可能是懂這個裝置的，但他們不瞭解我們這些個伺服器複雜架構的需求，即使給了他們環境說明，畢竟已經隔行，估計短時間也難有突破。 我認為我們ESB專案組應該掌握這個裝置，並解決我們面臨的問題。我們開始嘗試去理解負載均衡裝置的工作方式，我發現它並不難，而且可以說很簡單。

簡單的說，你可以把你想要平均分佈的伺服器，在這個負載均衡裝置裡組成一個組，然後這個裝置暴露你一個訪問的IP，最後你只需訪問這個IP，負載均衡裝置自動到伺服器組裡去挑伺服器來滿足你的使用。

我們在負載均衡裝置裡，把SAP 2臺伺服器分成了一個組；

OSB的6臺伺服器通過負載均衡裝置 把 基於RFC協議的6條鏈路依次的連線到了2臺SAP伺服器上。

經過測試，我們實現瞭如下架構：

我把它叫做夢幻架構，可能是我這些天睡覺都在想要實現的功能都有了。

1、基於RFC協議的負載均衡。

2、SAP雙機都有多條長連線鏈路同ESB通訊。

整個架構中沒有單點，我能想到的，它目前沒有任何缺陷。

整合專案中難免會出現一些問題，後面我會陸續的總結。