Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Перестать выращивать динозавров. Как эволюционирует архитектура приложения

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Привет, меня зовут Виталий Корж, я Dev Lead из Luxoft. Последние пару лет мы с командой занимаемся разработкой в области Digital Asset Management. Эта статья — небольшая ретроспектива на эволюцию монолитного приложения в множество сервисов. Она будет полезна разработчикам и QA-специалистам как уровня middle, так и senior.

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

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

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

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

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

Рассматривая спектр систем от огромного монолита на одном конце, до функций на другом, всегда существует понимание, что все они в общем-то похожи. Каждая система по-своему принимает, обрабатывает сигналы и хранит состояния.

Минимально возможный дизайн

Для примера рассмотрим веб приложение.

Независимо от сложности и специфики проект можно разделить на несколько слоев:

  1. Клиент
  2. Прокси сервер
  3. Сервис
  4. Ресурс

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

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

Независимо от гранулярности любой сервис можно свести к SRP. Понимание ответственности сервиса можно трактовать по разному и это нужно заранее оговорить.

Детализация

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

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

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

Монолитный хаос

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

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

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

Перестройка

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

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

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

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

Оркестрация

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

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

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

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

Структурирование

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

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

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

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

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

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

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

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

Обслуживающая инфраструктура

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

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

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

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

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

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

Сервис-монитор — также неотъемлемая часть любой инфраструктуры, позволяющая знать какие версии сервисов и где они запущены. Его присутствие способствует оперативному реагированию на различные неполадки. Невозможно представить систему без должной системы мониторинга, как на уровне сервиса, так и на уровня контейнера.

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

Заключение

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

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

При моделировании дизайна микросервисов все-таки первичны принципы ddd( bounded context) если им следовать, а не другим положениям — вроде сервис на таблицу или REST ресурс или размер(что вообще относительно) это позволит сохранить большинство бизнес сценариев в пределах одного сервиса без необходимости внедрять сложные паттерны между микросервисной коммуникации (в том числе request aggregator , или как вы его называете orchestrator — в целом такие инструменты всегда должны оставаться в меньшинстве и использоваться изредка в сценариях с бизнес логикой — в пользу бизнес транзакци внутри сервиса) это позволит сохранить возможности изолированной разработки/релизов, роста количества одновременно работающих команд за адекватную цену(сложность разработки и обслуживание).

Это если
1) у тебя есть достаточно времени и ресурсов на полный анализ домена
2) сам домен и бизнес модель не меняется (бизнес не смог развиться)

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

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

В этом случае и ежу понятно, что модульный лучше

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

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

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

не сыпьте соль на рану.

не только эти апологеты :)

утрировано ж многолетние претензии к вузам, не только у нас, о том что они выпускают негодных к работе в общем-то в двух пунктах
1. в вузах их учили «математике» и «информатике» а не программированию=созданию компьютерных программ
2. в вузах им не объяснили что существующие парадигмы создания компьютерных программ на универсальных ЯП фундаментально несовместимы с реляционными БД, и поэтому вся эта «наука» идет лесом, если ты не понимаешь, не говоря об умении, навыках — использования БД.

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

И сразу в ход идут велосипеды с квадратными колесами

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

как раз попытки моделировать бизнес-логику — данными — верный способ получить велосипед с квадратными колесами :D
такая попытка потому не только распространена, а объявляется бест практикой, в силу пункта 1
студентов учили математике и информатике, а многие остаются студентами и после выпуска не один год

в измерении одной возможно структуры данных

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

вообще-то очевидно что архитектура приложения и структура данных — это две независимо эволюционирующие вещи.

для непонимающих рукожопов даже придуман более простой термин
.... «прибито гвоздями к БД» ...

произведение строк и колонок.

ну да, следствие пункта 2. Все что осталось у большинства в голове после вуза о реляционных отношениях

не, вот о реляционных БД точно не на доу.

как раз попытки моделировать бизнес-логику — данными — верный способ получить велосипед с квадратными колесами :D

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

