Микросервисы *

Какое-то время назад появилась возможность уделить внимание языку Go и удачно на глаза попалась публикация «Паспортный контроль, или Как сжать полтора гигабайта до 42 мегабайт» . В статье кратко, но информативно, рассказывается о тестовой задаче по разработке сервиса проверки номеров российских паспортов на предмет наличия их в списке недействительных паспортов.  Среди основных требований к реализации – это скорость проверки и доступность сервиса.  

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

Кроме того, в упомянутой выше статье затронуты вопросы эффективной, с точки зрения памяти, организации битовых массивов (bitmap). И эта тема достаточно актуальна и востребована в разных прикладных решениях, например, в виде bitmap-индексов для СУБД.

Итак, есть желание посмотреть на новый для себя язык Go, есть интересная проблематика в виде организации и использования bitmap, есть практическое применение, на котором эти две задачи можно отработать. 

Около 3х лет занимаюсь разработкой микросервисов, однако изначального понимания подходящего стека технологий у меня не было. Испробовал множество различных подходов(одними из которых были OpenDDS и apache-thrift), но в конце концов остановился на RestApi.

RestApi общается по средствам HTTP-запросов, которые в свою очередь представляют структуру данных из заголовков и тела запроса передаваемые через сокет. Первым на что я обратил внимание это boost/asio который предоставляет tcp-сокеты, но тут возникают сложности с объемами разработки:

Недавно команда, занимающаяся портированием Spring на GraalVM, выпустила первый крупный релиз - Spring Native Beta. Вместе с создателями GraalVM они смогли пофиксить множество багов как в самом компиляторе так и спринге. Теперь у проекта появилась официальная поддержка, свой цикл релизов и его можно щупать.

Меня зовут Николай Первухин, я Senior Java Developer в Райффайзенбанке. Так сложилось, что единожды попробовав бизнес-процессы на Camunda, я стал адептом этой технологии и стараюсь ее применять в проектах со сложной логикой. Действительно сама идея подкупает: рисуешь процесс в удобном GUI-редакторе (моделлере), а фреймворк выполняет эти действия последовательно, соблюдая большой спектр элементов нотации BPMN.  

К тому же в Camunda есть встроенная поддержка еще одной нотации — DMN (Decision Model and Notation): она позволяет в простой и понятной форме создавать таблицы принятия решений по входящим наборам данных.

Но чего-то все же не хватает... Может, добавим немного скорости?

Всем привет! Я Иван, старший инженер-тестировщик в КРОК. Уже 6 лет занимаюсь тестированием ПО. Из них 3 года внедряю автоматизацию тестирования на различных проектах - люблю всё автоматизировать. На рабочей машине много разных “батников” и bash-скриптов, которые призваны упрощать жизнь.

Недавно у нас стартовал проект по модернизации и импортозамещению системы электронного документооборота (СЭД) в одной крупной организации. Система состоит из основного приложения и двух десятков микросервисов, в основном - для построения отчётов и интеграции с другими подсистемами. Сейчас в проекте уже настроено больше 100  автотестов, и они сильно помогают при частых релизах, когда времени на регресс почти нет. Весь набор автотестов выполняется примерно за 25 минут, в среднем экономим до 3,5 часов ручной работы при каждом запуске. А запускаем мы их каждый день.

Дальше будет про то, как мы выбирали технологии и инструменты, какой  каркас и подход к организации автотестов в итоге получился. И почему мы в КРОК решили тиражировать этот подход в других проектах, реализация которых основана на Content Management Framework (CMF) под СЭД. На базе CMF у нас есть комплексное решение для автоматизации процессов документооборота КСЭД 3.0. Конечно, отдельные решения по автотестам можно применять под любую СЭД.

Ещё расскажу про проблемы, и как мы их решали. Пост будет интересен и полезен, если в ваших автотестах необходимо подписывать документ электронной подписью (ЭП) в докер-образе браузера, проверять содержимое pdf файла, выполнять сравнение скриншотов или интегрироваться с одной из популярных Test Management System.

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

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

