Насчёт задержек. Честно признаться, в тех редких в наших тестах случаях, когда нам чего-то нужно было дождаться (например, серверную валидацию), мы использовали те самые слипы: await browser.sleep(300). Понимание, что это не круто, есть, но пока что оставили так. Если вдруг вы когда-то найдёте более элегантное решение, будем рады услышать :)
На проекте, описанном в статье, у нас 49 подобных тестов. На полный прогон уходит около 20 минут, запускаем по 2 Хрома и FF. Контейнер Zalenium'a развёрнут на виртуалке с 11Гб RAM, ей доступно 16 ядер xeon e5, но, очевидно, что один этот контейнер расходует очень малую часть всего этого. Вопросом минимальных требований железа не задавались.
Изначальная база для написания тестов была заложена разработчиками, сейчас новые тесты пишет QA-специалист.
По поводу отладки: дебажим локально. Visual studio предоставляет возможность локально дебажить контейнеры. На других средах мы не дебажим. Для этого мы используем Elasticsearch и Kibana.
Мы руководствовались двумя книгами: "Микросервисы .NET. Архитектура контейнерных приложений .NET" и "Микросервисы на платформе .NET". Лучше, чем там описано, мы не сможем объяснить. Главная идея: каждый микросервис должен отвечать за специализированную функциональность.
Асинхронный обмен у нас практически везде, кроме тех мест, где нужно гарантировать, что действие выполнено на другом микросервисе. Например, что результат, полученный с мобильного приложения, обработан другим микросервисом. Также мы руководствовались принципом, что микросервис должен иметь все данные в своей БД, которые ему нужны для работы.
Которые позволили организовать способ взаимодействия между клиентами и микросервисами, которые размещены в K8S. Мы реализовали собственный сервис авторизации,
Выбрать сервисы, которые нужно было разместить в K8S, а какие нет,
Поскольку компания крупная, и мы собираемся расширять функционал, решением будут пользоваться десятки тысяч человек.
О причинах выбора архитектуры подробно описали в этой статье. СУБД развернута на отдельной виртуальной машине без Kubernetes, поэтому объем хранимых данных не сказывается на производительности сервера с приложением, это больше вопрос к структуре БД.
У нас реализован отдельный микросервис авторизации, который отвечает за генерацию jwt токенов по SAML Assertion, который нам отдает ADFS 3.0. Этот jwt токен принимается всеми микросервисами. Реализацию мы подсмотрели здесь и здесь.
Пока всё находится на стадии разработки, поэтому не проработано до мелочей. Спасибо за ваш комментарий.
Сортировку пока скидываем изнутри, через её развернутое представление.
Справедливое замечание.
В этом случае шапка принимает компактный вид.
Да, появляется. Списки действительно большие, и это удобно.
Специфика проектов, для которых мы делали карточки, такова, что пользователи обычно опознают карточки по названию. Номер пригождается реже, в конкретных случаях, когда что-то случилось и нужно быстро найти карточку.
Отличная идея про выделение параметров маркером. Спасибо! Возьмем на заметку.
Конечно. Напишите вашу почту в ЛС?
Спасибо, перезалили схемы в статье. Увы, Хабр ужимает картинки. Если каждую схему открыть в новом окне — видно лучше.
Насчёт IE в докере — загляните вот сюда https://github.com/MicrosoftDocs/Virtualization-Documentation/issues/214. (P.S. ничего хорошего)
Насчёт задержек. Честно признаться, в тех редких в наших тестах случаях, когда нам чего-то нужно было дождаться (например, серверную валидацию), мы использовали те самые слипы: await browser.sleep(300). Понимание, что это не круто, есть, но пока что оставили так. Если вдруг вы когда-то найдёте более элегантное решение, будем рады услышать :)
На проекте, описанном в статье, у нас 49 подобных тестов. На полный прогон уходит около 20 минут, запускаем по 2 Хрома и FF. Контейнер Zalenium'a развёрнут на виртуалке с 11Гб RAM, ей доступно 16 ядер xeon e5, но, очевидно, что один этот контейнер расходует очень малую часть всего этого. Вопросом минимальных требований железа не задавались.
Изначальная база для написания тестов была заложена разработчиками, сейчас новые тесты пишет QA-специалист.
Спасибо за ценный комментарий! Полностью с ним согласны.
О, спасибо за рекомендацию!
Именно про само переписывание кода писали в предыдущей статье. Ваш комментарий — хорошее дополнение к тем пунктам.
Спасибо за ценный комментарий! Такие очень мотивируют писать новые статьи дальше.
Да, у каждого сервиса своя база.
Это решение на перспективу, когда количество пользователей и функциональности станет больше.
Да, на этом этапе уверены. На практике убедились, что мы правильно разбили проект на микросервисы, и это даёт результат.
Мы также рассматривали настройку с помощью конфиг мапа, но этот подход показался удобнее.
Версионность API нам пока не понадобилась.
Rabbit MQ почти используется для всех коммуникаций, частично ответили на этот вопрос в другом комментарии https://habr.com/company/eastbanctech/blog/420665/#comment_19037049
По поводу отладки: дебажим локально. Visual studio предоставляет возможность локально дебажить контейнеры. На других средах мы не дебажим. Для этого мы используем Elasticsearch и Kibana.
Мы руководствовались двумя книгами: "Микросервисы .NET. Архитектура контейнерных приложений .NET" и "Микросервисы на платформе .NET". Лучше, чем там описано, мы не сможем объяснить. Главная идея: каждый микросервис должен отвечать за специализированную функциональность.
Асинхронный обмен у нас практически везде, кроме тех мест, где нужно гарантировать, что действие выполнено на другом микросервисе. Например, что результат, полученный с мобильного приложения, обработан другим микросервисом. Также мы руководствовались принципом, что микросервис должен иметь все данные в своей БД, которые ему нужны для работы.
Мы считаем нетривиальным следующие решения:
В нашей компании TFS — это корпоративный стандарт, поэтому использовали его.
Именно поэтому микросервис авторизации имеет минимум связей с другими системами. Он зависит только от работы ADFS.
Поскольку компания крупная, и мы собираемся расширять функционал, решением будут пользоваться десятки тысяч человек.
О причинах выбора архитектуры подробно описали в этой статье. СУБД развернута на отдельной виртуальной машине без Kubernetes, поэтому объем хранимых данных не сказывается на производительности сервера с приложением, это больше вопрос к структуре БД.
Это хороший вопрос и достаточно обширный! Хотим ответить в отдельной статье на Хабре.
Спасибо, поправили это предложение в статье. Теперь фраза звучит так:
Соответственно, мы не можем запустить в Docker решения на платформе .Net Framework под Linux.
У нас реализован отдельный микросервис авторизации, который отвечает за генерацию jwt токенов по SAML Assertion, который нам отдает ADFS 3.0. Этот jwt токен принимается всеми микросервисами. Реализацию мы подсмотрели здесь и здесь.
Elasticsearch и Kibana развернуты на отдельной виртуалке, не в Kubernetes.
Да, вы правы, не хватает упоминания Mass Transit. Внесли правки в текст.
Пока всё находится на стадии разработки, поэтому не проработано до мелочей. Спасибо за ваш комментарий.