多個Mirth Connect客戶端的服務器體系結構

Question

問題：針對不同客戶端的多個歡樂連接安裝的最佳服務器體系結構是什麼？

詳細的問題：我們有一個客戶端發送HL7信息以及其他數據與CSV文件。我們使用Mirth Connect將這些數據處理到我們的系統中（在Mirth Connect中使用大約7個通道）。歡樂連接安裝和其內部數據庫位於同一臺服務器上。然而，在不久的將來，我們將增加許多客戶（今年約有10家），我們需要提出一個可擴展的解決方案，以便能夠處理負載。我們正在計劃使用一臺中央服務器（強大的）作爲所有歡樂連接安裝的內部數據庫（每個歡樂連接實例有不同架構的Postgresql db）。並且每個客戶端一個歡樂連接實例，每個實例都連接到連接到中央數據庫服務器的單獨（較小）的服務器上。
這是一個好方法嗎？

在此先感謝。

Answer 1

當然你所描述的是一個可行的解決方案。如果所有服務器連接到相同的內部數據庫，則所有通道都將部署在所有服務器實例上。但是，如果您保留每個實例的模式（總是感到奇怪），那麼您犧牲了可維護性，因爲現在您有多個MC實例可以登錄和管理。

它仍然可以在單個數據庫上做你想做的事情...例如，通道A1..An只應該部署在客戶端A的實例上，通道B1..Bn只應該部署在實例上客戶端B等。你可以做的一件事就是擁有一個全局部署腳本，它檢查你當前的服務器ID，並在你自己的自定義查找表中查找該服務器「允許」的通道。如果不允許，拋出一個異常，這樣通道就不會被部署。

還有一種混合方法。每個客戶端仍然有一個單獨的實例/數據庫，但您也可以爲每個客戶端使用多個實例。您可以爲主/備用故障轉移目的或主動/主動負載平衡目的執行此操作。這樣你也可以在MC應用程序級別提供高可用性。這正是Advanced Clustering extension真正閃耀的地方...它專門爲水平擴展共享單個共享數據庫（也可以水平縮放本身）的MC實例而構建。作爲一般說明，每當有人遇到性能/吞吐量問題時，在絕大多數情況下，瓶頸本身不是MC，而是磁盤I/O寫入時間。所以我肯定會推薦你的數據庫存儲層使用SSD。或者至少在旋轉磁盤上安裝SSD快速緩存。