0
我有許多輕量級方法和一個重量級方法的服務器。我似乎無法找到Apache Thrift支持多臺服務器傳輸的證據。我想要的是除重量級方法和TCP/IP(分佈式)以外的所有共享內存。我可以把它分解成兩臺服務器,但是這樣做打破了封裝的目標(我認爲)。Apache Thrift可以爲單個服務器使用多個傳輸嗎?
我有許多輕量級方法和一個重量級方法的服務器。我似乎無法找到Apache Thrift支持多臺服務器傳輸的證據。我想要的是除重量級方法和TCP/IP(分佈式)以外的所有共享內存。我可以把它分解成兩臺服務器,但是這樣做打破了封裝的目標(我認爲)。Apache Thrift可以爲單個服務器使用多個傳輸嗎?
如果你確實是指運輸 - 而不是直接。可能的是將處理程序作爲可以重新使用的獨立實體,例如,用不同的協議/傳輸棧。
聽起來,在你的情況下,最好的解決方案確實是讓兩臺服務器有兩個不同的協議/傳輸棧,它們都使用相同的處理程序代碼,但實現了不同的Thrift服務。
+----------------+
+----- uses ---------> | LWService | <-------+
| +----------------+ |
| implements
| |
+------+-----------+ +-----+-----+
| | | |
| | | |
| Client | | Handler |
| | | |
| | | |
| | | |
| | | |
| | +-----+-----+
+------+-----------+ |
| implements
| +----------------+ |
+---- uses ----------> | HeavyService | <-------+
+----------------+
我需要一段時間來思考這個問題。感謝您的迴應。 –
不,它不能。爲什麼運輸有關?如果方法是重量級的,我不會看到改變運輸方式將如何影響該特定方法的性能。 – m0skit0
哦,對不起,它太慢了,需要比調用代碼更多的馬力。假設應用程序代碼分佈在20臺服務器上。本地方法非常快,遠程執行會增加大量開銷(因此每個應用程序服務器上的共享內存都可以)。 「緩慢」的方法可以利用龐大的,專用的多核心節點(並且其中很多節點 - 比如數千個應用程序增長),因此分佈式傳輸對這些節點更有意義 - 事實上,它永遠不會合理完成限於20個節點。 「慢」到「快」方法的比例:最多100-1。 –
我明白了。你有沒有考慮使用集羣而不是手動進行此操作?這樣可以讓你的20臺服務器的行爲就像它們一樣,無需編寫代碼。 – m0skit0