多個Mirth Connect客戶端的服務器架構

Question

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

詳細的問題：我們有一個客戶端正在發送HL7消息以及其他帶有CSV文件的數據。 我們已使用Mirth Connect將這些數據處理到我們的系統中（在Mirth Connect中使用了大約7個通道）。 Mirth connect安裝及其內部數據庫位於同一服務器上。 但是，在不久的將來，我們將增加許多客戶（今年大約有10個），並且我們需要提出一個可處理負載的可伸縮解決方案。 我們計划為所有mirth connect安裝的內部數據庫使用單個中央服務器（功能強大）（每個mirth connect實例的Postgresql數據庫具有不同的架構）。 每個客戶端一個歡樂連接實例，每個實例都在連接到中央數據庫服務器的單獨（較小）服務器上。
這是一個好方法嗎？

提前致謝。

Answer 1

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

仍然可以在單個數據庫上做您想做的事情...例如，通道A1..An僅應部署在客戶端A的實例上，通道B1..Bn僅應部署在客戶端B的實例上，並且以此類推。 您可以做的一件事是擁有一個全局部署腳本，該腳本檢查您當前的服務器ID，並在您自己的自定義查找表中查找“允許”該服務器使用的通道。 然后，如果不允許，則引發異常，以便不部署通道。

還有一種混合方法。 每個客戶端仍然具有單獨的實例/數據庫，但是每個客戶端也可以具有多個實例。 您可以出於主要/備份故障轉移目的或活動/活動負載平衡目的來執行此操作。 這樣，您還將在MC應用程序級別上帶來高可用性。 這就是Advanced Clustering擴展的真正亮點……它是專為水平縮放共享單個共享DB（也可以水平擴展）的MC實例而構建的。

通常要注意的是，每當有人遇到性能/吞吐量問題時，在大多數情況下，瓶頸不是MC本身，而是磁盤I / O寫入時間。 因此，我絕對建議您將SSD用於數據庫存儲層。 或者至少是在旋轉磁盤之上的SSD快速緩存。