Микросервисное безумие пройдет в 2018 году +20

- такой же как Forbes, только лучше.

Именно с таким тезисом выступил Дэйв Керр, статья которого собрала за месяц 90 комментариев, вызвала бурные дискуссии на Reddit и Hacker News, а нас заинтересовала настолько, что мы решили срочно ее перевести. Пользуясь случаем, поинтересуемся: хотите ли допечатку основополагающей книги Сэма Ньюмена "Создание микросервисов", которая в последний раз выходила у нас еще в 2016 году, либо скепсис господина Керра кажется вам обоснованным?

Читайте и комментируйте!

В последние пару лет тема микросервисов стала очень популярна. «Фанатизм» любителей микросервисов сводится примерно к такому силлогизму:

В Netflix замечательно устроена практика devops. Netfix занимается микросервисами. Следовательно: если я стану заниматься микросервисами, то преуспею в devops.
Есть примеры, когда микросервисные паттерны внедрялись ценой огромных усилий, причем, их сторонники не вполне понимали, каковы издержки этой работы, и так ли велика польза микросервисов при решении данной конкретной задачи.

Здесь я подробно опишу, что такое микросервисы, почему эта парадигма так привлекательна, и каковы основные вызовы, которые она перед вами ставит.

В финале я сформулирую несколько простых вопросов, на которые, вероятно, стоит ответить самому, размышляя – а подходят ли микросервисы именно для вас?



Что такое микросервисы, и почему они так популярны?

Начнем с азов. Вот как можно реализовать гипотетическую платформу для совместного использования видео: сначала в виде монолита (единая большая структура), а затем в виде микросервисов:



Разница заключается в том, что в первом случае мы имеем одну большую конструкцию, а во втором – набор маленьких специфичных сервисов. Каждый сервис играет конкретную роль.
Если начертить схему именно с такой детализацией – она, конечно, привлекательна. Сплошные потенциальные достоинства:

Независимая разработка: небольшие независимые компоненты можно создавать силами маленьких независимых команд. Группа может дорабатывать изменения в сервисе «Закачка», не вмешиваясь в разработку сервиса «Перекодировка» — или даже не зная о нем. Значительно сокращается время, требуемое для знакомства с компонентом, разрабатывать новые возможности легче.

Независимое развертывание: Каждый отдельный компонент можно развернуть независимо от остальных. Таким образом, новые фичи можно выкатывать быстрее, с меньшим риском. Если мы дорабатываем или фиксим компонент «Потоковое видео», то можем развертывать его по мере надобности, и развертывать другие компоненты нам для этого не требуется.

Независимая масштабируемость: Все компоненты можно масштабировать независимо друг от друга. В горячую пору, когда выходят новые шоу, компонент «Скачать» можно усилить, чтобы справиться с возросшей нагрузкой, и для этого не требуется наращивать все прочие компоненты. Эластичное масштабирование, оказывается, не так и сложно реализовать, стоимость разработки снижается.

Многократное использование: Каждый компонент выполняет небольшую специфическую функцию. Таким образом, их легко адаптировать для применения в других системах, сервисах или продуктах. Так, компонент «перекодировка» можно использовать в бизнес-элементах или даже превратить в новый компонент бизнес-логики, возможно, предоставляющий возможности перекодировки для других групп.

При таком приближении превосходство микросервисов над монолитом кажется очевидным. Итак, в чем же дело – почему эта парадигма совсем недавно в фаворе? Где она была раньше?

Если они такие классные, почему раньше никто ими не занимался?

На этот вопрос есть два ответа. Первый: занимались — насколько позволяли наши технические возможности. Второй: лишь новейшие технологические прорывы позволили вывести микросервисную технологию на новый уровень.

Когда я стал писать ответ на этот вопрос, у меня вышло длинное объяснение, поэтому я решил вынести его в отдельную статью и опубликовать попозже. На данном этапе я не буду описывать пути от одной программы ко многим, не буду останавливаться на ESB и сервис-ориентированной архитектуре, дизайне компонентов, ограниченных контекстах и т.д.

Те, кто заинтересовался, могут почитать об этом пути отдельно. Предпочту сказать, что, так или иначе, мы занимались этим ранее, но, благодаря недавнему всплеску популярности контейнерных технологий (в частности, Docker) и оркестрации (например, Kubernetes, Mesos, Consul и т.д.) такой паттерн стало гораздо проще реализовать с технической точки зрения.
Итак, если принять как данность, что мы действительно можем возвести микросервисную систему, то далее следует тщательно подумать — а нужно ли? Теоретически в самом общем плане преимущества ясны, а какие вызовы при этом возникают?

Что за проблема с микросервисами?

Если микросервисы так великолепны, так в чем же дело? Вот некоторые из важнейших проблем, которые я вижу.

Задача разработчика усложняется

Для разработчика все может серьезно усложниться. Если программист желает разработать целую последовательность, либо фичу, потенциально охватывающую множество сервисов, то ему придется запускать их все на одной машине, либо подключаться к ним. Зачастую это гораздо сложнее, чем взять и запустить единственную программу.

Эта проблема частично решается при помощи соответствующего инструментария, но, по мере того, как количество сервисов в системе увеличивается, разработчику будет все сложнее запускать всю систему целиком.

Задачи операторов усложняются

Для команд, которые не разрабатывают сервисы, а поддерживают их, рост сложности может быть взрывным. Приходится управлять не несколькими сервисами, а несколькими десятками, сотнями или тысячами. Больше сервисов, больше путей коммуникации, больше потенциальных точек отказа.

Задачи devops усложняются

Возможно, кого-то покоробило, что в двух предыдущих пунктах эксплуатация и поддержка трактуются отдельно, особенно с учетом того, как популярна сегодня практика devops (кстати, я обеими руками за нее). Разве devops не решает этих проблем?

Проблема в том, что во многих организациях эксплуатация и поддержка – по-прежнему выполняются разными командами, и именно в такой организации переход на микросервисы, скорее всего, забуксует.

Для организаций, уже практикующих devops, все тоже сложно. Быть разработчиком и оператором одновременно уже тяжело (но необходимо, чтобы писать хорошие программы), но, если вдобавок требуется понимать нюансы систем оркестрации контейнеров, особенно таких систем, которые стремительно развиваются – крайне тяжело. Здесь я подхожу к следующему пункту.

Нужен серьезный опыт

Если такой работой занимаются эксперты, то результат может быть великолепен. Но представьте себе организацию, где и при эксплуатации единственной системы-монолита не все гладко. Назовите хоть одну причину, по которой дела могут наладиться, если в компании увеличится количество систем, а значит – и сложность их эксплуатации?

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

В реальных системах границы между компонентами зачастую нечеткие

Во всех примерах, на которых демонстрировались достоинства микросервисов, мы говорили о независимых компонентах. Однако, зачастую они просто не являются независимыми. На бумаге некоторые предметные области могут казаться четко очерченными, но, стоит углубиться в частности – и окажется, что проблема сложнее, чем вы предполагали.

Вот здесь все может стать совсем сложно. Если границы компонентов в вашей системе определены нечетко, то происходит вот что: хотя, теоретически, сервисы и можно развертывать независимо друг от друга, на практике оказывается, что они связаны взаимными зависимостями, и поэтому приходится развертывать набор сервисов как целую группу.

Это означает, что приходится управлять согласованными версиями сервисов, то есть, сервисами, надежность которых доказана, взаимодействия проверены. Но в таком случае речь уже не идет о независимо развертываемой системе, поскольку для разработки новой фичи требуется тщательно оркестровать одновременное развертывание множества сервисов.

Часто игнорируются сложности, связанные с состоянием

В предыдущем примере я упоминал, что для развертывания фич может потребоваться одновременно выкатывать множество версий разных сервисов единой группой. Тянет предположить, что эта проблема снимается, если применяешь толковые приемы развертывания, например, голубые/зеленые варианты развертывания (что без особых усилий делается на большинстве оркестровочных платформ), либо при параллельной эксплуатации нескольких версий сервиса – при этом потребляющие каналы сами определяют, какую версию использовать.

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

На самом деле, многие сервисы требуют сохранять состояние. Продолжая пример с нашей платформой для обмена видео, примером такого сервиса на ней может быть подписка. Новые версии сервиса подписки могут хранить информацию в подписочной базе данных в разной конфигурации. Если вы эксплуатируете оба сервиса параллельно, то в вашей системе одновременно работает две схемы. Если вы реализуете зеленое/голубое развертывание, а другие сервисы зависят от данных, оформленных в этой новой конфигурации, то обновлять их нужно одновременно. Если же развернуть сервис подписки не удается и приходится идти на откат, то, возможно, потребуется откатить и все зависимые сервисы, что может обернуться лавинообразными последствиями.

Опять же, тянет предположить, что при использовании NoSQL-баз данных такие проблемы со схемами исчезают — но это не так. Базы данных, не навязывающие конкретной схемы, не порождают бессхемных систем — просто управление такой схемой обычно реализуется на уровне приложения, а не на уровне базы данных. Ключевая проблема в данном случае – понимать конфигурацию ваших данных, как они развиваются. От нее никуда не уйти.

Часто игнорируются сложности, связанные с коммуникацией

При выстраивании обширной сети взаимозависимых сервисов вполне вероятно, что придется обеспечивать активную коммуникацию между ними. Здесь возникает еще несколько проблем. Во-первых, значительно увеличивается количество потенциальных точек отказа. Следует учитывать, что некоторые сетевые вызовы не пройдут, и это означает, что, когда один сервис вызывает другой, он должен быть запрограммирован на какое-то минимальное количество попыток.
Теперь, когда сервис потенциально может вызывать множество других сервисов, мы оказываемся в сложной ситуации.

Допустим, пользователь загружает на нашу видеоплатформу новое видео. Нам нужно запустить сервис закачки, передать данные сервису перекодировки, обновить подписки, обновить рекомендации и т.д. Все эти вызовы в той или иной степени требуют оркестрации, а если вызов не пройдет – нужно попытаться выполнить его еще раз.

Такая логика повторных попыток может стать сложноуправляемой. Синхронное выполнение операций часто оказывается неосуществимым, поскольку потенциальных точек отказа слишком много. В данном случае наиболее разумно организовать коммуникацию с применением асинхронных паттернов. Самое сложное в данном случае, что система с асинхронной коммуникацией по определению требует выстраивания системы с сохранением состояния. Как я упоминал в предыдущем пункте, управлять системами с сохранением состояния и с распределенными состояниями очень сложно.

Если коммуникация между сервисами микросервисной системе осуществляется при помощи очередей сообщений, у нас, в сущности, возникает большая база данных (очередь сообщений или брокер), «склеивающая» эти сервисы. Опять же, на первый взгляд такая система может и не казаться проблематичной, но впоследствии аукнется вам. Сервис в версии X может записать сообщение в определенном формате, и другие сервисы, зависящие от этого сообщения, также потребуется обновить, если сервис-отправитель изменит детали отсылаемого им сообщения.
Можно написать такие сервисы, которые смогут обрабатывать сообщения во множестве разных форматов, но управлять такими сервисами будет тяжело. В таком случае при развертывании новых версий сервисов возможны ситуации, когда разные сервисы пытаются обрабатывать сообщения из одной очереди, возможно, даже переданные различными версиями сервиса-отправителя. Тогда могут возникать сложные пограничные случаи. Во избежание их может быть проще допустить существование лишь определенных версий сообщений: то есть, разворачивать набор версий некоторого множества сервисов как согласованное целое и гарантировать, что устаревшие версии сообщений будут отбрасываться в первую очередь.

Здесь, опять же, можно убедиться, что на практике независимое развертывание организуется не так просто, если присмотреться к деталям.

Версионирование может быть сложным

Чтобы частично снять вышеупомянутые проблемы, нужно очень аккуратно управлять версионированием. Опять же, зачастую кажется, что если придерживаться стандарта вроде semserver, то такая проблема решаема. Нет, не решается. Придерживаться Semserver разумно, но все равно придется отслеживать версии сервисов и API, смотреть, какие из них могут взаимодействовать.

Такие проблемы могут очень быстро крайне осложниться, и дойти до такой точки, когда вы уже сами не будете представлять, какие сервисы нормально взаимодействуют друг с другом.
Печально известно, как сложно бывает управлять зависимостями в системе, состоящей из модулей Java, библиотек C и т.п. Сложности с конфликтами между независимыми компонентами, потребляемыми конкретным объектом, решаются очень тяжело.

Они сложны, даже если зависимости статичны – и их можно патчить, обновлять, редактировать и т.д.; но, если сами зависимости являются живыми сервисами, то их уже, вероятно, невозможно просто обновить; придется гонять сразу множество версий (сопутствующие сложности описаны выше), либо останавливать систему, пока она не будет полностью обновлена и заново зафиксирована.

Распределенные транзакции

В ситуациях, когда требуется сохранять целостность транзакций в пределах всей операции, микросервисы могут стать настоящей головной болью. Работать с распределенным состоянием сложно, оркестровка множества мелких модулей, каждый из которых может отказать – та еще задача.

Можно попытаться обойти эту проблему, сделав операции идемпотентными, предусмотрев возможность повторных попыток и т.д., во многих случаях это сработает. Но возможны сценарии, когда нам потребуется реализовать всего два исхода транзакции — «удалась» или «не удалась», а промежуточное состояние не предусматривать. Цена такого маневра или попытка реализовать такую систему при помощи микросервисов может быть очень высока.

Микросервисы могут быть замаскированным монолитом

Да, одиночные сервисы и компоненты могут развертываться по отдельности, но в большинстве случаев придется задействовать какую-либо оркестровочную платформу, например, Kubernetes. Если вы пользуетесь управляемым сервисом, например, GKE от Google или EKS от Amazon, то сложное управление кластером в значительной степени удастся автоматизировать.

Однако, если вы управляете кластером сами, то имеете дело с крупной, сложной системой, отказы в которой недопустимы. Да, отдельный сервис может обладать всеми вышеописанными достоинствами, но управлять кластером нужно будет очень осторожно. Развертывать такую систему может быть сложно, обновлять – сложно, восстанавливать после отказа – сложно и т.д.
Зачастую принципиальные преимущества никуда не деваются, но здесь важно не упрощать систему и не недооценивать дополнительные сложности, связанные с управлением еще одной крупной и сложной системой. Да, могут пригодиться управляемые сервисы, но многие из них только-только появились (например, Amazon EKS появился лишь в конце 2017 года).

Напоследок: не путайте микросервисы с архитектурой

Я специально старался не употреблять в этой статье слова на букву «а». Но мой друг Золтан, вычитывавший эту статью (мы написали ее в соавторстве), подметил очень важную вещь.
Микросервисной архитектуры не существует. Микросервисы – просто еще один принцип реализации компонентов, ни больше, ни меньше. Присутствие или отсутствие микросервисов в системе еще не означает, что ее архитектурные проблемы решены.

Во многих отношениях микросервисы скорее связаны с упаковкой и эксплуатацией, а не с проектированием системы как таковым. При инженерии таких систем одной из важнейших задач остается грамотное разграничение компонентов.

