Заметил, что посты с конспектом книжки про микросервисы очень длинные. Напрягает?
anonymous poll

Нет – 187
👍👍👍👍👍👍👍 89%

Да – 23
👍 11%

👥 210 people voted so far.

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

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

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

Для синхронного взаимодействия сервисов есть много вариантов, два самых популярных — 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 — вводная статья по основным понятиям девопса, стоит читать, если совсем не понимаете о чем речь.

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

#дайджест