Да ни разу. Людям объяснять надо нормально что зачем и почему. В этом и есть работа руководителя. И да, не поверите, но в айти в принципе практически везде подчиненные важнее руководителя. Делают то работу по факту они.
у нас вся работа построена через очереди, соответственно в каждый месседж в очереди просто добавлено какой счетчик оно меняет и как, например {«counter»:«payments_mts_123», «value»:-1} соответственно что бы ни происходило, это отражается на счетчиках. ну и у нас финансовые транзакции и показатели, соответственно там и проще и сложнее
да ну, зачем сюда мезос+марафон? мезос с марафоном крут когда на него деплоят микросервисы, вот тут он себя показывает. пихать в него такую систему поиметь головную боль на ровном месте, имхо.
у нас на нем живет куча микросервисов на Java 8+ Vert.х, у которых в качестве кеша hazelcast, бд Cassandra, а вертксовый эвентбас подружен с Confluent(он же допиленный Kafka) и вся эта хрень логгируется в graylog2, тобишь ориентировано все на кластеризацию
>>>Как я это все понимаю, нет, нельзя. Но я могу что-то не знать. По-дефолту это так.
разумеется что нельзя, логично же — почти всем нодам нельзя стартовать с меньшими ресурсами, потому если указано что ноде надо 8гб, то ей надо 8 гб и стартовать ее с 6 нельзя.
если эпизодически нужны ресурсы это называется autoscale — https://github.com/mesosphere/marathon-autoscale
в общем если коротко — выделяя ресурсов на ноду в марафоне больше, чем ему надо, в расчете на эпизодическую нагрузку, вы явно что-то не так делаете в плане архитектуры приложения. лучше 2 ноды по 4 гб чем 1 на 8. а еще лучше 3 по 2
есть жеж coreos(https://coreos.com), интересная штука. инстанс рестартует ~ 10 секунд, работает нормально, fleet(https://coreos.com/fleet/docs/latest/launching-containers-fleet.html) вообще изумительная вещь, если научиться готовить. мы юзаем coreos, поверх dc/os с марафоном, сервис дискавери через vip(https://docs.mesosphere.com/1.7/usage/service-discovery/virtual-ip-addresses/) — работает супер, есть идея заморочиться с rkt и flannel и заменить dc/os вообще, но подкупает коробочность, допиливать по минимуму приходится.
стабильность зависит от кол-ва инстансов, оно же мажется. будет нормально ресурсов для подхвата — оно впринципе неубиваемо
мы реляционные субд(постгрес) менеджим в рамках persistent volume'ов(http://mesos.apache.org/documentation/latest/persistent-volume/), пока полет нормальный. а под этими volume'мами просто гластер. в конфиге контейнера в марафоне указать что конкретно этот контейнер работает с этим разделом и все.
не то чтобы фанат реляционных субд в докере, но в такой связке пока проблем не было
мерчант в терминах визы-мастера это просто уникальный идентификатор по которому они опеределяют кто списывает деньги, его по договору нельзя передавать, потому да — отвечает тот кому выдали этот мерчант
не сайт, а мерчант. сайты сами по себе ничего не решают, списание денег по карте идет не в 1 запрос жеж, там есть этап проверки карты и вот на нем есть флаг есть ли 3д на карте. если есть, то как ни крути, а придется делать проверку кода иначе отобьет операци. а вот мерчант, который выдается этим сайтам(типа id) бывает с игнорированием 3д, т.е. они могут забить на 3д, хотя по факту вернет ответ что на карте он есть. это касается только покупок в интернете, если делать перевод с карты на карту там без вариантов. у алиэкспресса, например, такой. это легаси в протоколе визы/мастера с тех пор, как разрешили отелям лочить сумму без любых проверок на карте для предзаказов, так опция для мерчантов игнорировать 3дсекьюр и появилась
у нас на нем живет куча микросервисов на Java 8+ Vert.х, у которых в качестве кеша hazelcast, бд Cassandra, а вертксовый эвентбас подружен с Confluent(он же допиленный Kafka) и вся эта хрень логгируется в graylog2, тобишь ориентировано все на кластеризацию
разумеется что нельзя, логично же — почти всем нодам нельзя стартовать с меньшими ресурсами, потому если указано что ноде надо 8гб, то ей надо 8 гб и стартовать ее с 6 нельзя.
если эпизодически нужны ресурсы это называется autoscale — https://github.com/mesosphere/marathon-autoscale
в общем если коротко — выделяя ресурсов на ноду в марафоне больше, чем ему надо, в расчете на эпизодическую нагрузку, вы явно что-то не так делаете в плане архитектуры приложения. лучше 2 ноды по 4 гб чем 1 на 8. а еще лучше 3 по 2
стабильность зависит от кол-ва инстансов, оно же мажется. будет нормально ресурсов для подхвата — оно впринципе неубиваемо
не то чтобы фанат реляционных субд в докере, но в такой связке пока проблем не было