Варианты интеграции

При проектировании архитектуры нужно определиться, будет ли сервис работать синхронно или асинхронно. Это накладывает ограничения на доступные варианты интеграции сервисов. Синхронное общение сервисом основывается на механизме «запрос-ответ», асинхронное общение опирается на события.

Популярный тип интеграции сервисов — совместное использование базы данных. Это плохой путь. Все клиенты знают устройство базы данных, можно легко нарушить ее и сломать всех остальных потребителей (повышается связность сервисов). Любая логика завязанная на изменение данных должна дублироваться в каждом сервисе (снижается зацепление).

Для синхронного взаимодействия сервисов есть много вариантов, два самых популярных — RPC и REST. RPC — отличный вариант, нужно только выбрать подходящую реализацию и не завязываться на конкретные технологии, клиентские библиотеки создавать легко. REST — тоже хорошо, но сложнее создавать клиентские библиотеки (если придерживаться REST-философии).

Асинхронное взаимодействие сервисов обычно строится вокруг брокера сообщений. Но можно взять какой-нибудь протокол (например ATOM) и реализовать его самостоятельно. Асинхронное общение ведет к очень сложным решениям, поэтому нужно дважды подумать, прежде чем брать его как основной способ взаимодействия сервисов.

#микросервисы

​​Вот и джайджест.

+ СтрижПИ — в диком мире iOS-разработки новый фреймворк, обзор SwiftUI от Никиты Прокопова;

+ Композируй это — в ещё более диком мире Andoriod-разработки тоже новый фреймворк, снова обзор, снова от Никиты Прокопова;

+ Yarn 2 — с Prolog’ом и плагнплеями — краткий обзор революционного обновления классного менеджера пакетов для JS (в будущем, возможно вообще для любой экосистемы);

Пара статей на английском:

+ What I learned as a developer from accidents in space (перевод) — статья Андрея Ситника об ошибках космической индустрии, которые могут научить программистов чему-то полезному;

+ Writing JavaScript With Only Six Characters — история о волшебной системе приведения типов JS, которая позволяет сделать что угодно с помощью 6 символов;

#дайджест

Обретение навыков

Мне всегда казалось, что классическое программистское деление на junior-middle-senior достаточно бессмысленное: оно сильно разнится от компании к компании, конкретных критериев нет, часто превращается в инструмент вычисления зарплаты из опыта работы.

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

#рост

Общий код

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

#микросервисы

Джедайские техники

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

#softskills #сделывание

Решил написать заметку про генерацию трейс-айди в Node.js, пошел гуглить и наткнулся на куда более качественную статью.

Почитайте, очень хорошо рассказано — https://habr.com/ru/post/442452/

#js

Кстати, есть классная библиотека https://github.com/puzpuzpuz/cls-rtracer для удобной генерации trace-id в простых случаях.

Управление версиями

При разработке микросервисов стоит придерживаться семантического версионирования и контролировать ломающие изменения особенным образом.

Первый вариант — обеспечить функционирование конечных точек двух версий (например 1.5.3 и 2.0.0) в рамках одного сервиса и постепенно мигрировать клиентов на новую версию. В этом случае версию можно сообщать внутри URI (например, /v1/createUser/, /v2/createUser/), или, если используется HTTP, сообщать версию в заголовке запроса.

В крайних случаях можно запустить два отдельных сервиса (один с версией 1.5.3 и другой с версией 2.0.0), но тут возникают дополнительные сложности — маршрутизация клиентов, поддержание базы данных в консистентном состоянии. Такой путь стоит использовать, только если переезд с версии на версию занимает немного времени.

#микросервисы

Как пасти котов

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

Ханк Рейнвотер рассказывает о разных типах программистов (очень легко узнать себя 🤓), построении отношений с начальством, мотивации, деньгах. Обо всем, с чем мы сталкиваемся на работе каждый день.

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

#softskills #рост

​​Статьи этой недели:

+ Базовые принципы проектирования — инструкция, как создавать простые для понимания системы, отвечающие ожиданиям человека;

+ «Коллеги, дышите потише»: почему офисный шум сводит нас с ума — обсуждаем исследования — покажите эту статью коллегам и офис-менеджеру, если в офисе шумно;

+ Структура приложения — Сергей Сова рассказывает о методике раскладывания файликов по папкам во фронтенде, нужно прочесть, если обычно через пару месяцев после начала проекта обнаруживаете, что не понятно, где искать какой-то код;

И еще чуть-чуть на английском:

+ Algebraic Effects for the Rest of Us — Дэн Абрамов о алгебраических эффектах, пропустил эту статью когда она вышла, а зря, очень интересно;

+ Images done right: Web graphics, good to the last byte — ультимативный гайд по работе с изображениями в вебе;

+ Production Node Applications with Docker - 3 DevOps Tips for Shutting Down Properly — три простых правила для комфортного запуска Node.js приложений внутри Docker.

#дайджест

Пользовательские интерфейсы

Чтобы микросервисами пользоваться, нужен пользовательский интерфейс. Есть три пути.

Первый вариант самый простой — прямо из интерфейса вызывать нужные сервисы. Проблема в том, что часто сервисы предоставляют данные не совсем в том виде, который требуется интерфейсу.