Я не дискутирую на предмет разделения бизнес поведения модели и ее persistence на что нацелился ты уже развести очередную демагогию на этом форуме.

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

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

на что нацелился ты уже развести очередную демагогию на этом форуме.

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

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

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

Типичный пример, отставшего от жизни африканского ИТ. В то время, как весь цивилизованный мир ещё в середине 2000-х пришёл к консенсусу, что хранимые процедуры это зло, которое должно выжигаться из системы калёным железом — африканеры в 2020 заменяют продакт-код хранимыми процедурами.
Зато статьи читают и пишут — на рашкоязыке. :)

Не лазь на рашко-хабрах — плохому научишься.

В то время, как весь цивилизованный мир ещё в середине 2000-х пришёл к консенсусу

то-то мне помнится шутка, от работающего в американском энтерпрайзе

странно, я устраивался на работу разработчиком на Java, а кода последние годы написал больше на Pl/SQL

что хранимые процедуры это зло

там ему и предлагали уверовать в это стереотипное мнение.

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

тем и интересно, пощупать иногда палочкой эту еду миллиона мух.

там ему и предлагали уверовать в это стереотипное мнение.

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

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

хранимые процедуры это зло, которое должно выжигаться из системы калёным железом

Хранимые процедуры — вполне себе нормальный подход к реализации обработки данных. Но вот когда СУБД начинают использовать как аппликейшен-сервер, и в хранимые процедуры помещают логику рассылки/получения email, формирование/парсинга JSON/XML, взаимодействие с внешними к БД ресурсами через HTTP(s), разворачивание JAVA машины внутри БД и т.д. — появляется весьма обоснованное мнение, что «хранимые процедуры — гавно». Каждый компонент должен использоваться для задач, которые наиболее оптимально решать именно на этом уровне...

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

меня вот в КПИ этому не учили. научился на работе, от старших товарищей. Которых тоже этому не учили, в их время. со второго курса работал.

поэтому годами такие борзые в форумах студентропы, низвергатели авторитетов, приводят в итоге аргумент:

Это не стереотипное мнение, а результат обсуждений опытных людей,

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

что дяди говорили, почему они так говорили, как пришли к такому мнению, студентам конечно не понять.

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

Но поверь, аргументов не использовать хранимые процедуры предостаточно. И на любом уровне, как-то:
— человеческом: вкратце, умеющие обращаться с БД/SQL дерьмово пишут код и наоборот
— инструментальном: вкратце, средства разработки кода в СУБД — говно
— методологическом: вкратце, написанный в СУБД код нереально развивать/сопровождать/тестировать (это же относится к системам с таким кодом, в целом) + в нём нарушается куча принципов современной разработки типа солид, клин код, итп

Но поверь, аргументов не использовать хранимые процедуры предостаточно.

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

так что забирайте наконец еще один кубок победителя :)

А еще разные дяди в разные годы говорят разные вещи.
И да, дяди могут ошибаться.
И могут бояться вслух сказать, чтобы не засмеяли.
ithare.com/...​ii-scalability-to-follow

А еще разные дяди в разные годы говорят разные вещи.

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

Истина должна быть Одна. Абсолютная! На века, и высечена в скрижалях.

И могут бояться вслух сказать, чтобы не засмеяли.

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

не пугайте детей.

А скинь линку. А то хабра столько, что мне туда заходить страшно.

Как Lingualeo переехал на PostgreSQL с 23 млн юзеров
habr.com/...​ny/lingualeo/blog/515530

комментировать не буду, там все прекрасно :)
только
статья еще и пример того что может настоящий cowboy программист :)

Жесть! И до, и после.
Чуваку респект, что смог разгрести одно, и загрести другое.

Чуваку респект

вот и я про то :)

я не столь радикален в подходах, и так делать не рискну,
но понятно же — насколько крутую работу проделал, и — успешно!

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

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

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

