Закон Конвея и проектирование систем

«Организации, проектирующие системы, неизбежно производят кон­струкцию, чья структура является копией структуры взаимодействия внутри самой организации»

Обычно, если каждым сервисом владеет конкретная команда, система в целом получается лучше, а её развитие происходит быстрее.

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

Смотрите, какое доброе дело сделали в Breadhead.

Особенно круто, что сделали всего за неделю. Кайф!

Сделали за неделю вместе с Фондом профилактики рака

Подробности:
https://www.facebook.com/100001590164849/posts/3084960454900263/?d=n

Надежность

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

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

При падении отдельных сервисов система в целом должна продолжать работать как можно дольше — деградировать изящно (graceful degradation).

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

Надежность

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

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

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

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

18 апреля 2020 в 14.00 МСК я проведу вебинар про DDD в Node.js. Три часа будем вместе делать небольшой сервис на Node.js, отвечу на вопросы. Всех участников добавлю в специальный чат, где можно будет продолжить обсуждение.

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

Что можно узнать о Domain Driven Design за 10 минут?
Очень краткая вводная статья по DDD. Стоит прочитать, чтобы понять основные концепции. Обратите внимание, там внизу много хороших ссылок.

Статья

Strategic Domain Driven Design for Improving Flutter architecture
Доклад про DDD в Flutter. На самом деле, он почти не связан с конкретной технологией, а скорее презентует общие подходы.

Запись, слайды

#ddd

Чтобы разобраться в этой теме глубже — приходите на вебинар 18 апреля 2020 в 14.00 МСК.

На этой неделе еще можно купить за 1200 рублей, в субботу цена вырастает до 1500.

Я уже тысячу раз говорил, что считаю жутко важным знать много языков программирования: просто для кругозора. Например, можно почитать крутую книгу «Семь языков за семь недель».

А если хочется быстро вкатиться в какой-то другой язык за ограниченное время, то вместо чтения документации можно обратиться к Learn X in Y Minutes: Scenic Programming Language Tours — это простой сборник шпаргалок по разным языкам.

#языки

​​Суббота, дайджест.

Две прекрасные статьи, которые с разных сторон смотрят на современные проблемы софта:

+ В софте всё восхитительно, но все недовольны — дисс на Никиту Прокопова и его «Разочарование в софте»

+ Продолжаем обобщать и передергивать — дисс на дисс


Ну и просто несколько хороших статей:

+ «Злые марсиане»: как российские разработчики помогают стартапам взлетать (и сколько они на этом зарабатывают) — про самый загадочный аутсорс

+ Краткий гайд о том, как нанимать нормальных людей — про нормальные собеседования для нормальных специалистов

+ The Elephant in the Architecture — про бизнес-вэлью как часть архитектуры программ

+ Знай своего врага: создаём Node.js-бэкдор — про опасности в npm-пакетах

#дайджест

Масштабирование

Вертикальное масштабирование — заменить сервер на более мощный. Способ решить проблему с производительностью в моменте. Но не работает на большой дистанции.

Горизонтальное масштабирование — запустить несколько экземпляров приложения на разных машинах и балансировать нагрузку между ними. Это правильный путь. Легко масштабировать стейт-лесс сервисы, но с базами данных все усложняется.

Для масштабирования базы данных на операции чтения обычно применяется довольно простая тактика — создается полная копия базы, которая доступна только для чтения (реплика), и часть запросов отправляется туда. Иногда данные становятся не согласованными. С этим сложно бороться.

Масштабировать базу данных на операции записи черезвычнайно сложно. Например, можно разделить узлы для записи разных данных.


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

Кеширование

Кешировать результаты можно на клиенте, можно в прокси-сервере, а можно на сервере:

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

+ если прокси-сервер управляет кешом, то инвалидировать этот кеш сложно всем, результат все равно не получается быстро, зато не нужно вносить никаких правок в код, достаточно просто вставить прокси между сервером и клиентов;

+ если сервер управляет кешом, то для клиента это незаметно, сервис легко управляет временем жизни кеша, но скорость его ответа не может быть меньше чем лаг сети.

В реальных проектах, обычно, используется все три варианта кеширования.

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

Кеширование

В HTTP встроен мощный механизм кеширования. Можно управлять временем жизни кеша через заголовки cache-control и expires и передавать серверу ETag для получения только новой версии ресурса. Если сервисы общаются по HTTP, то можно смело кешировать данные на стороне клиента, в протокол строен удобный инструментарий для этого.

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

Кеширование — это опасно. Можно легко накосячить (сообщить клиенту, что кеш вечный, например) и потом долго исправлять все это. Поэтому, нужно быть очень осторожным и стараться делать максимально простые для понимания системы кеширования.

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

Теорема CAP

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

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

🌚 всё, конспект "Создания микросервисов" закончился.

Это хорошая книга, она рассказывает о сложных и важных штуках. Такой, хай-енд контент.

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

Через пару недель я соберу конспект в одном месте, почищу и выложу в виде заметки.

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

Больше про CAP-теорему

Кстати, про теорему CAP есть отличный подкаст. Там Рахим рассказывает не только о сути, но и приводит простое доказательство.

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

#общие_знания

DDD в Node.js — уже в эту субботу!

Никаких Hello-MVC примеров, реальные задачи, реальные решения. За три часа мы вместе запилим небольшой сервис и оценим, почему он получился клёвым.

18 апреля 2020, 14.00 МСК, 1500 рублей.

Напоминаю, вебинар через три часа. Если вы хотели купить, но тянули — сейчас самое время 😇

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

+ Refactoring This class is too large — Мартин Фаулер на живом примере разбирает рефакторинг слишком большого класса

+ Как быть, если всё моё время уходит на разработку всё новых и новых фич? — как объяснить бизнесу необходимость уплаты технического долга

+ Архитектура для начинающих или почему не нужно вставлять флажок в человека-меча — простая вводная статья про важность правильного дизайна

#дайджест