Може ли Apache Thrift да използва множество транспорти за един сървър?

Имам сървър с много леки методи и един тежък метод. Изглежда не мога да намеря доказателства, че Apache Thrift поддържа множество транспорти за сървър. Това, което бих искал, е споделена памет за всички, освен тежкия метод и TCP/IP (разпределен) за тежкия метод. Бих могъл да го разделя на два сървъра, но това нарушава целта на капсулирането (мисля).


person Los Alamos Al    schedule 15.12.2015    source източник
comment
Не, не може. Защо транспортът е уместен? Ако методът е тежък, не виждам как промяната на транспорта ще окаже влияние върху производителността на този конкретен метод.   -  person m0skit0    schedule 16.12.2015
comment
О, съжалявам, толкова е бавно, че изисква много повече конски сили от кода за повикване. Да приемем, че кодът на приложението е разпределен върху 20 сървъра. Локалните методи са толкова бързи, че дистанционното изпълнение би добавило значителни разходи (така че споделената памет на всеки сървър на приложения би била добре). Бавният метод може да използва огромни, специализирани, многоядрени възли (и много от тях - да кажем хиляди, докато приложението расте), така че разпределеният транспорт има повече смисъл за тях - всъщност той никога не би могъл да завърши разумно, ако е ограничен до 20-те възела. Съотношение на бавни към бързи методи: 100-1 в най-добрия случай.   -  person Los Alamos Al    schedule 16.12.2015
comment
Виждам. Обмисляли ли сте да използвате клъстер вместо да правите това ръчно? Това ще позволи на вашите 20 сървъра да се държат като един, без да се налага да го кодирате.   -  person m0skit0    schedule 16.12.2015
comment
Може да имаме предвид различни неща, когато казваме клъстер. Работя на HPC клъстери със силно ограничени операционни среди (само Linux, Slurm, MPI). Не мога да стартирам неща като Mesos, Aurora, AWS, load balancers и т.н. Трябва да го правя всичко сам. Много HPC приложения са статични, но моето е еластично. Така че трябва сам да напиша планиране, балансиране на натоварването и т.н. Thrift изглежда, че ще направи това донякъде по-лесно, като предостави възможност за асинхронизиране/синхронизиране на RPC. Може също да опитам ZeroMQ за динамични съобщения (мога да стартирам TCP/IP през HPC мрежите).   -  person Los Alamos Al    schedule 16.12.2015


Отговори (1)


Ако наистина имаш предвид транспорти - не директно. Това, което е възможно, е манипулаторът да бъде отделен обект, който може да се използва повторно, напр. с различен протокол/транспортен стек.

Както звучи, най-доброто решение във вашия случай наистина би било да имате два сървъра с два различни протокола/транспортен стек, като и двата използват един и същ манипулатор, но прилагат различни Thrift услуги.

                              +----------------+
       +----- uses ---------> | LWService      | <-------+
       |                      +----------------+         |
       |                                             implements
       |                                                 |
+------+-----------+                               +-----+-----+
|                  |                               |           |
|                  |                               |           |
|  Client          |                               | Handler   |
|                  |                               |           |
|                  |                               |           |
|                  |                               |           |
|                  |                               |           |
|                  |                               +-----+-----+
+------+-----------+                                     |
       |                                              implements
       |                      +----------------+         |
       +---- uses ----------> | HeavyService   | <-------+
                              +----------------+
person JensG    schedule 15.12.2015
comment
Ще трябва да размишлявам върху това известно време. Благодаря за отговора - person Los Alamos Al; 16.12.2015