Comments 44
А я вот только начал изучать Core, написал простенький сайтец и… встрял.
Дефолтная сборка докера падает на скачивании пакетов и желание искать причину почему-то не возникает (
Поскольку компания крупная, и мы собираемся расширять функционал, решением будут пользоваться десятки тысяч человек.
О причинах выбора архитектуры подробно описали в этой статье. СУБД развернута на отдельной виртуальной машине без Kubernetes, поэтому объем хранимых данных не сказывается на производительности сервера с приложением, это больше вопрос к структуре БД.
Если диаграмма про Service.Planning, Service.Report, и т.п. — это то, как вы порезали систему, то скорее всего вы слишком мелко ее нарезали. И скорее всего, с ростом сложности, у вас начнутся проблемы.
Сначала к вам придут с хотелками, которые размазываются по нескольким вашим микросервисам, и вы там будете плакать от супер-сложных API между сервисами, невозможности сделать нормально join между данными, лежащими по разным сервисам, и провести транзакцию, затрагивающую несколько сервисов.
Потом вы поймете, что все настолько повязано, что если хоть один сервис не работает — все лежит. И вы потеряете плюшку что микросервисы дали вам выживаемости. На деле — будет обратное, и в целом система будет лежать чаще, чем если бы она была одним куском.
Потом вы поймете, что с перформансом беда, и добавление инстансов не помогает — все упирается в стоимость API-коллов.
Дальше, вы поймете, что правильнее делить систему на сервисы вообще иначе — резать надо не по техническим границам, а так, как устроен бизнес. Один начальник/отдел/бизнес-процесс — это скорее всего один кусок.
Хороший вопрос, кстати, чтобы выяснить правильно ли вы делаете — это соотношение бекенд/фронтенд девелоперов. Если фронта меньше половины — вы точно переусложнили бекэнд.
![image](https://habrastorage.org/getpro/habr/comment_images/4b8/66f/a2e/4b866fa2e905a73fbd4c4156c0224c2e.jpg)
Безысходность
Возможно там взяли Redux какой, и на каждое поле каждой формы каждого скрина пишут по редьюсеру. Или там 10 скринов с табличками, и вся общая логика накопипастана. Или лид заставляет писать тесты типа «кликнули кнопочку — ушел AJAX», делать тройной кросс-ревью через пулл-реквесты на фиксы «я подвинул кнопку», и какой-нибудь еще такой херней вместо работы заставляет людей заниматься.
А может быть там и действительно делают красоту. Но вообще, для типичной бизнес-аппы, даже с выкрутасами типа всяких кастомных календариков и прочих пыщ-пыщ красивостей, 50/50 — норм баланс.
Но если UI свой — то чем сложнее бизнес, тем сложнее и UI. В тех же ERP — всюду гриды и формы. А на вебе не то что их встроенных нет, нет даже библиотек нормальных чтобы из коробки их сделать. Там от входа «слепляем свою UI-библиотеку из хипсторских поделок в NPM, пота, и слёз».
Авторизация по jwt? Один токен на все сервисы?
это неверно. докер замечательно поддерживает контейнеры windows 2016 server, более того, даже два вида контейнеров в windows. в кластере docker swarm или k8s могут быть ноды как под linux так и под windows, причем оба типа нод в одном кластере. и у ms оооооогромный набор контейнеризованного софта. даже sql server есть.
И зачем платить за лицензии Windows и тратить больше ресурсов вм? Зачем грузить громадную ОС обновы которой без спроса ребутают сервер (и без wsus от этого не избавиться)? Про размер "докеров" в Windows вам тоже уже сказали выше.
Microsoft молодцы что сделали поддержку Docker Windows, но гораздо большие молодцы, что они выпустили .net core!
Спасибо, поправили это предложение в статье. Теперь фраза звучит так:
Соответственно, мы не можем запустить в Docker решения на платформе .Net Framework под Linux.
В итоге мы решили использовать микросервисы на этом проекте, что потребовало принять ряд нетривиальных решений.
А что за «ряд нетривиальных решений»?
Мы считаем нетривиальным следующие решения:
- Которые позволили организовать способ взаимодействия между клиентами и микросервисами, которые размещены в K8S. Мы реализовали собственный сервис авторизации,
- Выбрать сервисы, которые нужно было разместить в K8S, а какие нет,
- Настройка Rabbit MQ,
- Организовать билды и релизы в TFS, и многое другое.
Хороший стэк, хотя мне больше с MongoDb нравится работать и драйвер для .net там шикарный.
Но вопрос необходимости микросервисов конечно открытый. Почему не просто горизонтальное масшабирование бэкенда?
Ну и мне лично Gitlab пока ближе.
В нашей компании TFS — это корпоративный стандарт, поэтому использовали его.
1.Много кто рассказывает как устроена инфраструктура, однако я не находил про то как организуется процесс разработки. Ведь одно из заявляемый преимуществ контейнеров — то, что среда в проде и в деве одна и та же. Однако как вообще идёт процесс отладки, ведь, как я понимаю, чтобы сохранялась концепция неизменности среды выполнения, нужно отлаживать в контейнере. Как Вы делали?
2. Чем руководствовались при выделении микросервисов?
3. Как разбивали на участки: где должен быть асинхронный обмен, а где синхронные команды?
По поводу отладки: дебажим локально. Visual studio предоставляет возможность локально дебажить контейнеры. На других средах мы не дебажим. Для этого мы используем Elasticsearch и Kibana.
Мы руководствовались двумя книгами: "Микросервисы .NET. Архитектура контейнерных приложений .NET" и "Микросервисы на платформе .NET". Лучше, чем там описано, мы не сможем объяснить. Главная идея: каждый микросервис должен отвечать за специализированную функциональность.
Асинхронный обмен у нас практически везде, кроме тех мест, где нужно гарантировать, что действие выполнено на другом микросервисе. Например, что результат, полученный с мобильного приложения, обработан другим микросервисом. Также мы руководствовались принципом, что микросервис должен иметь все данные в своей БД, которые ему нужны для работы.
1. Почему для фасада базы используется отдельный сервис, если у каждого сервиса своя база? Выглядит как непонятный оверхед на пустом месте + слабое место в перспективе (и сложнее будет разносить базы в случае чего)
2. Вы точно уверены что жизенно необходимы по несколько нод каждого микросервиса? Я недавно замерял простые запросы к netcore серверу (вытащить данные из Redis кэша) — он тысячу запросов в секунду пережевывает спокойно. На рабочем ноутбуке, где сам Редис в докере и SQL Express подняты. Т.е. вероятность упереться в базу и/или кривой код на порядок выше. А там без горизонтального масштабирования уже не выйдет. Впрочем, уверен на 99% что это излишне. Вон stackoverflow живут без горизонтального масштабирования, а у них скорее всего нагрузки будут на порядки выше чем у практически любого приложения.
3. Вы точно уврены что данные у микросервисов действительно не пересекаются? Не выйдет ли так что завтра захотят получить агрегат данных из нескольких сервисов?
4. Подключать файл с секретами как-то сложно на вид. Не рассматривали иные альтернативы? Почему файлы секретов в сорс контроле хранятся, если вы всё равно их подключаете отдельно?
5. Давать прямой доступ к микросервисам — на мой взгляд сомнительное решение (в т.ч. с т.з. безопасности). Как я понял, у вас есть клиенты на мобильных приложениях = поддержка разных версий API, т.к. клиентов так просто не заставить обновить приложение. Как вообще реализовано версионирование АПИ (даже не внутри микросервисов, а именно для мобильных клиентов)? Это один из самых волнующих меня вопросов, т.к. универсального рецепта я не знаю.
6. Rabbit MQ используется для всех коммуникаций или нет? Из предложения в статье совсем непонятно. Субъективно, это нужно для асинхронных сообщений (возможно даже с отложенной доставкой) и тех, где важна устойчивость. Для всего остального более чем достаточно обычного хттп.
Да, у каждого сервиса своя база.
Это решение на перспективу, когда количество пользователей и функциональности станет больше.
Да, на этом этапе уверены. На практике убедились, что мы правильно разбили проект на микросервисы, и это даёт результат.
Мы также рассматривали настройку с помощью конфиг мапа, но этот подход показался удобнее.
Версионность API нам пока не понадобилась.
Rabbit MQ почти используется для всех коммуникаций, частично ответили на этот вопрос в другом комментарии https://habr.com/company/eastbanctech/blog/420665/#comment_19037049
2. А сколько пользователей и какие нагрузки вы ожидаете, чтобы их одновременно не могли потянуть сервисы (при должном уровне написания) способные прожевать тысячи запросов в секунду, но при этом потянула база без горизонтального шардирования. По моему опыту, всё это куда быстрее упрётся в базу.
3. Понятно, спасибо
4. Понятно, спасибо.
5. А как жить с мобильными клиентами? Вы же не можете заставить их всех обновиться в одну секунду
6. А как быть в простом, но крайне реалистичном сценарии «послать в сервис какие-то параметры и получить от него результат». Может у вас своя специфика, но обычно это самый распространённый сценарий использования микросервисов
2. А сколько пользователей и какие нагрузки вы ожидаете, чтобы их одновременно не могли потянуть сервисы (при должном уровне написания) способные прожевать тысячи запросов в секунду, но при этом потянула база без горизонтального шардирования. По моему опыту, всё это куда быстрее упрётся в базу.
3. Понятно, спасибо
4. Понятно, спасибо.
5. А как жить с мобильными клиентами? Вы же не можете заставить их всех обновиться в одну секунду
6. А как быть в простом, но крайне реалистичном сценарии «послать в сервис какие-то параметры и получить от него результат». Может у вас своя специфика, но обычно это самый распространённый сценарий использования микросервисов.
Создание приложения на .NET Core и Kubernetes: наш опыт