Spring Boot — это быстрый способ создания микросервисов на Java. В этой статье мы рассмотрим, как улучшить производительность Spring Boot-микросервиса.

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

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

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

После ряда успешных (и не очень) проектов по развертыванию фреймворков на корпоративных инфраструктурах и в облаке, была сформулирована концепция фреймворка FaaS (Function as a Service). Его задача – обеспечить запуск приложений в контейнерах без сохранения состояния. Это дает разработчикам возможность сконцентрироваться на самом коде, а не на управлении сложной инфраструктурой и связанными с ней ресурсами. Это привело к изобретению бессерверной архитектуры, ориентированной исключительно на исполнение двоичных файлов приложений, при этом все необходимые ресурсы управляются сторонним провайдером и принадлежат ему. По своей сути бессерверная архитектура позволила предприятиям не только сильнее сосредоточиться на разработке основных приложений, но и существенно снизить накладные расходы.

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

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

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

Продолжаем рассказывать про feature flags (FF) – переключатели в коде, которые запускают и деактивируют функции продукта. На этот раз хотим вам рассказать про наше решение – портал фиче-флагов, который  позволяет бизнес-заказчикам управлять состоянием FF, а значит функциональностью продукта.

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

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

Всем привет! Меня зовут Алексей, я архитектор по клиентским решениям. Хочу рассказать о новой платформе «Пятёрочки» по работе с обращениями клиентов. 

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

Привет, Хабр! Меня зовут Антон. Примерно год назад я начал работать с Serverless — и был покорён этим подходом к разработке приложений. Несмотря на определённые недостатки и ограничения, потенциал бессерверных вычислений огромен, за ними большое будущее. Очень приятно, что честь стать первым куратором хаба Serverless выпала именно мне. Мои задачи — находить интересные материалы, показывать новые возможности и помогать тем, кто интересуется этой архитектурой. В первом посте я собрал статьи разных авторов с Хабра, которые знакомят с идеей Serverless- подхода и помогают разобраться, для чего её лучше всего применять.

Преподаватели Skyeng не сразу попадают «на передовую» — для начала они проходят отбор и обучение. Направление найма и онбординга преподавателей появилось в 2015 году — тогда же был сделан первый коммит в наш (уже бывший) легаси-монолит. Прежняя команда активно его поддерживала и старалась развивать, но в один момент ей стало объективно сложно справляться со всеми проектами. Так появилась моя команда.

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

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

Привет Хабр, на связи Иван Большаков — архитектор интеграционных решений, эксперт департамента разработки ПО КРОК. Я расскажу, как мы делали интеграционный слой для CRM-системы группы контакт-центров торговой сети Пятерочка.

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

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

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

Эту часть работы мы сейчас и автоматизировали в рамках отдельного микросервиса AReS – от Account Registration Service. Он умеет заводить в AD новых пользователей, отправлять им письма с регистрационной информацией, напоминать о необходимости придумать пароль. Это законченный компонент, и его можно копировать практически в любой продукт.

Архитектура процесса

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

Микросервис — это структурная единица, в которой все данные и функции, относящиеся к какой-нибудь одной конкретной бизнес-цели, объединены в один сервис.

Что ж, это достаточно общее понимание микросервиса, но что мы на самом деле под ним подразумеваем?

Для примера мы можем взять конструктор Lego, да, вы не ослышались, Lego.

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

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

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

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

При автоматизации сложного бизнес-процесса в продукте может быть задействовано сразу несколько микросервисов. И если в монолите выстроить взаимодействие нескольких модулей довольно просто, то в распределённой архитектуре, где каждый такой компонент – это отдельное приложение, возникают трудности.

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

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

Для разработчиков не секрет, что создание нового сервиса влечет за собой немало рутиной настройки: билд скрипты, зависимости, тесты, docker, k8s дескрипторы. Раз мы выполняем эту работу, значит текущих шаблонов IDE недосточно. Под катом мои попытки автоматизировать все до одной кроссплатформенной кнопки "сделать хорошо" сопровождаемые кодом, примерами и финальным результатом.

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