Comments 19
Не ответив, как минимум, на эти вопросы вы получите не микросервисы, а распределённый монолит.
С распределенными транзациями все могут дизайнить. Это как многопоточность разруливать через блокировки - код пишется легко, а потом работает с проблемами. Распределенные транзации, как и блокировки ИМХО это путь в один конец - бесконечное нарастание сложности системы, до предела, когда новый функционал не воткнуть т.к. никто не может в своей голове уложить всю систему и всех агентов, которые в ней взаимодействуют.
Под транзацией я понимаю некую работу, которая состоит из нескольких этапов, которая должна быть либо завершена полностью, либо отменена полностью.
2PC и другие варианты распределенных атомарных транзаций это те реализации, про которые я говорил. Да и если быть честным, когда говорят "распределенная транзация" имеют ввиду именно их.
> Под транзацией я понимаю некую работу, которая состоит из нескольких этапов, которая должна быть либо завершена полностью, либо отменена полностью.
> С распределенными транзациями все могут дизайнить.
У Вас либо идеальный мир, либо очень простые проекты. Не видел ещё ни одной распределенной системы, даже самой грамотно спроектированной, где хоть в каком-то виде не надо было бы атомарно выполнять действия в разных микросервисах.
У Вас либо идеальный мир, либо очень простые проекты.
У меня специфичный опыт, это геймдев. И да, простые проекты, ведь спроектировать наиболее простой проект это и есть задача разработчика. Спроектировать сложный проект может любой.
Не видел ещё ни одной распределенной системы, даже самой грамотно спроектированной, где хоть в каком-то виде не надо было бы атомарно выполнять действия в разных микросервисах.
Значит это микросервисы не изолированы друг от друга. При таких зависимостях и связанности возможно, там стоило бахнуть старый добрый сервис.
далеко не всегда нужна строгая транзакционность в системе. Но согласен, об этом как минимум стоит подумать в момент проектирования.
Когда начинаю рассказывать про сложность распределенных транзакций, оркестрацию, хореографию и прочие страшные вещи, случайно (случайно ли?) умалчивают, что в большинстве случаев микросервисы могут вообще не знать о существовании друг друга.
К сожалению, сейчас мало кто задумывается над вопросом, когда и как нужно использовать микросервисы. Мода - страшная штука. Микросервисы и скрам в тренде - значит в 99% случаях все будут работать по скраму и писать микросервисы. Даже если имеются отлаженные бизнес процессы, которые не менялись сто лет и ещё столько же не поменяются. Даже если разработка без понимания бизнес процесса в целом превращается в танцы на граблях, а половина кода и проблем в совершенно искусственно разделённых сервисах относится именно к взаимодействию сервисов - всё равно - монолит это фу-фу, каменный век и сейчас никто так не пишет, а думать дальше текущего или, в крайнем случае следующего одного-двух спринтов - это не по методологии.
Монолит всегда лучше. Для базовой и критической части систем монолит всегда лучше. Это если хватает ресурсов на разработку. И в обслуживании дешевле.
В вас говорит небольшой опыт и излишняя горячесть.
Да, в случае сферического коня в вакууме Вы правы. Но с опытом, приходит уверенность в том, что все мы не идеальны. Как следствие, системы которые устроены таким образом, чтобы нивелировать последствия наших ошибок намного выгоднее. Не смотря на все издержки их существавания. А это, как показывает практика, системы которые исключают монолит.
во всём есть свои плюсы и минусы.. уверенность, что микросервисы нивелируют ошибки зачастую приводят к тому, что никто не тратит время на проектирование. И пишет так, как пишется здесь и сейчас. И через пару лет имеет кучу сервисов с непонятной архитектурой и неизвестными никому толком связями. И полным отсутствием какого либо общего стиля и подхода
Ну как сказать, я работал на проекте, который час билдится и деплоится. Потом из-за того что кто-то зачем-то отключил один из юнит-тестов, на проде вылезает мелкий баг из-за которого ничего не работает. Потом час идет откат на предыдущую версию. Потом багфикс и еще час на раскатку. Ну нет, монолит вообще редко лучше. Если допустим кому-то привычнее, то я соглашусь. Если во всем лучше - ну это слишком категорично. Интересно сколько будет билдится амазон или фейсбук, если будет на монолите. И при этом если там по сотне релизных правок в день. Как-то бессмысленно и беспощадно.
Эта статья про сервисы или микросервисы? Это ведь совсем две разные вещи. Упоминаемая для примера система обработки заказов - никакой не микросервис, а полноценный сервис, который сослепу можно посчитать монолитом. А вот паттерн "Фасад" (он же паттерн "Передаст") - типичный кейс микросервиса. Так про что статья?
Хосспади, когда же, наконец, исчезнет эта вера в священный грааль микросервисов. И hr перестанут с апломбом заявлять, что у них на проекте не абы какой монолит, а сам спринг бут, микросервисы, кубернетес и скрам. Потому если ты не знаешь, как работает аннотация transactional, то это не к нам.
Когдаж уйдет эта вера туда, куда безвозвратно скрылась безудежная увлеченность corba, xml, soap и j2ee.
Ну зачем вам микросервисы - сделайте сначала просто декомпозицию системы на компоненты с правильными зависимостями. Выделите АПИ. Примените уже, наконец, не к столу будет сказано, этот ваш s, o, i и d из solid, про который вы все спрашиваете, на уровне компонентов. И тестируйте свои компоненты отдельно друг от друга. Напишите автотесты, тестируйте и релизьте свой продукт как душе угодно - хоть каждый день, хоть вместе, хоть по отдельности. Хоть на каждый комит.
Latency и throughput в микросервисах не станут лучше. Скорее наоборот. Как минимум лишние сетевые вызовы сделают latency выше.
Да, микросервисы могут улучшить дизайн системы потому что скорее всего вам придется делить код и уменьшать связность системы. Но это можно сделать и без микросервисов.
Ну есть же объективная причина использовать микросервисы - ресурсы же - память, storage. Или, например, время старта приложения (кому-то в облаках это еще интересно?). Или необходимость хранить в памяти большие датасеты, специфичные для разных задач. На худой конец независимая база.
С таким же успехом можно спрашивать достаточно ли у нас грамотные разрабы, чтоб задизайнить сразу все нормально и вовремя отрефачить и раздербанить на отдельные компоненты, когда возникнет необходимость. Или все-таки микросервисы - положим каждую какашку в отдельный горшочек. Если что сподручнее будет выбросить.
Но если, конечно, начальство решает выделять время на рефакторинг системы или нет, и оно знает, что микросервисы - это модно, стильно и молодежно, и это единственный способ начальство убедить - это таки сделать микросервисы, ну тогда да. Штош. Лучше так, чем никак.
Или, например, аргумент 15 летней давности. А почему ibm web sphere - это долго, дорого и больно, почему не просто tomcat. Потому что ibm web sphere стоит икс. А железо под него стоит еще икс. А там еще ibm db2 икс. И на этом фоне сумма икс, которую мы просим за проект выглядит вполне реалистично. А представь, что мы делаем проект на бесплатном томкате, используем бесплатную базу. У заказчика возникает вопрос а почему не бесплатно. Учись, студент.
Но вообще с плохим начальством нет смысла бодаться и пытаться что-то объяснить, показать и доказать. Гораздо проще найти вменяемое. А оно либо само развалится. Либо вы в том месте и не нужны.
У меня все. Минусуйте.
Хосспади, когда же, наконец, исчезнет эта вера в священный грааль микросервисов
ну исчезнет эта - возникнет какая нибудь следующая. Когда то возникла и пропала мода всё что ни попадя выносить в dll (шарп, когда только появлялся как раз и декларировал одним из плюсов- уход от ада длл и локализацию всего, что нужно приложению в отдельных сборках), потом помнится была мода, что давать приложению хоть какой то доступ к данным это не секьюрно и на каждый чих писали хранимки... А по итогу - всё же упирается в деньги. Как только зарплаты специалистов по базам стали сильно большие - так расцвели всякие ORM и хранимки стали древностью, которые правильные программисты не должны использовать ни за что и никогда. И по итогу - я знаю реально хороших, опытных программистов, которые писали приложения, активно работающие с базой и которые были не способны написать на Sql простейший join.
Правильный, хорошо написанный монолит
Требует более высокой квалификации рядовых разработчиков и гораздо больше времени на погружение. И это дороже для бизнеса. В первом приближение. А микросервис в идеальном мире - ну что там, пять-десять классов и всё. и если они будут написаны кривыми руками стажёра - это не смертельно. Ну это конечно в идеальном мире. А в реальности - кривые руки стажёра, по которым никто не бил потихоньку вырастают в кривые руки архитектора этих самых сервисов.. что ничуть не более страшно, чем тот же архитектор, выросший на привычке лепить костыли сбоку монолита. потому что глубже лезть страшно.
Жёстко привязан к языку. а микросервисы декларируют, что писать их можно на чём угодно. Я, честно говоря, слабо представляю себе систему, где каждый сервис написан на своём языке.. но с точки зрения уменьшения рисков - приятно наверное осознавать, что если зарплаты тех же джавистов улетят в космос - можно нанять... ну не знаю - специалистов на VBA.
Сейчас, как мне кажется, зарплаты девопсов сильно рванули вверх. и не хватает специалистов, способных поддерживать растущий как на дрожжах зоопарк микросервисов. Есть подозрение, что скоро в моду войдёт что нибудь, что будет декларироваться как избавление команд от ада микросервисов и какую нибудь очередную унификацию. и это опять будут продвигать, как панацею от всех проблем и опять никто не будет читать книги с описанием технологии дальше предисловия. А ведь и сейчас в большинстве книг по микросервисам описано, когда имеет смысл их применять, а когда проще будет делать монолит. Обычно уже в первой главе.
А скрам.. ну тоже мода. и тоже вероятно из финансовых соображений. Нормальных аналитиков днём с огнём не найти. Программистов на выяснение задач и общение с заказчиком отправлять не модно. А поставить маааленькую задачку то, что в большинстве команд зовётся аналитиком ещё в состояние. А вот разобраться в бизнесе и написать нормальное большое ТЗ - уже далеко не всегда. и тут опять микросервисы -наше всё. если очередная маленькая задачка будет противоречить написанному за несколько предыдущих лет - маленький сервис переписать всё так легче. ну, если он действительно микро. а не разросся так, что иной монолит позавидует
Когда действительно пора делать микросервисы