Уже нет. Балансировкой занимается Locator с помощью Gateway плагинов. Сейчас их два — простой adhoc gateway, который выбирает ноды рандомно, и IPVS gateway, который рулит локальным IPVS, создавая и удаляя в нём виртуальные сервисы, добавляя рилы и выставляя веса.
Давайте я расскажу =) PaaS & IaaS это всё, очевидно, marketing bullshit, так что давайте сразу эти аббревиатуры забудем. То что мы (и другие компании типа Гугла или ФБ) делаем — это попытка унифицировать инфраструктуру.
Совершенно не важно какими буквами это называть, главное — чтобы разработчики не думали о том, где и как их приложения будут запущены, а просто писали код, используя те инструменты, которые им подходят, а админы не думали о том, как разрешить очередной конфликт из трёх сотен зависимостей. Та же Borg/Omega от Гугла и наш Cocaine — это и не PaaS и не IaaS per se, это система управления инфраструктурными ресурсами, и как раз GAE и, я подозреваю, CE уже работают поверх неё.
В это понятие входит и изоляция (kvm, xen, lxc, openvz, docker — не важно), и service discovery, и messaging (protobuf, thrift, json-rpc, cap'n proto — опять же, не важно что именно), и resource provisioning и машрутизация вместе с балансировкой нагрузки и ещё куча всякого инструментария вокруг.
А нужно ли переписывать приложения или не нужно — это вопрос реализации и trade-offs. Совершенно несложно сделать всё так, чтобы ничего не нужно было переписывать, просто из-за этого не выйдет заимплементить некоторые другие штуки.
На одно ядро приходится по несколько гигабайт. Всё-таки обработка запросов пользователей это в большей мере вычислительная задача, поэтому памяти особо много не нужно.
CoreOS был анонсирован через полтора года после начала разработки Cocaine, так что мы никак не могли взять его за основу =) А сейчас у нас и так есть поддержка Docker и уже тестируется репликация конфигурации на основе Raft.
Яндекс.Браузер — весь браузерный бэкэнд работает через Cocaine. Например, “Умная строка”, “Быстрые ссылки”, “Любимые сайты”. Внутренняя инфраструктура Яндекса.
CoreOS это совсем не то, о чём мы тут рассказываем. CoreOS это просто ещё один linux flavor в комплекте с etcd и dockerd. Это значит, что:
— некая несуществующая подсистема всё равно должна терминировать траффик пользователей, маршрутизировать его в выбранный по какому-то алгоритму контейнер и возвращать ответ;
— некая другая несуществующая подсистема должна собирать статистику, метрики и контролировать жизненный цикл контейнеров, управляя текущим количеством запущенных экземпляров приложения;
— ещё одна несуществующая подсистема должна управлять образами, генерировать их из коммитов и тегов, запускать автотесты и, возможно, пушить прошедшие тестирование образы в репозиторий, который тоже нужно как-то менеджить;
— и много чего другого.
В общем, CoreOS выглядит неплохой базовой системой для запуска Cocaine, но никак не заменой =)
Задачи Cocaine — управление ресурсами, предоставление общей шины для связи компонент и маршутизация запросов — CoreOS не решает.
По-моему, в посте стоит уточнить, что TOR Freedom Hosting и сеть TOR (The Onion Router) никак не связаны, основателям TOR ничего не грозит и уж точно стоит убрать из поста TOR-овский логотип.
Я же не пишу, что придумал способ избавиться от this, я пишу о том, что его можно обернуть в smart_ptr и пользоваться так, если «в вас возникает такой ужас при виде this». Это такое саркастическое предложение, понимаете?
Под работает я подразумеваю, что им можно пользоваться так, как было задумано авторами. Если у объекта никогда не будет владеющего shared_ptr, например так:
class Type:
public enable_shared_from_this<Type>
{ };
unique_ptr<Type> object(new Type());
То в этом случае нет вообще никакого смысла использовать shared_from_this — он никогда не будет работать.
Вы ошибаетесь в том, что shared_from_this может вернуть nullptr: он либо вернёт shared_ptr на живой объект, либо бросит исключение.
А ещё вам неправильно кажется: на самом деле, weak_ptr будет проинициализирован и в случае создания shared_ptr через конструктор с указателем.
Ну, вместо того, чтобы обращаться через this->something, вы будете делать что-нибудь типа shared_ptr smart_this(shared_from_this()); smart_this->something. В этом предложении вообще была доля сарказма изначально, если что.
Чтобы работал shared_from_this, у объекта должна быть хотя бы одна не-weak ссылка — то есть, объектом кто-то должен владеть через shared_ptr. Поэтому просто создавать объект через make_shared недостаточно (и, в общем-то, необязательно), нужно где-то держать на него живой shared_ptr.
Нет, это решение не против протухания, а чтобы даже this был smart_ptr-ом. Для использования shared_from_this() необходим владелец, и я точно скажу, что это замечательно, когда все heap-allocated объекты встроены в иерархическую структуру владения.
Если в вас возникает такой ужас при виде this, можно наследоваться от enable_shared_from_this и обращаться к объекту через shared_from_this(), например.
А гарантия того, что функтор не исчезнет во время исполнения — это ваша задача: lifetime, ownership и прочее.
Ещё стоит вспомнить, что битовые поля — это thread unsafe штука, про что обычно забывают, и, в отличие от обычных полей структуры, независимо обновлять их из потоков уже не получится.
Она лежит в регистре, потому что вы не покидали call-site-а с заинлайнеными одноразовыми функциями, мало понимаете в C++, почти ничего не знаете о компиляторах и любите почесать языком впустую =) Удачи!
Никто не гарантирует, что переменная будет перечитана, она же лежит в регистре и _там_ её никто не менял, так что вы можете никогда не узнать о том, что она была изменена из хендлера.
1) Вы объявляете глобальную не-volatile переменную для работы с сигналами. Вы хотите проверять её только из what_about_our_signal_variable();
2) Эта функция инлайнится в call-site, потому что больше она ниоткуда не вызывается.
3) При заходе в call-site функцию переменная кладется в регистр.
4) Происходит сигнал, регистры и прочие вещи сохраняются, ваш хендлер инкрементирует переменную в памяти.
5) Старое значение в регистре восстанавливается, инкремент вы не заметили, но в памяти при этом будет новое значение.
6) Ваша программа начинает вести себя непредсказуемо, потому что вы ввели в неё неопределённое поведение; стандарт в этом случае развязывает руки компилятору, оставляя вас без единого формального способа доказать корректность вашего кода.
Совершенно не важно какими буквами это называть, главное — чтобы разработчики не думали о том, где и как их приложения будут запущены, а просто писали код, используя те инструменты, которые им подходят, а админы не думали о том, как разрешить очередной конфликт из трёх сотен зависимостей. Та же Borg/Omega от Гугла и наш Cocaine — это и не PaaS и не IaaS per se, это система управления инфраструктурными ресурсами, и как раз GAE и, я подозреваю, CE уже работают поверх неё.
В это понятие входит и изоляция (kvm, xen, lxc, openvz, docker — не важно), и service discovery, и messaging (protobuf, thrift, json-rpc, cap'n proto — опять же, не важно что именно), и resource provisioning и машрутизация вместе с балансировкой нагрузки и ещё куча всякого инструментария вокруг.
А нужно ли переписывать приложения или не нужно — это вопрос реализации и trade-offs. Совершенно несложно сделать всё так, чтобы ничего не нужно было переписывать, просто из-за этого не выйдет заимплементить некоторые другие штуки.
— некая несуществующая подсистема всё равно должна терминировать траффик пользователей, маршрутизировать его в выбранный по какому-то алгоритму контейнер и возвращать ответ;
— некая другая несуществующая подсистема должна собирать статистику, метрики и контролировать жизненный цикл контейнеров, управляя текущим количеством запущенных экземпляров приложения;
— ещё одна несуществующая подсистема должна управлять образами, генерировать их из коммитов и тегов, запускать автотесты и, возможно, пушить прошедшие тестирование образы в репозиторий, который тоже нужно как-то менеджить;
— и много чего другого.
В общем, CoreOS выглядит неплохой базовой системой для запуска Cocaine, но никак не заменой =)
Задачи Cocaine — управление ресурсами, предоставление общей шины для связи компонент и маршутизация запросов — CoreOS не решает.
Под работает я подразумеваю, что им можно пользоваться так, как было задумано авторами. Если у объекта никогда не будет владеющего shared_ptr, например так:
То в этом случае нет вообще никакого смысла использовать shared_from_this — он никогда не будет работать.
Вы ошибаетесь в том, что shared_from_this может вернуть nullptr: он либо вернёт shared_ptr на живой объект, либо бросит исключение.
А ещё вам неправильно кажется: на самом деле, weak_ptr будет проинициализирован и в случае создания shared_ptr через конструктор с указателем.
Чтобы работал shared_from_this, у объекта должна быть хотя бы одна не-weak ссылка — то есть, объектом кто-то должен владеть через shared_ptr. Поэтому просто создавать объект через make_shared недостаточно (и, в общем-то, необязательно), нужно где-то держать на него живой shared_ptr.
А гарантия того, что функтор не исчезнет во время исполнения — это ваша задача: lifetime, ownership и прочее.
1) Вы объявляете глобальную не-volatile переменную для работы с сигналами. Вы хотите проверять её только из what_about_our_signal_variable();
2) Эта функция инлайнится в call-site, потому что больше она ниоткуда не вызывается.
3) При заходе в call-site функцию переменная кладется в регистр.
4) Происходит сигнал, регистры и прочие вещи сохраняются, ваш хендлер инкрементирует переменную в памяти.
5) Старое значение в регистре восстанавливается, инкремент вы не заметили, но в памяти при этом будет новое значение.
6) Ваша программа начинает вести себя непредсказуемо, потому что вы ввели в неё неопределённое поведение; стандарт в этом случае развязывает руки компилятору, оставляя вас без единого формального способа доказать корректность вашего кода.