Напоминаю, что 18 апреля я проведу абсолютно эмейзинг вебинар «DDD в Node.js». Никаких Hello-MVC примеров, реальные задачи, реальные решения. Мы вместе напишем небольшой сервис на Node.js, обсудим преимущества подхода, я отвечу на все вопросы.
Сейчас вебинар стоит 1200 рублей, после 4 апреля цена вырастет до 1500.
Сейчас вебинар стоит 1200 рублей, после 4 апреля цена вырастет до 1500.
Ой, Робокасса немножко прилегла. Если вы хотите купить вебинар, но у вас не получается из-за ошибки на странице оплаты, напишите мне, пожалуйста — @igorkamyshev
Что-нибудь придумаем ☺️
Что-нибудь придумаем ☺️
Мониторинг
Для микросервисной архитектуры критически важен мониторинг.
Во-первых, необходимо отслеживать состояние хостов, на которых работают сервисы. Потребление памяти, нагрузка на процессор и объём свободного места на дисках.
Во-вторых, нужно следить на сервисом. Сервисы должны сообщать о своей состоянии через логи, которые нужно собирать (например, logstash) в единое место (например, Kibana) и там анализировать.
Кроме отслеживание чисто технических параметров (время отклика, коды ответов) стоит ещё подумать о сборе бизнес-метрик. Это поможет понять, влияют ли как-то технические показатели на бизнес.
Для спокойной жизни лучше настроить алерты: если сервис стал потреблять слишком много ресурсов или просели ключевые бизнес-метрики отправлять уведомление ответственным.
Все логи должны быть привязаны к конкретному изначальному запросу через идентификатор взаимосвязности. Это нужно, чтобы можно было провести трассировку вызовов внутри разных сервисов.
#микросервисы
Для микросервисной архитектуры критически важен мониторинг.
Во-первых, необходимо отслеживать состояние хостов, на которых работают сервисы. Потребление памяти, нагрузка на процессор и объём свободного места на дисках.
Во-вторых, нужно следить на сервисом. Сервисы должны сообщать о своей состоянии через логи, которые нужно собирать (например, logstash) в единое место (например, Kibana) и там анализировать.
Кроме отслеживание чисто технических параметров (время отклика, коды ответов) стоит ещё подумать о сборе бизнес-метрик. Это поможет понять, влияют ли как-то технические показатели на бизнес.
Для спокойной жизни лучше настроить алерты: если сервис стал потреблять слишком много ресурсов или просели ключевые бизнес-метрики отправлять уведомление ответственным.
Все логи должны быть привязаны к конкретному изначальному запросу через идентификатор взаимосвязности. Это нужно, чтобы можно было провести трассировку вызовов внутри разных сервисов.
#микросервисы
Безопасность
Касательно работы с пользователями все просто. Аутентификация — процесс определения, что некто является тем, кем он заявил. Авторизация — проверка, может ли совершающий действие его совершать. Нужно обеспечить единую точку аутентификации пользователей. Но решение о разрешении или запрете действия пользователю должны принимать сервис, в которых происходит это действие.
#микросервисы
Касательно работы с пользователями все просто. Аутентификация — процесс определения, что некто является тем, кем он заявил. Авторизация — проверка, может ли совершающий действие его совершать. Нужно обеспечить единую точку аутентификации пользователей. Но решение о разрешении или запрете действия пользователю должны принимать сервис, в которых происходит это действие.
#микросервисы
Безопасность при общении сервисов
Когда речь заходит о работе сервисов с сервисами, появляются варианты:
1. Любой сервис может совершить любой вызов внутри системы. Это вполне приемлемый вариант для систем, которые не работают с каким-то супер-важными данными. Нужно учесть, что если злоумышленник попадет внутрь сети — он получит доступ до всего, чего захочет.
2. Сервисы отправляют друг другу запросы через HTTP(S) Basic Auth. Во-первых, нельзя использовать это без HTTPS, а это вынуждает заниматься управлением SSL-сертификатами. Во-вторых, это дублирующая система (клиенты то не будут приходить с Basic Auth).
3. Заведение обычных учетных записей для сервисов. Заводить и управлять аккаунтами запарно, зато удобно — везде единая система авторизации, никакого дублирования, все безопасно.
4. Клиентские сертификаты. Очень сложно, непонятно зачем нужно.
5. Проверки подлинности сообщений на основе хеш-функции (HMAC). Тело сообщения кешируется, подписывается ключом, принимающая сторона проверяет корректность подписи. Можно использовать готовые протоколы (например JWT) или реализовать свой. В некоторых случая имеет смысл применить асимметричное шифрование — подписывающий знает приватный ключ, а читающий только публичный.
6. API-ключи. Рассматриваем все сервисы, как сторонние, которые умеют выдавать API-ключи. Удобно, но нужно управлять ключами для каждого сервиса, это накладно.
#микросервисы
Когда речь заходит о работе сервисов с сервисами, появляются варианты:
1. Любой сервис может совершить любой вызов внутри системы. Это вполне приемлемый вариант для систем, которые не работают с каким-то супер-важными данными. Нужно учесть, что если злоумышленник попадет внутрь сети — он получит доступ до всего, чего захочет.
2. Сервисы отправляют друг другу запросы через HTTP(S) Basic Auth. Во-первых, нельзя использовать это без HTTPS, а это вынуждает заниматься управлением SSL-сертификатами. Во-вторых, это дублирующая система (клиенты то не будут приходить с Basic Auth).
3. Заведение обычных учетных записей для сервисов. Заводить и управлять аккаунтами запарно, зато удобно — везде единая система авторизации, никакого дублирования, все безопасно.
4. Клиентские сертификаты. Очень сложно, непонятно зачем нужно.
5. Проверки подлинности сообщений на основе хеш-функции (HMAC). Тело сообщения кешируется, подписывается ключом, принимающая сторона проверяет корректность подписи. Можно использовать готовые протоколы (например JWT) или реализовать свой. В некоторых случая имеет смысл применить асимметричное шифрование — подписывающий знает приватный ключ, а читающий только публичный.
6. API-ключи. Рассматриваем все сервисы, как сторонние, которые умеют выдавать API-ключи. Удобно, но нужно управлять ключами для каждого сервиса, это накладно.
#микросервисы
Пришло время дайджеста 🧉
+ Может, нам слегка успокоиться с JavaScript? — история о плачевном положении современного веба, многие сайты даже для простых вещей используют много кода и это можно легко исправить;
+ Как написать аккуратный код? Часть первая: зацепление — краткая памятка о зацеплении в коде, примеры на Python;
+ Стоит ли хранить Google Fonts на своём сервере? — крутой разбор механизмов работы Google Fonts;
+ Принцип подстановки Лисков — разобор одного из самых важных принципов проектирования программ;
+ Как написать аккуратный код? Часть вторая: связность — небольшая заметка про связность внутри модулей;
#дайджест
+ Может, нам слегка успокоиться с JavaScript? — история о плачевном положении современного веба, многие сайты даже для простых вещей используют много кода и это можно легко исправить;
+ Как написать аккуратный код? Часть первая: зацепление — краткая памятка о зацеплении в коде, примеры на Python;
+ Стоит ли хранить Google Fonts на своём сервере? — крутой разбор механизмов работы Google Fonts;
+ Принцип подстановки Лисков — разобор одного из самых важных принципов проектирования программ;
+ Как написать аккуратный код? Часть вторая: связность — небольшая заметка про связность внутри модулей;
#дайджест
Общие рекомендации по безопасности
Нужно шифровать всё что можно. Микросервисы можно разделять в разные сети, чтобы изолировать из друг от друга и явно разрешать общение между ними.
Приложение должно хранить как можно меньше пользовательский данных. Например, зачастую вместо IP-адреса можно сохранить только хеш от него. Это защитит от кражи данных злоумышленниками.
Чаще всего проблемы безопасности связаны с человеческим фактором. Важно разработать политики, которые будут управлять доступами внутри компании.
#микросервисы
Нужно шифровать всё что можно. Микросервисы можно разделять в разные сети, чтобы изолировать из друг от друга и явно разрешать общение между ними.
Приложение должно хранить как можно меньше пользовательский данных. Например, зачастую вместо IP-адреса можно сохранить только хеш от него. Это защитит от кражи данных злоумышленниками.
Чаще всего проблемы безопасности связаны с человеческим фактором. Важно разработать политики, которые будут управлять доступами внутри компании.
#микросервисы
Закон Конвея и проектирование систем
«Организации, проектирующие системы, неизбежно производят конструкцию, чья структура является копией структуры взаимодействия внутри самой организации»
Обычно, если каждым сервисом владеет конкретная команда, система в целом получается лучше, а её развитие происходит быстрее.
#микросервисы
«Организации, проектирующие системы, неизбежно производят конструкцию, чья структура является копией структуры взаимодействия внутри самой организации»
Обычно, если каждым сервисом владеет конкретная команда, система в целом получается лучше, а её развитие происходит быстрее.
#микросервисы
Смотрите, какое доброе дело сделали в Breadhead.
Особенно круто, что сделали всего за неделю. Кайф!
Особенно круто, что сделали всего за неделю. Кайф!
Forwarded from Хлебголова
Сделали за неделю вместе с Фондом профилактики рака
Forwarded from Хлебголова
Надежность
Сбои происходят повсюду — диски выходят из строя, сеть ненадёжна, в дата-центре могут выключить электричество. Нужно быть готовым к сбоям, потому что на большом количестве сервисов они точно произойдут.
Следует определить такие параметры системы: живучесть данных, доступность сервисов, пропускная способность и приемлемое время отклика сервисов. И разрабатывать масштабируемость системы исходя из этих параметров. Например, для системы генерации отчетов простой в пару часов ничего не значит, а для системы распознавания лиц в супермаркете будет фатальным.
При падении отдельных сервисов система в целом должна продолжать работать как можно дольше — деградировать изящно (graceful degradation).
#микросервисы
Сбои происходят повсюду — диски выходят из строя, сеть ненадёжна, в дата-центре могут выключить электричество. Нужно быть готовым к сбоям, потому что на большом количестве сервисов они точно произойдут.
Следует определить такие параметры системы: живучесть данных, доступность сервисов, пропускная способность и приемлемое время отклика сервисов. И разрабатывать масштабируемость системы исходя из этих параметров. Например, для системы генерации отчетов простой в пару часов ничего не значит, а для системы распознавания лиц в супермаркете будет фатальным.
При падении отдельных сервисов система в целом должна продолжать работать как можно дольше — деградировать изящно (graceful degradation).
#микросервисы
Надежность
Базовый способ уберечь систему от каскадного сбоя — с умом выставить таймауты для вызовов сервисов. Это поможет определить, что какой-то сервис отвечает слишком медленно и другой сервис должен перестать его ожидать.
Более сложный подход — предохранители. В этом случае, при нескольких неудачных запросах к сервису, основная нагрузка не него перестает подаваться до тех пор, пока он не восстановиться. Обычно, этим должен заниматься не конкретный сервис, а какой-то общий менеджер.
Переборки — искусственные границы между сервисами, призванные снизить опасность от проблем в одном из них. Например, если два сервиса используют общий пул подключений к базе данных, то при сбое в одном сервисе (если он сожрёт все подключения), второй сервис тоже упадет. Можно разделить пулы и избежать такой ситуации. Переборки можно делать «подвижными», то есть закрывать их, только если обнаружены проблемы в одном из сервисов.
#микросервисы
Базовый способ уберечь систему от каскадного сбоя — с умом выставить таймауты для вызовов сервисов. Это поможет определить, что какой-то сервис отвечает слишком медленно и другой сервис должен перестать его ожидать.
Более сложный подход — предохранители. В этом случае, при нескольких неудачных запросах к сервису, основная нагрузка не него перестает подаваться до тех пор, пока он не восстановиться. Обычно, этим должен заниматься не конкретный сервис, а какой-то общий менеджер.
Переборки — искусственные границы между сервисами, призванные снизить опасность от проблем в одном из них. Например, если два сервиса используют общий пул подключений к базе данных, то при сбое в одном сервисе (если он сожрёт все подключения), второй сервис тоже упадет. Можно разделить пулы и избежать такой ситуации. Переборки можно делать «подвижными», то есть закрывать их, только если обнаружены проблемы в одном из сервисов.
#микросервисы
18 апреля 2020 в 14.00 МСК я проведу вебинар про DDD в Node.js. Три часа будем вместе делать небольшой сервис на Node.js, отвечу на вопросы. Всех участников добавлю в специальный чат, где можно будет продолжить обсуждение.
А чтобы легче было понять, что такое DDD и почему оно нам всем нужно, я принес кусочек списка полезных ссылок из чата вебинара.
А чтобы легче было понять, что такое DDD и почему оно нам всем нужно, я принес кусочек списка полезных ссылок из чата вебинара.
Что можно узнать о Domain Driven Design за 10 минут?
Очень краткая вводная статья по DDD. Стоит прочитать, чтобы понять основные концепции. Обратите внимание, там внизу много хороших ссылок.
Статья
Strategic Domain Driven Design for Improving Flutter architecture
Доклад про DDD в Flutter. На самом деле, он почти не связан с конкретной технологией, а скорее презентует общие подходы.
Запись, слайды
#ddd
Очень краткая вводная статья по DDD. Стоит прочитать, чтобы понять основные концепции. Обратите внимание, там внизу много хороших ссылок.
Статья
Strategic Domain Driven Design for Improving Flutter architecture
Доклад про DDD в Flutter. На самом деле, он почти не связан с конкретной технологией, а скорее презентует общие подходы.
Запись, слайды
#ddd
Чтобы разобраться в этой теме глубже — приходите на вебинар 18 апреля 2020 в 14.00 МСК.
На этой неделе еще можно купить за 1200 рублей, в субботу цена вырастает до 1500.
На этой неделе еще можно купить за 1200 рублей, в субботу цена вырастает до 1500.
Я уже тысячу раз говорил, что считаю жутко важным знать много языков программирования: просто для кругозора. Например, можно почитать крутую книгу «Семь языков за семь недель».
А если хочется быстро вкатиться в какой-то другой язык за ограниченное время, то вместо чтения документации можно обратиться к Learn X in Y Minutes: Scenic Programming Language Tours — это простой сборник шпаргалок по разным языкам.
#языки
А если хочется быстро вкатиться в какой-то другой язык за ограниченное время, то вместо чтения документации можно обратиться к Learn X in Y Minutes: Scenic Programming Language Tours — это простой сборник шпаргалок по разным языкам.
#языки
Суббота, дайджест.
Две прекрасные статьи, которые с разных сторон смотрят на современные проблемы софта:
+ В софте всё восхитительно, но все недовольны — дисс на Никиту Прокопова и его «Разочарование в софте»
+ Продолжаем обобщать и передергивать — дисс на дисс
Ну и просто несколько хороших статей:
+ «Злые марсиане»: как российские разработчики помогают стартапам взлетать (и сколько они на этом зарабатывают) — про самый загадочный аутсорс
+ Краткий гайд о том, как нанимать нормальных людей — про нормальные собеседования для нормальных специалистов
+ The Elephant in the Architecture — про бизнес-вэлью как часть архитектуры программ
+ Знай своего врага: создаём Node.js-бэкдор — про опасности в npm-пакетах
#дайджест
Две прекрасные статьи, которые с разных сторон смотрят на современные проблемы софта:
+ В софте всё восхитительно, но все недовольны — дисс на Никиту Прокопова и его «Разочарование в софте»
+ Продолжаем обобщать и передергивать — дисс на дисс
Ну и просто несколько хороших статей:
+ «Злые марсиане»: как российские разработчики помогают стартапам взлетать (и сколько они на этом зарабатывают) — про самый загадочный аутсорс
+ Краткий гайд о том, как нанимать нормальных людей — про нормальные собеседования для нормальных специалистов
+ The Elephant in the Architecture — про бизнес-вэлью как часть архитектуры программ
+ Знай своего врага: создаём Node.js-бэкдор — про опасности в npm-пакетах
#дайджест
