Владимир Грабко:
> А там если и буду маштабировать на разны физичиские сервера то между ними будет прямой канал без свичей в 1 цоде )
Это далеко не каждый датацентр позволяет, если только у вас будут не собственные сервера в collocation.
Как правило, сервера изолированы друг от друга и могут общаться только через внешний интернет, что медленно и этот канал подвержен DDoS.
Впрочем у OVH и AWS есть какая то внутренняя виртуальная сеть за отдельные деньги.
Однако это далеко не бюджетно в суммы. Поэтому я бы предусмотрел сразу минимизацию трафика между серверами, чтобы между серверами можно было внешними каналами связи пользоваться.
Владимир Грабко:
> я сечас на локальном сервере настроил куча виртуальных серверов и там тестирую всё это дело. Оверхед между сервисами не больше 23мс.
Не показатель.
Вы фактически меряете оверхед виртуальных машин.
Владимир Грабко:
> а для управления я просто сделал систему которая знает все части сети (ноды). мониторит, логи собирает и я могу ними от туда управлять.
Дело ваше. Но я бы взял готовый мониторинг Hashicorp Consul или Yandex Cocaine Runtime или Zookeeper или etcd.
> я не знаю что будет нужно. Я же не ванга что бы сказать что завтра у меня бдет 1м. играков которые уложат сервер. Верно?
> Gizmothron: сейчас для связи на 1 хосте я юзаю юникс сокет
Если не закладывайте масштабирования, то нет нужды делать столько нод.
И программировать удобнее и эффективнее будет работать в одной ноде.
И балансеры не нужны.
А если же планируется расширение на множество серверов, то простая замена unix socket на TCP/IP не поможет. Придется в корне переделывать.
Если вы не собираетесь горизонтально масштабироваться по множеству физических серверов, то не стоит огород городить из этих нод - это только сложности в разработки добавит.
Если же собираетесь масштабироваться на разные физические сервера, то задача синхронизации и управления между ними - это сложнейшая задача.
Владимир Грабко: а вдруг у вас один физический сервер будет вообще недоступен?
DDoS или просто блок питания из строя выше.
а что будет если сервер обратно вернется в строй. но пока он лежал он не синхронизировался с остальными. и что будет когда он вернется с устаревшими данными.
то есть fasthttp отказывается от net/http гошного.
но вынужден использовать стандартный сетевой протокол http. который текстовый, многословный и неэффективный по скорости.
Владимир Грабко:
fasthttp базируется на основе стандартного неэффективного http, и его задача снизить нагрузку на сервер, а не увеличить скорость доставки.
Владимир Грабко:
> upd будет медленее работать так как нужна обезательная доставка пакетов.
> а анолог tcp я точно делать не хочу.
Не будет.
Никто не мешает слать повторно пакет, не дожидаясь ответа.
Если измерять среднее время доставки пакетов и получения ответов
и посылать страховые пакеты-дубли, скажем, по достижению 80% этого времени.