Чуваку респект, что смог разгрести одно, и загрести другое.

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

За все надо платить.
Нельзя сделать быстро и качественно.

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

интересно все же, сколько постов скопипастят с «убийственной» критикой с хабра :D
надо былу линку вам в личку прислать... протупил.

За все надо платить.
Нельзя сделать быстро и качественно.

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

А вот представь, что все эти дыры — это часть спеки

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

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

Подозреваю, там много недосказанного. Т.к. чудес не бывает.

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

Ну да, там и набросить под разными углами можно. Сравните «Мы увеличили авейлабилити и ресайленси после переноса БЛ в хранимые процедуры» vs «Мы выкинули пыху нахый и стало только быстрее!!!»

Мы выкинули пыху нахый и стало только быстрее!!!

вместо пыхи можете поставить Java/C# - будет то же самое :)

но что это я, «копистить» тамошние коменты сюда начал...

можете поставить Java/C# - будет то же самое

Нет, рифмоваться не будет

шоб БД не оказалась узким местом

это да. и от защиты от падения астероида — даже намека нет.

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

но вы верно подметили, о защите от падения астероида на датацентр как-то не упомянуто. а надо бы!

Нуууууу.... с толковым подходом-то можно многова дастичь и без переноса БЛ в СП ;)

конечно.

у толкового подхода в результате — можно подставить любое название в технологических терминах :)

вообще-то очевидно что архитектура приложения и структура данных — это две независимо эволюционирующие вещи.

Думаю, зависимо, как и закон Конвея не на ровном месте.

ну, закон Конвея да, прессует всё :)

просто за годы в домене, как я его называю
финансово-экномического ПО (даже первый крупный проект вначале карьеры был — система продажи билетов с удаленными рабочими местами с GUI — на plain C)
или совсем шутя
опердени и склады

и видя как катаются в основном на квадратных колесах, и как Oracle PL/SQL TechLead вытягивают такие проекты
как всегда — философствуя на эту тему
пришел к мнению что главная ошибка первоначальных команд, отвтетственных за приложение в целом в том что у них в головах — синкретизм (хоть в культурологическом смысле, хоть по Выготскому к мышлению детей)

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

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

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

К сожалению, большинство разработчиков приложений обращаются с СУБД как с черным ящиком. При таком отношении, СУБД рано или поздно становится узким местом всего приложения, независимо от выбранной архитектуры. А если на это накладывается еще и некорректный выбор самой СУБД (как пример, «нам не нужна эта реляционная хрень, которой сто лет в обед, давайте использовать объектно-ориентированные БД, это модно и круто»), то все становится совсем печально и трудновывозимо на этапе, когда уже уперлись в трудности...

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

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

но хватает сценариев где она вообще не играет какой либо роли в ключевых моментах построения и функционирования приложений

угу, выше написал:

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

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

Трава зеленая, а небо голубое.

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

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

, чтобы приводить такие пустопорожние аргументы времен хайпа.

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

например типичная задача для Lucene-based решения — надо сделать dashboard(коих сейчас миллион в любом enterprise приложении или онлайн магазине) с поддержкой фильтраций по набору категорий, нечеткого поиска по нескольким текстовым атрибутам на различных языках, считать фасеты по ещё нескольким категориям, пейджинг — что нам может предложить готового Рсубд вендор или реляционная модель хранения, что бы решить такую задачу быстро и с вменяемым временем выполнения запроса(~200 мс) искать по миллиону рекордов на 2х ядерном intel актуального поколения?

например

есть для примера такой пример.

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

при этом, когда в аругментации присутствует фраза

общеизвестный факты

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

но, как годами ухмыляюсь
но демагог конечно я :)

пейджинг — что нам может предложить готового Рсубд

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

потому что, открою секрет одного тренинга
учитесь отличать утверждения оформленные в виде вопросов.
на такие «вопросы» нет смысла тратить времени
потому что невозможно ответить на то чего нет — на вопрос.

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

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

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

