Взгляд снизу на микросервисную архитектуру

Мы — aify.studio: делаем ИИ‑системы и надёжный backend, который решает бизнес‑задачи, а не просто «показывает демку». Пишем про архитектуру, LangGraph/LangSmith, базы данных и реальные кейсы внедрения — честно, по делу и с метриками. Если вам нужны практические решения и инженерные подходы без хайпа — вы по адресу.

микросервисы12factorконфигурация

#Rokcet_post

Совсем недавно я задумался, а как же должно выглядеть хорошее микросервсное приложение?

В этом посте хочется сделать небольшой обзор статьи The Twelve-Factor App. Все 12 пунктов рассматривать в одном посте считаю слишком громоздким, поэтому делю на 3 части.

Вот первые 4 из 12 пунктов, которые выделяют авторы:

  1. Приложение должно разрабатываться с использование СКС.
    Неважно будь это Git, Bitbucket или что угодно вашей душей. Приложение должно иметь единую кодовую базу, и она должна быть только одна(в противном случае это уже распределнная система). Таким образом кодовая база едина для всех развертываний приложения, отличие может быть только в версии, как, например, в ветках dev и prod(пока одну не вольют в другую).
  2. Зависмости
    Посыл автора в следующем: Приложение никогда не полагается на неявное существование общесистемных пакетов (типа curl, netsat, etc.). Оно объявляет все зависимости, полностью и точно, а так же использует инструмент изоляции, чтобы не было кофликтов с системой. В статье говорится о Ruby и Python, я приведу в пример Golang, все зависимоти содержаться в файлах go.mod+go.sum, устанавливаются же они в в локальный модульный кеш ($GOPATH/pkg/mod). Ну и естественно все можно обернуть в средство контейнеренизации(даже нужно).
  3. Конфигурация
    Следует разделять конфигурацию и код, ведь конфигцурация может существенно разница между развертываниями. Если Вас интересует вопрос "А правильно ли я храню конфиги?", ответ очень прост - в случае слива исходников не утекут ли ваши креды?
  4. Сторонние службы (Backing Services)
    Сторонняя служба — любой сетевой ресурс, используемый приложением: базы данных, броккеры сообщение, внешние API.
    Все сторонние службы - подключаемые приложения. Замена сервиса не должна требовать изменений кода. Каждая служба = отедельный ресурс(даже две Postresql, используемые для шардирования, будут двумя ресурсами)
Набросок: облако со шестерёнкой и падающими каплями, рядом схематичная фигура с лупой, в углу логотип AIFY — иллюстрация к посту об архитектуре.
Иллюстрация к посту об архитектуре микросервисов и обзору Twelve-Factor App.

Читайте так же