Под напором появления новых асинхронных неблокирующихся фреймворков может показаться, что блокирующиеся вызовы — это пережиток прошлого, и все новые сервисы нужно писать на полностью асинхронной архитектуре. В этом посте я расскажу, как мы решили отказаться от неблокирующих асинхронных вызовов бэкендов в пользу обычных блокирующих.Читать полностью »
Мы привыкли почему-то разделять REST и RPC, мне кажется это разделение искусственным. Просто REST строже и ограничен в методах, и это не всегда оправдано в сложном приложении.
Сделаем простую основу для написания сервисно-ориентированной архитектуры. Как стек технологий используем славный Yii2, быстрый Nginx и молниеносный Redis. Почему именно так, станет ясно позднее.
Для управления сущностями на примитивном уровне СREATE, UPDATE, DELETE, GET нам вполне достаточно Rest техники которая заложена в Yii2.
Для облегчения работы в сцепке Nginx + Redis, нам придется использовать немного нестандартный подход, то есть полностью передать как параметры: класс, метод и другие нужные параметры. Для валидации этой компании используем наипростейшую форму Yii2 Model (для экономии места проигнорируем code style):
Читать полностью »
MessagePack это эффективный сериализатор данных в бинарное представление.
Используя данную библиотеку вы можете обмениваться сообщениями между вашими компонентами системы подобно тому, как вы это делаете с помощью формата JSON. Интерпретация библиотеки существует для 44 языков программирования (!)
Читать полностью »
7 октября 2014 года в публичном доступе появились исходники Qt-модуля QtRemoteObjects. Модуль создан в недрах Ford Motor Company (автор Brett Stottlemyer). Вещь, на мой взгляд, очень перспективная. Модуль позволяет, например, передавать сигналы между объектами по сети. Но этим возможности модуля не ограничиваются. Более точно суть модуля описывает его предыдущее наименование — Replica, так как объекты «реплицируются» между процессами.
Ключевой идеей QtRemoteObjects, которая качественно отличает его от других способов межпроцессного взаимодействия/удаленного вызова процедур, является идея полностью продублировать Qt-объект в другие процессы. Это значит, что все изменения свойств (properties) в объекте — источнике отражаются (с уведомлением посредством сигналов) в объекте-реплике. Любые сигналы, которые эмитируются объектом-источником будут также эмитированы в каждом объекте-реплике. Также можно устанавливать свойства, вызывать слоты и в объекте-реплике, при этом запросы отправляются объекту-источнику, который их обрабатывает и затем изменения отражаются в других объектах-репликах посредством сигналов или с помощью изменения свойств. В результате все объекты (включая объект-источник) синхронизируются. При этом вся сложность межпроцессного взаимодействия скрыта внутри QtRemoteObjects.
Читать полностью »
В статье речь пойдет о технологии WebSocket. Точнее не о самой технологии, а о том, как ее можно использовать. Я давно слежу за ней. Еще когда в 2011 году один мой коллега прислал мне ссылку на стандарт, пробежав глазами, я как-то расстроился. Выглядело настолько круто, и я думал, что в момент, когда это появится в популярных браузерах, я уже буду планировать, на что потратить свою пенсию. Но все оказалось не так, и как гласит caniuse.com WebSocket не поддерживается только в Opera Mini (надо бы провести голосование, как давно кто-либо видел Opera Mini).
Кто трогал WebSocketы руками, тот наверняка знает, что работать с API тяжело. В Javascript API достаточно низкоуровневый (принять сообщение — отправить сообщение), и придется разрабатывать алгоритм, как этими сообениями обмениваться. Поэтому и была предпринята попытка упростить работу с вебсокетами.
Так и появился WSRPC. Для нетерпеливых вот простое демо.
Читать полностью »
Это не первая вводная статья про Impress на Хабре, но за последний год я получил много вопросов и приобрел некоторый опыт в объяснении архитектуры и философии этого сервера приложений и, надеюсь, стал лучше понимать проблемы и задачи разработчиков, начинающих его освоение. Да и в самом сервере произошло достаточно изменений, чтобы назрела актуальность совершенно новой вводной статьи.
Impress Application Server (IAS) — это сервер приложений для Node.js с альтернативной архитектурой и философией, не похожий на мэйнстрим разработки под нодой и призванный упростить и автоматизировать широкий круг повторяемых типовых задач, поднять уровень абстракции прикладного кода, задать рамки и структуру приложений, оптимизировать как производительность кода, так и производительность разработчиков. IAS покрывает сейчас только серверные задачи, но делает это комплексно, например, можно объединить на одном порту API, веб-сокеты, стриминг, статику, Server-Sent Events, проксирование и URL-реврайтинг, обслуживать несколько доменов и несколько приложений, как на одном сервере, так и на группе серверов, работающих в связке, как одно целое, как один сервер приложений.
Читать полностью »
В продолжение пятого урока по изучению азов RabbitMQ, публикую перевод шестого урока с официального сайта. Все примеры написаны на python (используется pika версии 0.9.8), но по-прежнему их можно реализовать на большинстве популярных ЯП.
Во втором уроке мы рассмотрели использование очередей задач для распределения ресурсоёмких задач между несколькими подписчиками.
Но что если мы захотим запустить функцию на удаленной машине и дождаться результата? Ну, это совсем другая история. Этот шаблон широко известен как Удаленный Вызов Процедур (Remote Procedure Call или RPC, далее в тексте RPC).
В этом руководстве мы построим, используя RabbitMQ, RPC систему, которая будет включать клиент и масштабируемый RPC сервер. Так как у нас нет реальной трудоемкой задачи требующей распределения, мы создадим простой RPC сервер, возвращающий числа Фибоначчи.
Читать полностью »
Мы проектировали агента для бекапов. Агент узнает у бекенда что бекапить и отправляет данные в хранилище. Злая врезка в канал и подмена адреса хранилища катастрофична.
HTTPS протестировали в первом подходе. Было ощущение, что можно сделать проще. Внутренние сервисы начинали масштабироваться по датацентрам. Хотелось сделать надежное решение для агента и внутренних сервисов. Без туннелей и HTTPS.
В итоге заменили HTTPS на net/rpc + crypto/tls.
Читать полностью »
Предоставляю вам краткий отчет об изменениях в Impress AS за последние несколько месяцев. Во-первых мы не пошли путем фреймворков, а ринулись в сферу серверов приложений, обеспечивая масштабирование в двух направлениях: (1) много приложений на одном сервере и (2) много серверов для одного приложения. Первое направление требовало развивать сендбоксинг (экранирования приложений друг от друга и от среды запуска), а второе направление предусматривало переход от кластера к многосерверному клауду. Тут нужно уточнить терминологию, в ноде кластером (cluster) принято называть способ многопоточного запуска приложений в режиме master/worker, поэтому, многосерверную инфраструктуру (с кластером на каждом сервере) мы будем нанывать клаудом (или прикладным облаком). Это облако ни как не связано с виртуализацией операционной системы, как это обычно ложно связывается в понимании широких масс. Облачные технологии совсем не обязаны быть организованы на базе технологий виртуализации, просто другого простого способа масштабирования сейчас для массового потребления нет. Облачная виртуализация не гарантирует бесконечной виртуализации прикладных приложений, и всем разработчикам крупных высоконагруженных систем известно, что для сотен тысяч и десятков миллионов пользователей нужно создавать специальные прикладные решения, обеспечивающие прикладную виртуализацию, размазывающую задачи по серверам и объединяю их в одну, распределенно функционирующую, но централизовано управляемую систему. Именно эту задачу мы и взялись решать в Impress, надеюсь я отстоял терминологию и могу переходить к подробностям.Читать полностью »
Это моя первая публикация на сем ресурсе, посему, прошу отнестись с пониманием к допущенным мною ошибкам.
RMI — весьма банальная задача для ЯП, поддерживающих интроспекцию. Но, С++, к сожалению, к ним не относится.
В данной публикации я хочу продемонстрировать возможность реализации весьма юзабильной RMI средствами С++ препроцессора.
1. Предоставить максимально простой синтаксис, чтоб невозможно было допустить ошибку.
2. Идентификация(связывание) процедур должна быть скрыта от пользователя для того, чтоб невозможно было допустить ошибку.
3. Синтаксис не должен накладывать ограничения на используемые С++ типы.
4. Должна присутствовать возможность версионности процедур, но, так, чтоб не ломалась совместимость с уже работающими клиентами.
Читать полностью »
