Исправление
vertexua,
(текущая версия)
:
Много критических систем, если они дейсвительно большие, являются очень многомодульными приложениями. Например один сервис - 100 машин, другой - 500, третий - 1000. В одном кластере. Вижу вдоль и впоперек реализацию числодробилок, low-level сервисов на С++, но координаторы процессов могут иметь большую свободу в выборе инструментом. Например на Python пишется
distributed_fs.Copy(src, dst)
Это производит вызов RPC в сервер, он может транзакционно общаться с сервером метаданных ФС, он вызовет контроллер. Контроллер передаст работу 1000 worker процессам, которые считают и перенесут 3 петабайта данных из кластера в кластер параллельно, peer-2-peer. Там из примут другие workers, запишут, сделают все перезапуски в случае падения машин и ответят контроллеру о успехе. Он вернет ответ в Python код.
Я думаю вы видите что в данной схеме тяжелой работой занимаются только workers. Любой overhead, который вы упомянули размыт по этой системе и 99.99999% работы делают workers. Являются они важнее, критичнее, или сложнее? Нет, они обычно совсем простые. Они - часть системы, которой нужны все части для работы. А сложность в контроллерах, в метаданных. Workers могут быть на С++ для экономии памяти в cgroups контейнере, так как работают на тысячах машин. Остальное можно писать на чем угодно, лишь бы оно имело большие возможности по написанию надежного кода.
Исправление
vertexua,
:
Много критических систем, если они дейсвительно большие, являются очень многомодульными приложениями. Например один сервис - 100 машин, другой - 500, третий - 1000. В одном кластере. Вижу вдоль и впоперек реализацию числодробилок, low-level сервисов на С++, но координаторы процессов могут иметь большую свободу в выборе инструментом. Например на Python пишется
distributed_fs.Copy(src, dst)
Это производит вызов RPC в сервер, он может транзакционно общаться с сервером метаданных ФС, он вызовет контроллер. Контроллер передаст работу 1000 worker процессам, которые считают и перенесут 3 петабайта данных из кластера в кластер параллельно, peer-2-peer. Там из примут другие workers, запишут, сделают все перезапуски в случае падения машин и ответят контроллеру о успехе. Он вернет ответ в Python код.
Я думаю вы видите что в данной схеме тяжелой работой занимаются только workers. Любой overhead, который вы упомянули размыт по этой системе и 99.99999% работы делают workers. Являются они важнее, критичнее? Нет, они обычно совсем простые, а сложность в контроллерах, в метаданных. Workers могут быть на С++ для экономии памяти в cgroups контейнере, так как работают на тысячах машин. Остальное можно писать на чем угодно, лишь бы оно имело большие возможности по написанию надежного кода.
Исходная версия
vertexua,
:
Много критических систем, если они дейсвительно большие, являются очень многомодульными приложениями. Например один сервис - 100 машин, другой - 500, третий - 1000. В одном кластере. Вижу вдоль и впоперек реализацию числодробилок, low-level сервисов на С++, но координаторы процессов могут иметь большую свободу в выборе инструментом. Например на Python пишется
distributed_fs.Copy(src, dst)
Это производит вызов RPC в сервер, он может транзакционно общаться с сервером метаданных ФС, он вызовет контроллер. Контроллер передаст работу 1000 worker процессам, которые считают и перенесут 3 петабайта данных из кластера в кластер параллельно, peer-2-peer. Там из примут другие workers, запишут, сделают все перезапуски в случае падения машин и ответят контроллеру о успехе. Он вернет ответ в Python код.
Я думаю вы видите что в данной схеме тяжелой работой занимаются только workers. Любой overhead, который вы упомянули размыт по этой системе и 99.99999% работы делают workers. Являются они важнее, критичнее? Нет, они обычно совсем простые, а сложность в контроллерах, в метаданных. Они могут быть на С++ для экономии памяти в cgroups контейнере, так как работают на тысячах машин. Остальное можно писать на чем угодно, лишь бы оно имело большие возможности по написанию надежного кода.