на чем будешь делать?

ни на чем.
если я начинаю, то начинаю с — как.
плюс к этому как — я всегда стараюсь учитывать закон Конвея.
а на чем, да хоть на монге.
да хоть на мускуле. да хоть на кафке с кроликом.
да хоть на хранимках оракловых
какая разница то?

а то что большинство подборов товаров тормозят — я в курсе :)
ну, какое комьюнити, такие и тормоза.

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

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

Це типова Elasticsearch задача. Вирішується за пару днів до рівня API

Вирішується за пару днів

+/- время на миграцию данных с продакшна и отладку актуализации кеша

Так не используйте реляционные БД там

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

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

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

ну так ресурсы этого большинства ушли в изучение О больших, и о маленьких, и прочем, и они просто не в курсе как лихо их тру архитектура с использованием передовейшего ORM приводит к SELECT N+1

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

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

Ну, спросите, что ли...) Самому интересно, как там нюансы.

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

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

Эволюция — это NP-долго, NP-жестоко и NP-тяжело

Как перестать выращивать динозавров: надеть на динозавра маску жабки. Те же яйца, только в профиль.

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

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

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

Микросервисы на сегодняшний день в 95% проектов — это утопия. В будущем должна появится одна большая консолидированная платформа которая поможет как-то сносно работать с этим всем, но до этого лучше туда не лезть.

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

в действительности уже наблюдаю горемык, которые перепровелили на себе тезисы
«Смерть микросервисного безумия в 2018 году» (в названии статьи так и стоял год ее публикации, и движухи вокруг нее на HN и потом в русском переводе на хабре)

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

ведь

Разница по сложности между монолитом и микросервисами примерно как между однопоточным и многопоточным кодом с вот этим вот всем.

очевидно было уже на уровне концепции...

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

Держи еще в копилочку, пятилетней давности
ithare.com/...​el-is-considered-harmful

о, не встречал, забросил себе в покет, спасибо.

просто когда хайп начался, у меня сразу глаза на лоб полезли
вот такой подход — призван решить вот эти проблемы? рылли?
«Эта жидкость экономит топливо при заливке в бак всего 1% от его объема, а так же предотвращает выпадение волос, если ее втирать по утрам!»
так бывает?
ДА!!! — хором, вы не понимаете! и т.п.

ну, оно и правда, чем больше в программировании, тем меньше «понимаешь»...

Вот тот же чувак показывает как делать хай-лоад без хайпа
ithare.com/...​-threading-with-a-script

В будущем должна появится одна большая консолидированная платформа

Говорят, что убивший дракона сам становится новым драконом (почти ©)

— Куме, а знаєте, як москалі називають Оркестратор, який вдома партитуру забув?
— Як?!
— Диспетчер!
* завіса

Когда Нетфликсу нужна высоконагруженность/масштабируемость — что делают кодерки Нетфликса? Пишyт код на С, всё это крутят (в т.ч. распределённо) на нгинксax + дописывают в операционку функции, выполняющие нужные действия не вылазя из ядра (в уровень приложения).

Что делают галерные лиды? Генерят тучу микросервисов на каком-нибудь тормознутом интерпретируиемом языке или даже на жабе, оборачивают их в контейнеры/докеры с кубернетами/оркестрациями — и всё это крутят со скрипом на адском (и дорогостоящем) количестве ресурсов.
Зато модно-хипстерски!

Как бы нетфликс это джава хаус и у них микросервисы полных ходом

Как бы нетфликс это джава хаус и у них микросервисы полных ходом

Посмотрел презентации — жаба, микросервисы, оркестрэйшн, и вот это вот всё... Куда катится мир?

Похоже, несправедливо наехал на оратора выше.

А ты думал айтишники зря к пенсии в 45 готовятся в нищей европе ?
В этой самой немеччине даже когда тебе будет 60, возьмешь лопату и будешь размешивать микросервисы с горящими 18ти летними глазами.

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

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