Второй вариант — создать единый API-шлюз, который будет предоставлять всем интерфейсам удобные ендпонты. Но не ясно, кто должен отвечать за подобную структуру и как это поддерживать (она быстро станет слишком большой).

Третий путь — backend-for-frontend (BFF). Каждая команда разработки интерфейса (например, мобильного приложения) создаёт для себя API-шлюз и поддерживает его.

При двух последних вариантах, следует тщательно контролировать отсутствие логики в API-шлюзе.

#микросервисы

Интеграция сторонних систем

Во многих компаниях используется сторонние сервисы (например, CMS или CRM). С ними тоже нужно научиться интегрироваться. Просто и правильный путь — закрыть эту внешнюю систему своим фасадом, который будет контролировать все обращения к системе и предоставлять другим сервисам простой и привычный API.

#микросервисы

Внимание!

Скоро я ухожу из Самоката, поэтому нужен новый ведущий фронтендер на внутренние продукты. Это хорошая работа над интересными продуктами.

Тут можно прочитать больше подробностей, или просто напишите мне @igorkamyshev, я расскажу все что смогу.

Кейворды: Питер, офис, реакт, продукт, ритейл, кикер.

Разбиение монолита на части

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

Есть много причин разбить монолит. Одна из них — грядущие изменения. Если известно, что в один из ограниченных контекстов скоро будут вноситься серьёзные изменения, имеет смысл выделить его в сервис и получить простоту тестирования и развертывания. Другие популярные причины: особенные требования к безопасности отдельных частей; желание использовать альтернативную технологию в части системы.

#микросервисы

Разбиение монолита на части

При разделение монолита на части возникает проблема, что транзакции уровня базы данных становятся невозможны. Решение — распределенные транзакции. Этот механизм позволяет получить достаточно надежные транзакции для разделённых сервисов. А во многих случаях, стоит вовсе отказаться от транзакций и разработать самовостанавливающуюся систему (например, попытки записи могут повторяться несколько раз, пока не получится).

В микросервисной архитектуре не так просто реализовать отчеты. Мы не можем просто сделать большой запрос к единой базе данных и получить результат. Есть четыре варианта:
+ каждый сервис может слать свои данные для отчетов в сервис отчетов;
+ сервис отчетов может ходить к остальным сервисам за данными;
+ если сервисы общаются через события, то сервис отчетов может просто подписаться на эти события;
+ сервис отчетов может брать бекапы разных сервисов и генерировать отчеты на основе этих данных (так делает Netflix).

#микросервисы

Docker

Последнее время много пишу о микросервисах (потому что много читаю о микросервисах), а какие микросервисы в 2020 без докера?

Комрад нашел хороший базовый интреактивный туториал по контейнеризации приложений.

Learn Docker, Container Runtimes, Builders and Registries

#docker

Развертывание

Для комфортного развертывания микросервисов в компании должна быть внедрена непрерывная интеграция. Каждое вносимое изменение, должно подвергаться набору проверок (тесты, статические анализаторы) и постоянно попадать в основную сборку проекта. Ветки для изменений должны жить совсем не долго (день-два).

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

#микросервисы

Развертывание

Чтобы упростить доставку сервисов, нужно обеспечить единообразие способа развёртывания. Для этого можно взять систему управления конфигурациями, например Chef, Puppet или Ansible. Этот путь ведёт к нескольким проблемам — повторяемость сборки зависит от текущего состояния системы, подготовка занимает значительное время. Другой хороший вариант — создать артефакт для запуска на конкретной операционной системе, например deb-пакет. Но это приводит к сложностям с разными операционными системами. Чтобы избежать любых с совместимостью, можно распространять сервис в виде образа системы с подготовленным окружением для запуска в виртуальной машине. И тут есть трудности — образы много весят и долго делаются.

LXC-контейнеры — это лучший вариант для большенства задач. Но ими сложно управлять. Docker решает многие проблемы — управляет предоставлением контейнеров, справляется с некоторыми проблемами использования сетей, а чтобы решить остальные придумали Kubernetes.

#микросервисы

​​Суббота — время дайджеста 🥑

+ Что можно узнать о Domain Driven Design за 10 минут? — очень кратко о DDD, внутри ссылки на хорошие материалы;

+ Не надо заставлять, надо автоматизировать — Саша Беспоясов рассказывает о принуждении через удобство, обязательно прочтите;

И немножко статей на англйиском:

+ TechnicalDebt — статья Мартина Фаулера о том что такое технический долг и откуда он берется;

+ The Economics of Technical Debt — рассмотрение причин и последствий технического долга в проектах;

+ A Mess is not a Technical Debt — дядюшка Боб о том как отличить беспорядок от технического долга;

+ Programming Languages To Learn In 2020 To Boost Your Career As A Software Developer — программисты должны знать много языков программирование, автор рассказывает об интересных языках, на которые стоит обратит внимание;

+ The DevOps — вводная статья по основным понятиям девопса, стоит читать, если совсем не понимаете о чем речь.

Кстати, с этого дня дайджест будет выходить два раза в месяц. 🌟

#дайджест

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

Никаких Hello-MVC примеров, реальные задачи, реальные решения. Я не буду рассказывать о синтаксисе языков, о базовых правилах создания программ, за этим можно почитать книжки из списка маст-ридов. На вебинарах я буду делиться взглядом на разработку качественных приложений, опытом создания разных сервисов (и факапами тоже, кстати).