Как моделировать сервисы

Микросервисная архитектура (как и любая другая) должна обладать слабой связностью сервисов и сильным зацеплением внутри каждого сервиса.

Слабая связность — это когда можно легко внести изменения в один сервис, не трогая остальные. Чтобы этого достичь, нужно гарантировать, что каждый сервис знает о других только необходимый минимум.

Связанное поведение должно находиться в одном месте. То есть, все части внутри сервиса должны относиться к одной и той же области. Это сильное зацепление.

Делить сервисы по ограниченным контекстам (понятие Эрика Эванса из книжки DDD) — хорошая идея.

Обычно, системы проще начинать создавать как монолитные, а потом разбивать на микросервисы. Это связно с ценой ошибки. Если система была неудачно нарезана на ограниченные конктесты, перекроить модули внутри монолита дёшево, а переделать микросервисы — дорого.

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

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

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

​​Суббота начинается с дайджеста статей. Насладжайтесь.

+ О 30-кратном увеличении параллелизма в Node.js — отличная история рефакторинга, который сэкономил компании 300 тысяч долларов за год;

+ Делаем HTTP-запросы, изящно деградируем (и ни единого разрыва) — хорошая статья про аккуратную работу с сетью;

+ Чем программирование сегодня отличается от программирования 20 лет назад? — очередное размышление на тему плачевного состояния нашей индустрии, но в этот раз справедливое.

И еще три англоязычные статьи:

+ Goodbye, Clean Code — Дэн Абрамов рассказывает когда нужно и когда не нужно делать код «чистым»;

+ How to move your project to TypeScript - at your own pace — статья о постепенном переводе приложения на TypeScript без большой единовременной траты времени;

+ who are you trying to impress with your deadlines? (перевод) — критика необоснованных дедлайнов, замораживания состава спринта, очень актуальная тема.

#дайджест

Собрал книги, которые считаю обязательными к прочтению в единый список с краткими описаниями.

https://read.kamyshev.me

Ставьте звездочки на гитхабе, присылайте пулл-реквесты — igorkamyshev/mustread.

Интеграция

При выборе языка общения сервисов нужно обратить внимание на следующие характеристики:
+ возможность вносить не-ломающие изменения в протокол;
+ независимость протокола от языка (технологии);
+ сокрытие деталей реализации сервиса.

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

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

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

Какие софт-скилы нужны

Сейчас популярно мнение, что софт-скилы для разработчика супер-важны. Иногда, они даже важнее технический экспертизы. Есть две проблемы:
1. непонятно, какие скилы нужны;
2. непонятно, как их развивать;

Андрей Смирнов нашел интересный рецепт выбора самых важных навыков и сделал доклад The state of soft skills. Он классный, посмотрите.

#softskills

Сегодня дайджеста не будет, простите. Я в мини-отупске и не хотел его готовить. 🙄

Говорить в мире собеседника

Мой опыт работы начался с фриланса. Неотъемлемой частью было общение с заказчиками: сбор требований, согласование работы, решение проблем вроде сдвинутых сроков.

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

Объясню на примере. Представьте, что человеку нужно сделать сайт, а он в этом ничего не понимает. Он нанимает специалиста и в какой-то момент интересуется, как продвигается работа. Ему отвечают:

> У меня возникли проблемы с модулем кеширования страниц в WordPress, почитал StackOverflow, там рекомендуют обновиться до PHP 7, тем более в нём появились декларации типов, которые очень полезны в разработке. Я обновил PHP, но из-за этого пришлось решать проблемы с новым механизмом обработки ошибок. К счастью, как раз сегодня закончил с этим разбираться и доделал главную страницу, двигаюсь дальше!

Что из этого понятно заказчику:

> доделал главную страницу, двигаюсь дальше!

Иногда люди считают, что собеседник обладает не меньшими знаниями, чем они сами, и начинают грузить его ненужной, непонятной и часто страшно звучащей для него информацией. Ситуацию усугубляет ещё и часто сопутствующее этой проблеме неумение отвечать на поставленный вопрос.

Чтобы не совершать этих ошибок, можно пользоваться двумя приёмами:

1. Отвечать на вопросы максимально коротко, не погружаясь в детали. Собеседник при необходимости переспросит или уточнит важные ему детали.
2. В разговоре ставить себя на место собеседника и стараться оценить, будете ли вы ему понятны.

Это сильно упростит жизнь вам и всем, с кем вы будете разговаривать.

Заметил, что посты с конспектом книжки про микросервисы очень длинные. Напрягает?
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, я расскажу все что смогу.

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