Привет, меня зовут Владимир Кустиков, я — архитектор решений в e-Legion. И сегодня я хотел бы рассказать вам про микросервисы.
Рубрика «монолит» - 2
Микросервисы. Не всё то золото, что хайп
2021-09-24 в 14:38, admin, рубрики: Анализ и проектирование систем, Блог компании e-Legion, Микросервисная архитектура, микросервисы, монолит, Проектирование и рефакторинг, проектирование системМодули, монолиты и микросервисы
2021-08-12 в 7:30, admin, рубрики: Анализ и проектирование систем, Блог компании Флант, микросервисы, модули, монолит, Проектирование и рефакторингПрим. перев.: системный архитектор Avery Pennarun, создавший VPN-решение Tailscale на базе WireGuard, размышляет об отличиях монолитов с модулями от микросервисов. Он рассказывает об эволюции подхода к модульности вообще и о том, почему изоляция до сих пор далека от совершенства, а также делится своим мнением о том, когда проводить границы между сервисами рационально.
В последнее время меня часто спрашивают, в каких случаях переход на микросервисы — хорошая затея. В статье «Systems design explains the worldЧитать полностью »
Скрытые расходы при переходе на микросервисы
2020-12-03 в 8:53, admin, рубрики: Анализ и проектирование систем, Микросервисная архитектура, микросервисы, монолит, оценка трудозатрат, управление проектами, управление разработкой, чеклистВ идеальном мире можно просто взять исходный код монолита, разделить его код между микросервисами и, соединив их между собой, получить ту же систему, но на новой архитектуре. В жизни так не происходит никогда. Жизнь вносит множество сложностей в эту идеальную картинку. Какие конкретно сложности могут увеличить бюджет перехода на микросервисы в два-три раза?
Я опишу факторы, которые затягивают процесс перехода на микросервисы и делают его сильно дороже, чем ожидалось вначале. Вы получите чеклист для оценки этих факторов и будете более реалистично считать бюджет перехода.
С этой темой я выступал на Читать полностью »
Google продвигает новый стандарт WebBundles — потенциально опасную для веба технологию «упаковки» веб-сайтов
2020-09-07 в 8:00, admin, рубрики: Google, Google Chrome, url, WebBundles, адреса, Блог компании VDSina.ru — хостинг серверов, Веб-разработка, информационная безопасность, монолит, пространство имен, Разработка веб-сайтов, сайты, ссылкиВ общем потоке новостей остался незамеченным совместный призыв продукт-менеджера Chrome Кенджи Бахе и веб-консультанта Google Юсуке Уцуномии об использовании нового стандарта Web Bundles, разработанного Google. На chromium.googlesource появился соответствующий мануал по использованию WebBundles и, собственно, особо о нем больше не говорилось. Запись от лица Базе и Уцуномии была опубликована еще в ноябре 2019 года, но вызвала реакцию сообщества только сейчас, и то, исключительно на нескольких профильных площадках и в одном блоге, посвященном кибербезопасности.
Чем так опасна технология «упаковки» содержимого веб-страницы в один источник, что это вообще такое, и почему команда веб-разработки Google ступает на очень скользкую дорожку, давайте разбираться ниже.
Читать полностью »
Как мы распилили монолит. Часть 1
2020-08-31 в 12:17, admin, рубрики: angular, Блог компании Tinkoff, микросервисы, микрофронтенд, монолит, монолитное приложение, Разработка веб-сайтов, фронтендПривет, меня зовут Ваня. Я решаю архитектурные задачи на фронтенде в Тинькофф Бизнесе и сейчас расскажу вам про одну из них.
Несколько лет назад у нас было большое монолитное приложение, которое со временем превратилось в десяток поменьше. В этой статье я поведаю, какие проблемы у нас возникали на регулярной основе в монолите, как мы их решили и стоит ли «распиливать» свой фронтенд.
Синхронизация
Темы секции Frontend на DUMP Казань: ML для фронтенд-разработчика, пиксельная магия, SvelteJS, смех, пот и слезы
2019-10-21 в 16:37, admin, рубрики: angular, canvas, javascript, machine learning, ml, react.js, ReactJS, svelte, SvelteJs, vue.js, vuejs, Блог компании IT-People, казань, монолит, монорепозиторий, фронтенд«Все об этом говорят, некоторые понимают, (как они думают), а занимаются, по-настоящему, лишь единицы» — цитата программного директора DUMP Казань. Если вы думаете, что вы тертый калач фронтенд, и ничего нового на конференциях не услышите, то загляните на frontend-секцию 8 ноября. Мы вспотели, пока слушали мат.часть некоторых докладов и истории взлетов-падений.
Кир Шатров: Shopify начался с Rails и здесь искренне любят этот фреймворк
2019-09-16 в 7:02, admin, рубрики: Conference, railsclub, railsconf, ROR, ruby, ruby on rails, rubyrussia, Shopify, архитектура, Блог компании RubyRussia, интервью, конференции, монолитНа конференции RubyRussia Кир Шатров расскажет об архитектуре Shopify. Как одного из самых больших и нагруженных в мире приложений на Rails поддерживает рост бизнеса на протяжении 10 лет, не переходя на микросервисы, Elixir и другие популярные альтернативы? В традиционном интервью перед конференцией вопросы Киру задал Анатолий Зайцев, разработчик компании Evrone.
Расскажи, как ты начал карьеру?
Читать полностью »
Микросервисы или монолит: ищем решение
2019-07-12 в 15:28, admin, рубрики: php, микросервисы, монолит, Программирование, рекомендации
Когда задумывается большой продукт или маленький софт начинает вырастать в левиафана, какой путь развития выбрать? Стоит ли все переписывать с нуля или продолжать «исторически сложившиеся» традиции? Да и вообще, стоит ли пересматривать саму концепцию архитектуры?
Здравствуйте! Меня зовут Константин, и я являюсь ведущим разработчиком одной довольно крупной системы, которая начиналась когда-то как эксперимент. Небольшой сайт на PHP, созданный буквально «на коленке» и, конечно же, монолитом. Шло время, сайт рос и столкнулся с рядом проблем, решение которых поставило вопрос «а дальше-то как?».
Читать полностью »
9 лет в монолите на Node.JS
2019-07-09 в 11:16, admin, рубрики: javascript, node.js, Анализ и проектирование систем, микросервисы, монолит, Разработка веб-сайтов
Неделю назад я выступал на митапе по Node.JS, и многим обещал выложить запись выступления. Уже потом я понял, что мне не удалось вместить в регламентированные полчаса некоторые интересные факты. Да и сам я больше люблю читать, а не смотреть и слушать, поэтому решил выложить выступление в формате статьи. Впрочем, видео тоже будет в конце поста в разделе ссылок.
Рассказать я решил про набившую оскомину тему — жизнь в монолите. Об этом на хабре уже есть сотни статей, тысячи копий сломаны в комментах, истина давно погибла в спорах, но… Дело в том, что у нас в OneTwoTrip есть весьма специфический опыт, в отличие от многих людей, которые пишут про некие архитектурные паттерны в вакууме:
- Во-первых, нашему монолиту уже 9 лет.
- Во-вторых, всю жизнь он провёл под хайлоадом (сейчас это 23 млн запросов в час).
- А в NaN-ых, мы пишем наш монолит на Node.JS, который за эти 9 лет изменился до неузнаваемости. Да, мы начинали писать на ноде в 2010, безумству храбрых поём мы песню!
Так что всякой специфики и реального опыта у нас довольно много. Интересно? Поехали!
Вечный вопрос технического долга
2019-06-18 в 7:03, admin, рубрики: архитектура, Блог компании Туту.ру, легаси, монолит, проект, разработка, сервис, управление проектами, управление разработкой
Это одно из самых крутых облегчений проекта. На картинке — график суммарного времени, затрачиваемого CPU на обработку всех пользовательских запросов. В конце видно переход на PHP 7.0. с версии 5.6. Это 2016 год, переключение во второй половине дня с 24 ноября.
Туту.ру с точки зрения вычислений — это в первую очередь возможность купить билет из точки А в точку Б. Для этого мы перемалываем огромное количество расписаний, собираем в кэш ответы множества систем авиакомпаний и периодически делаем невероятно длинные join-запросы к базе данных. В целом мы написаны на PHP и до недавних пор были полностью на нём (если язык правильно готовить, то можно даже строить на нём системы реального времени). С недавнего времени критичные по производительности участки стали рефакториться на Go.
У нас постоянно возникает технический долг. Причём это происходит быстрее, чем нам бы хотелось. Хорошая новость: его не надо закрывать весь. Плохая: по мере роста поддерживаемой функциональности техдолг тоже пропорционально растёт.
Вообще технический долг — это плата за ошибку при принятии решения. Вот ты что-то предсказал не так, как архитектор, то есть совершил ошибку прогнозирования или принимал решение в условиях недостаточной информации. В какой-то момент понимаешь, что надо что-то менять в коде (часто на уровне архитектуры). Дальше можно сразу поменять, а можно подождать. Если подождал — на техдолг набежали проценты. Поэтому хорошая практика — время от времени реструктуризировать его. Ну или признавать себя банкротом и писать весь блок заново. Читать полностью »