Комментарии 4
Интересный проект, спасибо что нашли время поделиться.
Для каждого сервиса можно и нужно запускать несколько копий (instance'ов). Они будут распределяться по разным физическим серверам и, в дальнейшем, ДЦ для повышения отказоустойчивости. Но при этом балансировка запросов будет происходит к оптимальным instance'ам.А каким образом предполагается распределение по серверам, вручную или автоматически. Аналогичный вопрос по балансировке запросов, как организован механизм load balance к «оптимальным instance'ам»?
Каждый instance в интерфейсе представлен набором основных метрик, обновляющихся практически в реальном времени. Среди них количество запросов, количество успешных/ошибочных/прочих ответов, среднее время ответа, нагрузка на CPU, потребляемая память, ...А как используется эта информация?
Распределение — автоматическое.
Runner'ы обмениваются информацией о состоянии друг друга и на основе этих данных принимается решение о вероятности выбора инстанса для запроса. Т.е. вероятность попасть на более близкий и свободноный инстанс выше, чем нам более дальний или занятный.
Метрики — это приборы, без которых летать нельзя :)
Runner'ы обмениваются информацией о состоянии друг друга и на основе этих данных принимается решение о вероятности выбора инстанса для запроса. Т.е. вероятность попасть на более близкий и свободноный инстанс выше, чем нам более дальний или занятный.
Метрики — это приборы, без которых летать нельзя :)
Если бы я был CTO, мои мысли при выборе вашей платформы для хостинга сервисов:
1. платформа молодая, придется стать пилотом, набивать шишки за свой счет
2. не факт что стек технологий оптимален для моей компании
3. решение в облаке и перенести on-prem невозможно
4. контролировать надежность/масштабируемость невозможно, полная зависимость от поставщика решения
5. в моей команде уже есть devops и infra teams и они уже поддерживают существующие решения. Получается что нужно доп. обучать народ новому решению, причем ценность обучения сомнительная
Ни в коем случае не негатив, но я рассматриваю adoption probability и пока не в вашу пользу.
Нужно чтоб либо решение было более атомарное, решающее более мелкие и конкретные задачи, либо решение шло от большого вендора (Amazon, Google, MS) с опытом и существующими средами, в которые органично интегрируется ваше решение.
Напишу в личку.
1. платформа молодая, придется стать пилотом, набивать шишки за свой счет
2. не факт что стек технологий оптимален для моей компании
3. решение в облаке и перенести on-prem невозможно
4. контролировать надежность/масштабируемость невозможно, полная зависимость от поставщика решения
5. в моей команде уже есть devops и infra teams и они уже поддерживают существующие решения. Получается что нужно доп. обучать народ новому решению, причем ценность обучения сомнительная
Ни в коем случае не негатив, но я рассматриваю adoption probability и пока не в вашу пользу.
Нужно чтоб либо решение было более атомарное, решающее более мелкие и конкретные задачи, либо решение шло от большого вендора (Amazon, Google, MS) с опытом и существующими средами, в которые органично интегрируется ваше решение.
Напишу в личку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Облако для SOA приложений и не только