В твои 60 коболом будут микросервисы, а ипотека еще не выплачена =)

В твои 60 коболом будут микросервисы, а ипотека еще не выплачена

Современный КОБОЛ — это жаба и шарп (в подавляющем случае, без каких-либо микросервисов).
В то время, как C/C++ — вообще вечны!

Мой C++, который выучил 13 лет назад, уже мертв — все хотят авто, функторы, лямбды и промисы.

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

я последнее время не следил, но интересно, как там фронтендеры, соснули уже тунца с хайпом вокруг ФП(который до них добирался дольше чем до тех девочек), или еще в предвкушении?

Заходит как-то ФП в js-bar, заказал выпивку, получил обещание что нальют, но представиться как зовут забыл

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

И то после конверсии к строковому типу

а так, тип то может оказаться — строго 5 букв, потому что предыдущий бармен думал о vodka и ушел на повышение, потому что тру функциональщик

В баре шумно, так что тип скорее всего масив елементов по 4,7 букв

BTW очень забавная но возможно (местами?) рабочая свежая штука www.youtube.com/...​lsTW4tBKqVwJWMJQh&index=1
Распутывание спагетти превращением в ФП, покрытием тестами, и сворачивнием назад.

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

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

И где там шутка? И кстати ни про какое сворачивание назад речь не шла, по крайней мере в этом коротком видео. Речь шла про дополнительный возможный рефакторинг pure functions в те же самые pure functions.

фронтендеры, соснули уже тунца с хайпом вокруг ФП

С чего бы это? Фронт-енд сам по себе — это функция «данные => HTML». Точнее, «(данные, локальное состояние) => (HTML, новое локальное состояние)»

Так что, тут, как говорится, сам Бог велел.

С чего бы это?

да так.

Как один, похоже с интонациями из
— Они тут, на Брайтоне, уверены что уехали из СССР

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

авто и лямбды тупо удобны. особенно в Qt когда слот можно нарисовать лямбдой прямо в коннекте не отходя от кассы

Для меня плохо то, что язык стал слишком большим и разнородным. Его и раньше за 21 день тяжело было осознать, а теперь — вообще фиг.
Ну и pthread очевиднее работает, чем промисы. С изначально был про закатывание солнышка ручками, а тут чем дальше — тем больше автоматики, которая по стилю ни разу не подходит.

Промисы уже в std, вроде, а pthread — это линух. Значит, не базируются, а отданы компилеру на откуп.

В новых плюсах добавили корутины, раньше они в бусте были.
Вот держи статью ithare.com/...​hreading-with-a-script/2
Вроде это то, что ты хочешь — несколько контекстов выполнения в одном потоке. Но оно как обычно — несколько новых кейвордов, а чтобы заработало — надо неделю писать руками фреймворк. По крайней мере, ничего вменяемого в нете не гуглится.

Думаю что где-то так.

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

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

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

Нет смысла мешать типичные бизнес-задачи типичных же веб-аппликух с чисто инженерными. Если в каком-то проекте появится инженерная задача, то она будет решаться соответственно (хоть на C, хоть использованием стороннего решения). Или ты предлагаешь бизнес-правила на C описывать? Мощно, чё).

Ну и да, у Нетфликса как бы именно так, как ты описываешь с микросервисами — модно по-хипстерски). Там далеко не один стриминг видео (который ты, скорее всего, имеешь в виду).

Хех, ось вам погляд Нетфлікса на це все, класична вже доповідь: m.youtube.com/watch?v=CZ3wIuvmHeM

Так уверенно вещаешь. Неужто тебя взяли на нетфликс контрактором за 100500 бачей в час?

Тут речь немного о другом. Когда Нетфликсу нужно у них есть Опция 1 (на си) и Опция 2 (микросевисами на джаве).
Когда аутсорцу нужно у них есть Опция 2а и Опция 2б.

похоже, ктото Half-Life пишет

Это все замечательно, но есть один критически важный вопрос, а сколько задач на литкоде ты уже решил?

