Поделимся личным опытом, как у нас получилось организовать взаимодействие микросервисов на Ruby и Go на основе gRPC. Мы расскажем:
- о преимуществах gRPC;
- об особенностях работы с протоколом;
- о трудностях, с которыми может столкнуться начинающий разработчик.
Привет, Хабр!
Микросервисы стали выбором многих благодаря их гибкости, масштабируемости и способности поддерживать сложные приложения в динамично меняющемся мире.
Но не всё так просто. Одной из ключевых проблем, с которыми сталкиваются при переходе от монолитных архитектур к микросервисным, является обеспечение согласованности данных.
Каждый сервис работает автономно, управляя своим собственным набором данных. Как гарантировать, что данные, распределенные по разным сервисам, будут консистентными? Как избежать потери данных и обеспечить их актуальность в реальном времени?
Возникла задача проверки нескольких типов пользовательских документов Excel. Проверка должна покрывать такие аспекты как корректность шаблона (наличие ожидаемых страниц, колонок таблиц) и корректность данных (присутствие обязательных значений, корректность значений точки зрения форматов, отсутствие дубликации, итд).
Пользователю нужно возвращать информацию "что не так с файлом": какую проверку не прошел файл и где конкретно в файле проблемные данные.
Эта задача - про качество данных и очень напоминает тестирование. Так почему не использовать фреймворк тестирования pytest, и не написать тесты на каждый проверяемый аспект и для каждого типа файлов? Однако, есть небольшое "но". проверка должна быть реализована в качестве сервиса, чтобы встраиваться в более широкий процесс обработки пользовательских документов.
Давайте посмотрим, как заставить pytest работать внутри сервиса. Это не так тривиально, как может показаться на первый взгляд.
Такие схемы на проектах готовят наши архитекторы. Достаточно ли их чтобы оценить состав и сложность каждого модуля, объем и трудоемкость работ в целом. Поможет ли такая схема при планировании работ?
В статье рассуждение о том что могло бы помочь.
Старые программы покрываются коркой сомнительных фич.
ls просто создаёт список файлов, cat просто выводит содержимое файлов, grep просто фильтрует данные, wc просто подсчитывает слова и так далее. У каждой программы есть несколько опций, меняющих её поведение, но не слишком сильно. Например: wc можно сконфигурировать для подсчёта строк или слов, но не для подсчёта количества абзацев или вхождений какой-то фразы.wc, если с этим уже способна справиться grep?
Познакомим вас с надстройками Kubernetes в платформе dBrain, большая часть которых - наши собственные разработки для отслеживания пограничных состояний кластеров K8s.
Хабр, привет! На связи Дмитрий Бадулин, я занимаюсь разработкой ПО в компании К2Тех. Корпоративная сервисная шина, или как это по-другому называется, интеграционная платформа — это отдельная боль для множества компаний. И сегодня в условиях, когда некоторые middleware-решения класса ESB перестали нормально работать в России, возникает новая волна спроса на проектирование системы обмена данными между множеством ИС. В их числе, разумеется, есть как красивые и удобные, которые легко интегрировать, так и кошмар интегратора, которые никак не хотят нормально работать.
В этой статье я расскажу о том, почему нам все-таки пришлось создавать нашу собственную корпоративную шину, как мы ее делали, а также поделюсь примерами ее использования.
Всем привет! Кратко обо мне: меня зовут Никита и я уже третий год работаю над тем, чтобы платформа СберМаркета становилась лучше день ото дня. Мой основной язык программирования — Go, но, учитывая специфику платформенной разработки, еще и bash.
В этой статье на примерах разберу, что мешает строить разработчикам надежные интеграции, попутно заглядывая в детали реализации нашей утилиты sbm-cli, шаблона микросервиса и CI/CD.
Задумывались ли вы, почему мы используем отдельную базу данных для каждого сервиса, но при этом один общий брокер для нескольких сервисов? Ведь вполне возможно использовать базу данных в роли брокера сообщений. Однако, если мы попробуем заменить RabbitMQ на Redis, то натолкнемся на проблему общего использования базы данных. Это станет проблемой, потому что общее использование базы данных является антипаттерном.
Привет, Хабр! Меня зовут Игорь Гербылев, я технический директор в компании Just AI. В этой статье я расскажу о методологии структурирования ansible-плейбуков, которую мы называем «Компонентный ансибл». Этот подход позволил нам упростить разработку и поддержку большого объёма ансибл-кода, который мы используем для настройки инфраструктуры и развёртывания наших SaaS продуктов.
Те, кто использует Helidon в проде, наверняка точно знают, зачем им это нужно. Что делать остальным? Основная задача хомячка — объяснить детям концепцию смерти. Кажется, точно так же основная задача Helidon для широких народных масс — посмотреть на самые новые фишки Java и понять, нужно вам это или нет. Посмотрим, что же произошло в версии 4.0.0...
Привет, Хабр! С вами Валентин, архитектор направления Backend компании SimbirSoft. В данной статье мы с коллегами поделимся опытом реализации большого и сложного проекта с микросервисной архитектурой, а также поговорим о роли архитектора в таких проектах.
Статья ориентирована на разработчиков различного уровня, управленцев, а также IT-специалистов, занимающихся построением архитектуры, в частности микросервисной. Надеемся, что материал будет полезен широкому кругу читателей, вне зависимости от специализации и компетенций.
Всем привет!
В прошлой статье была поставлена задача о надёжных мутациях и транзакциях в архитектуре Профи, в этой статье разберём один из вариантов решения — применить workflow-engine Temporal.
Почему микросервисы помогут вам ускорить поставку бизнес-ценности.
История появления микросервисов
В статье От микросервисного монолита к оркестратору бизнес-сервисов (укороченный вариант в видео) я рассматривал механизм эволюции IT-архитектуры и причины, которые подталкивают к изменениям от одной стадии к другой. Я бы хотел дополнительно погрузить вас в историю того, как и почему мы пришли к микросервисам.
Привет, меня зовут Максим Качинский, я ведущий DevOps-инженер в компании RocketData. Более 6 лет мы развиваем одноимённую платформу для управления репутацией — за это время она выросла с монолитного MVP на единственном сервере до 15+ микросервисов с пятью разными видами баз данных. И всё это в гибридной инфраструктуре.
Чем больше рос проект, тем сложнее нам было его поддерживать. Чтобы облегчить жизнь DevOps-инженерам, мы начали постепенно переходить на managed-решения. Но этот путь не был идеально прямым, и нам пришлось пересмотреть многие привычные рабочие инструменты.
В этом посте поделюсь нашим опытом: покажу, как мы используем Terraform, и расскажу, что стоит учесть при масштабировании гибридной инфраструктуры и переезде в облако.
Эта статья предназначена для новичков и рассматривает микросервис отправки писем через smtp Yandex с использованием .Net Web Api и MailKit. В ней будет рассмотрено, как настроить и использовать данный микросервис для отправки писем с помощью почтового сервиса через существующий почтовый ящик Яндекса.
Ссылки для понимания и работы
Дерево проекта:
При большом количестве микросервисов в проекте приходится сталкиваться с тем, что в некоторых из них нужно дублировать один и тот же код (утилитные классы, настройки конфигураций и прочее), а обнаружив баг в одном месте, искать и исправлять его везде. При этом, если микросервисы поддерживаются разными разработчиками, то каждый будет исправлять баг по-своему и в дальнейшем будет сложнее привести всё к единообразию. Давайте на примере рассмотрим несколько подходов к переиспользованию кода в микросервисах.
Разделяй и влавствуй, или как провести клининг легаси-кода GoLang.
Этот пост является частью большого цикла статей, в которых мы демонстрируем, как создавать приложения на Go, которые легко разрабатывать, поддерживать и с которыми приятно работать в долгосрочной перспективе. Мы делаем это, делясь проверенными методами, основанными на множестве экспериментов с командами, которыми мы руководили, и научных исследованиях («при съёмках фильма ни одно животное не пострадало»).
Мы убеждены, что для решения некоторых задач читов не существует. Поэтому, если вы хотите создавать сложные приложения быстро и эффективно, вам придётся потратить кусочек своей жизни на обучение этому. Будь это просто, в мире бы не было такого количества устаревшего кода.
Что касается подхода к «чистой» архитектуре, описываемого далее, то это симбиоз двух идей: разделение Ports и Adapters, а также контроль за тем, как пакеты ссылаются друг на друга...
Собрались как-то вместе: продакты, HR, лиды и архитекторы ИТ, и начали думать, как же им перестроить HR-процессы в Банке так, чтобы улучшить клиентский опыт сотрудников и им стало удобно работать с HR-услугами..
У нас была идея продуктового подхода, десяток backend систем, 23 приложения, 109 процессов и продуктов, 683 различных заявок. Но раз уж мы начали собирать все это под единый интерфейс, то надо идти в этом до конца.
Меня зовут Михаил Михеев. Я руководитель направления интеграций в одной из команд клиентского пути в Альфа Банке. В этой статье я поделюсь нашим опытом создания единого канала контакта с сотрудником, в условиях, когда «под «капотом» множество монолитных систем.
Ничего революционного в статье не будет, все применяемые нами технологии и подходы извести, но вот как именно мы их применили и что из этого получилось — об этом речь и пойдет.