Комментарии 44
Когда это RabbitMQ стал шиной?
Elasticsearch тоже в Кубере? На сколько критичные в нём данные? Как-то пока стремаюсь ES в оркестрацию пулять, с ним всё таки грамотно надо обращаться без спонтанных рестартов.
А что с версионностью контрактов?
А я вот только начал изучать Core, написал простенький сайтец и… встрял.
Дефолтная сборка докера падает на скачивании пакетов и желание искать причину почему-то не возникает (
НЛО прилетело и опубликовало эту надпись здесь
Поскольку компания крупная, и мы собираемся расширять функционал, решением будут пользоваться десятки тысяч человек.
О причинах выбора архитектуры подробно описали в этой статье. СУБД развернута на отдельной виртуальной машине без Kubernetes, поэтому объем хранимых данных не сказывается на производительности сервера с приложением, это больше вопрос к структуре БД.
У нас 20к пользователей на подобные бизнес-аппы спокойно тащат аппы на одном серваке вместе с БД.
Если диаграмма про Service.Planning, Service.Report, и т.п. — это то, как вы порезали систему, то скорее всего вы слишком мелко ее нарезали. И скорее всего, с ростом сложности, у вас начнутся проблемы.
Сначала к вам придут с хотелками, которые размазываются по нескольким вашим микросервисам, и вы там будете плакать от супер-сложных API между сервисами, невозможности сделать нормально join между данными, лежащими по разным сервисам, и провести транзакцию, затрагивающую несколько сервисов.
Потом вы поймете, что все настолько повязано, что если хоть один сервис не работает — все лежит. И вы потеряете плюшку что микросервисы дали вам выживаемости. На деле — будет обратное, и в целом система будет лежать чаще, чем если бы она была одним куском.
Потом вы поймете, что с перформансом беда, и добавление инстансов не помогает — все упирается в стоимость API-коллов.
Дальше, вы поймете, что правильнее делить систему на сервисы вообще иначе — резать надо не по техническим границам, а так, как устроен бизнес. Один начальник/отдел/бизнес-процесс — это скорее всего один кусок.
Хороший вопрос, кстати, чтобы выяснить правильно ли вы делаете — это соотношение бекенд/фронтенд девелоперов. Если фронта меньше половины — вы точно переусложнили бекэнд.
Если диаграмма про Service.Planning, Service.Report, и т.п. — это то, как вы порезали систему, то скорее всего вы слишком мелко ее нарезали. И скорее всего, с ростом сложности, у вас начнутся проблемы.
Сначала к вам придут с хотелками, которые размазываются по нескольким вашим микросервисам, и вы там будете плакать от супер-сложных API между сервисами, невозможности сделать нормально join между данными, лежащими по разным сервисам, и провести транзакцию, затрагивающую несколько сервисов.
Потом вы поймете, что все настолько повязано, что если хоть один сервис не работает — все лежит. И вы потеряете плюшку что микросервисы дали вам выживаемости. На деле — будет обратное, и в целом система будет лежать чаще, чем если бы она была одним куском.
Потом вы поймете, что с перформансом беда, и добавление инстансов не помогает — все упирается в стоимость API-коллов.
Дальше, вы поймете, что правильнее делить систему на сервисы вообще иначе — резать надо не по техническим границам, а так, как устроен бизнес. Один начальник/отдел/бизнес-процесс — это скорее всего один кусок.
Хороший вопрос, кстати, чтобы выяснить правильно ли вы делаете — это соотношение бекенд/фронтенд девелоперов. Если фронта меньше половины — вы точно переусложнили бекэнд.
Безысходность
А если фронта больше половины — вы переусложнили UI, получается?
Надо смотреть тогда дальше как фронт делают.
Возможно там взяли Redux какой, и на каждое поле каждой формы каждого скрина пишут по редьюсеру. Или там 10 скринов с табличками, и вся общая логика накопипастана. Или лид заставляет писать тесты типа «кликнули кнопочку — ушел AJAX», делать тройной кросс-ревью через пулл-реквесты на фиксы «я подвинул кнопку», и какой-нибудь еще такой херней вместо работы заставляет людей заниматься.
А может быть там и действительно делают красоту. Но вообще, для типичной бизнес-аппы, даже с выкрутасами типа всяких кастомных календариков и прочих пыщ-пыщ красивостей, 50/50 — норм баланс.
Возможно там взяли Redux какой, и на каждое поле каждой формы каждого скрина пишут по редьюсеру. Или там 10 скринов с табличками, и вся общая логика накопипастана. Или лид заставляет писать тесты типа «кликнули кнопочку — ушел AJAX», делать тройной кросс-ревью через пулл-реквесты на фиксы «я подвинул кнопку», и какой-нибудь еще такой херней вместо работы заставляет людей заниматься.
А может быть там и действительно делают красоту. Но вообще, для типичной бизнес-аппы, даже с выкрутасами типа всяких кастомных календариков и прочих пыщ-пыщ красивостей, 50/50 — норм баланс.
А вы рассматриваете вариант, когда бизнес сам по себе сложный? Ну например какая-нибудь универсальная ERP или биллинг? Задача UI — быть простым, а для бизнеса (который представляет backend) таких требований обычно не ставится.
Если только у тебя какая-нибудь готовая ERP (1С та же), которая по метаданным рисует гриды — типа там бекендеры вместо фронтов плачут и гнут ее как получится.
Но если UI свой — то чем сложнее бизнес, тем сложнее и UI. В тех же ERP — всюду гриды и формы. А на вебе не то что их встроенных нет, нет даже библиотек нормальных чтобы из коробки их сделать. Там от входа «слепляем свою UI-библиотеку из хипсторских поделок в NPM, пота, и слёз».
Но если UI свой — то чем сложнее бизнес, тем сложнее и UI. В тех же ERP — всюду гриды и формы. А на вебе не то что их встроенных нет, нет даже библиотек нормальных чтобы из коробки их сделать. Там от входа «слепляем свою UI-библиотеку из хипсторских поделок в NPM, пота, и слёз».
НЛО прилетело и опубликовало эту надпись здесь
Авторизация по jwt? Один токен на все сервисы?
Все мы знаем, что такое классический .Net Framework. Основным минусом платформы является то, что она не кроссплатформенная. Соответственно, мы не можем запустить в Docker решения на платформе .Net Framework.
это неверно. докер замечательно поддерживает контейнеры windows 2016 server, более того, даже два вида контейнеров в windows. в кластере docker swarm или k8s могут быть ноды как под linux так и под windows, причем оба типа нод в одном кластере. и у ms оооооогромный набор контейнеризованного софта. даже sql server есть.
это неверно. докер замечательно поддерживает контейнеры windows 2016 server, более того, даже два вида контейнеров в windows. в кластере docker swarm или k8s могут быть ноды как под linux так и под windows, причем оба типа нод в одном кластере. и у ms оооооогромный набор контейнеризованного софта. даже sql server есть.
Правда размер контейнера слегка не микросервисный…
И зачем платить за лицензии Windows и тратить больше ресурсов вм? Зачем грузить громадную ОС обновы которой без спроса ребутают сервер (и без wsus от этого не избавиться)? Про размер "докеров" в Windows вам тоже уже сказали выше.
ребутают сервер без спросу? как-то не сталкивался с таким, не наговаривайте. По остальным пунктам справедливо.
у меня у заказщика в AWS поднимал Win2016 — ребут обычное дело посреди ночи по системному времени. То же самое и с серверами на голом железе: стоит нотификейшен на почту в IPMI если сервер уходит в ребут — приходит письмо, класика посреди ночи раз в месяц. P.S. Win2012 так себя не ведет, это катается только Win2016+
можно и в Windows, но это все таки для очень конкретных решений.
Microsoft молодцы что сделали поддержку Docker Windows, но гораздо большие молодцы, что они выпустили .net core!
Microsoft молодцы что сделали поддержку Docker Windows, но гораздо большие молодцы, что они выпустили .net core!
ой, ну да, ну да, советчиков таких много, только стоило бы самому попробовать для начала, после чего давать советы про виндовые контейнеры
Спасибо, поправили это предложение в статье. Теперь фраза звучит так:
Соответственно, мы не можем запустить в Docker решения на платформе .Net Framework под Linux.
В итоге мы решили использовать микросервисы на этом проекте, что потребовало принять ряд нетривиальных решений.
А что за «ряд нетривиальных решений»?
Мы считаем нетривиальным следующие решения:
- Которые позволили организовать способ взаимодействия между клиентами и микросервисами, которые размещены в K8S. Мы реализовали собственный сервис авторизации,
- Выбрать сервисы, которые нужно было разместить в K8S, а какие нет,
- Настройка Rabbit MQ,
- Организовать билды и релизы в TFS, и многое другое.
Спасибо за статью.
Хороший стэк, хотя мне больше с MongoDb нравится работать и драйвер для .net там шикарный.
Но вопрос необходимости микросервисов конечно открытый. Почему не просто горизонтальное масшабирование бэкенда?
Ну и мне лично Gitlab пока ближе.
Хороший стэк, хотя мне больше с MongoDb нравится работать и драйвер для .net там шикарный.
Но вопрос необходимости микросервисов конечно открытый. Почему не просто горизонтальное масшабирование бэкенда?
Ну и мне лично Gitlab пока ближе.
В нашей компании TFS — это корпоративный стандарт, поэтому использовали его.
C MongoDb ещё и может быть проще разносить данные по базам если используется database per service.
из моего опыта могу сказать что микросервисы могут быть полезны, например мне достался проект от говнокодеров которые не понимали как фреймворки работают и всё было сделано мало эффективно, но зато куча сервисов, чтоб юзеры не страдали от того что импорт данных написан криво и забирает под себя почти все ресурсы я его взял и тупо перенёс на другую машину вернее даже на 2(до этого всё стояло на одном жирном сервере) и юзерам стало жить легче пока сервисы оптимизировал, если писать монолит то программисты начнут срезать углы и вместо модуля может получиться трудно выделяемая хрень, так что микросервисы могут быть полезны если уровень программистов и архитекта так себе, иногда даже хочется на функциональном языке таких застявлять писать, там много ограничений которые не позволят писать совсем криво
Три вопроса
1.Много кто рассказывает как устроена инфраструктура, однако я не находил про то как организуется процесс разработки. Ведь одно из заявляемый преимуществ контейнеров — то, что среда в проде и в деве одна и та же. Однако как вообще идёт процесс отладки, ведь, как я понимаю, чтобы сохранялась концепция неизменности среды выполнения, нужно отлаживать в контейнере. Как Вы делали?
2. Чем руководствовались при выделении микросервисов?
3. Как разбивали на участки: где должен быть асинхронный обмен, а где синхронные команды?
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 используется для всех коммуникаций или нет? Из предложения в статье совсем непонятно. Субъективно, это нужно для асинхронных сообщений (возможно даже с отложенной доставкой) и тех, где важна устойчивость. Для всего остального более чем достаточно обычного хттп.
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
1. Но зачем тогда отдельный сервис который рулит базами? Не лучше ли обращаться в свою базу непосредственно из сервиса, без прослоек? Меньше оверхед, меньше проблем при последующем разнесении базы на разные сервера
2. А сколько пользователей и какие нагрузки вы ожидаете, чтобы их одновременно не могли потянуть сервисы (при должном уровне написания) способные прожевать тысячи запросов в секунду, но при этом потянула база без горизонтального шардирования. По моему опыту, всё это куда быстрее упрётся в базу.
3. Понятно, спасибо
4. Понятно, спасибо.
5. А как жить с мобильными клиентами? Вы же не можете заставить их всех обновиться в одну секунду
6. А как быть в простом, но крайне реалистичном сценарии «послать в сервис какие-то параметры и получить от него результат». Может у вас своя специфика, но обычно это самый распространённый сценарий использования микросервисов
2. А сколько пользователей и какие нагрузки вы ожидаете, чтобы их одновременно не могли потянуть сервисы (при должном уровне написания) способные прожевать тысячи запросов в секунду, но при этом потянула база без горизонтального шардирования. По моему опыту, всё это куда быстрее упрётся в базу.
3. Понятно, спасибо
4. Понятно, спасибо.
5. А как жить с мобильными клиентами? Вы же не можете заставить их всех обновиться в одну секунду
6. А как быть в простом, но крайне реалистичном сценарии «послать в сервис какие-то параметры и получить от него результат». Может у вас своя специфика, но обычно это самый распространённый сценарий использования микросервисов
1. Но зачем тогда отдельный сервис который рулит базами? Не лучше ли обращаться в свою базу непосредственно из сервиса, без прослоек? Меньше оверхед, меньше проблем при последующем разнесении базы на разные сервера
2. А сколько пользователей и какие нагрузки вы ожидаете, чтобы их одновременно не могли потянуть сервисы (при должном уровне написания) способные прожевать тысячи запросов в секунду, но при этом потянула база без горизонтального шардирования. По моему опыту, всё это куда быстрее упрётся в базу.
3. Понятно, спасибо
4. Понятно, спасибо.
5. А как жить с мобильными клиентами? Вы же не можете заставить их всех обновиться в одну секунду
6. А как быть в простом, но крайне реалистичном сценарии «послать в сервис какие-то параметры и получить от него результат». Может у вас своя специфика, но обычно это самый распространённый сценарий использования микросервисов.
2. А сколько пользователей и какие нагрузки вы ожидаете, чтобы их одновременно не могли потянуть сервисы (при должном уровне написания) способные прожевать тысячи запросов в секунду, но при этом потянула база без горизонтального шардирования. По моему опыту, всё это куда быстрее упрётся в базу.
3. Понятно, спасибо
4. Понятно, спасибо.
5. А как жить с мобильными клиентами? Вы же не можете заставить их всех обновиться в одну секунду
6. А как быть в простом, но крайне реалистичном сценарии «послать в сервис какие-то параметры и получить от него результат». Может у вас своя специфика, но обычно это самый распространённый сценарий использования микросервисов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание приложения на .NET Core и Kubernetes: наш опыт