Комментарии 55
>> Только горизонтальное масштабирование. Мы можем лишь «накинуть железа»: добавить памяти, процессоров или диск на сервер, где крутится система.
Как мне кажеться, это вертикальное маштабирование
Тоже всегда путал это... Всегда, казалось, "вертикальное" это добавление новых серверов в стойку, расти в верх. А "горизонтально" это расти в ширь, увеличивая мощность текущего :) Но в ИТ все на оборот.
так и есть, распухание железа это вертикальное масштабирование
Да, это точно. Но смысл в целом понятен -- расширение мощности
Стратегически выгодно все сервисы магазина вынести в облако. Это позволит напрямую сэкономить на мощностях 20–40%, так как облачные серверы дешевле bare metal.
Ровно до того момента как произойдёт сбой в облаке и встанут все магазины одновременно, или просто отвалится связь и перестанет работать один конкретный магазин. Такие объекты непрерывного функционирования должны иметь возможность автономной работы, возможно с некоторой деградацией функциональности. Так что в облако можно выносить далеко не всё.
Опять ода микросервисам, хотя дело-то не в них, а в архитектуре решения - как обеспечивается взаимодействие, синхронизация, резервирование, отказоустойчивость, масштабирование. В целом сделать хреновую систему на микросервисах проще, чем монолитом. А если квалификация проектировщиков достаточная, то вопрос стоит не монолит vs микросервис, а выбор оптимального разделения на функциональные блоки и способов их взаимодействия.
Тоже удивился с такой "экономии". Как правило, в долгосрок облака не дешевле, а ДОРОЖЕ self hosted решений. Во всех смыслах. И это не говоря про вендор лок.
Ну там надо считать, во сколько обойдётся поддержание доступности, надёжности и геораспределённости на selfhosted варианте. В конце концов любое облако работает на железе :). Тут в принципе недопустимо выносить процессы работы магазина за его пределы.
И вы однозначно правы, что полагаться на вендорское облачное решение для крупной компании несерьёзно.
Во первых Не путайте SaaS и виртуальные сервера в облаке. Во вторых облако может быть своим (у гигантов вроде х5 наверняка такое).
У них вполне себе может быть свое облако. Пусть даже с 3 ДЦ (допустим МСК/СПб/Новосиб)
Спасибо! Как раз прорабатываем этот сценарий тоже. Тут может быть несколько вариантов -- обеспечение автономности и постепенный переезд в облако (возможно с резервным "спящим" инстансом для быстрого отката на локальную версию). Тенденция развивается в сторону увеличения пропускной способности, надежности и стабильности каналов. Если лет 10 назад мобильный интернет еле-еле работал, то сейчас у нескольких операторов можно чуть ли не HD смотреть. Дальше будет только лучше с каналами. Тем более если резервировать оптику мобильными каналами (или VPN поверх мобильных каналов).
Про оду микросервисам тоже верно, но для нас такое решение оказалось наиболее приемлемым, так как переписывать легаси монолит в новый монолит -- больно и долго
Я ни в коем разе не против микросервисов - в частности, если стоит задача по динамической балансировке нагрузки, полностью согласен что с ними обычно удобнее.
А вот насчёт каналов связи - тут дело не в самой по себе их надёжности, сейчас действительно это не та проблема как 10-20 лет назад, а именно в централизации логики и получении единой точки отказа (хоть и резервированной по самое небалуйся). Может я параноик, но мне кажется что приостановка продаж по всей сети одним махом это очень большие прямые финансовые потери - ту не сравнить с какими нибудь сотовиками, у которых это "только" репутация.
Поддерживаю, остановка продаж — недопустимый сценарий. Но на этот счет у нас магазин полностью автономен. Риск отказа облачной системы — цена не будет обновляться.
Вот мне почему то вспоминается история одна старая (. Приезжаю в крупный сетевой магазин(не X5, другая сфера). Все работает. Вдруг слышу что на кассе нагло не хотят продавать товары, в смысле за нал - тоже. Свет при этом есть. Обосновывали что у них якобы нет интернета (если что - в магазине и сотовые модемы и симки - продаются, центр города, с точки зрения покупателя выглядит отговоркой).
Подозреваю что этому магазину мой уход обошелся не только в утраченную продажу но и в замену <подробности в моем телеграм-канале, ну когда я его заведу, и все равно срок давности вышел уже>
Хм, а почему решили, что если нет компетенций написать монолит, то хватит написать гораздо более сложную распределенную систему? Если даже понимания МСА особого нет и даже с простыми задачами в монолите не удалось справиться?
Описание проблем монолита показывают просто очень плохое понимание архитектуры. Можно два монолита параллельно на двух машинах запустить и обновления могут быть абсолютно без даутайма.
Вот именно. И базу тоже можно без даунтаймов апдейтить, и микросервисы тут совершенно непричем.
Да тут большая часть "проблем монолита" надумана, и решается совершенно другими способами. Я бы даже сказал, что имея десятки тысяч инсталляций, оновная проблема не обновлять их помодульно вразнобой, а наоборот объединять в единые пакеты обновлений и выкатывать их по расписанию, нечасто, и ступенчатым раскатыванием.
Согласен, но проблема балансировки нагрузки на отдельные функции внутри монолита так не решается. А нас как раз это больше беспокоит
Новый ценник 40 дней? 1Сники смеются. Сквозь слезы.
Новый тип ценника. 1С было бы прекрасно, но такие объемы данных им пока не по зубам (проверяли)
Эээ, а какие "такие объемы"? Один магазин, даже большой - не выглядит чем-то неподъемным для 1С, где даже автозапчасти умудрялись впихнуть.
Про ценники тоже улыбнуло. В своё время в 1с сделали отдельный справочник макетов под ценники и его применение по всем филиалам одним нажатием кнопки. С тех пор маркетологи с опаской стали к нам обращаться, ибо одно их "рац.предложение" моментально разошлось по всем точкам и они получили по шапке за шквал звонков от продавцов и администраторов зала)
ТСД - терминал сбора данных, не сверки.
Уже весь мир понял что, облака - это дорого и ловушка маркетинга.
Если все данные хранить в облаке, то любой хак облака положит все магазины. Если хранить у себя в магазине, то достаточно залить сервер чаем. Если отключиться интернет, то работа встает и без этих двух инцидентов. Если отрубить электричество, то работа встает вообще вся. В нашем сельпо в 90е расчеты были наличкой, а считали сдачу деревянными счетами. И это был пуленепробиваемый, хакероустойчивый, энергонезависимый вариант...Но как-то раз в магазин пришли спортивные ребята с кастетами. Но это уже совсем другая история.
А про проблемы авторизации в Микросервисах не указали🤷♂️
Возможно я не прав, но статью увидел так:
1. Был монолит на Java.
2. Начался рост технического долга из-за роста потребностей бизнеса в развитии нового функционала.
3. Решили увеличить команду разработчиков. Но централизованное управление большой командой сложно.
4. Решили делить большую команду на отдельные группы разработчиков, по отдельным направлениям.
5. Каждая группа разработчиков стала предлагать свой любимый стек технологий для лучшего удовлетворения потребностей бизнеса (В статье было про Java и JavaScript ). Но группы разработчиков не смогли договориться по внутренним стандартам разработки и тестирования единого монолита.
6. Вот и появилась логичная идея распила на микросервисы и назначение отдельных команд разработчиков на каждый микросервис.
А вот уже сам переход наверняка разрабатывала и проводила отдельная DevOps команда.
Так что статья больше не о технологиях, а про решение организационных задач, поставленных бизнесом. И после полного перехода надобность в функционале развития, поддержки монолита, а так же в функционале обеспечения перехода с монолита на микросервисы, у сотрудников исчезнет. Надеюсь знаниям сотрудников найдут достойное применение в дальнейших успешных проектах.
Но возможно, что я что-то упустил.
Интересно как вы организовали работу с распределенными транзакциями. Используете ли сагу или у вас другой подход?
А тут нигде нет распределённых транзакций. Концептуально "сага" есть в виде потока событий (изменение и "пропагация" цен на магазины). И этот поток однонаправленный и последовательный. Где-то он разделяется и схлопывается, но разных ожиданий (блокировок) и синхронизаций по моему нет (насколько я помню взаимодействие систем). Один поток приходит в магазины, второй по событию с кассы уходит из магазина. С распределёнными транзакциями я даже представить на таких объемах и на такой сложности процессов боюсь
Интересно как вы организовали работу с распределенными транзакциями. Используете ли сагу или у вас другой подход?
Почему не начали с Перекрёстка и Чижика?
Ой да ладно, просто устали читать код на немецком и билдить Это
По мне, так микросервисы приведут к потребности увеличения производительности железа в магазине. Помножив каждый новый сервак (или апгрейд сервака) на кол-во магазинов получим ценник, который вряд ли понравится бизнесу. А железо сейчас ой как подорожало. К тому же у микросервисов хватает проблем, которые уже обсуждали в комментах и можно ещё много что накинуть сверху. А ещё нужно ответить на вопрос: зачем в магазине микросервисы если не планируете горизонтально масштабироваться и динамически подключать новые ноды при увеличении нагрузки? Может я конечно не прав, но мне кажется, что такая архитектура избыточна и вносит больше проблем, чем принесет бенефитов.
Что касается облака и внешних для магазина сервисов, то я считаю, что магазины должны работать автономно. И если моргнула сеть у провайдера или дядя на экскаваторе задел провод, то магазин должен продолжать работать автономно. Мало того, в самом магазине, если сервак вышел из строя или сгорел коммутатор, кассы должны так же продолжать работать автономно. Доступность и стабильность работы каждого магазина очень важна для ритейла.
Да. По поводу касс -- полностью согласен, они автономны и точно продолжат сохранять максимальную автономность. Про микросервисы в магазине -- это шаг к централизации магазина. Всё таки каналы связи, сети и инфраструктура продолжает развиваться. И централизованные решения (несмотря на дороговизну) поддерживать и развивать значительно легче. Нужно только обеспечить отказоустойчивость и стабильность каналов и инфраструктуры, но тут как я уже выше отвечал -- тенденция/время работает на нас, а не против
Микросервисы обладают своими плюсами, такими как:
возможность вводить в эксплуатацию новые экземпляры микросервиса буквально в пару кликов мышкой
возможность использовать один микросервис разными продуктами одной организации
возможность отдать разработку микросервисов разным командам с различным техническим стеком, что позволяет в свою очередь решить проблему с наймом кадров, когда достаточно квалифицированных программистов приверженных к определенному техническому стеку на рынке просто нет, а так же позволяет использовать более специализированные технические стеки для задач, возложенных на микросервис
...
А минусов... Их перечислять можно устать!
Просадка по быстродействию, так как ни одна микросервисная архитектура не сравнится по быстродействию с монолитом, выполненным на том же уровне качества. Причина тут в потере времени на распространении информации между микросервисами и/или на прямом общении между микросервисами. Так же часто появляются лишние абстракции такие как APIGateway и прочие, что жрут деньги как не в себя. И не нужно говорить, что мощности монолита не масштабируются - еще как масштабируются!
Разделение на множество микросервисов увеличивает общую сложность архитектуры. Нужно продумывать взаимодействие между сервисами, их границы и зависимости.
Труднее отследить и устранить ошибки, которые проявляются в связях между микросервисами.
Возможность использовать разные технологии в микросервисах может усложнить поддержку из-за необходимости владения множеством инструментов - потеря специалистов может ударить фатально по всей организации, несмотря на то, что штат уменьшится незначительно.
Необходимы сложные системы для централизованного мониторинга, трассировки запросов и анализа логов.
Нужен целый штат девопсов, чтобы следить за всем созданным зверинцем микросервисов, который рано или поздно превратится в закрытый Ктулху клан, а потом ему нужно будет приносить разнообразные и многочисленные жертвы.
Любая неполадка внутренней сетевой коммуникации приводит к тому, что проект не просто тормозит, а приводит проект к неконсистентному состоянию БД. Это, конечно, решается и есть механизмы, но нужны специалисты и нужно время на поддержку или даже реализацию этих механизмов.
Если разные команды отвечают за разные микросервисы, потребуется налаженная коммуникация и четкое разделение ответственности. Но обычно с этим справляются не сразу, так как это не только про "программисты пообщались", а про деньги.
Микросервисы должны согласовывать контракты (API для OpenHost микросервисов и облако доменных событий для остальных) для взаимодействия. Изменения в одном сервисе могут повлиять на другие. В мире не так уж много специалистов, кто сможет спроектировать контракты и еще меньше тех, кто сможет их поддерживать длительное время не допуская мешанины, которая приведет к тому, что некоторые сервисы станут либо закрытыми для доработки, либо опасными для использования. И посмотрел бы я на то, кто именно решится на пересмотр доменных событий после года проектировки микросервисов - даже небольшое изменение событий ядра может привести к созданию новых версий большей части микросервисов, что привнесет на ровном месте столько когнитивной нагрузки, что проще уволиться.
При развитии системы требуется поддерживать обратную совместимость между различными версиями микросервисов. А так же бояться увольнять тех людей, которые знают почему микросервис был таким, а стал таким и какие мины в нем зарыты.
Буквально всех разработчиков придется вводить в курс как работает оркестрация микросервисов, какие этапы CI/CD в целом у всех микросервисов и какие у отдельных в частности. А ведь у нас есть как минимум три программных окружения: DEV, Staging/testing, prod и каждый обязательно заимеет свою специфику.
...
Часто общаюсь на тему микросервисов с разработчиками и рассказываю, что почти всё, что они хотят от микросервисов, доступно и в монолите. А что недоступно, то можно вынести в небольшие OpenHost микросервисы, требующие к себе минимальное внимание и даже не требующие себя разворачивать в DEV окружении. И зачастую разработчики отказываются потом менять шило на мыло, когда достаточно поднять свою квалификацию и решить все проблемы здесь и сейчас. Нужно знать зачем именно нужны вам микросервисы и знать - перевешивают ли плюсы все получаемые минусы. Сейчас я за смешанную архитектуру, где основной код в монолите.
Комментарий появился потому что я не увидел убедительных аргументов за переход от монолита к микросервисам, а не потому что, я захотел открыть новый холивар. Повторюсь - микросервисы могут быть полезными. Но очень многие неосмотрительно перепрыгнули на микросервисную архитектуру, когда им в действительности хватало и монолита или в крайнем случае распределенного монолита. В итоге они забывали про микросервисы, понимали плюсы монолита, но делали уже распределенный монолит из-за невозможности вернуть время вспять, чтобы откатиться обратно. И скорее я писал комментарий не для автора статьи - он уже все для себя решил, а для романтически настроенных программистов и их менеджеров, которые могут вдохновиться статьей.
Так много минусов, но микросервисы прямо захлестнули мир разработки софта. Не думаю, что это только мода. Практическая выгода микросервисов перевешивает монолитные решения.
У микросервисов только одна выгода - упрощение линейного менеджмента. И ради этого их и внедряют - так как компетентность линейного менеджмента очень невысокая в индустрии (
Не, ну выгода есть не только для менеджмента. Узкоспециализированные микросервисы снижают когнитивную нагрузку на программиста. Программист понимает, что пусть хоть весь остальной мир рухнет - все равно. Он всего лишь занимается конкретной функциональностью, которая реализует заданные контракты - API и результат вызова этого API. Никаких "А если", "А вдруг".
Это, увы, иллюзия.
Во-первых, снижать когнитивную нагрузку можно и модулями, микросервисы тут не обязательны.
Во-вторых, любая распределенная система на порядки сложнее и при разработке микросервиса приходится думать про все эти сложности, так что программисту становится только сложнее.
Ну и кто-то должен думать о создании контракта и если программист занимается "лишь конкретной функциональностью", значит кто-то другой подумал про прочую часть системы.
Да, можно плюнуть на качество (что обычно и происходит в распределенных проектах, где считают, что можно съэкономить на программистах), но в таком случае и в монолитах (или других видах распределенных систем) будет не сложно.
Не практическая выгода, а возможная выгода. Возможность нужно уметь реализовать. Реализована ли возможность получения этой выгоды в проектах, где есть микросервисы? Все ли в организации получили выгоду или кто-то один, имеющий самый громкий голос? Ответ не всегда очевиден.
возможность использовать один микросервис разными продуктами одной организации
Это преимущество касается любых типов веб-сервисов
Вся правда о переходе с монолита на микросервисы, когда у тебя сеть из десятков тысяч магазинов: опыт Х5 Tech