Как стать автором
Обновить
1
0
Габриэль Гарсия Маркес @MadMac

Пользователь

Отправить сообщение
Ну вот честно, какое каноническое определение у термина DevOps?
Арбитра, кворума ничего такого нет. Сервисы общаются по IP multicast.
Keepalived — это реализация широкоизвестного VRRP на Linux.
Думаю, у меня не получится сказать лучше чем в rfc3768

По второй части Вашего вопроса могу ответить словами классика — все хорошие инфраструктуры счастливы одинаково, каждая плохая инфраструктура несчастлива по-своему :)
Я говорил о том, что не стоит использовать разные сервисы для управления ORM одного типа объектов. Это высказывание не запрещает использование одного микросервиса для нескольких ORM.
Например такой кейс — регистрация пользователя в интернет-банке:
— можно зарегистрироваться в офисе;
— можно зарегистрироваться через интернет;

В обоих случаях один и тот же сервис должен выполнить запись о пользователе в какую-то базу (LDAP каталог, SQL, NoSQL, ?). Хотя и получит запрос из разных источников.

Если разбирать Ваш пример, то я бы сгруппировал сервисы попарно:

  • Пользователи (логика) + ORM Пользователи
  • Каталог (логика) + ORM Каталог


В этом есть смысл если пользователи лежат в LDAP, а товары, например в MongoDB.
Но я не знаю всех деталей вашего проекта и по этому строю свои предположения со многими допущениями.
Если
для остальной сети видны оба
, то у keepalived, скорее всего не получится поднять в сети интерфейс с уже существующим в ней IP (тут тоже возможны варианты. зависит от архитектуры сети).

Вообще, multipathing в сети и добросовестное соблюдение процедур change management нивелируют риски возникновение таких ситуаций.

Если в вашей практике был подобный случай с VRRP расскажите, пожалуйста, как и почему это произошло и как решали проблему.
Знать о какой-то конкретной модели ORM

Иначе говоря, объекты одного класса не должны персиститься более чем одним сервисом/реализацией.

Сервисов, занимающихся ORM может быть сколь угодно много.
Polyglot Persistence опять же никто не отменял.
За облака не скажу, но в классическом энтерпрайзе ваш случай выглядел бы так (возможны вариаты):
— 2 HTTP балансировщика. Например NGINX установленных на виртуалки. Например RHEL 6-7. Hostnames: HOST1 и HOST2. IP: IP1 и IP2.
— на HOST1 поднят сетевой интерфейс c IP1 и также есть dummy интерфейс с IP2. на HOST2, соответственно — наоборот.
— на обеих машинах крутятся keepalived и пингуют друг-друга. Если keepalived на HOST1 теряет связь с HOST2, то он поднимает второй интерфейс (который dummy) c IP2 и HOST1 начинает обслуживать два IP адреса. То же самое для HOST2.
— в копроративных DNS серверах (а их должно быть несколько. и все должны быть прописаны на машине) делается A-запись типа balancer.mycompany.com
— для записи balancer.mycompany.com на DNS выставляется TTL по вкусу и настраивается round-robin балансировка на IP1 и IP2
— для A-записи содаётся CNAME типа http-balancer-prod

Отказоустойчивая инфраструктура для балансировки и динамического управления capacity ваших микросервисов готова.
Создана единая точка входа для всех микросервисов, использующих HTTP транспорт.
Балансировщик будет разруливать весь трафик на бэкенды анализируя HTTP-заголовок HOST.

Начните с ruhighload.com
Также уход микросервиса в оффлайн никак не влияет на работу нашего продукта, так как он просто переключается на запасной аналогичный сервис.

Если главный микросервис не пингуется, то пропускаем все процессы через вспомогательный.


Так всё-таки, как конкретно ваш продукт переключается (failover) на запасной инстанс микросервиса?
Ваш продукт на этапе деплоя знает местонахождение обоих микросервисов или используется балансировщик?
Что значит «пингуется»? ICMP Echo-Request? Кастомные heartbeats домашней выделки?
1. Знать о какой-то конкретной модели ORM должен только один микросервис (назовём его, например PersistenceManager). Если при изменении кода в одном микросервисе вам регулярно приходиться менять код в другом, то будет правильно объединить оба микросервиса в один.
2. Налицо сильное связывание в IT-архитектуре. Это не микросервисный подход. Если какому либо микросервису нужно пообщаться БД, то он должен делать это опосредованно с помощью PersistenceManager, который по своему усмотрению решает как и с какой базой работать (см. п 1).
3. HTTP позволяет легко, стандартными практиками организовать балансировку нагрузки и отказоусточивость микросервисов, а еще он работает через прокси. Можете использовать ZeroMQ если все-таки решите, что HTTP недостаточно быстр.

p.s.
Рекомендую ознакомиться с классическим трудом по интеграции приложений www.enterpriseintegrationpatterns.com

Причем тут счета ЛОРО и НОСТРО? Эти счета относятся к межбанковским расчетам.
Если щеголяете знанием бухгалтерского учета, то называете вещи правильно — Дебет и Кредит.
Точнее CVV2 для Visa и CVC2 для MasterCard.
Обратная совместимость, говорите?
Если через X-сервер запустить свинговое приложение на 7 JRE, то после потери фокуса ввода, вы никак не сможете этот фокус ввода вернуть обратно. Из работающих решений — только запуск под более ранней версией JRE. Баг до сих пор не закрыт.
Погуглите «swing application lost focus on x-server».
Молодцы бельгийцы! Не только вафли и шоколад могут делать))
Rijndael так же в Брюссельской области придумали.
Если бы через XML еще и Action-ы привязывались к пунктам меню, то было бы намного полезней, а так мы получаем меню, которое ничего не делает. Попробуйте добавить в XML имя класса Action-а и создавать его в рантайме через рефлекшн, с последующей привязкой к пункту меню.
Сразу вспоминается Буратино, который на Поле Чудес монетку закопал посадил.
Еще Козьма Прутков говорил, что нельзя объять необъятное. Но, вы все-таки решились, не имея соответствующего бэкграунда написать пост из серии «Все обо всем». В итоге получилось из серии «Собрание расхожих стереотипов и заблуждений о программировании».

Верните мне мои 10 минут.
Мопед не его, он просто разместил объяву.
Вот пристали к человеку… зачем вы расшатываете стройную картину мировосприятия ТС своими четкими однозначными вопросами? В топике преобладают слова «поверхностно»,«предполагаю»,«думаю», «потенциально» и (внимание) «логарифмические функции мозга»… автор просто не поймет что вы хотите от него.
Для этого не надо быть гуру.
Сорцы стандартных классов идут с JDK. Любая IDE вам в помощь (Ctrl+Click по классу).
Я ведь так и знал, что до этого дойдёт! :)
Глава 10 «Внутренние классы». Страница №260, второй абзац заголовок «Классы внутри интерфейсов».
Уверяю Вас, что первые 4 пункта есть у Эккеля. Могу ручаться за 4-е издание.
Буду искренен — мне никогда не приходила в голову такая мысль.
Также не стоит забывать, что не все книги есть в продаже в силу своей специфичности или возраста.
1

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность