09.06.2024 10:00
Bright_Translate 30 16000 Источник

Писать эту статью было весело. Многие наверняка её захейтят, но …

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

Сегодня микросервисы очень популярны. Это прекрасный архитектурный стиль, который помогает масштабировать систему и саму организацию. Их используют многие успешные компании (Netflix, Spotify и прочие). Поэтому вполне нормально, что большинство организаций уже применяют или планируют начать применять этот стиль. Однако не все учитывают сопутствующие затраты.

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

Как всё начиналось — были ли это микросервисы?


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

В то время я читал книгу «Scalability Rules: 50 Principles for Scaling Web Sites», где была представлена модель AKF Scale Cube.


Модель AKF Scale Cube из книги «Scalability Rules: 50 Principles for Scaling Web Sites»

Я нашёл эту модель чрезвычайно понятной, поэтому стал с её помощью объяснять другим, почему нам нужно использовать в продакшене иные исполняемые файлы. Картина трафика, обрабатываемого модулем Search, сильно отличалась от его картины для модуля Shopping Cart. Разумным решением было разделить эти компоненты. Кроме того, это бы позволило нам наладить независимую работу нескольких команд, решив проблему масштабирования штата до тысяч инженеров.

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

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

Так в чём проблема?


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

▍ Пример 1 — вы создаёте сервис, они создают сервис, все создают сервисы


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

В частности, припоминаю случай, когда общался с двумя директорами по разработке (Director of Engineering) в стартапе, инженерный отдел которого включал 200 человек. Невероятные ребята, очень умные и открытые к общению.

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

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

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

▍ Пример 2 — вы меняетесь, я меняюсь, все мы меняемся


Нелегко правильно реализовать концепцию высокой связности и слабого зацепления (high cohesion and low coupling), особенно в контексте микросервисов. У вас могут получиться очень маленькие микросервисы (иначе называемые наносервисами), имеющие тесное зацепление и слабую внутреннюю связность.

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

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

▍ Пример 3 — всё было хорошо, пока не испортилось


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

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

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

▍ Пример 4 — давайте запустим стартап на основе микросервисов


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

Думаю, вы согласитесь, что очень круто создавать проекты с нуля. Можно сравнить такой проект с пустым холстом, ожидающим руки художника. В данном случае художник решил нарисовать цветную картину. Он выбрал для неё основные цвета — Ruby, Golang и Java — смешав их с небольшим количеством Postgresql, Elasticsearch и Cassandra.

Картина? Это мог быть труд на уровне Пикассо, если бы создателям хватило времени на его завершение.

Всегда ли это плохо?

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

Хорошо, но почему?


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

На мой взгляд, причина глубже, и Скотт Ханнер неплохо выразил одну из версий в своём твите:


Перевод
Думаю, что я сильно привык к микросервисам, ровно как и к ООП. Я уже не помню, как выглядит что-то иное. Эта информация оказалась вытеснена из сознания многих знакомых мне людей. Можно сравнить это с «Новоязом» из романа «1984». Мы утратили способность выстраивать мысль. Нам нужна помощь.

Пожалуй, мы слишком глубоко впитали концепцию микросервисов. Возможно, поэтому её применяет так много небольших команд. Она глубоко укоренилась в нашей модели мышления.
Часть вины также можно возложить на политику нулевой процентной ставки (zero interest-rate policy, ZIRP), о чём говорит DHH в этом твите:


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

Скотт Ханн: Я слышал, что микросервисы вызвали ажиотаж. Но дело обстоит куда хуже. Они уничтожают всё остальное. Даже если я предложу не разделять какие-то два компонента, кто-нибудь обязательно выпучит глаза со словами: «Это же будет монолит», будто мы все должны понимать, насколько это глупо.

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

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

У вас ещё есть время


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

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

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

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

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

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

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

Иногда микросервисы прекрасны, но вам они, возможно, не нужны.

Telegram-канал со скидками, розыгрышами призов и новостями IT ?

Комментарии (30)


  1. Farongy
    09.06.2024 11:11
    #26914753
    +2

    Пример 1 — вы создаёте сервис, они создают сервис, все создают сервисы

    А можно подробнее как для данного примера поможет "монолит"?

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

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


    1. SpiderEkb
      09.06.2024 11:11
      #26914925
      +19

      На самом деле, какой-то крупный монолитный монолит - это (на мой взгляд) некая страшилка типа бабайки под кроватью (свесишь руку с кровати - бабайка откусит).

      Куда более распространены т.н. "модульные монолиты", которые и не монолиты вовсе а набор модулей, каждый из которых и есть тот самый "черный ящик", выполняющий свою атомарную логическую функцию. Фактически каждый модуль суть процедура, оформленная в виде отдельного бинарника (со всеми вытекающими - отдельно разрабатываем-отлаживаем-тестируем-разворачиваем, в любой момент можем изменить внутреннюю логику при условии сохранения обратной совместимости контракта и т.п.)

      Вообще все это восходит корнями к модели акторов А уж модульный монолит, микросервисы... Это тонкости реализации. Везде есть свои плюсы и минусы. Основной минус микросервисов, как мне кажется, в их чрезмерной изолированности. Например, если у вас есть БД из десятков тысяч объектов и все сервисы так или иначе их совместно используют, то держать копию БД на каждом сервисе - огромные проблемы с синхронизацией и репликацией. Опять же передача данных между сервисами через джейсоны (да даже протобуфы) тащит за собой большие накладные расходы (особенно если речь идет о hiload системах с десятками тысяч взаимодействующих между собой сервисов).

      И тут опять выиграет "модульный монолит" при условии что каждый модуль, будучи обособленным бинарником, может вызываться как обычная внутренняя процедура с передачей описанного контрактом набора параметров as is (т.е. ровно так же, как вызывается любая процедура).


      1. c3gdlk
        09.06.2024 11:11
        #26914943
        +1

        Про модули не совсем согласен. Но, в целом, Вы правы. Микросервисы это не что-то, к чему стоит стремиться. Это очень, очень плохая архитектура. Просто, она лучше, чем смерть проекта. Аналогия, которая на ум приходит, это https://ru.wikipedia.org/wiki/Маляриятерапия


        1. SpiderEkb
          09.06.2024 11:11
          #26914979
          +3

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

          Сам работаю с "модульным монолитом". Наш стек позволяет у любой программе иметь набор аргументов не фиксированный, как в С (int argc, char* argv[]) но произвольный - как у любой процедуры. Фактически, процедура может быть внутренней (в той же программе) или внешней - внутри динамичекской библиотеки (extproc) - это случаи раннего связывания, или вообще отдельной программой (extpgm) - позднее связывание.

          И вот как пример. Есть такая сущность у нас - дата актуализации клиента. Которая берется из таблицы. Причем, таблица эта - "историческая" - хранит всю историю изменения этих самых дат актуализации. И чтобы получить текущее значение баты актуализации нужно по этой таблице взять самую свежую (с последней датой изменения) запись. Для этого был реализован ретривер - программа GETDA1R для вызова которой она (в вызывающей программе) описывалась как "внешняя процедура"

          Dcl-PR getDatInfo  extpgm('GETDA1R');
  CUS           char(6)    const;
  CLC           char(3)    const;
  Typ           char(3)    const;
  dsHDA         likeds(t_dsHDA);
  dateOnly      ind        options(*omit: *nopass);
  Error         char(37)   options(*nopass);
End-PR;

          на вход которой передается идентификатор клиента (CUS + CLC), тип даты актуализации (Typ) и структура для заполнения нужной информацией из найденной записи dsHDA

          Dcl-DS t_dsHDA len(512) qualified template;
  DAT           zoned(7:0) inz(0);
  USID          char(4)    inz(' ');
  UNAM          char(35)   inz(' ');
  BRNM          char(4)    inz(' ');
  BRN           char(35)   inz(' ');
  CRD           timestamp  inz(*loval);
  MBN           char(2)    inz(' ');
  MBND          char(35)   inz(' ');
  SQN           zoned(3:0) inz(0);
End-DS;

          Ну и пара необязательных параметров...

          Т.е. внутри вызывающей программы все это вызывается как обычная процедура, например:

          getDatInfo(CUS: CLC: 'DOC': dsHDA);

          При вызове getDatInfo на самом деле будет вызвана программа GETDA1R.

          Таких вызовов огромное количество во всей системе. В самых разных модулях.

          В какой-то момент решили улучшить производительность и сделали "витрину" - отдельная таблица, где хранятся только текущие значения (т.е. не надо искать "самую свежую запись" - просто берем запись по уникальному ключу CUS + CLC + TYP и все.

          Для этого просто переписали сам ретривер. С сохранением контракта. Все. Во всех 100500 местах где оно вызывается стало работать быстрее. Без отслеживания - где вызывается, как вызывается. Контракт сохранился - все работает. Просто заменили один модуль.

          Тот самый "черный ящик", выполняющий атомарную логическую операцию.


      1. Batalmv
        09.06.2024 11:11
        #26915427

        Поддержу

        Надо попробовать на каком-то проекте вернуться к "монолиту", потому что конечно "интересно", но иногда думаешь - а как бы оно все было проще :)


      1. Farongy
        09.06.2024 11:11
        #26915857
        +1

        Вообще то одна БД на кучу сервисов - это антипаттерн для микросервисов.

        Если у вас что-то такое, есть распределённые транзакции, etc., то очевидно имеет смысл использовать другие инструменты.


        1. SpiderEkb
          09.06.2024 11:11
          #26916677
          +2

          Да, об чем и речь.

          А нас (АБС банка) порядка 30 000 объектов БД. И несколько десятков тысяч различных программных модулей, которые эти объекты использует одновременно, реализуя различную бизнес-логику. Объекты БД, которые используются одним-двумя модулями, конечно, есть, но таковых крайне мало (обычно это какие-то рабочие таблицы, не для постоянного хранения данных). А есть ряд таблиц (например, основная таблица клиентов), которые используются практически везде (в том или ином виде).

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

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

          Аналогично работают т.н. "журнальные мониторы" - есть сервис, отслеживающий изменения в таблицах по системному журналу. При обнаружении изменения в журналируемой таблице сервис находит (по настройкам) связанные с этой таблицей ЖМ и запускает их с передачей на вход образов записей "до" и "после" и типа изменения (удаление/добавление/изменение) записи.

          Т.е. система когда событие инициирует связанный с ним актор.


      1. rukhi7
        09.06.2024 11:11
        #26916065
        +1

        Основной минус микросервисов, как мне кажется, в их чрезмерной изолированности.

        А что мешает использовать в нескольких микросервисах общую библиотеку? Это противоречит определению микросервиса? А сколько есть определений микросервисов? Какому проценту этих определений противоречит использование одной библиотеки несколькими микросервисами?

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


        1. SpiderEkb
          09.06.2024 11:11
          #26916693

          Что такой "общая библиотека" (и вообще "библиотека") в данном контексте?

          Я не против микросервисов как таковых. Просто есть много вариантов реализации "модульности". И каждый имеет свои особенности и уже от системы и задачи зависит как именно реализовать тот набор требований (модульность и независимость разработки-отладки-тестирования-развертывания для каждого модуля) к системе.


          1. rukhi7
            09.06.2024 11:11
            #26917165

            Что такой "общая библиотека" (и вообще "библиотека") в данном контексте?

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

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


            1. SpiderEkb
              09.06.2024 11:11
              #26917501

              "В данном контексте" - значит что вы имели ввиду, говоря

              А что мешает использовать в нескольких микросервисах общую библиотеку?

              Лично для меня "библиотека" это может быть или статическая библиотека как объект сборки программы. Или динамическая библиотека как объект, содержащий некоторый набор функций, используемых разными программами.

              А на нашей платформе "библиотека" это вообще объект файловой системы (некий аналог "папки" в винде, к примеру).

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

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

              Хотя, на самом деле, контейнеризация отнюдь не обязательное условие микросервисной архитектуры


              1. rukhi7
                09.06.2024 11:11
                #26918003
                +1

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

                мне кажется что это описание:

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

                это вообще не о чем! Потому что любой исполняемый файл (программа) и так, по определению, делает что-то одно, и взаимодействует с другими программами простыми средствами (командная строка, консольный ввод-вывод) , получается что мы просто теперь любой исполняемый файл называем модно-молодежно микросервисом, здорово конечно.


                1. SpiderEkb
                  09.06.2024 11:11
                  #26918065

                  Вот и мне непонятно. Когда говорят о микросервисах - имеется ввиду концепция отдельных модулей, каждый из которых выполняет атомарную логическую функцию и взаимодействует с остальными, или же о конкретной "контейнерной" реализации когда каждый модуль работает в отдельном контейнере со своей копией БД и вот это все вот...


        1. 3263927
          09.06.2024 11:11
          #26920859

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


          1. rukhi7
            09.06.2024 11:11
            #26922497

            А как это, изменить общую бибиотеку под себя, я этого не понимаю! Как вы совмещаете слова "общая" и "измените для своего сервиса" в одном предложении? Плюсовую библиотеку STD тоже можно для своего сервиса изменить следуя вашей логике?

            Если вам нужна уникальная функциональность не надо ее пытаться воткнуть в общую библиотеку, по моему это очевидно.

            Вроде как получается в ответ на ваше (вполне актуальное кстати) замечание что просто надо уметь различать-разделять общее от локально -уникального, красивые умные слова:

            распределённый

            монолит

            антипаттерн

            микросервис

            здесь в общем то не при чем.


            1. 3263927
              09.06.2024 11:11
              #26923049

              платформенный код например. общая библиотека это не то что вы с нюгета скачали, а то что вы туда положили. и через какое-то время такие общие библиотеки приходится обновлять, хотябы потому что обновляются библиотеки которые ломают тесты (потому что Microsoft например обновила какие-то свои механизмы). и вам придётся согласовывать такие вещи с другими командами, и вот сервисы как раз позволяют этого не делать. ну тоесть у каждого свой код, общие только протоколы и DTO. ну кагбэ я с вами не то чтобы спорю а просто в моей практике сталкивался с такими проблемами как обновление платформенного кода, который на 50 сервисах работает, и это было геморно. но зато не надо было заморачиваться с многими другими вещами типа healthcheck, проверка целостности, удалённое управление сервисами итд... это такая тема которая к искусству ближе чем к науке на моей взгляд


  1. Sly_tom_cat
    09.06.2024 11:11
    #26914837
    +1

    Ох уж эти holly wars.... (доставая попкорн :)


    1. egribanov
      09.06.2024 11:11
      #26916003
      +1

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


      1. posledam
        09.06.2024 11:11
        #26916499
        +3

        Критерий крайне однобокий. Собственно, жду когда наконец придёт осознание, что никаких "микросервисов" не существует. Есть программы и программные комплексы.


      1. SpiderEkb
        09.06.2024 11:11
        #26916727
        +3

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

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

        Упорные попытки противопоставить их какому-то абстрактному "монолиту" не более чем прием "сам придумал, сам опроверг, ай какой я молодец".


    1. Azgiliat
      09.06.2024 11:11
      #26917589

      Холиварить - неотъемлемая часть профессии


  1. posledam
    09.06.2024 11:11
    #26916483

    К тому времени, как многие крупные компании только раскачались, уже созрели и готовы использовать микросервисы, уже "они не нужны". Ну камон! :)


    1. SpiderEkb
      09.06.2024 11:11
      #26916737

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

      А вообще - долго раскачивались. Модель акторов была разработана еще в 1973-м году. А это тоже способ распределить логику по обособленным компонентам.


  1. etaradayko
    09.06.2024 11:11
    #26917245
    +1

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


    1. shashurup
      09.06.2024 11:11
      #26924149
      +1

      А объясните мне, за счет чего в микросервисах можно "грамотно все объекты и методы спроектировать" а в монолите нельзя?
      Тут какая-то логическая ошибка. Если кто-то не может грамотно разделить отвественность по функциональным единицам в тепличных условиях монолита, то в более сложных условиях с сетевым взаимодействием он и подавно не сможет.


  1. kenomimi
    09.06.2024 11:11
    #26918855
    +1

    Какие я вижу плюсы микросервисов:

    • Малый размер и малое время старта. На кластере в 100-300 инстансов можно сделать так, чтобы падение любого инстанса пользователю заметно не было, и не ломало общую картину распределения нагрузки. С монолитом это намного сложнее реализовать.

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

    • Разделение релизов от разных команд, больше обнов прода, быстрее циклы разработки.

    Минусы:

    • Обеспечить связность. Это на самом деле ад уже тогда, когда у тебя 10-20 компонент. Нужен проворный техпис, который будет с немецкой точностью и пунктуальностью все отслеживать. Малейший косяк в документации, и всё, многочасовое веселье гарантировано.

    • Сериализация/десериализация данных. Вроде бы пустяковая мелочь, но нет - в микросервисах она дает приличный такой процент нагрузки, особенно когда ходят километровые портянки данных в одном запросе.


    1. SpiderEkb
      09.06.2024 11:11
      #26918949
      +1

      На кластере в 100-300 инстансов можно сделать так, чтобы падение любого инстанса пользователю заметно не было, и не ломало общую картину распределения нагрузки

      Вот этот момент не совсем понятен.

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

      Старт монолита же займет огромное время, скинет сессии, и так далее

      Ну неужели кто-то еще делает реальные одномодульные монолиты огромного размера? Что-то мне не верится в это... Сколько приходилось сталкиваться, даже в конце 90-х - начале 00-х, уже делали разбивку на модули, каждый из которых реализует что-то свое (и сам такое писал). А когда есть разбивка на модули, то

      Разделение релизов от разных команд, больше обнов прода, быстрее циклы разработки.

      уже совсем не проблема.


      1. kenomimi
        09.06.2024 11:11
        #26919327

        Вот этот момент не совсем понятен.

        Когда падает большая дура-монолитина в популяции 20-50 штук, потому что пользователь залил какую-то разновидность zip-bomb (в том же ворде их можно тысячи сделать, причем часто не специально) - это авария, потому что на остальные пошла бошльшая нагрузка - пока оно поднимется за полчаса... Когда падает файловый загрузчик-наносервис которого 300 штук популяция, он перестартовывает через пару секунд - ни значимого перераспределения нагрузки, ни простоя нет. При этом тяжелые модули сидят в меньшем числе, но спроектированы так, что уронить их извне почти невозможно - все, что идет от пользователя, уже причесано микро- и наносервисами, если что - падают именно они, а не разом все приложение. Та же петрушка с конвертерами, разархиваторами или распознавалками - они выделены в атомарный наносервис, их много, и их падения по ООМ - нормальный рабочий процесс, не ломающий приложение.

        Ну неужели кто-то еще делает реальные одномодульные монолиты огромного размера?

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


    1. bogolt
      09.06.2024 11:11
      #26919685
      +1

      Честно для меня это звучит примерно как: "а давайте все функции вызывать не просто CallFunction(a,b,c) а через сеть. И оно как-то там волшебно будет эффективнее работать."

      Малое время старта? Да вроде монолит тоже быстро (мгновенно ) стартует. Если мы про юникс процесс говорим который читает конфиг и начинает слушать сеть.

      Старт монолита же займет огромное время, скинет сессии, и так далее.

      о чем это вообще? Старт процесса займет сходное время, сессии в смысле TCP подключения? Да тоже не обязательно если монолит за каким-то своим фронтендом ( условно nginx ).

      Разделение релизов от разных команд, больше обнов прода, быстрее циклы разработки.

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


      1. kenomimi
        09.06.2024 11:11
        #26919783

        Я лично видел, как старт крупного страхового монолита занимал 40 минут... Жарник под гиг в вебсфере, оракл базы (архив, быстрая, медленная, ...), сотня интеграций, кеши в памяти под терабайт - вот где боль. И когда это нарезают на модули да микросервисы, начинается кайф - перезапускать сразу все нужно в исключительных случаях, а так взял, перезапустил нужное за минуту и доволен. Да, какие-то сервисы стартуют дольше минуты, но их и трогают реже - кеш словарей и кеши частых запросов те месяцами могут не обновлятся, когда как мидл обновляется ежедневно.

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