kamyshev.code
1.94K subscribers
40 photos
565 links
Архитектура, код, софт-скиллы и всё остальное. Вопросы, пожелания, комментарии — @igorkamyshev

https://kamyshev.me
Download Telegram
Надежность

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

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

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

#микросервисы
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 есть отличный подкаст. Там Рахим рассказывает не только о сути, но и приводит простое доказательство.

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

#общие_знания
This media is not supported in your browser
VIEW IN TELEGRAM
DDD в Node.js — уже в эту субботу!

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

18 апреля 2020, 14.00 МСК, 1500 рублей.
Напоминаю, вебинар через три часа. Если вы хотели купить, но тянули — сейчас самое время 😇
​​Вчера был вебинар, поэтому не было дайджеста. Вот вам маленький сегодня 🌚

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

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

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

#дайджест
Машинное обучение

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

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

#общие_знания
Где поесть?

Два месяца назад я переехал на Пхукет и растерялся — я не понимал, где тут есть стоит, а где нет.

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

Так я придумал бота — «Где поесть?» @trip_trip_robot.

Он умеет выбирать хорошее рядом, понимает время суток и вообще классный. Пока он знает не так много локаций — Таллин, Петербург и Пхукете, и немного Томск, Москву, Новосибирск, Тель-Авив, Хельсинки, Берлин и Протарас. Но я ищу варианты, как мастштабировать его и научить искать еду везде.

Пробуйте, пишите фидбеки (@igorkamyshev) и ешьте вкусно. Я понимаю, что сейчас почти везде в России все закрыто, но вы все равно попробуйте. А как откроется — я выкачу новую версию, еще лучше. И напомню.
Preact — идея на 5, реализация на 3

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

Читать на Medium

#react
В январе я сделал список маст-ридов для разработчиков, теперь хочется перевести его на английский. Ищу помощников для перевода — пишите мне @igorkamyshev, или присылайте сразу ПРы — igorkamyshev/mustread.

Ну и ставьте звездочки, рассказывайте друзьям 🌚