Comments 171
Одно время , я часто слышал от разрабов - мы будем переходить на микросервисную архитектуру .
Оказалось , они под микросервисной архитектуры понимают кучу бд в одном экземпляре СУБД к которым коннектится backend.
Зато теперь могут всем говорить - наша информационная система построена на микросервисной архитектуре .
Микросервис не обязательно должен иметь свой экземпляр СУБД.
Основная мотивация к делению на микросервисы - независимая разработка отдельных фитч продукта. Это значит что идеальный микросервис содержит базу, логику и даже ui. Когда заказчик захочет улучшить фитчу, команда это сделает самостоятельно, ни на кого не блочась. В этом главный профит. Если начать резать на сервисы по вдоль слоев архитектуры а не поперек, этого преимущества не будет. Чтобы что-то добавить придется вовлекать много команд. Поэтому если у микросервисы нет своей базы, основное преимущество архитектуры уже отпадает. То что остаётся может не стоить свеч.
светч
"даже ui", полный бред, компоненты системы могут построены на микро, почитай Microsoft eShop on containers.
Я вообще не вижу связи делать отдельный фронт на каждый микросервис, то что будет один фронт никак не ограничит разработку бек команды.
Хотя многие шлюз воспринимают как нарушение, что уж говорить.
Отдельные СУБД под микро сразу может посадить на бутылку распределенных транзакции, но в целом идея звучит хорошо, когда одной СУБД будет не хватать
И возникает закономерный вопрос как этим всем управлять
Только архитектурный стиль или независимость БД никак не связаны с низкой связностью компонент.
Связность зависит от анализа, а не от монолита или SOA.
Ну, если бд реплицирована, то почему нет
Собственно, в ответе на вопрос "почему shared database - антипаттерн" нет явного декларирования того, что одна база с кучей схем - однозначно плохо.
В одном сервисе накосячили с запросом, ложатся все
Приведёте пример такого запроса, при котором лягут остальные соединения?
Делаем например запрос который приводит к seqscan на большой таблице, бд ложится, остальные сервисы не могут использовать бд. Т.е. один сервис ошибся и убил бд - ложатся все сервисы.
Ложится не вся бд, а лишь одна реплика, с которой работает этот сервис.
Да, но это мастер. Уже мы вынуждены делать фейловер. Причём после фейловера запросы смерти могут продолжать прилетать и класть теперь уже нового мастера. Но если имелось в виду что только 1 шард ложится то да, другие живут, если в них не прилетает такой же плохой запрос но с другими данными.
Откройте для себя max_worker_processes.
Открыли, но запрос смерти мог прилететь более чем в одном экземпляре. В сумме получили больше чем есть ресурсов, бд ложится.
Да и в целом такой параметр не так то просто подобрать чтобы работало всегда
Есть куча возможностей ограничить ресурсы на одного клиента.
Это исключительно особенности настройки БД, не какой-то рокет-сайнс.
Ну и, заметим, шансов плохим запросом убить все сервисы, которые в нем участвуют (при каком-нибудь джойне, реализованном ручками на API GW) не меньше.
Почитайте рядом, уже обсуждали. Несколько клиентов могут сделать плохой запрос. Например забыли добавить индекс для новой функциональности
И? У тебя 1000 соединений на PG, от одного сервиса в пуле 10, эти 10 стали тормозить - и в чем проблема для остальных?
Ну, в теории да, кэш страниц вымывается - но и только.
И, главное, как от этого спасет разделение на несколько БД? Кроме того, что подобные проблемы будут происходить чаще?
Причём тут "соединения стали тормозить"? Плохой запрос на то плохой что он не просто тормозит но и утилизирует кучу ресурсов, например оперативную память и диск. При этом в какой то момент могут быть утилизированы все доступные серверу бд ресурсы. В этом случае это не повлияет на остальных клиентов бд?
Даже в PG есть инструменты (хотя и мало) ограничения ресурсов на сеанс. С памятью там сложнее, с IO возможностей больше. В более взрослых БД таких инструментов гораздо больше.
И нежелание настраивать СУБД или осознанно выбирать конкретную СУБД - не повод выделять по серверу на каждый сервис.
Я уже отвечал на вопрос про ограничения ресурсов на сеанс. Не так просто подобрать нужные значения чтобы они работали во всех случаях, приложение ещё и развивается/меняется. И даже если мы это сделали то "сеансов" с плохим запросом может оказаться много так что суммарно они скушают все доступные ресурсы.
Так если не удается спланировать соединения - точно так же не удастся спланировать ограничения на отдельные СУБД и точно так же оно начнет падать из-за нехватки ресурсов. А число сеансов на сервис как раз легко контролируется.
В чем выигрыш-то от "одна база на сервис"?
А никто и не говорит что оно внезапно перестанет падать. Просто теперь при проблеме в одном сервисе лежит только этот сервис а не все сервисы системы вместе. В этом и есть выгода
Хм. Вот у тебя 8 ядер, 128GB RAM и 10 сервисов (20 экземпляров). Этого достаточно для штатной нагрузки при условии "все сервисы в одной БД".
Как ты поделишь ресуры на 10 БД и при этом увеличишь надежность? Даже если все сервисы у тебя автономны (в реальности так не бывает).
С помощью технологий виртуализации/контейнеризации наверное
Ну, это один из вариантов, но я про другое.
На основании чего ты выделишь конкретное число ядер и памяти на каждый сервис? Как у тебя получится "подобрать нужные значения чтобы они работали во всех случаях, приложение ещё и развивается/меняется"?
Надо делать оценку при проектировании, провести нагрузочное тестирование, взять с запасом. Ну и мониторить как оно в проде, когда надо добавить ресурсов. Тут главное что у нас в итоге будет изоляция бдшек сервисов друг от друга. Какие-то сервисы могут быть не критичными. Если такой сервис сильно нагрузит бд то и хрен с ним, зато не случилось такое что упало вообще всё.
Чем это отличается от планирования ограничений на отдельные сессии или клиентов средствами БД?
Точно так же сервис не сможет запросом съесть всю память, не сможет занять все ядра и так далее, но только оверхеда будет в разы меньше (не нужна куча виртуалок, гораздо меньше расходов на работу самого сервера управления БД), перекидывать ресурсы будет гораздо проще (поменял ограничения и все), поддержка (с учетом репликации, контроля прав доступа и так далее) будет вообще кратно дешевле.
Т.е. используя одну СУБД - мы решаем все те же задачи, но при этом в разы дешевле. Зачем тогда создавать по БД на сервис?
Я не уверен что мы можем настолько гранулярно ограничивать во всех бд, например в постгресе. При этом могут существовать какие-нибудь демоны которые делают жирные запросы и у них лимиты завышены. В целом если на уровне одного инстанс бд мы можем хорошо ограничить то это не будет сильно отличаться, сэкономим ресурсы. Способ через отдельные инстансы будет работать для любых бд, даже если они сами не умеют управлять потреблением ресурсов
В PG - не все, но это особенности реализации решения на PG и никак не связано с необходимостью всегда делать "БД на сервис". Скорее уж "если для нас существенна изоляция исполнений по сервисам и мы взяли PG - то нужно делать много разных баз".
Кстати, даже в этом случае скорее имеет смысл выделить два СУБД - для "основного функционала" и для "необязательного функционала", создавать по БД на сервис все равно не нужно.
Хм, почему БД ложиться? Одно соединение тормозит - и все.
Потому что упали по оом например
Хмм, и какая БД ложиться по OOM от одного запроса?
Никто не утверждал что от одного запроса.
Да я вообще не видел БД, которая складывается от OOM. Это как-то очень криво надо ее настраивать (да и то не факт, что получится).
Ну я сумел Постгрес целиком свалить запросом (в процедуре), который вытащил в джойне по FDW овердофига. Естественно, сразу на ПРОМ, на НТ и раньше такое не стреляло. Естественно, запрос и так работал долго, но требовался примерно раз в полгода, а после шардирования каак... Больно.
А почему shared database - антипаттерн? Почему интеграция через БД - плохо, а интеграция через kafka - нет (хотя это та же самая интеграция через БД)?
Вообще, любые паттерны или антипаттерны не имеют смысла без описания граничных условий и ограничений.
Не перестал
Пожалуй, соглашусь со всем, кроме последнего пункта. Почему микросервисы обязательно должны тянуть за собой организационные изменения?
Почему за микросервисы должны отвечать автономные команды? Это выглядит как реверанс к п.1 и тому, что понимается под микросервисом. Это может быть справедливо для вашей организации, если вы условитесь о таком определении. Но это точно не аксиома менеджмента и не жёсткое техническое требование.
В остальном, как уже сказал, согласен. Микросервисы - это не панацея и в них тоже нужно уметь.
Почему за микросервисы должны отвечать автономные команды? Это выглядит как реверанс к п.1 и тому, что понимается под микросервисом. Это может быть справедливо для вашей организации, если вы условитесь о таком определении. Но это точно не аксиома менеджмента и не жёсткое техническое требование.
Полностью согласен. Часто жестко декларируется требование "один микросервис - одна команда".
Потому что если у вас одна команда то зачем вам много сервисов? Это же накладно за ними следить, разрабатывать, деплоить. Их можно объединить в монолит и горя не знать.
А потом одним деплоем сломать сразу все.
Одним деплоем можно и микросервисную систему поломать. Если закосячили критически важный сервис. Авторизацию например.
Например у тебя разные НФТ для разных частей поддомена (за который отвечает команда). Разные требования по безопасности, производительности, жизненному циклу и так далее...
Почему за микросервисы должны отвечать автономные команды?
Микросервис это передача команды в анальное рабство отделу бизнеса, где никто не будет мешать ставить требования к микросервису, так как он изолирован. Требования не потребуется долго согласовывать если они противоречат другим частям монолита. Как следствие, бизнес отделы тоже становятся менее связанными и даже могут получить звание бизнес доменов или вообще филиалов.
Но это только теория. В реальности всё не так как на самом деле.
И да, это упрощение потогонной работы разработчика если отдел DevOps сзади стоит и отгребает лопатой всю сложность
Работал в .net монолите и в (прости, Господи, больше так не буду!) PHP с докером и всеми приблудами. Так вот в .net это только разработчики, а во втором случае DevOps больше чем разработчиков
Почему микросервисы обязательно должны тянуть за собой организационные изменения?
Потому что Conway's law. Безос не зря автономизировал команды, запрещая горизонтальные коммуникации между ними. Service discovery и API как орг.стуктура.
В свое время слышал шикарное определение Микросервисов - это решение в котором нет Oracle DB!
дота 2 это микросервис?
Контрольная по алгебре это микросервис
Она решает одну задачу, обособлена от других частей обучения, требует одного учителя для обработки. Ах да и не содержит oracle db. Получается микросервис 😄
обособлена от других частей обучения
Каким образом?
Вы можете провести контрольную по алгебре в любой момент, в любом классе с любым учителем, даже если класс никогда алгебру не изучал. Получается контрольная - как список вопросов и метод их оценки - может быть как частью учебной программы, так и существовать отдельно от неё (как метод оценки знаний на собеседовании например). А это как раз и значит обособлена. В контексте статьи - микросервис - это вещь в себе, не зависящая от конкретных реализаций внешних зависимостей, так и контрольная тоже.
Выглядит как "я перестал пользоваться молотком, после того как ударил себе по пальцу". Зачем ограничивать себя в доступном инструментарии из "идеологических сображений"?
Если микросервисы не общаются через шину сообщений, то это не микроснрвисная архитектура, а просто монолит, разбитый на отдельные процессы. Теперь подумайте, нужен ли вам этот гемор с сообщениями, откатами после сбоя, если нет - вам микросервисв не нужны
Ну а если нет ни шины, ни сообщений, ни откатов, а есть лишь распределённая бд и куча микросервисов, с ней работающая?
Раньше это называлось "зоопарком технологий" :) Микросервис - это не потому что он микро, т.е. обладает ограниченной функциональностью, а потому что он как Класс в ООП - отвечает за какую ту конкретную функциональность, в рамках композиции классов. А вот композицию классов как раз такие нужно проектировать. В ООП объекты как между собой общаются? Правильно - сообщениями (ну по канонам). Такие дела. Т.е. если у вас есть какой-то источник данных и к нему постепенно подсасываются какие то клиенты - это не архитектура, а просто - распределенные вычисления. Ну т.е. я к тому, что архитектуру придумывают в начале и ей следуют, как и в разработке приложения.
Где же тут зоопарк? Бд одна, микросервисы на писаны на одной технологии и шарят большую часть кода, читают из одного места бд, пишут в другое. Или архитектура - это лишь когда обмазываешься костылями в виде очередей сообщений?
"Или архитектура - это лишь когда обмазываешься костылями в виде очередей сообщений" - вот вы правильно сказали: "костылями в виде очередей сообщений" - вместо того, чтобы взять проверенную временем транзакционную СУБД, которая тебе дает готовый и надежный механизм отката транзакций, который писали умные дядьки десятками лет, юное дарование решает пилить очередь сообщений с сагами, со всеми вытекающими. Хотя нагрузки на проект нет и не предвидится.
Т.е. вместо того, чтобы спокойно подключиться монолитом к БД, запустить транзакцию, поделать какие-то дела, закоммитить или откатить по результатам, тратится время на разработку этих самых откатов при общении через сообщении. Но вот вам и пример, что в вашем распределенном монолите можно просто откатить транзакцию, а в микросервисной взаимодействия и откаты нужно продумывать. Это всё сложнее монолита, но необходимо, если нагрузка действительно растет и приходиться всё раскидывать по разным серверам.
ТПервопричина микросервисов - это распределение нагрузки, а не из-за того, что кто-то там не умеет в язык А и хочет кодить на языке Б, ну или какая то часть приложения требует более частого обновления. Т.е. в вашем случае - это реально больше похоже на распределенный монолит.
Распределение нагрузки это такое минорное свойство, с тридцатым архитектурным приоритетом, если только вы не гиперскейлер.
Какой же это монолит, если каждый микросервис выполняет свою задачу, независимо от остальных?
Вот именно что микросервисы - это в совокупности, а не по отдельности. Типа как классы в приложении взаимодействуют друг с другом. А так у вас просто способ передачи параметров между функциями изменился и всё (просто транспорт между параметрами и результатами выбран http) , т.е. организация когда как в монолите.
Много вы встречали монолитов, где классы ничего не знают друг о друге и уж тем более не делают никаких вызовов методов с передачей параметров?
Возьмите любое приложение на джанге. Sentry например. Там много независимых приложений (в терминах джанги), которые тем неменее четенько работают в рамках одной транзакции.
Где вы в моих словах увидели распределённые транзакции?
Это я говорю, что основная трабла в мса это транзакции, вернее компенсация ошибочных ситуаций и когда говорят про мса - это первая причина по которой от мса пр возможностм лучше отказаться. То что все умеют дергать rpc - ну молодцы. Вы же субд тоже дергаете через сервис, но почему оо её не называете микросервисрм
А rpc вы где в моих словах увидели? Каждый микросервис выступает одноранговым узлом распределённой сети и работает со своей локальной частью базы данных. Все транзакции тоже, разумеется, локальны.
Под rpc я подразумеваю вызоа апи сервиса в том или ином виде.
Смотрите, микросервисы - это про асинхронное взаимодействие, чтобы сгладить пики нагрузки через очередь сообщкний (не важно, брокер это или внутрення асинхронная обработка запроса), их для этого такими и делают, со всеми вытекающими сагами. У вас же модель синхронная и распределенная.
обмазываешься костылями в виде очередей сообщений
В мемориз!
Частично
Микросервисы это ещё один уровень low coupling high cohesion, что сплачивает функционал в предметной области, но уменьшает зависимость доменов друг от друга.
Кстати, зависимость доменов (ограниченных контекстов?) бывает разной. Например, и магазин где есть заказ, склад, оплата. При оплате есть 2 транзакционные зависимости:
Заказ и склад - со склада снимаем, заказ переводим в состояние принят
Заказ и оплата - деньги снимаем и одновременно переводим заказ в состояние оплачен
Две транзакционные зависимости, но они разные по природе бизнеса. Финансовая транзакция не только имеет более сильные требования к согласованности (обратные действия не желательны), но и сильные требования к разделению инфраструктуры по вопросам безопасности действий, периметра и данных. Тут коммит только после полного подтверждения в обоих системах. И систему оплаты желательно выделить отдельно по причинам безопасности данных, аудита меньшего объема кода и минимизации периметра соприкосновения критичной системы
А складу достаточно и Саги, если что отменим. Да и разделение БД заказа и склада может подождать пока процессы не определились, границы не определились, ИТ команды не выросли и их взаимодействие не стало сложным.
Там в итоге одно за одно цепляется. В итоге и в складе сага нежелательна, а какая-то двухфазная фиксация - потому что вокруг склада какие-то процессы тоже есть. Это и проверка доступности и планирование закупок исходя из этого, и бюджетирование.
Везде по итогу все по-разному
Вы путаете две разные вещи, это распределенные системы и микросервисы. Камнем преткновения именно микросервисов является степень дробления до уровня микро-. Реально на практике нет такой необходимости. Вот смотрите, пример отличного монолита это Linux система. Все мы работаем на Linux, у меня смартфон в эксплуатации более 4 лет, за это время система падали всего 3-4 раза. На мой взгляд, это отличный показатель. Почему то, никто не пишет, что раз Linux монолит, то это дерьмо, и что бы он стал конфеткой, его необходимо распилить на микросервисы.
В ИТ микросервисы стали сродни религией. Если у тебя нет микросервисов, то значит ты какой-то не такой.
Микросервисы приводят к существенному усложнению проекта, кодовая база вырастает в разы, сборка всего проекта просто превращается в ад (не забываем, что программисты практически не пишут документацию), добавим к этому накладные расходы пересылки данных между сервисами. В итоге, на практике вместо пользы получим только проблемы.
А решать проблему зависимостей путем микросервисов, это как микроскопом забивать гвозди, потому что микросервисы это не про зависимости. Зависимости решаются путем ввода в проект системы абстракций, но не как микросервисов. Вы можете, например спокойной в монолите использовать интерфейс для логгера, а не методы конкретного логера. Например, в C# используем ILogger, вместо конкретного класса реализации:
using Microsoft.Extensions.Logging;
using ILoggerFactory factory = LoggerFactory.Create(builder => builder.AddConsole());
ILogger logger = factory.CreateLogger("Program");
logger.LogInformation("Hello World! Logging is {Description}.", "fun");Если вы в коде напрямую вызываете MS SQL Server, то никакие микросервисы вам не помогут снизить зависимости. Т.е. все упирается в то, как это было реализовано на уровне программного кода.
Почему то, никто не пишет, что раз Linux монолит, то это дерьмо, и что бы он стал конфеткой, его необходимо распилить на микросервисы
Вся экосистема вокруг ядра и философия построения пользовательского пространства в Unix/Linux как раз очень сильно напоминают микросервисный подход – маленькие, независимые утилиты, взаимодействующие через стандартные интерфейсы. Именно поэтому для пользователя система ощущается как гибкий и мощный набор инструментов, а не неповоротливый монолит.
А ядро монолитное для скорости, но там совсем другие принципы. Ядро windows гибридное, например.
Если у тебя нет микросервисов, то значит ты какой-то не такой.
Это отличный способ вывода денег из компании. Как раньше был SAP
Unix/Linux как раз очень сильно напоминают микросервисный подход – маленькие, независимые утилиты, взаимодействующие через стандартные интерфейсы
Звучит как натягивание совы на глобус. Linux создавался во времена, когда про микросервисы никто и не говорил. Опять начинаются личные фантазии, Linux монолит и точка, никаких микросервисов в нем нет, с точки зрения архитектуры. Да, Linux в отличие от Windows, модульный и слабосвязанный, но не микросервисный.
Выходит новая версия ядра Linux и половина софта у вас перестает работать. Вы технически не можете запустить в одной системе новое ядро Linux, в совокупности с некоторыми старыми Linux ядрами предыдущих версий для совместимости. А в сервис-ориентированной модели это должно работать.
В сервисной модели ОС существует микроядро, а все остальное это сервисы. Но ядро Linux не тянет на звание микроядра.
Читаем хотя бы вики:
Микроядро (англ. microkernel) или μ-ядро (англ. μ‑kernel) — ядро операционной системы, реализующее минимальный набор функций.
Далее, читаем:
Для того, чтобы микроядерная ОС по скорости не уступала ОС, построенной на базе монолитного ядра, требуется очень аккуратно проектировать разбиение системы на компоненты и стараться минимизировать взаимодействие между ними. Таким образом, основная сложность при создании микроядерных ОС — необходимость очень аккуратного проектирования.
Любая система построенная на парадигме микросервисов, будет существенно проигрывать в скорости.
маленькие, независимые утилиты,
Еще как зависимы, стоит одной утилите поменять формат вывода, и вся цепочка обработки данных накрывается медным тазом. Поэтому многие перешли на дублирование вывода в формате json, это хоть как-то позволяет снизить проблему.
Это оффтопик
Не натягивайте сову на глобус
Оффтопик это у вас. Как раз таки это имеет непосредственное отношение. Сервис ориентированные ОС с микроядром существуют, и используются только в узко специализированных нишах. Такие системы по объему кода сравнительно небольшие и список выполняемых задач тоже небольшой. Но если, вы строите систему общего назначения, аля что-то на базе Linux, то это будет либо монолит, либо распределенная система, и никаких модулей типа микросервисов в ней не будет.
В моем понимание, микросервисы для интернет сервисов появились благодаря новомодным молодым программистам, которые не читали книг 90-х годов. А потом когда ударились головой об стену, внезапно оказалось, что это не так хорошо работает, как они изначально думали.
Была интересная история появление сервиса redtube. Они вначале решили реализовать классическую трехуровневую архитектуру для подобных систем. Но внезапно оказалось, что скорость работы такой системы оставляет желать лучшего.
В результате, весь этот религиозный бред, в виде многоуровневой архитектуры и микросервисов, для всего и вся, они выбросили на помойку из-за низкой скорости.
И реализовали трехкомпонентную практически горизонтальную систему, состоящую из БД, шины данных, одного монолита, который содержит все остальное, и реверс-прокси балансировщик.
Нагрузка возрастает, они линейно масштабируют свой монолит, добавляя экземпляры в локации, где возрастает количество запросов. Скорость в итоге увеличилась в разы.
Любые системы типа микросервисов, очень сильно просаживаются по скорости, и нету тут никакой совы.
Поэтому, если вы дробите систему, то вам следует вначале задуматься, что для вашего проекта важнее, скорость или гибкость. И можете ли вы, пожертвовать скоростью ради гибкости.
Ну "в отличии от винды" вы совершенно зря добавили. В винде драйверы не являются частью ядра и для их компиляции не нужны хедеры от ядра.
Ага конечно, вы как собираетесь компилировать драйвера для Windows без WDK. В Linux это хедеры, в Windows это WDK, суть одна и та же.
Суть совершенно разная. как по вашему в винде работают драйвера, скомпиленные пару десятилетий назад в совершенно новых версиях ОС? Или наоборот, новые драйвера в старых ОС (частенько)
Вы заблуждаетесь, и не совсем понимаете, как это работает. Мое утверждение абсолютно верно. Ваш пример совместимости, с снизу вверх объясняется тем, что новые версии Windows сохраняют API вызовы старых версий Windows. Именно поэтому в папке Windows, вы можете найти всякие иконки вплоть до Windows 95. Из-за этого Windows становится очень большой и тормозной, и не работает на микроконтроллерах.
ККонцепция Linux совершенно другая. Вышла новая мажорная версия ядра, дуб да мочало, начинай сначала. Драйвера, как и некоторые программы, перестают работать. Старый код жестко выпиливается, это классика.
Например, на плате Orange Pi 4 LTS прекрасно работает Wi-Fi чип в версии ядра Linux 5.10. Но в версии Linux 6.x не работает связь на частоте 5 ГГЦ, хотя точки доступа видит, пытается авторизоваться. А все почему? Потому что в новой версии ядра Linux, не переписаны некоторые функции под новые системные вызовы. Драйвер из версии Linux 5.10, в версии Linux 6.x технически не работает, потому что в Linux 6.x просто нет таких функций. Драйвер так же не перекомпилируешь, потому что в хедерах нет таких функций.
До абсолюта вашим утверждениям еще дальше чем моим
API вызовы сохраняются, только это API не ядра, а прослоек т.н "драйверной модели", которых много разных. В этом и была суть моего возражения о том, что драйвера в винде к ядру не прибиты гвоздями
В Linux это хедеры, в Windows это WDK, суть одна и та же.
Согласен, не одно и тоже, каюсь, невнимательность к деталям иногда меня подводит. Для компиляции драйверов Windows, сами исходники ядра Windows не требуются.
Когда я начал изучать Linux, некоторое время не мог понять, почему исходники системы с Linux ядром для платы называют SDK. По аналогии с Windows, я ожидал что-то отдельное как WDK, но оказалось что тут совсем другой подход.
В части новой модели работы аудио устройств после Windows 7, не могу добиться качественного звука. MS сломали нормальную дискретизацию звука, в результате на качественных наушниках с LDAC получается какофония. Слушаешь на Linux, Ubuntu или Android, все отлично, каждую нотку по отдельности слышно. Раньше смеялся над выражением "сочный звук Alsa", а теперь мне не смешно, он действительно сочный. Запланировал частичный переход на Ubuntu для наслаждения сочным звуком).
Еще в Windows есть GUI, который такими гвоздями прибит, что проще написать New Windows 1.0, чем выбросить графику из ядра Windows.
Работал с Windows Embedded 7. Особенная проблема заключалась в подавление всплывающих сообщений. Если использовались системные функции, а они именно и использовались, то родителем окна был интерфейс ОС. И вот поверх приложения рисуется панель задач с меню Пуск. И проблема была не только в банальных MessageBox, а при разрыве соединения по модему всплывал Dialer, и вот здравствуй меню Пуск.
тут сплошная мешанина, заблуждения и проблемы терминологии. Вот совсем не хочется офтопить (особенно про качество звука) и защищать винду, но
в винде гуя два - GDI-based и DirectX-based. И они оба не являются частью ядра, иначе говоря, и тут гвозди не предусмотрены. Уж не знаю чем закончилось это в Windows 11 или кто там сейчас, но серьезный редизайн базовых библиотек начался еще в висте.
Интерфейс ОС - это на самом деле т.н shell, в дефолте explorer.exe, оставлять который вас никто не заставлял. Что касается родительских отношений и прочих абстракций в окошках, то посмотрите на понятие\объект "WindowStation"
Со звуком действительно в Windows плохо. В Windows при проигрывание симфонических записей на Bluetooth наушниках возникает проблема с дискретностью звучания отдельных инструментов. Короче говоря, слышна какофония, невозможно выделить отдельные инструменты. Тестировал разные наушники, адаптеры, ПК, результат неизменен. Но такой проблемы нет на Android и Linux. Даже слушая с одноплатного компьютера на Ubuntu все звучит классно. Это я не говорю про отсутствие поддержки LDAC кодирования в Windows 10/11.
Почему именно так получается в Windows, не могу сказать. Тема лежит у меня в закладках на исследование, надеюсь, найду время разобраться.
Подчеркну два важных момента:
1) Разница слышна практически только на концертных записях. Попсятина, рок, металл, разница не ощутима.
2) Нужно обладать хорошим слухом, и уметь слышать мельчайшие тональности. По статистике, львиная доля людей, думаю >80%, не способна это уловить.
Почему то, никто не пишет, что раз Linux монолит, то это дерьмо, и что бы он стал конфеткой, его необходимо распилить на микросервисы.
GNU Hurd, не слышали о таком?
Вы можете на уровне субд запретить читать таблицы финансовой системы, зачем её отдельно выносить?
Я понимаю, что вынос фин данных "на всякий случай" полежен, но это не инженеоное решение, а административное, т.е. не влияющее на архитектуру приложения
Сообщения можно передавать кучей разных способов. Обращение к view в БД - тоже отправка сообщения на чтение, никакой разницы. И соответствует ООП )
Если микросервисы не общаются через шину сообщений
то это SOA либо SBA - там разрешено пользоваться одной БД, хотя и шина тоже может быть
CAP работает для всех распределенных систем, не только микросервисных. Поэтому первое правило построения систем - как можно дольше уклоняться от их распределенности не взирая на свидетелей MSA.
Ни в одном определении микросервисов нет ничего про "шину сообщений".
Да и какая разница, шина сообщений или сервис-меш? Связность от этого не меняется (ну, если только не pub-sub, при этом связность вырастает).
Автору следует перестать публиковать статьи, слишком поверхностные знания
мне публикация оч. понравилась, вокруг микросервисов действит. довольно много шума, но ломать копья За или Против, действит. по-пусту -- 99% моей, например, каждодневной работы -- реализация тех или иных BL-запросов/функций, чем лучше получится сделать это с первого подхода, тем меньше шансов на доп. последующие переделки/шлифовки.
:-) С автором статьи во многом согласен...
Особенно в части - если производительности одной БД для вашего прикладного ПО с учетом масштабирования и развития достаточно - микросервисы вам точно не нужны....
Но если у вас нет общего понимания (на ближайшие 10 лет) как будет масштабироваться и развиваться ваш программный продукт - проблема не в архитектуре, а в архитекторе...
Микросервисы снижают когнитивную нагрузку. (Для кого? И действительно ли это так, или они просто переносят сложность в другое место?)
Ну конкретно команде, которая этот микросервис делает - не снижает нагрузку под него. Для остальных это чёрный ящик с входными-выходными данными, за который они не отвечают и не разбираются(бывают исключения конечно), для них нагрузка супер сильно снижена по сравнению с монолитом, где можно копать и копать самому(или пошлют это делать вместо помощи)
Так и в монолите так же.
Ну конкретно команде, которая этот микросервис делает - не снижает нагрузку под него
Снижает, как раз за счёт того, что для остальных это "чёрный ящик". Нет рисков, что некий Вася в своей части монолита внезапно переиспользовал кусок функционала, потому что счёл его подходящим, и теперь при доработках надо учитывать и код Васи.
Ещё как не снижает, когда надо чуть сложнее, чем описано в доке (потому что доки обычно нет, есть пара слов и пример использования), и даже в сорцы не посмотреть, потому что они из другого подразделения, и сорцами им делиться запрещено. Начинается переписка, созвоны, и крайне повезёт, если с той стороны адекватные люди, которые быстро отвечают. А вот мы передаём некоторые данные в другой сервис, обязаны, а посредником между нами - третий. С этими вторыми мы чуть в кабак не ходим, жаль в разных городах живём, отличные отношения, вопросы решаются за 5 минут. А третьи просто не отвечают. И мы вынуждены УГАДЫВАТЬ, что там у них и как работает. Какие лимиты на нагрузку, какие предельные размеры сообщений, можно или нет сжимать данные, и так далее. Ну нет этого в описании АПИ. И в примере нет. Месячную работу растянули на полгода.
Я бы придерживаюсь следующего различия - микросервисов это сервис без состояния, способный масштабироваться горизонтально через pod-ы.
В монолите такого не добиться.
Далее есть путаница сервисная архитектура и микросервисная: Сервисная архитектура объединяет функциональность по доменной модели, т.е. сервис заказов, сервис доставки и т.д. Микросервисная - это буквально несколько функций и да до 1000 строчек кода )
Почему же нет определения?
Микросервисная архитектура — вариант сервис-ориентированной (то есть модульной и распределенной) архитектуры программного обеспечения, направленный на взаимодействие (желательно) небольших, слабо связанных и легко изменяемых модулей — микросервисов.
Как следствие слабой связанности разные микросервисы однозначно не могут иметь одну и ту же БД, что является отличительным признаком от иных распределенных архитектур.
Требование к небольшому размеру опционально.
Есть ещё отличительные признаки, но этого достаточно
И в той же литературе четко описано какое именно качество достигается микросервисной архитектурой. Всего лишь deployability.
Как следствие слабой связанности разные микросервисы однозначно не могут иметь одну и ту же БД, что является отличительным признаком от иных распределенных архитектур.
Это булшит. Микросервисы прекрасно могут читать из одной и той же БД. Писать в каждую «таблицу» может только один из, это да.
Если сущность занимает двадцать байт — лучше её передать из одного сервиса в другой напрямую. Если она занимает двадцать мегабайт — лучше передать ссылку, никто не помрёт. Условную таблицу «разрешенных операционных валют» и прочие константные словари — необходимо читать из одного места, иначе у вас завтра всё рассинхронизируется.
Прочитайте пожалуйста. Будет понятно, что сервисы с единой БД сильно меняют свои архитектурные свойства и для них есть специальное название, даже 3. И микросервисамт называть их не корректно не смотря на размеры
Я не читаю технические книжки, и никогда не читал, пардон.
То, что данныеавторы считают так-то и сяк-то, не является истиной в последней инстанции. В зависимости от конфигурации прекрасно одни пишут, другие читают и синхронизируются. В нашей команде иметь несколько БД по числу (микро)сервисов - удесятерить сопровождение, нам просто никто не даст ресурсов. И ничего, на картинках архитекторов всё прекрасно обозначается как микросервисы. И все довольны. Только нашему архитектору по рукам даём, когда он ещё попилить рвётся.
Это всего лишь одна из множества книг. Как и все прочие - как с верными, так и с неверными утверждениями.
И чье это определение? И кто его придерживается?
И связность никак не зависит от "одна БД" или "несколько БД".
Очень пространно ниочем.
TL&DR:
Люди в количестве более трёх никогда не смогут ни о чем договориться
Они будут возвращаться к обсуждению каждый раз когда им захочется просрать ещё немного времени, оплаченного работодателем
Работает - не трогай, не работает - трогай, но сначала подумай
кстати, вот мой телеграм канал
Я наконец-то поклялся больше не общаться с архитекторами о микросервисах.
Абстрактные обсуждения вредны. Будет проблема с конкретным доменом буду решать отрезать его от монолита или нет. Способ это дорогой и вначале я проверю все остальные альтернативы.
А хотите потренироваться - идите пилите свой учебный или пет проект, а не тренируйтесь на бизнесе.
Автор молодец: надо же собрать столько заблуждений в одном месте! Что творится в неокрепших головах?
это не конечный результат сам по себе, а побочный продукт достижения какой-то другой цели.
Это шаблон реализации цели, но не цель
Мне больше всего нравится это определение:
«Каждый сервис автономен, самостоятелен и выполняет уникальный процесс».
По сути так как сервис автономен, команда может выбирать стек разработки, систему хранения данных, способ аутентификации, способ развертывания, а так же выбрать процесс разработки удобный ей. И да, сервис должен решать какую-то бизнес-задачу, в зависимости от того сколько бизнес-задач решает сервис стоновится понятно насколько он "микро"
команда может выбирать стек разработки, систему хранения данных, способ аутентификации, способ развертывания, а так же выбрать процесс разработки удобный ей.
Врагу не пожелаю работать в компании с таким подходом.
Так как сервисы все-таки взаимодействуют, они уже не являются совсем независимыми. И выбор разных стеков или БД - становится или очень дорогим или вообще невозможным.
Странно это всё.
Возьмём для примера Хабр. Вот у нес есть лента публикаций. Можно ли её реализовать отдельно ото всего? А отдельные пункты меню? А личный кабинет? А рекламный блок справа?
Всё, что можно выделить в отдельный поток реализации, можно назвать микросервисом.
У микросервисов две цели. Из личного опыта.
Масштабируемость. Если я хочу масштабировать какую то часть, то её имеет смысл выделить как микросервис.
Разделение разработки. Если монолит большой, то всем нужно будет синхронизировать свои изменения, мерджить брэнчи и вот это вот все. Либо у каждой отдельной команды разрабов свой микросервис или сервис, и они сами решают когда его релмзмть и как. Если есть слабая связанность, то сервис выполняет контракты и все работает даже если версии других микросервисов изизменились.
Остальное Лирика.
Как архитектор поддерживаю
У микросервисов две цели
Вспомнилась цитата как раз в период роста популярности к этому архитектурному решению:
Микросервисная архитектура не была ответом на задачу быстрейшего CI/CD. Она решает ровно одну проблему — нехватку team lead'ов на всех. team lead тщательно думает про интерфейсы, а дальше джуниоры в пределах интерфейсов творят любую фигню. Если это важная фигня, то её фиксят. Если это не важная фигня, то она так и страдает в углу, не задевая при этом приложения.
Если bottleneck'а в teamlead'ах нет, или нет сильных teamlead'ов, вытаскивание микросервисов, это отличный метод перевести лапшу в коде в лапшу в инфраструктуре, которую будут отлаживать… кто?
Короче, удачи. Пачка миддлов, решившая поиграть в микросвервисы в отсутствие тимлида и сильной команды админов — это новый антипаттерн для долгострочного, глубокого, фундаментально-персистентного факапа всея проекта с вынесением момента факапа на несколько итераций разработки в будущее.
Т.е. это всё равно, что утверждать, что тротуары на улицах — это решение проблемы загрязнённого воздуха. Совершенно ортогональные явления, не связные друг с другом.
Да, бывает так, что админу предлагают это всё "починить", вывалив на него лапшу из коннективити и плавающих api. В принципе, я помню электрика, который отказывался чинить что-либо в доме, где проводка была сделана с помощью knob-and-spool, причём частично. Вот примерно такое же ощущение.
Момент касаемый пачки мидлов, решивших поиграть в микросервисы поверял на собственном опыте, причём, неоднократно.
Что касаемо статьи, на мой взгляд, довольно глубокое, но изложенное простым языком видиние проблематики проектирования и развития микросервисным систем. А некоторые озвученные моменты просто глоток свежего воздуха.
пачки мидлов, решивших поиграть в микросервисы
Или когда вся команда, начиная от архитектора и заканчивая джуном решили использовать микросервисы чтобы записать их в резюме. Такой resume driven development. А потом устроиться в Озон на golang и потогонную систему за скромные деньги.
А какие озвученные моменты для вас глоток свежего воздуха?
В мемо:
Микросервисы это паттерн разработки со слабыми тимлидом и архитектором. Хоть как-то использовать слабую команду скидывая проблемы интеграции на DevOps. Бггг
Или когда вся команда, начиная от архитектора и заканчивая джуном решили использовать микросервисы чтобы записать их в резюме
Встречался и с таким паттерном, когда команда разработки думает не о продукте, а о резюме. Презабавнейшие вещи получались.
А какие озвученные моменты для вас глоток свежего воздуха?
1 Реальные перечисленные проблемы
2 Про не понимание бизнесом микросервисного подхода. Неоднократно слышал пожелание о более тесной связности и зависимости приложений и приходилось доказывать обратное, что приложения (микросервисы) должны быть минимально связаны и зависимы от остальных
3 И то что большинство решающих взяться за микросервисы мало представляют уровень сложности такой разработки
большинство решающих взяться за микросервисы мало представляют уровень сложности такой разработки
Сначала оказывается что на рынке нет или нельзя быстро набрать тимлидов и архитекторов чтобы держать жёсткую диктатуру дисциплину в проекте. Или денег жаль (что очень глупо на этом этапе). Потом оказывается что на микросервисы нужно вдвое больше разработчиков и многократно больше DevOps. Потом или бизнес готов поддерживать 10 кратные расходы от того что вовремя не успели собрать костяк команды либо того кто ввёл микросервисы гонят ссаными тряпками.
Потом оказывается что на микросервисы нужно вдвое больше разработчиков и многократно больше DevOps
Девопсов на проекте обычно многократно меньше чем разработчиков. Иногда отсутствуют полностью.
Кстати, хорошая и грамотная команда инженеров DevOps также играет немаловажную роль - хорошо и грамотно спроектированные микросервисные приложения, могут запнуться о кривую или некудышнюю реализацию в CI/CD и инфраструктуре.
либо того кто ввёл микросервисы гонят ссаными тряпками
Увы, такова действительность. Не всегда бизнес готов к технологическим вызовам: аналитика в Excel, web портал на простенькой CMS, сервис ААА (autorisation, accounting, authentification) на базе AD или 1С
Масштабируемость. Если я хочу масштабировать какую то часть
Почему не всё приложение?
Из-за таких вот определений мир наполнили нано-сервисы: рой сильно-связанных сервисов, которые никак не ложатся ни на домен, ни на орг. структуру.
Приходишь в компанию, а там 30 команд пилят 1500 сервисов. Да еще гордятся этим. Чтобы хоть как-то начать в этом ориентироваться, надо потратить полгода и километр нервов.
есть еще определение: микросервисы - это распределенный монолит
ибо сначала они говорят, что сервисы независимы, но на практике A зависит от B и C, B зависит от D и E и конечно особый шик это закольцевать зависимости чтобы E зависел от А,B
и тогда раскатка любой мажорной фичи - просто песня, надо загасить весь кластер, обновиться и заново поднять
Если команда не умеет в обратную совместимость — это не проблема архитектуры.
Только очень мало кто умеет в обратную совместимость, так как это вообще технологически нетривиально. Для синхронных вызовов еще есть решения (особенно если забыть про RESTful), с БД уже сложнее, а вот с брокерами - совсем грустно.
Хотя если не нужно уметь откатывать релиз при ошибках, то все чуть проще, но не надежно.
Микросервисы могут решить когнитивную нагрузку разработчиков, ценой когнитивной нагрузки других разработчиков (кто будет объединять микросервисы в приложение выполняющее бизнес-фичу) и девопсов.
Я из мира фронтенда, у нас вместо микросервисов есть микрофронты (по факту микросервисы). Часто слышу, а давайте начнем делать микрофронты, но только это потребует кучи времени настроек CI, особого мышления, так как сильно изменится способ взаимодействия с микрофронтом против обычного компонента. За 1,5 года на последнем проекте я смог выделить для себя только один микрофронт, который бы привел к уменьшению кванта развертывания, так как есть два приложения с разным релизным циклом, в которых надо одновременно зарелизить один и тот же компонент.
Наконец то годный пост, какой холивар заварили... простите за оффтоп...
Монолит неправильно называть монолитом, т.к. это не монолит а макросервисы!
Проблема №1. Хрен знает, что такое сепулька.
Проблема №2. Сепулькарий не решает проблемы бизнеса.
Проблема №3. Сепульведение требует слишком большого количества ресурсов.
Это архитектурный паттерн. Какие определения могут быть? Это размытое понятие, с размытыми границами, некоторыми обобщенными характеристиками.
Проектирование сам по себе процесс недетерминировнный, неряшливый, с бесконечной вариативностью (ибо сложность и жизни и решаемых проблем бесконечна).
хотелось бы отдать должное GitOps. Этот термин используется относительно стабильно, в основном благодаря исходному чёткому определению
А для меня наоборот GitOps кажется не очень подходящим определением.
Если остальные xOps (например, DevOps, MLOps, TestOps и т.д.) — это широкие концепции процессы, практики и культуру в определённой области.
То в случае с GitOps — это узкая, технически конкретная практика управления infrastructure as code, с жёстким набором принципов (даже операторы это часть определения)
То есть, в отличие от других xOps, GitOps — это не "operations с Git", а конкретная модель управления инфраструктурой. Название как бы вводит в заблуждение, делая его похожим на другие xOps, хотя по сути это определённый паттерн, а не целая дисциплина.
Получается термин слишком специфичен для такого рода суффикса.
Блин, а почему люди с такой низкой квалификацией считаются архитекторами? О_о
Ну что я могу сказать... не прошло и пяти десяти лет с тех пор как каждый второй школьник, не читавший Брукса и проблему серебряной пули, вдохновившись коллективным безумием и хайпом писал статью про то как он пилил монолит на микросервисы, а за оспаривание этого безобразия можно было отхватить и дизлайки и минусы в карму... как вот, наконец, до авторов начало доходить понимание, что маркетологов и школьников нельзя пускать в архитектуру.
Это, конечно, похвально. Нет, я серьезно - я то вот как бы сразу говорил, что "и миллиард муравьёв не вытащат бульдозер из карьера - для этого нужен другой бульдозер", что "микросервисы - очень частный случай компонентно-ориентированной архитектуры" и уже из-за того, что в них маниакально выкрутили в абсолют "фичу развязанности" - их нельзя применять огульно без понимания зачем это тебе... да кто-ж меня слушал ))))
Но, теперь то, дорогие мои, что делать то будем с уже наклепанными на коленке системами, в которых сотни дублирующих друг друга микросервисов, мирриады практически одинаковых ДТО-шек, которые боязно трогать... и разваливающиеся дышащие на ладан процессы завязанные на кучу "независимо разработанных фич", между которыми (о ужас! "никогда не было и вот опять!") есть зависимости, которые никто никогда не документировал, ни понимал.. ?
А ведь ещё есть толпы спринг-бут-овцев заточенных строго на один процесс разработки, один (имхо, достаточно примитивный) инструмент, и считающих что спрингбут=java....?
Что? бюджеты освоены, лохи окучены обучены на курсах "программист за 3 месяца", проекты радостно сданы, а проблемы поддержки - это проблемы тех кто следующим выиграет госконтракт ?
Риторический вопрос. Но решать надо. Всем добра.
Почему я перестал говорить с архитекторами о микросервисах