В последнюю субботу февраля нас ждет обзор главных событий и явлений в мире PHP в 2020-м и 2021-м, пара докладов и розыгрыш притяных и полезных мелочей для разработчика.
Выложили интреграцию Sentry с gRPC на GitHub
В декабре Андрей Перепёлкин выпустил статью «Разработка, сборка, деплой и мониторинг сервисов: от общего к частному и обратно». В ней рассказал об организации разработки микросервисов так, чтобы вынести инфраструктуру из продуктового проекта и управлять ей отдельно. О том, как создали общее поле разработки для независимых команд и как выстраиваем микросервисы в инфраструктуру, собираем метрики и логи, не загружая этим разработчиков.
Мы использовали различные опенсорс-решения для работы, но в части развития инфраструктурных модулей делали свои стартеры. Например, интрегрировали Sentry с gRPC.
Такой интеграции не было в опенсорсе, поэтому выложили всё в публичный доступ на GitHub. Пользуйтесь, если для вас это тоже актуально.
23 апреля — бесплатная IT-конференция BeeTech Conf 2.0
Привет! 23 апреля состоится BeeTech Conf 2.0 — ежегодная IT-конференция от Beeline Казахстан для инженеров, разработчиков, product-менеджеров, QA-специалистов, agile-коучей, скрам-мастеров и других dev-специалистов.
Будет 4 потока — Engineering, Big data, Product management и Agile. Более 30 спикеров, доклады middle+ и senior-уровня и панельные дискуссии.
Все это в online-формате и доступно IT-специалистам со всех уголков Казахстана и СНГ. Регистрация на конференцию тут: ссылка на регистрацию.
gRPC — фреймворк от Google для удалённого вызова процедур
Tutorial
В деле удалённого вызова процедур дела уже давно обстоят в точности как в известном комиксе «14 стандартов» — чего только тут ни напридумано: древние DCOM и Corba, странные SOAP и .NET Remoting, современные REST и AMQP (да, я знаю, что кое-что из этого формально не RPC, для того чтобы обсудить терминологию даже вот специальный топик недавно создали, тем ни менее всё это используется как RPC, а если что-то выглядит, как утка и плавает, как утка — ну, вы в курсе).
И конечно же, в полном соответствии со сценарием комикса, на рынок пришел Google и заявил что вот теперь наконец он создал ещё один, последний и самый правильный стандарт RPC. Google можно понять — продолжать в 21-ом веке гонять петабайты данных по старому и неэффективному HTTP+REST, теряя на каждом байте деньги — просто глупо. В то же время взять чужой стандарт и сказать «мы не смогли придумать ничего лучше» — совершенно не в их стиле.
Поэтому, встречайте, gRPC, что расшифровывается как «gRPC Remote Procedure Calls» — новый фреймворк для удалённого вызова процедур от Google. В этой статье мы поговорим о том, почему же он, в отличии от предыдущих «14 стандартов» всё-таки захватит мир (ну или хотя бы его часть), попробуем собрать билд gRPC под Windows + Visual Studio (и даже не говорите мне, что инструкция не нужна — в официальной документации упущено штук 5 важных шагов, без которых ничего не собирается), а также попробуем написать простенький сервис и клиент, обменивающиеся запросами и ответами.
Сервисы на Go в Badoo: как мы их пишем и поддерживаем
Блог компании Badoo Высокая производительность *Программирование *Анализ и проектирование систем *Go *
Написать сетевой сервис на Go очень просто: в стандартной библиотеке есть куча инструментов, а если чего-то и не хватает, то на Github есть много модных библиотек для удовлетворения большинства нужд.
Но что, если необходимо написать с десяток разных сервисов, работающих в одной инфраструктуре?
Если каждый демон будет использовать все свежие разнообразные «смузи»-технологии, получится «зоопарк», который сложно и дорого поддерживать, не говоря уже о добавлении в них новой функциональности.
У нас в Badoo крутятся >30 самописных демонов, написанных на разных языках, и ~10 из них – на Go. Все эти демоны работают на порядка 300 серверах. Как мы к этому пришли, не получив в итоге «зоопарк», как админы с мониторингом умудряются спать спокойно, не ограничивая при этом никого в смузи, а девелоперы, QA и релизеры живут дружно и до сих пор не переругались – читайте под катом.
Как перейти на gRPC, сохранив REST
Tutorial
Многие знакомы с gRPC — открытым RPC-фреймворком от Google, который поддерживает 10 языков и активно используется внутри Google, Netflix, Kubernetes, Docker и многими другими. Если вы пишете микросервисы, gRPC предоставляет массу преимуществ перед традиционным подходом REST+JSON, но на существующих проектах часто переход не так просто осуществить из-за наличия уже использующихся REST-клиентов, которые невозможно обновить за раз. Нередко общаясь на тему gRPC можно услышать "да, мы у нас в компании тоже смотрим на gRPC, но всё никак не попробуем".
Что ж, этой проблеме есть хорошее решение под названием grpc-rest-gateway, которое занимается именно этим — автогенерацией REST-gRPC прокси с поддержкой всех основных преимуществ gRPC плюс поддержка Swagger. В этой статье я покажу на примере как это выглядит и работает, и, надеюсь, это поможет и вам перейти на gRPC, не теряя существующие REST-клиенты.
Асинхронные режимы фреймворка gRPC и принципы их работы в С++
Из песочницы
Однажды мы с нашей командой решили попробовать gRPC для своих задач. После некоторых обсуждений, пришли к выводу, что будем использовать асинхронные клиент и сервер. Однако, под рукой оказался рабочий пример из документации только для одного режима. Примеры остальных режимов взаимодействия, основные принципы работы асинхронных операций, принципы работы асинхронного сервера и клиента в gRPC и многое другое под катом.
Дружим gRPC с долгоживущим проектом, PHP и фронтендом
Пару лет назад мы достаточно спокойно работали нашей небольшой командой и делали хостинг. Вышло так, что каждый сервис в системе обладал собственным уникальным и неповторимым API. Но потом это стало проблемой и было решено все переделать.
Мы расскажем о том, как объединить внешнее API с внутренним и что делать, если у вас много кода на PHP, но хочется воспользоваться преимуществами gRPC.
NGINX и gRPC теперь настоящие друзья
Несколько дней назад зарелизилась новая версия Nginx — 1.13.10. Главная фича данного релиза — это нативная поддержка проксирования HTTP/2, и, как следствие, gRPC.
Twirp против gRPC. Стоит ли?
Если вы используете микро-сервисную архитектуру, то скорее всего знаете, что накладные расходы на коммуникацию между сервисами часто становятся значительной проблемой и если Вы сталкивались с этой проблемой, то скорее всего начали использовать один из RPC фреймворков поверх Protobuf, например, gRPC от Google или Go-Kit от Peter Bourgon или что-то другое. Пересказывать что это и как этим пользоваться нет смысла, все достаточно хорошо описано до меня. Я сам активно использую gRPC в своих проектах, но тут Twich решил выпустить свою реализацию protobuf Twirp. Если Вам интересно, зачем им это было нужно или чем она отличается проходите под кат.
Qt обертка вокруг фреймворка gRPC в C++
Всем привет. Сегодня мы рассмотрим, как можно связать фреймворк gRPC в C++ и библиотеку Qt. В статье приведен код, обобщающий использование всех четырех режимов взаимодействия в gRPC. Помимо этого, приведен код, позволяющий использовать gRPC через сигналы и слоты Qt. Статья может быть интересна в первую очередь Qt разработчикам, заинтересованных в использовании gRPC. Тем не менее, обобщение четырех режимов работы gRPC написано на C++ без использования Qt, что позволит адаптировать код разработчикам, не связанных с Qt. Всех заинтересовавшихся прошу под кат.
7 сентября, Екатеринбург — митап для .NET-разработчиков
Привет, Хабр!
Мы решили организовать очередной митап. На этот раз — в Екатеринбурге и для .NET-разработчиков.
В рамках митапа наши ребята расскажут о том, что и как делается на .NET и C# в Альфа-Банке, поговорят о разработке в целом и поведают о нашем сообществе разработчиков.
Также среди спикеров — коллега из СКБ Контур.
Темы докладов и ссылка на регистрацию — под катом.
Мы решили организовать очередной митап. На этот раз — в Екатеринбурге и для .NET-разработчиков.
В рамках митапа наши ребята расскажут о том, что и как делается на .NET и C# в Альфа-Банке, поговорят о разработке в целом и поведают о нашем сообществе разработчиков.
Также среди спикеров — коллега из СКБ Контур.
Темы докладов и ссылка на регистрацию — под катом.
Построение микросервисной архитектуры на Golang и gRPC, часть 1
Из песочницы
Tutorial
Введение в микросервисную архитектуру
Часть 1 из 10
Адаптация статей Ewan Valentine.
Это серия из десяти частей, я постараюсь раз в месяц писать про построение микросервисов на Golang. Я буду использовать protobuf и gRPC в качестве основного транспортного протокола.
Стек, который я использовал: golang, mongodb, grpc, docker, Google Cloud, Kubernetes, NATS, CircleCI, Terraform и go-micro.
Зачем мне это? Поскольку мне потребовалось много времени, чтобы разобраться в этом и решить накопившиеся проблемы. Так же я хотел поделиться с вами тем, что я узнал о создании, тестировании и развертывании микросервисов на Go и другие новые технологии.
В этой части, я хочу показать основные концепции и технологии для построения микросервисов. Напишем простую реализацию. В проекте будут следующие сущности:
- грузы
- инвентарь
- суда
- пользователи
- роли
- аутентификация
Фреймворк Автоматизации Морских Перевозок (SAF)
Из песочницы
Александр Гусятинер, Олег Жихарев
ВВЕДЕНИЕ
Фреймворк Автоматизации Морских Перевозок (SAF)
Sea-Freight Automation Foundation (SAF)
Версия 0.2, 04 Октября 2018
Текущая модель информационного сопровождения транспортных процессов может быть охарактеризована следующим образом:
Ручное управление процессами, ручное выполнение задач и повторный ввод данных.
Большинство бизнес-процессов, включая те процессы, которые повторяются регулярно и не требуют принятия сложных решений, полностью контролируются и выполняются людьми. В процессе выполнением различных логистических контрактов, персонал рутинно совершает телефонные звонки, пользуется электронной почтой, повторно вводит данные в различные веб-формы, отслеживает грузы в различных онлайн платформах, документирует выполнение договоров и так далее.
Courier: миграция Dropbox на gRPC
Блог компании Badoo Высокая производительность *Разработка веб-сайтов *Программирование *Серверная оптимизация *
Перевод
Примечание переводчика
Большинство современных программных продуктов не являются монолитными, а состоят из множества частей, которые взаимодействуют друг с другом. При таком положении дел необходимо, чтобы общение взаимодействующих частей системы происходило на одном языке (притом что сами эти части могут быть написаны на разных языках программирования и выполняться на разных машинах). Упростить решение этой задачи помогает gRPC — open-source-фреймворк от Google, выпущенный в 2015 году. Он решает сразу ряд проблем, позволяя:
- использовать язык Protocol Buffers для описания взаимодействия сервисов;
- генерировать программный код на основании описанного протокола для 11 разных языков как для клиентской части, так и для серверной;
- реализовать авторизацию между взаимодействующими компонентами;
- использовать как синхронное, так и асинхронное взаимодействие.
gRPC показался мне довольно интересным фреймворком, и мне было интересно узнать про реальный опыт компании Dropbox по построению системы на его основе. В статье есть масса деталей, связанных с использованием шифрования, построением надёжной, наблюдаемой и производительной системы, процессом миграции со старого RPC-решения на новое.
Дисклеймер
Оригинальная статья не содержит описания gRPC, и некоторые моменты могут показаться вам непонятными. Если вы не знакомы с gRPC или другими подобными фреймворками (например, Apache Thrift), рекомендую предварительно ознакомиться с основными идеями (достаточно будет прочитать две небольшие статьи с официального сайта: «What is gRPC?» и «gRPC Concepts»).
Спасибо Алексею Иванову aka SaveTheRbtz за написание оригинальной статьи и помощь с переводом трудных мест.
Спасибо Алексею Иванову aka SaveTheRbtz за написание оригинальной статьи и помощь с переводом трудных мест.
Иногда больше — это меньше. Когда уменьшение нагрузки приводит к увеличению задержки
Перевод
Как и в большинстве постов, появилась проблема с распределённой службой, назовём эту службу Элвин. На этот раз я не сам обнаружил проблему, мне сообщили ребята с клиентской части.
Однажды я проснулся от недовольного письма из-за больших задержек у Элвина, которого мы планировали запустить в ближайшее время. В частности, клиент столкнулся с задержкой 99-го процентиля в районе 50 мс, намного выше нашего бюджета задержки. Это было удивительно, так как я тщательно тестировал сервис, особенно на задержки, ведь это предмет частых жалоб.
Прежде чем отдать Элвина в тестирование, я провёл много экспериментов с 40 тыс. запросов в секунду (QPS), все показали задержку менее 10 мс. Я готов был заявить, что не согласен с их результатами. Но ещё раз взглянув на письмо, я обратил внимание на что-то новое: я точно не тестировал условия, которые они упомянули, их QPS был намного ниже, чем мой. Я тестировал на 40k QPS, а они только на 1k. Я запустил ещё один эксперимент, на этот раз с более низким QPS, просто чтобы ублажить их.
Однажды я проснулся от недовольного письма из-за больших задержек у Элвина, которого мы планировали запустить в ближайшее время. В частности, клиент столкнулся с задержкой 99-го процентиля в районе 50 мс, намного выше нашего бюджета задержки. Это было удивительно, так как я тщательно тестировал сервис, особенно на задержки, ведь это предмет частых жалоб.
Прежде чем отдать Элвина в тестирование, я провёл много экспериментов с 40 тыс. запросов в секунду (QPS), все показали задержку менее 10 мс. Я готов был заявить, что не согласен с их результатами. Но ещё раз взглянув на письмо, я обратил внимание на что-то новое: я точно не тестировал условия, которые они упомянули, их QPS был намного ниже, чем мой. Я тестировал на 40k QPS, а они только на 1k. Я запустил ещё один эксперимент, на этот раз с более низким QPS, просто чтобы ублажить их.
Построение микросервисной архитектуры на Golang и gRPC, часть 2 (docker)
Tutorial
Пришло время заняться контейнерами
Прежде всего, мы используем новейший образ Linux Alpine. Linux Alpine — это легкий дистрибутив Linux, разработанный и оптимизированный для запуска веб-приложений в Docker. Другими словами, Linux Alpine обладает достаточным количеством зависимостей и функциональных возможностей для выполнения большинства приложений. Это означает, что размер образа составляет около 8 МБ!
По сравнению с, скажем… виртуальной машиной Ubuntu объемом около 1 ГБ, вот почему образы Docker стали более естественным образом подходить для микросервисов и облачных вычислений.
Итак, теперь я надеюсь, что вы видите ценность в контейнеризации, и мы можем начать «Dockerising» нашего первого сервиса. Давайте создадим Dockerfile $ touch consignment-service/Dockerfile.
Как создать простой микросервис на Golang и gRPC и выполнить его контейнеризацию с помощью Docker
Из песочницы
Привет, Хабр! представляю вашему вниманию перевод статьи «Go, gRPC and Docker» автора Mat Evans.
Существует множество статей о совместном использовании Go и Docker. Создавать контейнеры, способные взаимодействовать с клиентами и между собой, очень легко. Далее следует небольшой пример того, как это делается на базовом уровне.
Существует множество статей о совместном использовании Go и Docker. Создавать контейнеры, способные взаимодействовать с клиентами и между собой, очень легко. Далее следует небольшой пример того, как это делается на базовом уровне.
Григорий Петров: работа с сетью в Ruby
28 сентября на конференции RubyRussia DevRel компании Evrone Григорий Петров расскажет о том, как общаются микросервисы. В сегодняшнем интервью Иван Соловьев поговорил с Григорием о теме его предстоящего выступления и не только об этом.
Расскажи о себе, чем ты занимаешься в Evrone?
Расскажи о себе, чем ты занимаешься в Evrone?
Просто еще одна Qt обертка для gRPC и protobuf
Не так давно я озадачился тем, что нет достаточно удобных и простых враппера и генератора для protobuf и gRPC, основанных и полностью совместимых с Qt. Натыкался на статьи, в т.ч. здесь, об обертках, но их использование мне показалось куда менее практичным, чем даже существующее С++ API.