Не так. Статья, раз названа ретроспективной — продаёт компетенции компании.
Это и фрилансер умеет. А если не умеет, то уже умер с голоду.

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

Ну и потом и от других компаний,и сравнить компетенции. А то проекты какие-то. У всех проекты.
А задач на литкоде — сколько в день ваша компания решает, а?

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

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

Non-agnostic service второго уровня (Task на диаграмме по ссылке)
patterns.arcitura.com/...​n_patterns/service_layers

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

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

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

Он уже отдельный, естественно — иначе как он будет агрегировать? Чем?)

Либо когда сценарий многошаговый, и последующий шаг зависит от предыдушего. Привет, состояние.

Какая зависимость от предыдущего состояния в аналитическом запросе? Может, я чего-то не понимаю, конечно...

Чтобы внести ясность, откуда скептицизм.

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

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

Оптимальным вариантом может послужить шаблон оркестратора (Orchestration pattern), который способен объединять цепочки вызовов других сервисов в слаженный сценарий, дополнительно обрастая дополнительными возможностями.

Т.к. анализ — это, очевидно, read операция, то, выходит, описан банальный средненький аналитический запрос (вряд ли масштабный, т.к. бил бы по базе — правда, можно read реплики настроить, если ситуация позволяет обойтись ими, но это уже детали). Поэтому, если требуется просто дёрнуть несколько сервисов и слепить из их ответов один, то называть это «окрестратором», ну, блин...)) Термин «окрестрация» чаще всего применяется в случаях изменения состояния (т.е. write операций) — для операций чтения я встречаю его упоминание, честно говоря, впервые. В общем, непонятно, почему самые обычные агрегации ответов, которые используют чуть ли не все вокруг, вдруг стали проблемой, которую стоит упоминать в подобном контексте (притягивая туда «окрестрацию»).

дополнительно обрастая дополнительными возможностями.

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

Термин «окрестрация» чаще всего применяется в случаях изменения состояния (т.е. write операций) — для операций чтения я встречаю его упоминание, честно говоря, впервые.

та слово просто хорошее, модное и серьезное :)

Мне из одного проекта в котором принимал самое скромное участние запомнилось
Оркестрация провижионинга.

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

не взлетел вроде, как продукт, пришли кубернетесы, с более скромными функциями.

Это чисто маркетинговая статья, как и основная масса «технических» статей на доу.

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

Разве у Люксофта есть внутренние заказчики?
Или это программистов хайрить, кто хочет научиться быть крутым?

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

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

Могу конечно выбрать статей 10 таких на доу,и показать основные фишки жанра. Но как бы мне это не надо, а кому надо? Да никому :)
Но эта — очень хороша. Я её аж несколько раз перечитал, неужели нет помарок? Не нашёл. Может быть потому что использованы типовые наработки, раз это аж целый люксофт. Я своих не делал, потому все есть в интернете, а написание такого — не регулярная деятельность :)

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

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

Для меня (без опыта с распределенными системами) звучит очень спорно. Много правил без доказательств, а системы правил обычно работают в одной узкой области.

Есть классическая рекомендация начинать незнакомую разработку с монолита martinfowler.com/bliki/MonolithFirst.html
И есть свежая статья о том, как потом постепенно переходить на микросервисы, если монолит стало тяжело обслуживать www.hillside.net/...​lop/2020/papers/yoder.pdf
И эти две статьи звучат проще и конкретнее, чем данный топик.

100% правда. Такий підхід простіший. Автор рішає проблеми яких нема, якщо самому їх не створити

Скоріше навіть не моноліт тяжко обслуговувати, а навантаження таке, що сервіс потрібно розбивати. Насправді моноліт хороша річ і всі проблеми в ньому як правило від рукожопості. Хоча вона нікуди не зникає при переході до мікросервісів. Вцілому, підтримую Ваш комент.

После всех реорганизаций ошибка останется

Підписатись на коментарі