
Есть 100500 способов и инструментов создать простого serverless чат-бота для телеграм. А наш все-равно будет проще, хотя бы по числу кликов в интерфейсе. Сам бот будет написан на Python, а выполнятся будет на serverless движке Swifty.
Микросервисная архитектура и все что с ней связано
В этой статье я опишу использование Go kit, набора инструментов и библиотек для создания микросервисов на Go. Эта статья — введение в Go kit. Первая часть в моем блоге, исходный код примеров доступен здесь.
Компания Zfort Group приняла решение не продлевать корпоративную подписку на Хабре.
Но есть и хорошие новости:
Мы бы хотели анонсировать запуск обновленного сайта zfort.com.ua, кратко рассказать о некоторых технических особенностях создания сайта, а также сообщить о решении перенести публикацию дайджестов с Хабра в блог нового сайта. В блоге нашего нового сайта мы продолжим публиковать дайджесты, статьи и анонсировать профессиональные митапы. На все обновления и публикации можно подписаться, чтобы быть в курсе и ничего не пропустить.
Краткая версия дайджестов также останется и на Хабре, но будет публиковаться не в корпоративном блоге Zfort Group, а с аккаунта alexzfort.
Одна из целей, которую мы ставили перед собой — обновить наш сайт, направленный на локальную аудиторию, сделать его быстрым и легким. Дополнить сайт разделами для отображения актуальных новостей компании, анонсов проводимых мероприятий и публикации дайджестов/статей в короткие сроки с максимальной гибкостью и возможностью для расширения.
А теперь подробнее о деталях создания обновленного сайта zfort.com.ua
При разработке и использовании распределенных систем перед нами возникает задача контроля целостности и идентичности данных между системами — задача реконсиляции.
Требования, которые выставляет заказчик — минимальное время данной операции, поскольку чем раньше расхождение будет найдено, тем легче будет устранить его последствия. Задача заметно усложняется тем, что системы находятся в постоянном движении (~ 100 000 транзакций в час) и добиться 0% расхождений не получится.
Привет, Хабр! Представляю вашему вниманию перевод статьи "Pattern: Saga" автора Chris Richardson.
Есть приложение, к которому применялся паттерн Database per Service. Теперь у каждого сервиса приложения есть своя собственная база данных. Некоторые бизнес транзакции охватывают сразу несколько сервисов, так что нужен механизм, обеспечивающий согласованность данных между этими сервисами.
Например: давайте представим, что мы разрабатываем интернет магазин, где у клиента есть кредитный лимит. Приложение должно гарантировать, что новый заказ не превышает кредитный лимит клиента. Так как Заказы и Клиенты — различные базы данных, то приложение не может использовать локальные ACID транзакции.
Как обеспечить согласованность данных между сервисами?
Необходимо каждую бизнес транзакцию, которая охватывает несколько сервисов, реализовывать как сагу.
Сага представляет собой набор локальных транзакций. Каждая локальная транзакция обновляет базу данных и публикует сообщение или событие, инициируя следующую локальную транзакцию в саге. Если транзакция завершилась неудачей, например, из-за нарушения бизнес правил, тогда сага запускает компенсирующие транзакции, которые откатывают изменения, сделанные предшествующими локальными транзакциями.
Привет, меня зовут Максим, я системный администратор. Три года назад мы с коллегами начали переводить продукты на микросервисы, а в качестве платформы решили использовать Openstack, и столкнулись с некоторым количеством неочевидных граблей при автоматизации тестовых схем. Этот пост про нюансы настройки OpenStack, которые с трудом находятся на пятой странице выдачи поисковика (а лучше, чтобы легко находились на первой).
Нагрузка на ядра: было — стало
В некоторых инстансах мы используем dualstack. Это когда виртуальная машина получает сразу два адреса — IPv4 и IPv6. Сначала мы сделали так, что «плавающий» v4-адрес назначался во внутренней сети через NAT, а v6 машина получала через BGP, но с этим есть пара проблем.
NAT — дополнительный узел в сети, где и без него нужно следить за нормальным распределением нагрузки. Появление NAT в сети почти всегда ведёт к сложностям с отладкой — на хосте один IP, в базе другой, и отследить запрос становится сложно. Начинаются массовые поиски, а разгадка всё равно будет внутри OpenStack.
Ещё NAT не позволяет сделать нормальную сегментацию доступов между проектами. У всех проектов свои подсети, плавающие IP постоянно мигрируют, и с NAT управлять этим становится решительно невозможно. В некоторых инсталляциях говорят об использовании NAT 1 в 1 (внутренний адрес не отличается от внешнего), но это всё равно оставляет лишние звенья в цепочке взаимодействия с внешними сервисами. Мы пришли к мнению, что для нас лучший вариант — это BGP сеть.
Про фреймворк micronaut я мельком вычитал из дайджест рассылок. Заинтересовался, что за зверь такой. Фреймворк ставится в противовес напичканному всем нужным инструментарием Spring.
Предвосхищая грядущую конференцию для разработчиков, где как раз будут рассказывать и показывать, как использовать micronaut в ваших этих микросервисах, я решил хоть раз подготовиться и прийти хоть с каким-то контекстом в голове, с неким набором проблем и вопросов. Выполнить так сказать домашнее задание. Я решил налабать какой-нибудь небольшой pet-project за пару-тройку вечеров (как пойдёт). В конце статьи будет ссылка на репозиторий всех исходников проекта.
Так как я заметил, что ты, Цезарь, уже много построил и продолжаешь строительство, я разработал определенные правила, чтобы ты сам смог оценить качество как уже существующих, так и будущих зданий.
Витрувий, архитектор времен Римской империи
Итак, как наверняка все знают, совсем недавно 1-2 октября в Москве в “Инфопространстве” прошёл DevOpsConfRussia2018. Для тех кто не вкурсе, DevOpsConf — профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации.
Наша компания также приняла участие в этой конференции. Мы являлись её партнерами, представляя компанию на нашем стенде, а также провели небольшой митап. К слову это было первое наше участие в подобном роде деятельности. Первая конференция, первый митап, первый опыт.
О чём мы рассказывали? Митап был на тему “Бэкапы в Kubernetes”.
Скорее всего услышав это название, многие скажут: “А зачем бэкапить в Kubernetes? Его не нужно бэкапить, он же Stateless”.