По поводу отладки: дебажим локально. Visual studio предоставляет возможность локально дебажить контейнеры. На других средах мы не дебажим. Для этого мы используем Elasticsearch и Kibana.
Мы руководствовались двумя книгами: "Микросервисы .NET. Архитектура контейнерных приложений .NET" и "Микросервисы на платформе .NET". Лучше, чем там описано, мы не сможем объяснить. Главная идея: каждый микросервис должен отвечать за специализированную функциональность.
Асинхронный обмен у нас практически везде, кроме тех мест, где нужно гарантировать, что действие выполнено на другом микросервисе. Например, что результат, полученный с мобильного приложения, обработан другим микросервисом. Также мы руководствовались принципом, что микросервис должен иметь все данные в своей БД, которые ему нужны для работы.
Которые позволили организовать способ взаимодействия между клиентами и микросервисами, которые размещены в K8S. Мы реализовали собственный сервис авторизации,
Выбрать сервисы, которые нужно было разместить в K8S, а какие нет,
Поскольку компания крупная, и мы собираемся расширять функционал, решением будут пользоваться десятки тысяч человек.
О причинах выбора архитектуры подробно описали в этой статье. СУБД развернута на отдельной виртуальной машине без Kubernetes, поэтому объем хранимых данных не сказывается на производительности сервера с приложением, это больше вопрос к структуре БД.
У нас реализован отдельный микросервис авторизации, который отвечает за генерацию jwt токенов по SAML Assertion, который нам отдает ADFS 3.0. Этот jwt токен принимается всеми микросервисами. Реализацию мы подсмотрели здесь и здесь.
Пока всё находится на стадии разработки, поэтому не проработано до мелочей. Спасибо за ваш комментарий.
Сортировку пока скидываем изнутри, через её развернутое представление.
Справедливое замечание.
В этом случае шапка принимает компактный вид.
Да, появляется. Списки действительно большие, и это удобно.
Специфика проектов, для которых мы делали карточки, такова, что пользователи обычно опознают карточки по названию. Номер пригождается реже, в конкретных случаях, когда что-то случилось и нужно быстро найти карточку.
Отличная идея про выделение параметров маркером. Спасибо! Возьмем на заметку.
Разворачивание кластера, анализ ошибок/предупреждений в логах докера/кубернетиса, запуск тестовых приложений и снова анализ логов.
В связке Oracle Linux + docker + k8s из стандартных репозиториев не было ошибок вообще, а предупреждений было 7 штук и все они совершенно некритичные. После этого мы развернули нашу микросервисную систему и провели нагрузочное тестирование (смоделировали работу приложения в пиковом режиме нагрузки) — ничего не упало, ошибок в логах платформы не было, а сама система отработала в расчетное время с верными результатами.
БД мы вынесли за пределы контейнеров/Кубернетиса, так как у нее свои регламенты обновления/бэкапа/администирования. В тестовых окружениях мы разворачивали её вне контейнеров, а в проде вынесли на отдельную виртуальную машину.
Вы можете развернуть систему в K8S и так, если уже упаковали её в Docker. Цель нашей статьи рассказать про K8S как про один из инструментов, позволяющий достичь цели time to market (быстрой доставки решений до продашна): быстро и надёжно разворачивать приложения на любой инфраструктуре, обеспечивать высокую степень отказоустойчивости, обновлять систему незаметно для пользователей. Но для того чтобы воспользоваться всеми этими возможностями, мы рекомендуем разделить систему на микросервисы.
Спасибо за ценный комментарий! Полностью с ним согласны.
О, спасибо за рекомендацию!
Именно про само переписывание кода писали в предыдущей статье. Ваш комментарий — хорошее дополнение к тем пунктам.
Спасибо за ценный комментарий! Такие очень мотивируют писать новые статьи дальше.
Да, у каждого сервиса своя база.
Это решение на перспективу, когда количество пользователей и функциональности станет больше.
Да, на этом этапе уверены. На практике убедились, что мы правильно разбили проект на микросервисы, и это даёт результат.
Мы также рассматривали настройку с помощью конфиг мапа, но этот подход показался удобнее.
Версионность 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. Внесли правки в текст.
Пока всё находится на стадии разработки, поэтому не проработано до мелочей. Спасибо за ваш комментарий.
Разворачивание кластера, анализ ошибок/предупреждений в логах докера/кубернетиса, запуск тестовых приложений и снова анализ логов.
В связке Oracle Linux + docker + k8s из стандартных репозиториев не было ошибок вообще, а предупреждений было 7 штук и все они совершенно некритичные. После этого мы развернули нашу микросервисную систему и провели нагрузочное тестирование (смоделировали работу приложения в пиковом режиме нагрузки) — ничего не упало, ошибок в логах платформы не было, а сама система отработала в расчетное время с верными результатами.
БД мы вынесли за пределы контейнеров/Кубернетиса, так как у нее свои регламенты обновления/бэкапа/администирования. В тестовых окружениях мы разворачивали её вне контейнеров, а в проде вынесли на отдельную виртуальную машину.
Вы можете развернуть систему в K8S и так, если уже упаковали её в Docker. Цель нашей статьи рассказать про K8S как про один из инструментов, позволяющий достичь цели time to market (быстрой доставки решений до продашна): быстро и надёжно разворачивать приложения на любой инфраструктуре, обеспечивать высокую степень отказоустойчивости, обновлять систему незаметно для пользователей. Но для того чтобы воспользоваться всеми этими возможностями, мы рекомендуем разделить систему на микросервисы.
В этой статье рассказали о самой концепции, а о тонкостях и примерах обязательно расскажем в следующих материалах.