Решил написать заметку про генерацию трейс-айди в Node.js, пошел гуглить и наткнулся на куда более качественную статью.
Почитайте, очень хорошо рассказано — https://habr.com/ru/post/442452/
#js
Почитайте, очень хорошо рассказано — https://habr.com/ru/post/442452/
#js
Хабр
Как логировать в NodeJS, чтобы пацаны во дворе уважали
Что вас бесит сильнее всего, когда вы пытаетесь организовать читаемые логи в вашем NodeJS приложении? Лично меня чрезвычайно напрягает отсутствие каких-либо вме...
Кстати, есть классная библиотека https://github.com/puzpuzpuz/cls-rtracer для удобной генерации trace-id в простых случаях.
GitHub
GitHub - puzpuzpuz/cls-rtracer: Request Tracer - CLS-based request id generation for Express, Fastify, Koa and Hapi, batteries…
Request Tracer - CLS-based request id generation for Express, Fastify, Koa and Hapi, batteries included - puzpuzpuz/cls-rtracer
Управление версиями
При разработке микросервисов стоит придерживаться семантического версионирования и контролировать ломающие изменения особенным образом.
Первый вариант — обеспечить функционирование конечных точек двух версий (например 1.5.3 и 2.0.0) в рамках одного сервиса и постепенно мигрировать клиентов на новую версию. В этом случае версию можно сообщать внутри URI (например,
В крайних случаях можно запустить два отдельных сервиса (один с версией 1.5.3 и другой с версией 2.0.0), но тут возникают дополнительные сложности — маршрутизация клиентов, поддержание базы данных в консистентном состоянии. Такой путь стоит использовать, только если переезд с версии на версию занимает немного времени.
#микросервисы
При разработке микросервисов стоит придерживаться семантического версионирования и контролировать ломающие изменения особенным образом.
Первый вариант — обеспечить функционирование конечных точек двух версий (например 1.5.3 и 2.0.0) в рамках одного сервиса и постепенно мигрировать клиентов на новую версию. В этом случае версию можно сообщать внутри URI (например,
/v1/createUser/, /v2/createUser/), или, если используется HTTP, сообщать версию в заголовке запроса.В крайних случаях можно запустить два отдельных сервиса (один с версией 1.5.3 и другой с версией 2.0.0), но тут возникают дополнительные сложности — маршрутизация клиентов, поддержание базы данных в консистентном состоянии. Такой путь стоит использовать, только если переезд с версии на версию занимает немного времени.
#микросервисы
Как пасти котов
Вообще, это книга для людей, которые собираются управлять программистами, но, на мой взгляд, ее стоит прочитать вообще любым техническим специалистам.
Ханк Рейнвотер рассказывает о разных типах программистов (очень легко узнать себя 🤓), построении отношений с начальством, мотивации, деньгах. Обо всем, с чем мы сталкиваемся на работе каждый день.
Это очень хорошая книжка, которая точно поможет лучше понимать, что происходит вокруг и как с этим можно эффективно взаимодействовать.
#softskills #рост
Вообще, это книга для людей, которые собираются управлять программистами, но, на мой взгляд, ее стоит прочитать вообще любым техническим специалистам.
Ханк Рейнвотер рассказывает о разных типах программистов (очень легко узнать себя 🤓), построении отношений с начальством, мотивации, деньгах. Обо всем, с чем мы сталкиваемся на работе каждый день.
Это очень хорошая книжка, которая точно поможет лучше понимать, что происходит вокруг и как с этим можно эффективно взаимодействовать.
#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.
#дайджест
+ Базовые принципы проектирования — инструкция, как создавать простые для понимания системы, отвечающие ожиданиям человека;
+ «Коллеги, дышите потише»: почему офисный шум сводит нас с ума — обсуждаем исследования — покажите эту статью коллегам и офис-менеджеру, если в офисе шумно;
+ Структура приложения — Сергей Сова рассказывает о методике раскладывания файликов по папкам во фронтенде, нужно прочесть, если обычно через пару месяцев после начала проекта обнаруживаете, что не понятно, где искать какой-то код;
И еще чуть-чуть на английском:
+ 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-шлюзе.
#микросервисы
Чтобы микросервисами пользоваться, нужен пользовательский интерфейс. Есть три пути.
Первый вариант самый простой — прямо из интерфейса вызывать нужные сервисы. Проблема в том, что часто сервисы предоставляют данные не совсем в том виде, который требуется интерфейсу.
Второй вариант — создать единый API-шлюз, который будет предоставлять всем интерфейсам удобные ендпонты. Но не ясно, кто должен отвечать за подобную структуру и как это поддерживать (она быстро станет слишком большой).
Третий путь — backend-for-frontend (BFF). Каждая команда разработки интерфейса (например, мобильного приложения) создаёт для себя API-шлюз и поддерживает его.
При двух последних вариантах, следует тщательно контролировать отсутствие логики в API-шлюзе.
#микросервисы
Интеграция сторонних систем
Во многих компаниях используется сторонние сервисы (например, CMS или CRM). С ними тоже нужно научиться интегрироваться. Просто и правильный путь — закрыть эту внешнюю систему своим фасадом, который будет контролировать все обращения к системе и предоставлять другим сервисам простой и привычный API.
#микросервисы
Во многих компаниях используется сторонние сервисы (например, CMS или CRM). С ними тоже нужно научиться интегрироваться. Просто и правильный путь — закрыть эту внешнюю систему своим фасадом, который будет контролировать все обращения к системе и предоставлять другим сервисам простой и привычный API.
#микросервисы
Внимание!
Скоро я ухожу из Самоката, поэтому нужен новый ведущий фронтендер на внутренние продукты. Это хорошая работа над интересными продуктами.
Тут можно прочитать больше подробностей, или просто напишите мне @igorkamyshev, я расскажу все что смогу.
Кейворды: Питер, офис, реакт, продукт, ритейл, кикер.
Скоро я ухожу из Самоката, поэтому нужен новый ведущий фронтендер на внутренние продукты. Это хорошая работа над интересными продуктами.
Тут можно прочитать больше подробностей, или просто напишите мне @igorkamyshev, я расскажу все что смогу.
Кейворды: Питер, офис, реакт, продукт, ритейл, кикер.
Telegraph
Ищем классного тим лида
Ищем человека, который будет управлять командой фронтендеров, строить внутренние сервисы компании. Контролировать качество кода, архитектуру приложений, вместе со стейкхолдерами и дизайнерами продумывать интерфейсы. Принимать много технических решений. Координировать…
Разбиение монолита на части
Разбивать монолит на части нужно постепенно. Выделять ограниченные контексты, выносить их в модуль внутри приложения, анализировать зависимости и уже потом выделать отдельный микросервис.
Есть много причин разбить монолит. Одна из них — грядущие изменения. Если известно, что в один из ограниченных контекстов скоро будут вноситься серьёзные изменения, имеет смысл выделить его в сервис и получить простоту тестирования и развертывания. Другие популярные причины: особенные требования к безопасности отдельных частей; желание использовать альтернативную технологию в части системы.
#микросервисы
Разбивать монолит на части нужно постепенно. Выделять ограниченные контексты, выносить их в модуль внутри приложения, анализировать зависимости и уже потом выделать отдельный микросервис.
Есть много причин разбить монолит. Одна из них — грядущие изменения. Если известно, что в один из ограниченных контекстов скоро будут вноситься серьёзные изменения, имеет смысл выделить его в сервис и получить простоту тестирования и развертывания. Другие популярные причины: особенные требования к безопасности отдельных частей; желание использовать альтернативную технологию в части системы.
#микросервисы
Разбиение монолита на части
При разделение монолита на части возникает проблема, что транзакции уровня базы данных становятся невозможны. Решение — распределенные транзакции. Этот механизм позволяет получить достаточно надежные транзакции для разделённых сервисов. А во многих случаях, стоит вовсе отказаться от транзакций и разработать самовостанавливающуюся систему (например, попытки записи могут повторяться несколько раз, пока не получится).
В микросервисной архитектуре не так просто реализовать отчеты. Мы не можем просто сделать большой запрос к единой базе данных и получить результат. Есть четыре варианта:
+ каждый сервис может слать свои данные для отчетов в сервис отчетов;
+ сервис отчетов может ходить к остальным сервисам за данными;
+ если сервисы общаются через события, то сервис отчетов может просто подписаться на эти события;
+ сервис отчетов может брать бекапы разных сервисов и генерировать отчеты на основе этих данных (так делает Netflix).
#микросервисы
При разделение монолита на части возникает проблема, что транзакции уровня базы данных становятся невозможны. Решение — распределенные транзакции. Этот механизм позволяет получить достаточно надежные транзакции для разделённых сервисов. А во многих случаях, стоит вовсе отказаться от транзакций и разработать самовостанавливающуюся систему (например, попытки записи могут повторяться несколько раз, пока не получится).
В микросервисной архитектуре не так просто реализовать отчеты. Мы не можем просто сделать большой запрос к единой базе данных и получить результат. Есть четыре варианта:
+ каждый сервис может слать свои данные для отчетов в сервис отчетов;
+ сервис отчетов может ходить к остальным сервисам за данными;
+ если сервисы общаются через события, то сервис отчетов может просто подписаться на эти события;
+ сервис отчетов может брать бекапы разных сервисов и генерировать отчеты на основе этих данных (так делает Netflix).
#микросервисы
Docker
Последнее время много пишу о микросервисах (потому что много читаю о микросервисах), а какие микросервисы в 2020 без докера?
Комрад нашел хороший базовый интреактивный туториал по контейнеризации приложений.
Learn Docker, Container Runtimes, Builders and Registries
#docker
Последнее время много пишу о микросервисах (потому что много читаю о микросервисах), а какие микросервисы в 2020 без докера?
Комрад нашел хороший базовый интреактивный туториал по контейнеризации приложений.
Learn Docker, Container Runtimes, Builders and Registries
#docker
Развертывание
Для комфортного развертывания микросервисов в компании должна быть внедрена непрерывная интеграция. Каждое вносимое изменение, должно подвергаться набору проверок (тесты, статические анализаторы) и постоянно попадать в основную сборку проекта. Ветки для изменений должны жить совсем не долго (день-два).
При непрерывной доставке сервис обычно проходит несколько сред (тестирование автоматизированное, тестирование ручное, продакшн). Нужно контролировать идентичность этих сред и стремится к полной концептуальной схожести. Но без фанатизма. Конфигурация должна быть отделена от сервиса и поставлять в него только в момент развёртывания.
#микросервисы
Для комфортного развертывания микросервисов в компании должна быть внедрена непрерывная интеграция. Каждое вносимое изменение, должно подвергаться набору проверок (тесты, статические анализаторы) и постоянно попадать в основную сборку проекта. Ветки для изменений должны жить совсем не долго (день-два).
При непрерывной доставке сервис обычно проходит несколько сред (тестирование автоматизированное, тестирование ручное, продакшн). Нужно контролировать идентичность этих сред и стремится к полной концептуальной схожести. Но без фанатизма. Конфигурация должна быть отделена от сервиса и поставлять в него только в момент развёртывания.
#микросервисы
Развертывание
Чтобы упростить доставку сервисов, нужно обеспечить единообразие способа развёртывания. Для этого можно взять систему управления конфигурациями, например Chef, Puppet или Ansible. Этот путь ведёт к нескольким проблемам — повторяемость сборки зависит от текущего состояния системы, подготовка занимает значительное время. Другой хороший вариант — создать артефакт для запуска на конкретной операционной системе, например deb-пакет. Но это приводит к сложностям с разными операционными системами. Чтобы избежать любых с совместимостью, можно распространять сервис в виде образа системы с подготовленным окружением для запуска в виртуальной машине. И тут есть трудности — образы много весят и долго делаются.
LXC-контейнеры — это лучший вариант для большенства задач. Но ими сложно управлять. Docker решает многие проблемы — управляет предоставлением контейнеров, справляется с некоторыми проблемами использования сетей, а чтобы решить остальные придумали Kubernetes.
#микросервисы
Чтобы упростить доставку сервисов, нужно обеспечить единообразие способа развёртывания. Для этого можно взять систему управления конфигурациями, например 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 — вводная статья по основным понятиям девопса, стоит читать, если совсем не понимаете о чем речь.
Кстати, с этого дня дайджест будет выходить два раза в месяц. 🌟
#дайджест
+ Что можно узнать о 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 — вводная статья по основным понятиям девопса, стоит читать, если совсем не понимаете о чем речь.
Кстати, с этого дня дайджест будет выходить два раза в месяц. 🌟
#дайджест
До января этого года я работал в Нетологии, потому что уверен — хорошие программисты начинаются с обучения. Сейчас многие обучают новичков до состояния «могу пойти работать», но что делать дальше говорят очень немногие. Поэтому, в качестве эксперимента, я запускаю вебинары для уже практикующих специалистов.
Никаких Hello-MVC примеров, реальные задачи, реальные решения. Я не буду рассказывать о синтаксисе языков, о базовых правилах создания программ, за этим можно почитать книжки из списка маст-ридов. На вебинарах я буду делиться взглядом на разработку качественных приложений, опытом создания разных сервисов (и факапами тоже, кстати).
Никаких Hello-MVC примеров, реальные задачи, реальные решения. Я не буду рассказывать о синтаксисе языков, о базовых правилах создания программ, за этим можно почитать книжки из списка маст-ридов. На вебинарах я буду делиться взглядом на разработку качественных приложений, опытом создания разных сервисов (и факапами тоже, кстати).
Книга, которая сильнее других сказалась на моем профессиональном росте — Domain-Driven Design. #ddd перевернуло мой взгляд на разработку программ, на ценности которые они несут.
Я хочу, чтобы больше программистов следовало этой методологии, поэтому первый вебинар — «DDD в Node.js».
Три часа будем вместе делать небольшой сервис на Node.js, отвечу на вопросы. Всех участников добавлю в специальный чат, где можно будет продолжить обсуждение.
Вебинар пройдёт 18 апреля 2020 в 14.00 МСК.
До 4 апреля его можно купить за 1200 рублей, потом — за 1500.
Я хочу, чтобы больше программистов следовало этой методологии, поэтому первый вебинар — «DDD в Node.js».
Три часа будем вместе делать небольшой сервис на Node.js, отвечу на вопросы. Всех участников добавлю в специальный чат, где можно будет продолжить обсуждение.
Вебинар пройдёт 18 апреля 2020 в 14.00 МСК.
До 4 апреля его можно купить за 1200 рублей, потом — за 1500.
kamyshev.code pinned «Книга, которая сильнее других сказалась на моем профессиональном росте — Domain-Driven Design. #ddd перевернуло мой взгляд на разработку программ, на ценности которые они несут. Я хочу, чтобы больше программистов следовало этой методологии, поэтому первый…»
Тестирование
Юнит-тестов нужно много, они должны иметь техническую, а не бизнесовую направленность. Для каждого сервиса нужно писать тесты его поведения, их нужно меньше, они должны быть ориентированными на бизнес-требования. E2e тесты очень важны, но они сложные и дорогие.
Для не-сквозных тестов нужно как-то заменять реальные вызовы других компонентов системы — можно делать имитацию работы (моки), а можно просто возвращать одно и тоже значение (стабы). Есть и другие разновидности заглушек. Крутое решения для генерации таких тестовых дублеров — Mountebank.
#микросервисы
Юнит-тестов нужно много, они должны иметь техническую, а не бизнесовую направленность. Для каждого сервиса нужно писать тесты его поведения, их нужно меньше, они должны быть ориентированными на бизнес-требования. E2e тесты очень важны, но они сложные и дорогие.
Для не-сквозных тестов нужно как-то заменять реальные вызовы других компонентов системы — можно делать имитацию работы (моки), а можно просто возвращать одно и тоже значение (стабы). Есть и другие разновидности заглушек. Крутое решения для генерации таких тестовых дублеров — Mountebank.
#микросервисы
Тестирование
Сквозные (e2e) тесты хороши. Их нужно запускать на самом последнем этапе CI, потому что они медленные и не дают понимания, что именно сломалось. Иногда их можно заменит на CDC (контракты определяемые потребителем сервиса).
Юнит-тесты и тесты сервисов пишут владельцы конкретного сервиса. Сквозные же тесты должны разрабатываться совместно всеми командами (чтобы избежать дублирования).
Любые тесты должны быть повторяемыми. То есть при повторных запускать показывать одинаковые результаты.
После запуска сервиса в продакшн над ним нужно провести смоук-тесты, которые проверят общую работоспособном системы.
#микросервисы
Сквозные (e2e) тесты хороши. Их нужно запускать на самом последнем этапе CI, потому что они медленные и не дают понимания, что именно сломалось. Иногда их можно заменит на CDC (контракты определяемые потребителем сервиса).
Юнит-тесты и тесты сервисов пишут владельцы конкретного сервиса. Сквозные же тесты должны разрабатываться совместно всеми командами (чтобы избежать дублирования).
Любые тесты должны быть повторяемыми. То есть при повторных запускать показывать одинаковые результаты.
После запуска сервиса в продакшн над ним нужно провести смоук-тесты, которые проверят общую работоспособном системы.
#микросервисы
Тестирование и релиз
Иногда примеряется сине-зелёное развёртывание: рядом с боевой версией сервиса поднимается ещё одна — новая. Над ней выполняется большой набор автоматизированных и ручных тестов и потом переключается трафик. Так можно убедиться в корректной работе на продакшн-стенде.
Канареечные релизы (часто путают с сине-зелёными релизами) — это способ мягко перевода пользователей на новую версию. Нужно определить набор метрик для сервиса (например, время ответа, ответы с определённым статусом или какие-нибудь бизнес-метрики). После поднимается вторая версия сервиса, на неё отправляется небольшое количество трафика. Если метрики не упали, то подаётся больше трафика. Так продолжается, пока старая версия сервиса не станет ненужной.
#микросервисы
Иногда примеряется сине-зелёное развёртывание: рядом с боевой версией сервиса поднимается ещё одна — новая. Над ней выполняется большой набор автоматизированных и ручных тестов и потом переключается трафик. Так можно убедиться в корректной работе на продакшн-стенде.
Канареечные релизы (часто путают с сине-зелёными релизами) — это способ мягко перевода пользователей на новую версию. Нужно определить набор метрик для сервиса (например, время ответа, ответы с определённым статусом или какие-нибудь бизнес-метрики). После поднимается вторая версия сервиса, на неё отправляется небольшое количество трафика. Если метрики не упали, то подаётся больше трафика. Так продолжается, пока старая версия сервиса не станет ненужной.
#микросервисы