Независимо от того, какого размера ваши сервисы, упакованы они в контейнеры Docker или нет – всегда важно задумываться о том, как сложить систему из элементов. Однозначного ответа не существует, вариантов всегда много.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (70):

  1. SbWereWolf
    /#10661362

    спасибо за перевод

  2. zenkz
    /#10661440 / +1

    Микросервисы, как и любая другая архитектура или подход, хороши пока не ударяешься в радикализм. Т.е. выделить авторизацию, вспомогательные компоненты системы в отдельные сервисы — это хорошо и полезно. Но когда начинают дробить оперативную базу данных на части и на каждый чих нужно дёрнуть 2-3 сервиса, то это превращается в кошмар. Отдельно стоит упомянуть проблему коммуникации между сервисами. Во-первых к каждому такому запросу добавляются транспортные расходы, а также нужно затратить очень много усилий чтобы предусмотреть все отказы на сетевом уровне и не потерять данные или их целостность.

    • VolCh
      /#10662142

      Часто оказывается, что если нужно дергать 2-3 сервиса на изменение данных, то или границы сервисов определены неверно, или неверно понята атомарность бизнес-транзакции.

  3. Vkuvaev
    /#10661454

    Третий вариант ответа, допечатывайте, хайп проходит, люди трезвеют, но «опохмелиться» нужно.

  4. Alex_ME
    /#10661540

    Вот все говорят, что одно (если не главное) из преимущество микросервисов — горизонтальное масштабирование. Мол, не справляетесь — а выкатите еще несколько инстансов одним кликом! Ну это все хорошо в случае stateless инстансов. Но это гладко только в случае stateless. Есть состояние — ну все, куча головной боли.


    И все тоже самое можно сделать и с монолитом. Если нехватка на уровне приложения — запустить несколько инстансов. Если бутылочное горлышко БД — это будет проблемой при обоих подходах. Только в случае монолита проблемы обеспечения согласованности распределенных данных начнутся только упершись в ограничения БД, а у микросервисов — сразу.


    А еще увеличенная куча boilerplate кода. Передаем какой-нибудь объект из сервиса А (сериализуем) в сервис Б (десериализуем). Упс, и там и тут нам нужно два соответствующих класса. Давайте добавим общую библиотеку… Постойте, только что всю идею сломали.

    • VolCh
      /#10661970

      Ну, в плане масштабирования у микросервисов плюс в том, что масштабировать можно более гибко по ресурсам, чем монолит. Грубо, если монолит жрёт 100 метров на запрос, какая-то его часть 20 из них, надо 1000 запросов обработать из которых половина приходится на эту часть, то дешевле дать 10 гигов только этой части, 40 остальным, чем 100 монолиту.

    • VulvarisMagistralis
      /#10662004

      Если бутылочное горлышко БД — это будет проблемой при обоих подходах. Только в случае монолита проблемы обеспечения согласованности распределенных данных начнутся только упершись в ограничения БД, а у микросервисов — сразу


      БД так же можно подробить — каждому виду микросервисов своя БД.

      А это значит, что и нагрузка на БД будет размазана по большому числу серверов, пусть не столь гибко как с stateless, но все равно нагрузка на СУБД будет ниже.

      • areht
        /#10662200

        … и тут вам в одном из сервисов надо(внезапно, естественно. И срочно!) сделать join данных с разных баз…

        • VulvarisMagistralis
          /#10662494

          … и тут вам в одном из сервисов надо(внезапно, естественно. И срочно!) сделать join данных с разных баз…


          Внезапно?
          Вы намекаете на то, что монолит прощает плохо продуманную БД?

          • nsinreal
            /#10662500

            Может развернете концепцию плохо продуманной БД? Просто для меня немного удивительно читать ваше сообщение.

            Является ли легкая адаптация к изменившимся требованиям плохим продумыванием?
            И почему вы противопоставляете микросервисам только монолит, а не что-то обеспечивающие модульность без лишних сетевых взаимодействий?

            • VulvarisMagistralis
              /#10662516

              Является ли легкая адаптация к изменившимся требованиям плохим продумыванием?


              Если адаптация легкая — это как раз является хорошим продумыванием.
              И почему вы противопоставляете микросервисам только монолит, а не что-то обеспечивающие модульность без лишних сетевых взаимодействий?


              Проследите нить разговора чуть выше.

              • nsinreal
                /#10662526

                Если адаптация легкая — это как раз является хорошим продумыванием.
                Так как тогда возможность сделать join (т.е. легкая адаптация) является плохим продумыванием?

                Проследите нить разговора чуть выше.
                Я просто говорю о том, что для снижения нагрузки на бд можно использовать другие техники.

                • VulvarisMagistralis
                  /#10662536

                  Так как тогда возможность сделать join (т.е. легкая адаптация) является плохим продумыванием?


                  Выглядит как «возможность сделать все что я хочу не думая ни о каких ограничения».
                  Но так не бывает.

                  Поскольку мы говорим о микросервисах — то давайте вспомним, что вся эта сложность придумана не для чего иного и не кем иным как гигантами веб-индустрии для горизонтального масштабирования.

                  Вот эта же статья, но перевод получше:
                  habrahabr.ru/company/flant/blog/347518
                  Видно, что автор статьи уделил внимание масштабам:
                  Размер команды
                  Можно ли усадить всю вашу команду за один большой стол?

                  Да! Возможно, микросервисы ещё не нужны. Сложности, связанные с деплоем, разработкой, эксплуатацией и т.п., вероятно, легко решаются с помощью хороших коммуникаций и хорошей архитектуры, а микросервисы могут оказаться решением проблемы, которой у вас нет.
                  Нет! Микросервисы могут помочь. Если у вас большая команда или несколько команд, строго обозначить границы компонентов с помощью одной лишь архитектуры может быть затруднительно. Выделение компонентов в изолированные сервисы может помочь в реализации этих границ.


                  Ну а если ваша СУБД потребует маштабирования, то возможность бездумного применения join сегодня приведет вас к неприятной дилемме:

                  1) Резкое снижение производительности в случае запуска СУБД распределенным образом на нескольких серверах, непримлимое снижение производительности.

                  2) Только вертикальное масштабирование возможно. Но крайне дорогое железо для него.

                  Я просто говорю о том, что для снижения нагрузки на бд можно использовать другие техники.


                  Из простых методов знаю — кэш в оперативной памяти или более быстрое железо, прежде всего диски. Наверняка все эти методы уже испробованы были до перехода на микросервисы.

                  Из сложных — тщательно пошевелить мозгами и спроектировать архитектуру не универсальной, а индивидуальной под задачу. Вон люди даже специальные СУБД пишут индивидуально под свои задачи. Будет дорого, долго. Да еще и при изменении задачи — нужно будет переделывать.

                  • nsinreal
                    /#10662582

                    Занятно. Мы говорим о разных вещах. Скажем так, по вашим цитатам получается, что микросервисы по сути изолированные системы с изолированными командами. Я не спорю, что когда у вас сотня разработчиков, то делать единый монолит — не самая лучшая идея.

                    Однако, когда говорят о микросервисном безумии, то имеют в виду нечто другое. Например, у вас пять разработчиков и данные помещаются на одну бд. Вы зачем-то делаете три микросервиса, каждый со своей бд. И они больше связаны, нежели независимы. Это пример того, что называют безумием. И это реальность того, как используются микросервисы.

                    Выглядит как «возможность сделать все что я хочу не думая ни о каких ограничения».

                    В рамках описанных вами масштабов это скорее всего даже невозможно. Точно так же, как если бы я предъявлял бы в претензию стороннему продукту, что я не могу сделать join на их данные.

                    В рамках масштабов типичных (небольшая команда, данные в одной бд) невозможность сделать join является чем-то реально странным. Модульность модульностью, но если за неё вы платите реальным проседанием производительности системы, то вы облажались при продумывании.

                    Из простых методов знаю — кэш в оперативной памяти или более быстрое железо, прежде всего диски. Наверняка все эти методы уже испробованы были до перехода на микросервисы.

                    Я очень сильно улыбаюсь с этой цитаты. Это было бы испробовано, если бы не было «микросервисного безумия». В некоторых проектах сначала начинают с микросервисов, а уже потом добавляют кеширование.

                    Но вообще есть еще: распределенные кеши, репликация, шардирование не по логической структуре, денормализация для ускорения чтения, снижение времени проводимого в транзакциях (многие современные системы держат транзакцию дольше, чем пишут данные), всякие точечные оптимизации. У всех техник свои недостатки. Примечание: но это техники снижения нагрузки, а не техники хендлинга большого количества данных.

                    • VulvarisMagistralis
                      /#10662676

                      Например, у вас пять разработчиков и данные помещаются на одну бд. Вы зачем-то делаете три микросервиса, каждый со своей бд. И они больше связаны, нежели независимы. Это пример того, что называют безумием. И это реальность того, как используются микросервисы.


                      Э… нет.

                      3 — это не микросервисы. Это просто сервисы.

                      И они вполне себе хорошо делятся.

                      Например — интернет-магазин:

                      1. Бэкенд «Каталог». Отображение товаров, поиск, иерархия, фильтры.

                      2. Бэкенд «Корзина» (то, что покупатели выбирают и откладывают, путешествуя по вашему интернет магазину) и «желаемые покупки».

                      3. Бэкенд «Заказы». Оформление товара, адрес, виды доставки, уведомления по email и sms

                      4. Фронтенд.

                      БД вполне себе независимые.

                      Может показаться нужным делать join в «Корзине» и «Заказе» для отображения наименований товаров в корзине и списка товаров при заказе.

                      Но вполне достаточно в БД сервисов «Заказы» и «Корзина» хранить только ID товара, отдавать ID товара на фронтенд, а дальше фронтэнд уже запросит у «Каталога» конкретное наименование по ID (запрос название цены и описания товара по ID легко кэшируется на стороне веб-клиента и не будет дергаться каждый раз)

                      Более того, БД всех 3 сервисов — могут быть разного типа, смотря что лучше для данной подзадачи.

                      Например, каталог с полнотекстовым поиском — это специализированная БД для полнотекстового поиска.
                      Корзина — какая-нибудь БД in-memory с сохранением состояния типа Tarantool
                      Ну а заказы — классическая реляционная СУБД.

                      Другое дело, что еще куча накладных расходов на оркестрацию. Впрочем, возможно что команда из 5 разработчиков работает над магазином не просто так, а цель — покорить весь мир а ля Амазон, АлиБаба или eBay.

                      И тут деление на сервисы позволит легко отмасштабироваться по мере роста посетителей.

                      • nsinreal
                        /#10662946

                        3 — это не микросервисы. Это просто сервисы.
                        Окей, допустим. В таком случае поясните какая по вашему мнению разница между ними.
                        Может показаться нужным делать join в «Корзине» и «Заказе» для отображения наименований товаров в корзине и списка товаров при заказе.

                        Но вполне достаточно в БД сервисов «Заказы» и «Корзина» хранить только ID товара, отдавать ID товара на фронтенд, а дальше фронтэнд уже запросит у «Каталога» конкретное наименование по ID (запрос название цены и описания товара по ID легко кэшируется на стороне веб-клиента и не будет дергаться каждый раз)
                        Серьезно? Вы создали N+1 запросов на ровном месте. Без кеша это адское падение производительности. С кешом это по прежнему адское падение, потому что вы увеличили количество данных для кеширования и они теперь не помещаются в кеш! Да и еще предлагаете кеш втулить на клиент, что делает кеш еще менее влияющим на производительность бекенда. Просто жесть.
                        Более того, БД всех 3 сервисов — могут быть разного типа, смотря что лучше для данной подзадачи.

                        Например, каталог с полнотекстовым поиском — это специализированная БД для полнотекстового поиска.
                        Корзина — какая-нибудь БД in-memory с сохранением состояния типа Tarantool
                        Ну а заказы — классическая реляционная СУБД.
                        Ничто не мешает в монолите юзать три разные бд, если они нужны. Но при этом количество ситуация «не могу сделать join» будет в разы меньше.

                        • VulvarisMagistralis
                          /#10663008

                          Серьезно? Вы создали N+1 запросов на ровном месте. Без кеша это адское падение производительности. С кешом это по прежнему адское падение, потому что вы увеличили количество данных для кеширования и они теперь не помещаются в кеш! Да и еще предлагаете кеш втулить на клиент, что делает кеш еще менее влияющим на производительность бекенда. Просто жесть.


                          Кэш на клиенте в браузере — УЖЕ есть, он существует и используется браузером ВСЕГДА.

                          Он используется вашим браузером прямо сейчас.
                          Это снижает и загрузку и ваших каналов связи и каналов связи сервера Хабра и нагрузку на сервер Хабра.

                          Кэш на клиенте — это норма.

                          С кешом это по прежнему адское падение, потому что вы увеличили количество данных для кеширования и они теперь не помещаются в кеш!


                          Что?

                          • nsinreal
                            /#10663042

                            Это снижает и загрузку и ваших каналов связи и каналов связи сервера Хабра и нагрузку на сервер Хабра.

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

                            Что?

                            Допустим я хочу посмотреть детали заказа. В классической системе это один запрос к бд и один запрос к серверу. В описанной вами схеме это N+1 запросов к бд и N+1 запросов к серверам. Соответственно количество данных, которые нужно кешировать увеличивается. Но память ограниченная. Значит кеш теперь может спасать меньшее количество запросов.

                            • VulvarisMagistralis
                              /#10663154

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


                              Наименование и описания товаров — никакие не динамические данные

                              • nsinreal
                                /#10663470

                                Вообще в целом это довольно динамические данные, которые изменяются редко. Но не суть.

                                Перекладывать кэш полностью с бекенда на клиент имеет смысл только если у вас очень большое количество операций дублирующихся чтения в рамках одной сессии. Это верно не для всех систем.

                                Если во время одной сессии человек много работает с разными данными, то кеш на бекенде все так же нужен.
                                Если во время одной сессии человек мало работает с данными, то кеш на бекенде все так же нужен.

                                В описанных мною случаях отсутствие кеша на бекенде будет почти аналогично отсутствию кеша вообще.

                            • VulvarisMagistralis
                              /#10663160

                              Допустим я хочу посмотреть детали заказа. В классической системе это один запрос к бд и один запрос к серверу. В описанной вами схеме это N+1 запросов к бд и N+1 запросов к серверам. Соответственно количество данных, которые нужно кешировать увеличивается. Но память ограниченная. Значит кеш теперь может спасать меньшее количество запросов.


                              В моей схеме это будет все тот же один вопрос к БД, так как если вы хотите видеть детали заказа, то этот товар вы уже смотрели и в корзину клали, то есть он гарантировано есть в локальном кэше браузера.

                              Но память ограниченная. Значит кеш теперь может спасать меньшее количество запросов.


                              Браузерный кэш на диске. И места там много.

                              • nsinreal
                                /#10663454

                                Вы заоптимизировались под определенный путь навигации пользователя. Это очень хорошая оптимизация. Но она не будет и не может работать всегда. Это не решает проблему, хотя и очень сильно уменьшает её.

                            • VolCh
                              /#10663484 / +1

                              Откуда N+1? Обычно это 1+1.

                              • nsinreal
                                /#10663512

                                В корзине/заказе обычно может быть больше одного товара. Поэтому N+1. Одна сущность + N связанных. Да, можно было бы реализовать балк-запрос на N связанных сущностей, но вылезут дополнительные трудности с кешом.

                                • VolCh
                                  /#10664104

                                  Балк-запрос я и имел в виду.


                                  С кешом всегда трудности, с одной стороны, а, с другой, не особо он в кейсе корзины и нужен, если идти по пути 1+1 запросов.

                    • VulvarisMagistralis
                      /#10662680

                      Я очень сильно улыбаюсь с этой цитаты. Это было бы испробовано, если бы не было «микросервисного безумия». В некоторых проектах сначала начинают с микросервисов, а уже потом добавляют кеширование.


                      Это почти ничего не стоит.
                      В сотни раз дешевле микросервисов.

                      Думаю, что все же испробовано.

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


                      Не считается.
                      Ибо тут вы уже напрочь отходите от тех самых «легких и простых и дешевых» join с которых и начался наш разговор.

                      • nsinreal
                        /#10662950

                        Это почти ничего не стоит.
                        В сотни раз дешевле микросервисов.

                        Думаю, что все же испробовано.

                        Вы смешной. Я вам говорю о том, что вижу с самого начала проекта. Это не какая-то сранная гипотетическая ситуация. Такие проекты реальны, я их видел.

                        Ибо тут вы уже напрочь отходите от тех самых «легких и простых и дешевых» join с которых и начался наш разговор.

                        Я не понимаю как распределенные кеши могут мешать делать join. Я не пониманию, как денормализация может мешать делать join. Шардирование — да, может, но количество таких ситуаций в идеале будет реже. Просто потому что разрез выбирается согласно данным, а не согласно фичам.

                        • VulvarisMagistralis
                          /#10663020

                          Я не понимаю как распределенные кеши могут мешать делать join. Я не пониманию, как денормализация может мешать делать join. Шардирование — да, может, но количество таких ситуаций в идеале будет реже.


                          При денормализации join не нужен. В этом и смысл денормализации.

                          Шардирование — мешает. Распределенный — кэш не мешает?
                          Поясните пожалуйста.

                          • nsinreal
                            /#10663054

                            При денормализации join не нужен. В этом и смысл денормализации.

                            У вас же больше двух таблиц в бд. Вот здесь оптимизировали чтение, улучшилась общая отзывчивость бд. А вот здесь продолжаем использовать join.

                            Распределенный — кэш не мешает

                            Смотрите, есть какой-нибудь запрос: дай мне заказ со всеми товарами. Это один запрос к бд с использованием join. Дальше, я беру и результаты сохраняю в распределенном кеше. В следующий раз я беру и достаю из кеша результат этого запроса. Естественно, не забывая про инвалидацию.

                            Кеш есть, join есть. В чем проблема?

                            • VulvarisMagistralis
                              /#10663202

                              Кеш есть, join есть. В чем проблема?


                              В слове «распределенный»
                              Смотрите, есть какой-нибудь запрос: дай мне заказ со всеми товарами. Это один запрос к бд с использованием join.


                              join не нужен.
                              Вам нужен заказ — это (ID_товара, количество, сумма)
                              Сам товар — у нас уже в локальном кэше.

                              • areht
                                /#10663406 / +1

                                Напомните, а как вы инвалидируете локальный кэш?

                              • nsinreal
                                /#10663472

                                В слове «распределенный»

                                Распишите, что с вашей точки зрения создает проблему.

                                Также заодно распишите почему браузерный кеш — ок, а распределенный кеш на бекенде — не ок. Реально интересно :-)

          • areht
            /#10662522

            Я намекаю, что прежде чем оптимизировать БД вертикальным разрезанием надо хорошо подумать несколько раз.
            (это даже не обсуждая, что 80% нагрузки будет от 20% микросервисов и оптимизировать так едва ли получится)

            И да, внезапно бывает хорошо продуманная БД перестаёт удовлетворять требованиям. Не знаю при чем тут монолит.

        • VulvarisMagistralis
          /#10662520

          … и тут вам в одном из сервисов надо(внезапно, естественно. И срочно!) сделать join данных с разных баз…


          Ничего страшного. Огромные СУБД можно построить только как распределенные по множеству серверов.

          Классический JOIN от реляционных баз данных — конечно же в такой ситуации себя показывает плохо. Поэтому подобные СУБД и не строятся как реляционные.

          • areht
            /#10662544

            Вы же понимаете, что JOIN я там упомянул не как оператор SQL, а как некую тяжелую операцию над множествами?

            Сможете ли вы сделать её через join в реляционной БД, или придумывать более экзотические решения — не существенно (а вот количество данных, прокачиваемых для этого через сеть — существенно).

            • VulvarisMagistralis
              /#10662560

              Вы же понимаете, что JOIN я там упомянул не как оператор SQL, а как некую тяжелую операцию над множествами?


              В том то и дело — что это ограничение не только реляционных СУБД.

              Когда придумали концепцию «ура NoSQL лучше» выяснилось, что:

              1. NoSQL заведомо быстрее реляционных СУБД только пока нет join-подобных операций
              2. Сделать распределенную СУБД с полноценным ACID и высокой производительность — невозможно.


              Пробовали, придумывали, но пока ничего не придуманно с быстрыми распределенными join.

              Классические реляционные СУБД делают join быстрее почти всех. Но строго на одном компьютере.

              Потому я и говорю, что в данном конкретном случае, когда речь идет о микросервисах,
              то давайте не будем забывать, что все эти микросервисные заморочки мы терпим прежде всего из за прекрасной масштабируемости горизонтальной.

              А join — плохо поддающаяся горизонтальной масштабируемости концепция.

              Другими словами:
              если у вас вся система (неважно, монолит она или микросервисная) дает нагрузку, которую может держать один сервер, то вы можете применять join без проблем.
              Но — ровно до тех пор пока вам хватает одного сервера СУБД на вашу систему.

              Как только у вас появляется нужда в горизонтальном масштабировании СУБД — от join придется или отказываться или строго ограничивать их использование.

              Но изначально-то разговор об этом зашел почему?
              Потому что я упомянул об одной из двух концепций в микросервисах — своя БД для каждого вида микросервисов.
              Есть еще одна концепция — одна общая БД на все.

              • areht
                /#10662578

                Что-то вы в кучу всё смешали, релиционное-nosql, распределенное-нераспределенное, ACID-BASE… Давайте теплое с мягким не путать.

                > Сделать распределенную СУБД с полноценным ACID и высокой производительность — невозможно.

                Этой новости минимум лет 20, так что она чуть постарше NoSQL.

                > БД так же можно подробить — каждому виду микросервисов своя БД.

                Я так понимаю, что это не про хорошее горизонтальное масштабирование. Это раньше у вас было 3 сервера с единой базой данных, а стало два с левой половинкой, и один с правой. Ну или было 300 типа одинаковых, а стало 200+100 — не суть.

                > Классические реляционные СУБД делают join быстрее почти всех. Но строго на одном компьютере.

                Раньше, пока вы не поделили инстансы БД по микросервисам, джойн левого с правым и работал бы на одном компьютере (любом из 300). То есть пока у нас база данных помещалась на одном компьютере, у нас проблемы с джойном не было вообще. Мы же микросервисы внедряем когда команда за столом перестает помещаться, а не БД на диске?

                > прежде всего из за прекрасной масштабируемости горизонтальной.

                Ну так ещё раз, было у вас 3 сервера и 3 инстанса БД. Вы выделили аутентификацию в отдельный микросервис, теперь у вас 3 сервера и до 6 инстансов БД. Что именно вы планируете выиграть от разделения БД при масштабировании, при том, что данные аутентификации занимают менее 1% ресурсов?

                • VulvarisMagistralis
                  /#10662686

                  Ну так ещё раз, было у вас 3 сервера и 3 инстанса БД. Вы выделили аутентификацию в отдельный микросервис, теперь у вас 3 сервера и до 6 инстансов БД. Что именно вы планируете выиграть от разделения БД при масштабировании, при том, что данные аутентификации занимают менее 1% ресурсов?


                  Я выделил только один-единственный сервис для начала.
                  Чтобы выделить еще нужно хоть какой нибудь конкретный пример рассматривать.

                  Возьмем задачу интернет-магазина:

                  • Так же легко и просто выделяется корзина.
                  • И отдельно от корзины заказы товаров.
                  • Статьи, которые многие сайты для SEO публикуют у себя.
                  • Шлюз к платежной системе.
                  • Уведомления по SMS
                  • Уведомления по eMail
                  • Каталог товара (без поиска), что потом прекрасно кэшируется на веб-клиенте — какой нибудь example.com/catalog/product_by_id_138 с использованием технологии etag, к примеру
                  • Поиск по товару (да, да, да — БД не обязана отдавать найденную информацию, вполе достаточно, если она отдаст ID найденных товаров), ну поиск товара по ID будет уже простым, так как он уже закэширован на веб-клиенте.
                  • Всевозможные нейросети для «рекомендации товаров» покупателю
                  • Складской учет остатков
                  • Мониторинги разного толка
                  • и т.п.

                  • areht
                    /#10662794

                    Вы так отвечаете на вопрос «Что именно вы планируете выиграть от разделения БД»? Ответ, видимо «ничего, зато какая движуха была»© анекдот.

                    Для начала, у вас базу данных использует только 3 сервиса из перечисленного: учет, каталог и поиск. Кстати, а как вы производите поиск по каталогу товаров, если сам каталог в базе другого сервиса?

                    • VulvarisMagistralis
                      /#10662888

                      Вы так отвечаете на вопрос «Что именно вы планируете выиграть от разделения БД»? Ответ, видимо «ничего, зато какая движуха была»© анекдот.


                      От масштабов задачи зависит.
                      Для начала, у вас базу данных использует только 3 сервиса из перечисленного: учет, каталог и поиск. Кстати, а как вы производите поиск по каталогу товаров, если сам каталог в базе другого сервиса?


                      Я это описал уже.

                      Вариант А)

                      В полнотекстовом поиске/фильтрации — всего лишь ИД.
                      Сами элементы каталога там не обязательны.

                      То есть:
                      Ищите по слову «лабуда» с фильтром «цвет=зеленый».
                      В ответ вам возвращается: [123,778,345]

                      Обращаетесь к кэшу на веб-клиенте с целью получить что такое товары с кодами 123,778,345.
                      Если в кэше пусто — обращаетесь к каталогу и получаете что это за товары такие

                      Вариант Б)

                      Разве это не вы привели в качестве примера повышения производительности денормализацию?

                      Кто мешает держать в БД каждого сервиса свою копию списка товаров?

                      • areht
                        /#10662918 / +1

                        > Сами элементы каталога там не обязательны.

                        Давайте уточним:
                        каталог — это там где у нас привязка "[123,778,345] лежит в категории «валенки», так?
                        А карточку [123,778,345] мы уже из другого сервиса получаем?

                        > Ищите по слову «лабуда» с фильтром «цвет=зеленый».
                        > В ответ вам возвращается: [123,778,345]

                        Нет, я ищу «лабуда» с фильтром «в категории валенки». А спрашиваю как вы это реализовывать планируете, не держа категории и карточки товаров в одной базе. И что вы при этом выиграть хотите.

                        > Разве это не вы привели в качестве примера повышения производительности денормализацию?

                        я?

                        > Кто мешает держать в БД каждого сервиса свою копию списка товаров?

                        Exactly.
                        То есть мы сначала поделим БД, а потом накостылим репликацию левой части в правую, что бы было удобно join делать? Напомните, а делили то зачем?

                        • VulvarisMagistralis
                          /#10663032

                          Давайте уточним:
                          каталог — это там где у нас привязка "[123,778,345] лежит в категории «валенки», так?


                          Это просто обобщенный список товара.

                          Вы можете получить этот список как содержимое группы валенки.
                          Вы можете получить ровно такой же список как содержимое ответа при поиске по названию товара.
                          И т.п.

                          А карточку [123,778,345] мы уже из другого сервиса получаем?


                          Да.

                          Для одного-единственного запроса это выглядит, согласен, странновато.

                          Но в реальности — никаких проблем производительности.

                          Так как типичное поведение пользователя — просматривать товары одной группы, заходить вновь и вновь, обдумываеть покупку, смотреть в корзину.

                          И там везде будет отображаться уже закэшированые названия товаров.

                          Ваш же вариант, когда нужно сразу отдавать пользователю полный результат иллюзорно эффективен.

                          При множестве запросов — у меня дешевле выходит.

                        • VulvarisMagistralis
                          /#10663034

                          То есть мы сначала поделим БД, а потом накостылим репликацию левой части в правую, что бы было удобно join делать? Напомните, а делили то зачем?


                          Ну если исключить эмоциональную окраску терминов — да.

                          Правда, я вам толкую за то, что join не нужен в данном случае. Его значение — преувеличено.

                          Вы рассуждаете шаблонно — видите только проблемы РОВНО ОДНОГО текущего запроса.

                          А ведь в реальности пользователи проводят на сайте много времени (ну по крайней мере так бы хотелось владельцам интернет-магазина). И на каждый чих ВНОВЬ и ВНОВЬ отдавать им все то же наименование товара — глупо и не эффективно с точки зрения производительности.

                          На каждый чих придется отдавать список ID товаров, так как затруднительно закэшировать все результаты поиска. Но список ID — это компактно и просто.

                          А получение полной информации из имеющегося ID — это уже из кэша.

                          Про денормализацию — это для другого моего оппонента приведено
                          Для nsinreal:
                          habrahabr.ru/company/piter/blog/348740/#comment_10662582
                          Сам бы я выбрал бы первый вариант.

                          • areht
                            /#10663062

                            > Так как типичное поведение пользователя — просматривать товары одной группы, заходить вновь и вновь, обдумываеть покупку, смотреть в корзину.

                            > И там везде будет отображаться уже закэшированые названия товаров.

                            И поэтому это можно и не обсуждать — нагрузку будет давать именно поиск.

                            > Ваш же вариант, когда нужно сразу отдавать пользователю полный результат иллюзорно эффективен.

                            Это не мой вариант, я с вами вообще про базу данных говорю. Не знаю зачем вы мне про взаимодействие с клиентом пытаетесь рассказать.

                            >> Напомните, а делили то зачем?
                            > Ну если исключить эмоциональную окраску терминов — да.

                            Ну, я так и понял.

                            • VulvarisMagistralis
                              /#10663208

                              Это не мой вариант, я с вами вообще про базу данных говорю. Не знаю зачем вы мне про взаимодействие с клиентом пытаетесь рассказать.


                              Вы рассматриваете задачу только с точки зрения базы данных. А не всей системы в целом.

                              О каких микросервисах можно говорить в таком случае?

                              Микросервисы — это как раз система грамотно разбитая на части.

                              • areht
                                /#10663248

                                Если вы хотите аргументировать что мне мешает отдавать данные кусочками из монолита — пожалуйста. Если нет — не понимаю почему взаимодействие с клиентом мне мешает грамотно делить(или не делить) систему на части.

              • VolCh
                /#10663492 / +1

                Потому что я упомянул об одной из двух концепций в микросервисах — своя БД для каждого вида микросервисов.
                Есть еще одна концепция — одна общая БД на все.

                Есть ещё одна: своя БД для каждого микросервиса для записи и дергания по ключу и одна общая для чтения по всяким джойнам.

      • ElectroGuard
        /#10662382

        если не нужно, что бы была одна бд, одни данные. а чаще всего нужно.

        • VulvarisMagistralis
          /#10662514

          если не нужно, что бы была одна бд, одни данные. а чаще всего нужно.


          Конечно, нас система интересует только как единое целое.
          И в этом смысле БД одна.

          Но почему БД должна быть расположена строго на одном сервере?

          Скажем, аутентификация пользователей и соответствующая БД — вполне безболезненно выносится отдельно во многих случаях.

          • ElectroGuard
            /#10662674

            Выносится, только репликацию делать придётся делать постоянно между базами. Всё это — усложнение. И, как в статье верно замечено, потенциальные точки отказа.

  5. Envek
    /#10661832

    Если вы всё равно делаете микросервисы, то я вам пару статей чтива принёс, как некоторые проблемы решать:


  6. hardegor
    /#10661920

    Такие же проблемы в Linux — множество сервисов, разные версии библиотек, слабо описанные API, история идёт по спирали, теперь и до web добралась.

  7. fukkit
    /#10661946 / +2

    Правильно приготовить микросервисы — относительно непросто. Нытье по этому поводу исходит от людей, которые, поддавшись хайпу, не рассчитали свои силы. Если это считать — безумием, оно закончится ровно тогда, когда основная масса хипстеров потрогает микросервисы и решит для себя, учиться дальше или забить.

    • VolCh
      /#10661974

      Ещё вариант — не рассчитали способности админов/девопсов поддерживать сложную распределённую архитектуру.

    • nsinreal
      /#10662584

      А также нытье исходит от людей, которые пришли в проекты с микросервисным безумием имея достаточный бэкграунд, чтобы понять как легко ломается система

  8. VulvarisMagistralis
    /#10662262

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


    Кто может пояснить?
    Что такое бессервисная модель?

    • RidgeA
      /#10662286

      Ошибка в переводе. В оригинале — serverless

    • gtbear
      /#10662288

      Скорее всего это был перевод с serverless. Такие сервисы как например Amazon Lambda. В этом случае приложение является как бы функцией которая запускается по требованию.

      • VulvarisMagistralis
        /#10662380

        Но как на этом написать ВСЮ систему?
        Речь же об этом.

        • gtbear
          /#10662572

          serverless актуален для различных облачных сред, где персистентное хранилище предоставляется как служба (тот же amazon dynamodb). Так что вполне можно разрабатывать только serverless код, а всю боль со stateless отдать на откуп провайдера. Я не думаю что многие разрабатывают по настоящему stateful приложения, которым очень нужен доступ к диску для корректной работы, обычно все ходят за данными во внешние сервисы (та же SQL/noSQL/kv база данных).

    • kkorsakoff
      /#10662334

      Вероятно serverless? По контексту именно оно. Azure Functions/Amazon Lambda

    • ph_piter
      /#10664006

      Спасибо за внимательность, поправили

  9. ElectroGuard
    /#10662434

    У нас, например, примерно четверть кода занимает взаимодействие гуй <> сервис (имеется в виду сервис windows). После перехода на UniGUI отказались от разделения сервиса на части, обработка сильно упростилась и стабилизировалась.

  10. Alesh
    /#10662548

    До до, микросервисы это зло. Лепите все одним комом на ПиЭчПи ;)

  11. KirEv
    /#10663226

    сервисы\микросервисы — как дальнейшее развитие монолита…

    со временем (не один год) кодовая база разрастается, нужно поддерживать текущие функции системы, создавать новые, приходят новые люди в компанию, новые технологии…

    вынос функции\функций из большого блока (монолит) — и обращение через, пусть даже внутренний API не видимый миру — нормальная практика, и было это дело задолго до микросервисного хайпа…

    оттого и проектировать изначально как микросервис — наверное глупо, разработка такого решение в разы сложнее, оттого дольше и дороже, а бизнес ждать не может.

  12. vialz
    /#10664008

    Честно говоря, не понимаю почему столько копий ломается на эту тему. Не соглашусь с автором статьи что MSA это не про архитектуру — на мой взгляд вполне себе архитектурный стиль. Другое дело что это если взять тот же togaf, то этот стиль влияет прямо на 1 домен архитектуры предприятия.
    В целом же прежде чем что-то менять и имплементировать, надо подумать зачем. Микросервисы это довольно дорого как по ресурсам железа, так и по людям. Спецов по классическому подходу гораздо больше, чем ребят, реально хорошо сделавших микросервисы в проме. Развернутый на 1 ноуте кластер кубера с 2-3 тестовыми сервисами не в счет :)
    Да, с развитием контейнеризации и оркестрации сделать правильный msa стало более реально. Но всегда перед тем как что-то делать надо задать себе вопрос «в чем профит?». Правильных ответов на мой взгляд 2: «Без msa вот прям никак не будет работать» и «так дешевле. Я все-все просчитал и так дешевле». В остальных случаях вы должны понимать что скорее всего реализуете свои амбиции и жажду знаний за счет работодателя.

    • VolCh
      /#10664120

      В чём выражается "довольно дорого по ресурсам железа"? Один из плюсов (микро)сервисов — экономия на железе при прочих равных, даже если не брать гибкие скейлинги в облаках.


      По людям тоже спорно. На разработку большинства микросервисов (не архитектуры, самих сервисов) можно как раз брать менее квалифицированных спецов — они архитектурно не смогут нарушить изоляцию модуля, с одной стороны, а, с другой, для некритических частей можно брать более дешевый стек в целом. Грубо, не писать всё приложении на C++ с ассемблерными вставками из-за того, что один модуль очень требователен к производительности, f только этот модуль на нём, а остальное на PHP :)

  13. vialz
    /#10664270

    Один из плюсов (микро)сервисов — экономия на железе при прочих равных, даже если не брать гибкие скейлинги в облаках.

    На мой взгляд, все же больше. Помимо резервирования мощности для скейлинга, там еще реализация интеграционной обвязки, превращение stateful в стейтлесс, да и сама оркестрация и непростой мониторинг и аудит.
    По людям тоже спорно. На разработку большинства микросервисов (не архитектуры, самих сервисов) можно как раз брать менее квалифицированных спецов — они архитектурно не смогут нарушить изоляцию модуля, с одной стороны, а, с другой, для некритических частей можно брать более дешевый стек в целом. Грубо, не писать всё приложении на C++ с ассемблерными вставками из-за того, что один модуль очень требователен к производительности, f только этот модуль на нём, а остальное на PHP :)

    Тут скорее история про опыт людей работы в командах изолированных сервисах и их «софт скиллз». Если вы возьмете команду монолита и рассадите их по модулям, то первый же релиз скорее всего будет ужасен. Взаимное возлагание вины за баги, непонимание общей картины как оно должно работать. «С моей стороны пуля вылетела...».