В этой статье я опишу использование 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”.
Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).
Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.
Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.
Ситуация с распределенной базой обостряется, если компания пытается перейти на микросервисную архитектуру. Под катом я рассказываю, как обеспечить целостность данных в микросервисной архитектуре без распределенных транзакций и жесткой связности. (А в самом конце объясняю, почему выбрал для статьи такую иллюстрацию).
27 сентября мы провели второй митап «Орки тут» — про оркестрацию, автоматизацию и полевое применение CI/CD. В этом посте полные видео и таймкоды с важными местами из трех докладов.
Темы такие:
Что так притягивает разработчиков в микросервисах? За ними нет никакой революционной технологии, преимущества перед монолитом достаточно спорные. Только легкость, с которой современные инструменты разработки и развёртывания позволяют создать системы для запуска на тысячах серверов. Предлагаем проследить путь к настоящему моменту, когда разработка и развёртывание такой распределённой системы возможно силами одного разработчика. О том, как эволюционировали технологии виртуализации, какую роль сыграли Linux-контейнеры, Docker и Kubernetes, рассказывает Александр Трехлебов holonavt, корпоративный архитектор Промсвязьбанка, занимается разработкой ПО больше 15 лет. Начинал с C++, затем перешел на Java. В последнее время разрабатывал банковсковский бэкенд на платформе Spring Cloud.
