Решение. Найти положение своего AirTag через приложение на телефоне.
линк — основная картинка
https://arxiv.org/pdf/2103.02282.pdf — очень рекомендую почитать оригинальную спецификацию
https://habr.com/ru/news/t/554226 — интересное описание на русском

Apple AirTag имеет начальную инициализацию маячка с “основным устройством пользователя”. На ней создается мастер ключ (приватный+публичный, они никогда не передаются через bluetooth).

Маяк броадкастит данные, включая специальный меняющийся со временем Rolling encryption ключ. Так сильно тяжело телефонам вокруг единожды идентифицировать устройство.

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

Основное устройство пользователя может запрашивать эти данные у бэкенда по открытому ключу. Чуть подробнее и с большим математическим погружением в криптографию можно изучить вопрос в пункте 6.1 спецификации.

Немного интересных фактов из спецификации работы AirTag:
— Apple в теории не знает ничего про местонахождение маячков, нашедший маячок телефон шифрует позицию с помощью публичного ключа с маячка, который потом может расшифровать только владелец устройства с помощью приватного ключа.
— Каждый телефон копит батчи с маячков вокруг и отправляет их на сервер балково с медианой 26 минут.
— Apple хранит зашифрованные репорты о координатах 7 дней.
— Каждый маяк меняет bluetooth адрес каждые 15 минут.
— Apple гипотетически может понять что несколько разных пользователей могут находиться рядом друг с другом по тому о каких девайсах они отправляют репорты в бэкенд Apple. Законодательство каких-то стран позволит деанонимизировать пользователей даже если какие-то из девайсов находятся в “режиме в самолете”.

#case #task #architecture #device

Библиотка VS Сервис VS Сайдкар.
Library vs Service vs Sidecar.
https://atul-agrawal.medium.com/library-vs-service-vs-sidecar-ff5a20b50cad

Подвернулась интересная статья со сравнением подходов к разработке переиспользуемой функциональности. Не со всем согласен, где-то в скобках прокомментировал, но аргументы хорошие.

Библиотека — переиспользуемый код распространяется как часть приложения. Код библиотеки работает в том же процессе и контейнере, что и код приложения.
Плюсы:
+ Сетевая задержка: код запускается в одном процессе с приложением, никаких расходов.
+ Доступность: общая доступность высока, т.к. нет сетевого взаимодействия (CAP-теорема)
+ Простота использования: библиотеку просто подключить (спорно: если у вас зоопарк языков, то чтобы подключить библиотеку, например, к C++, можно потратить много времени).
+ Тот же контекст окружения: память, процессор итд доступны для библиотеки как части того же контейнера (спорно: не очень ясно почему это преимущество, т.к. это ресурсы, за которые код библиотеки будет конкурировать с основным приложением)
Минусы:
- Ресурсы: за память, процессор итд библиотека будет конкурировать с приложением, что может вызывать разные проблемы.
- Технологии: может потребоваться несколько реализаций библиотеки (или для нее коннекторов), если у вас используются разные, например, языки программирования.
- Поддерживаемость: любые багфиксы в библиотеке требуют тестирования и перевыкатки всех использующих ее приложений.

Сервис — переиспользуемый код выносится в отдельный сервис/инстанс/контейнер, в который приложение ходит по сети, используя request/response механизм.
Плюсы:
+ Ресурсы: основное приложение и сервис задеплоены по-отдельности так, чтобы процессор, память итд не шарились между ними. Ресурсы могут оптимизироваться и управляться для обоих по-отдельности.
+ Поддерживаемость: сервис может выкатываться отдельно от основного приложения, так что релизы всех используемых приложения не требуются.
+ Технологии: сервис может быть написан с использованием любых необходимых технологий, главное, чтобы сетевой протокол с основным приложением был поддержан.
Минусы:
- Простота использования: сервисы менее просты по сравнению с библиотекой (спорно: для сервиса можно сделать удобный клиент, а библиотеку можно так обновить, что потребуется переписать половину приложения).
- Сетевая задержка: добавляются задержки при сетевых хождениях в сервис.
- Тот же контекст окружения: память, процессор итд основного приложения недоступны сервису, т.к. запущены чаще всего в разных инстансах. (спорно: не очень понятно, почему это минус).
- Доступность: общая доступность ниже по сравнению с библиотекой из-за хождений по сети.

...продолжение

Сайдкар — паттерн, при котором переиспользуемый код живет как отдельный процесс в том же контейнере, что и приложение. (например, envoy).
Поддерживаемость: сайдкар может релизиться независимо от основного приложения (спорно: например, не так-то просто организовать, чтобы обновлялась какая-то часть докер-контейнера).
Технологии: сайдкар может быть написан на любой подходящей технологии.
Задержка: меньше, чем у сервиса, но выше, чем у библиотеки. Есть антипаттерн - если много компонентов сделаны на сайдкарах, то можно получить огромную просадку по производительности.
Ресурсы: приложение и сайдкар релизятся совместно, так что ресурсы у них общие. Однако, лимит на использование ресурсов можно может быть установлен по-отдельности на приложение и сайдкар. (спорно: на деле может быть не так просто реализовать, не знаю готовых решений для этого). Если все компоненты реализованы как сайдкары, то можно получить очень сильный оверхед на менеджмент ресурсов.
Простота использования: сайдкар менее прост в использовании в сравнении с библиотекой и может быть сильно проще сервиса, если CI/CD поддерживает это из коробки. (спорно: сильно зависит от ваших технологий. Подключить сайдкар может быть проще, чем библиотеку).
Тот же контекст окружения: память, процессор итд основного приложения доступны для сайдкара. Это позволяет сайдкару делать, например, мониторинг основного приложения.
Доступность: может быть выше в сравнении с сервисом т.к. нет “настоящих” походов по сети. В действительности, доступность будет сильно зависеть от протокола между основным приложением и сайдкаром.

#pattern #microservices #sidecar #medium #en

Highload++ 2022
На прошлой неделе прошла конференция Highload++. Сразу дисклеймер — все мысли исключительно мои личные и субъективные. Мне довелось побывать, наверное, на 4-5 хайлоадах (и даже выступить), это был единственный раз, я не мог найти по программе, куда можно сходить и что послушать.

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

Много рекламы, за которой тяжело рассмотреть контент. Я сужу по рекламе в телеграм-канале, предназначенном для объявлений, которым было невозможно пользоваться из-за постоянного спама, это и доклады, которые направлены больше на порекламировать продукт или компанию, чем на то, чтобы поделиться своим опытом. Я пошел на пафосно звучащий доклад об 1С и их low-code платформе (т.к. мы тоже делаем low-code платформу). Доклад начался с того, что у компании всегда был low-code платформа, а сам термин просто такой хайповый стал последнее время и рассказ до середины (того момента, до которого я смог досидеть, дальше не знаю), был простым обзором продукта 1С. От коллег слышал похожий фидбек и по другим докладам.

Если вы меня спросите — пошел бы я еще, я бы ответил — да. Были и очень хорошие доклады. В сжатых выжимках в следующих постах попробую поделиться тем, что я вынес с конференции.

Если у вас похожее или в корне отличное мнение, поделитесь в комментариях. Вы были на хайлоаде? Какой доклад вам понравился?

Санкционная модель OSI

Алексей Учакин из EdgeCenter на HighLoad++ 2022 посмотрел на классическую семиуровневую модель OSI (которая описывает архитектуру и принципы работы передачи данных от физического уровня до прикладного программного уровня) с учетом тех реалий, в которых мы все с вами оказались. Ниже мой небольшой конспект.

Сравнивать Россию с Ираном и КНДР по введенным санкциям уже поздно, но можно попробовать построить краткосрочный прогноз того, что стоит ожидать на каждом из уровней и перенять какие-то практики.

Уровень 1. Физический уровень.
Проблемы:
— Отсутсвие железа на складах
— Уход вендоров с рынка, закрытие офисов
— Бан у вендоров из-за санкций

Уровень 2-3. Связанность.
Проблемы:
— Блокировка сервисов и пользователей по геолокации
— DDos-атаки
— Уход провайдеров (магистральных)

Уровень 4-7. Сервисы.
Проблемы:
— Отзыв TLS сертификатов
— Проблемы с продлением или трансфером доменов
— Проблемы с облачными сервисами

Обходные пути:
— Оплата через другие юрисдикции
— Использование российских сервисов и облаков
— Параллельный импорт

Что можно попробовать спрогнозировать:
— Вероятные проблемы с банковским обслуживанием
— Цифровой суверенитет и железный занавес
— Если очень хочется — работать можно
— Использование сервис-провайдеров для обслуживания железа
— Ослабление санкций
— Появление новых логистических коридоров

Еще раз перечитал свой конспект — получилось весьма сухо. За каждым пунктом скрываются много комментариев и трейдофов, поэтому я рекомендую посмотреть полную версию доклада, когда она будет доступна.

https://highload.ru/foundation/2022/abstracts/8968

#highload #osi #sanctions

Симптомы распределенного монолита.

Распределенный монолит возникает, когда структура организации и код разъезжаются, но все еще тесно связаны. Это становится проблемой, если масштаб системы продолжает увеличиваться, а всеми ее частями все еще нужно управлять вместе — это замедляет и увеличивает риск любых изменений.
Симптомы распределенного монолита:
— Когда новая функциональность затрагивает параллельную разработку во многих сервисах
— Когда у сервисов есть общие базы данных или очереди
— Когда количество передаваемых параметров между сервисами быстро растет
- Когда сервисы и компоненты шарят общий бойлерплейтный код
— Когда версионность эндпоинтов сервисов важна
— Когда сервисы циклично зависят друг от друга

Одна из приведенных статей говорит, что есть только два выхода: жить с этим или “перекомпоновать” бизнес-логику, что не стоит себя обманывать и небольшими итеративными изменениями тут не обойтись, вы согласны?

https://medium.com/codex/6-symptoms-of-a-distributed-monolith-78a097320ebb
https://www.techtarget.com/searchapparchitecture/tip/The-distributed-monolith-What-it-is-and-how-to-escape-it

#monolith #distibuted #macroservices #microservices #medium #en

Метрики инцидентоного менеджмета.
MTBF, MTTR, MTTA, and MTTF.
https://www.atlassian.com/incident-management/kpis/common-metrics

Ранее мы немного касались практик инцидентного менджмента, давайте поговорим немного подробнее про метрики, на которые можно и нужно смотреть.
Зачем они нужны? Недостаточно просто считать как часто мы падаем, важно понимать — на что конкретно мы тратим время при починке и как сделать так, чтобы свести это время к минимуму.
Самая, наверное, показательная статья по этому поводу у atlassian, ее и берем за основу.

Каждое падение сервиса и время на его починку — это сгоревшие заказы, потерянные подписки, недовольные клиенты, другими словами — деньги. Поэтому очень важно как быстро вы восстанавливаетесь после выхода из строя. Для этого существует куча достаточно популярных метрик измерения эффективности вашего инцидентного менеджмента:

MTBF (Mean time between failures) — среднее время между факапами. Очевидно, что чем больше значение этой метрики, тем более надежная ваша система.

MTTR (mean time to repair) — среднее время на починку. Считается от начала работ на починку до того момента, когда сервис снова стал доступен. Как считать: берем время, которое сервис был недоступен и делим на количество падений за тот же период.

MTTR (mean time to recovery) — среднее время на восстановление. Считается от момента поломки до полного восстановления сервиса. Как считать: берем время, сколько лежали за определенные период и делим на количество инцидентов за тот же период.

MTTR (Mean time to resolve) — среднее время на решение причины проблемы. Включает не только время от возникновения проблемы до починки, но и время на то, чтобы добиться, что такая проблема больше не воспроизводилась.

MTTR (Mean time to respond) — среднее время реакции на проблему. Тут все просто — это среднее время от момента, как мы получили алерт до момента, когда восстановились.

MTTA (Mean time to acknowledge) — а это время от алерта до начала работ по ее починке, другими словами - как долго мы понимали, что сломалось и как чинить.

MTTF (Mean time to failure) — среднее время между неповторяющимися (из-за одной причины) проблемами.

Что хочется добавить: нормальная практика адаптировать метрики под свои нужды. Если что-то удобнее и показательнее считать иначе - стоит делать так, как удобно для вас. У вас есть метрики о том, как быстро вы восстанавливаетесь после падения?

https://www.atlassian.com/incident-management/kpis/common-metrics

#practices #managment #incidents #metrics

Цифры latency, которые должен знать каждый программист.

Наткнулся в очередной раз на ссылку с цифрами времен задержек ответов от разных ресурсов.

Из интересного:
— 0.5нс — ответ от кэша первого уровня (L1)
— 7нс — ответ от кэша второго уровня (L2)
— 25нс — взять мьютекс
— 100нс — ответ от оперативной памяти
— 500,000нс (0.5мс) — round trip в том же датацентре
— 150,000,000нс (150мс) — отправить пакет CA->Netherlands->CA

Прочитать 1мб:
— 0.4мс — с оперативной памяти
— 1мс — с SSD
— 20мс — с HDD

https://gist.github.com/jboner/2841832

Архитектура распределенных систем или как пройти System Design интервью.

Недавно выступал с лекцией в МГУ "Архитектура распределенных систем на примере задачи о назначении в такси". Была цель объяснить базовые принципы и заодно дать какой-то понятный план того, что интервьюер ждет от кандидата на архитектурной секции. Получилась вполне самодостаточная подсказка.

4 августа в Москве будет Plus Camp - эвент для техлидов и тимлидов, который устраивают наши сервисы Яндекса Go и Плюс.

Я буду участвовать в подкасте, где расскажу про алгоритмы под капотом Яндек Go.
А еще в дебатле с Женей Смирновым @not_boring_ds, руководителем ML лаборатории в Альфа-Банке почеледжу миф о том, что программистов скоро заменит ИИ.

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

Хоть меня и попросили опубликовать этот пост наша devrel команда, это не отменяет крутости этого мероприятия, с кем-то встретимся на Белорусской, а для других опубликую запись подкаста про алгоритмы, не пропустите.

Инструменты для большой миграции на примере опыта Netflix с GraphQL
https://netflixtechblog.com/migrating-netflix-to-graphql-safely-8e1e4d4f1e72

На глаза попалась череда статей Netflix о переезде на GraphQL. Если хочется углубиться во все детали, то в конце поста все релевантные ссылки. Я же хочу вынести ключевые, как мне кажется, инструменты, которые могут пригодиться для большой миграции. Будь это какие-то технические или продуктовые изменения, рецепты того, как раскатывать большие фичи, примерно одинаковые, но будут на примере опыта из статей с GraphQL.

Итак, вы собрались релизить большую фичу, вы выкатили ее на продакшн, естественно, рядом с тем решением.
Инструментарий:

1. АБ-тестирование.
Нетфликс берет две равные аудитории клиентов: по 1 млн пользователей. Первая группа пользуется старым API, на вторую включается клиент с походом в GraphQL. Тестируется именно клиентская часть — клиент сам выбирает куда идти. На какие метрики смотреть: сравнение рейта ошибок на обоих группах, задержек итп. На клиентах замеряется и сравнивается метрика QoE (оценка качества восприятия пользователем).

2. Replay Testing — валидация на масштабе.
Если запросы клиентов идемпотентны, то можно перед двумя решениями поставить Gateway, который будет ходить в оба решения и сравнивать результаты. На примере Netflix, оба решения должны базово давать одинаковые результаты, поэтому достаточно просто было найти, в каких случаях новое решение на GraphQL дает ответ, отличающийся от легаси решения (просто сравнивая и логируя json’ы от обоих решений).

3. Sticky Canary
Хз как точно перевести. Решение очень похожее на AB тестирования, но только со стороны бекенда: для новой схемы на бекенде заводится отдельный кластер для нового решения и Gateway (который умеет роутить на старое или новое решения). Пользователи при этом “приклеиваются” к одному из кластеров и живут на нем. На что смотреть: в сравнении по кластерам задержки, рейты ошибок, логи, утилизацию ресурсов, QoE, другие метрики здоровья сервиса.


— о миграции Netflix на GraphQL
— о предпосылках к GraphQL
— о миграции более подробно часть 1
— о миграции более подробно часть 2

Как по закону Конвея можно зафакапить внедрение DDD.

Мы пишем микросервисы. Дальше еще больше микросеврисов, затем еще и еще до того момента как общая картинка перестает умещаться в голове даже самого опытного инженера. А как мы знаем, любую архитектурную проблему можно решить дополнительным слоем абстракции. Появляется идея внедрить DDD.
DDD — не новая методология, о который мы тут не так часто говорим, но которая призвана, добавив слой абстракции (домены), снизить связанность, возвести заборы (bounded context) и открыть новые возможность масштабирования.
С помощью DDD хочется порешать сразу несколько проблем:
— Cильная связанность микросервисов.
— Отсутсвие Observability.
— Проблемы нечетких зон ответственности.
Дальше идут классические подходы к выделению доменов — задача декомпозируется, делегируется командам и те идут дизайнить свое виденье бизнес-сущностей.

В чем ту проблема? Стоит обратиться к классическому закону Конвея:
Современная его трактовка  — «Если архитектура системы и архитектура организации противоречат друг другу, победу одерживает архитектура организации» (по версии Рут Малан).

Команды, исторически образовавшиеся в результате роста компании почти всегда уже поделены по четким зонам ответственности. Если внедрение DDD будет происходить через делегирование нарезание бизнес сущностей командам — вы с немалой вероятностью просто проделаете бюрократическую работу по описыванию зон ответственности, уже закрепленных за существующими командами.

Пример — сервис заказа пиццы. Одна команда отвечает за флоу создания заказа, другая — за его назначения курьеру. Делегировав командам описывать домены, можно получить две бизнес сущности об этом и том же — пользовательский заказ и заказ курьерский. То, что, возможно, одна бизнес сущность — заказ, разъедется по понятиям и не выделится в отдельный домен, а всего лишь подчеркнет текущее разделение между командами.

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

https://www.uber.com/en-GB/blog/microservice-architecture/
https://cleverics.ru/digital/2020/12/conways-law-importance-teams-design/

Strangler Pattern

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

Основная идея паттерна состоит в том, что вы не беретесь “переписывать” весь монолит за раз, а просто блокируете написание новой функциональности в нем.

Новые фичи начинают с точки зрения разработки стоить дороже, ведь их теперь нужно выносить в отдельный микросервис. И не просто писать новый код в новом микросервисе, но и выносить из монолита зону ответственности, в которую новая функциональность входит.
Функциональность, которая выезжает из монолита, при этом заменяется “походом” в новые сервисы. Монолит превращается в фасад.
Старый код при этом может какое-то время оставаться в монолите и даже использоваться как фолбек или дополнительная сверка работы новой логики.

Дополнительные затраты на вынос старой логики из монолита размазываются во времени и не сильно влияют на time-to-market продукта.

Через какое-то время монолит переписывается, зоны ответственности разъезжаются по микросервисам, снижается связанность.

Есть минусы/консерны у подхода, заслуживающие внимания:
— Большая фича в новой концепции может стоить очень дорого из-за того, что придется переписать большой кусок монолита.
— Можно неправильно выделить зоны ответственности из монолита, потому что будет желание “переписать поменьше”.
— Дополнительно могут возникать затраты на вынос из монолита зон ответственности, от которых ваша функциональность зависит, например, хранилища каких-то данных.

https://microservices.io/patterns/refactoring/strangler-application.html
https://serverspace.ru/about/blog/pattern-mikroservisa-strangler/
https://www.geeksforgeeks.org/strangler-pattern-in-micro-services-system-design/

Яндекс всё.

Пару недель назад я сдал бейдж. 7 лет назад я стоял у истоков Яндекс Go, мы прошли большой и тернистый путь роста от стартапа в рамках всей компании до большого энтерпрайза с 44 млн MAU. А пару недель назад я, как CTO Go New Ventures, отвечал за запуски новых стартапов, уже внутри Яндекс Go - такая спираль, которая прокрутилась на 360.
И как говорится - пришло время выходить из зоны комфорта и двигаться дальше.
Для канала - это значит новый виток. Моя новая роль, ради которой я оставил Яндекс, подразумевает еще больше свежих взглядов и смелых решений - контента, которым я хотел бы продолжать тут делиться.

Stay tuned. Если интересно продолжение персональной истории - ставьте лайк. Если нет - новый пост уже на подходе. Делитесь ссылкой на канал с коллегами @startup_architecture - рост числа читателей сильно мотивирует писать.

Антологии технологий Яндекс Такси про изнанку сервиса.

Записали серию Антологии Такси о том, как работает Яндекс Go под капотом. Я даже попытался показать схематично на доске как все работает на уровне микросервисов.

Кстати, местный мем: когда я 7 лет назад пришел в такси, мы решили нарисовать все микросервисы Такси на стене кухни (БЦ Аврора на Павелецкой) со всеми связями между ними. Спустя пару часов мы израсходовали всю стену и бросили эту идею. Через пару дней схема уже была outdated. Но до сих пор по чатам гуляет фотография этой стены с 20-30 микросервисами. С тех пор их количества выросло до примерно 1000 штук. Надеюсь, ни у кого похожей идеи визуализации не возникает.

https://www.youtube.com/watch?v=GR7za5CWpxA

System Design Master Template.
https://medium.com/javarevisited/how-to-crack-system-design-interviews-in-2022-tips-questions-and-resources-fcad05e2dab

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

PS: если у вас есть другие полезные макеты по теме, поделитесь в комментариях.

Если хочется копнуть глубоко в тему архитектуры, то вот большой репозиторий с актуальными концептами системного дизайна:
https://github.com/ByteByteGoHq/system-design-101

Software Architecture and Design Trend 2023.

Наткнулся на исследование архитектурных трендов 2023 года. Почему это важно, если год почти закончился? Чтобы технологиях или практика стала инструментом большинства, она должна пройти через все стадии жизненного цикла продукта (по Роджерсу). То, чем пользуются сегодня только инноваторы, завтра может стать стандартом индустрии. Поэтому важно смотреть на то, какие технологии и практики в этом году вошли в стадии Innovators и Early Adopters.

Innovators:
— LLM или большие языковые модели окажут значительное влияние: от помощи в понимании архитектурных компромиссов до расширения возможностей нового поколения low-code и no-code разработчиков.
— Software Supply Chain Security или Безопасность цепочки поставки ПО.
— Design for Sustainability — нацеленность на снижение углеродный след (как часто лично вы задумываетесь? Что по утилизации ресурсов?)
— GraphQL Federation
— Policy as Code
— HTTP/3
— dApps — децентрализованные приложения.

Early Adopters или получающие распространение:
— Design for Portability получает все большее распространение (такие платформы как Dapr ориентированы на то, чтобы дать архитекторам возможность еще больше абстрагироваться от деталей реализации).
— Data-Driven Architecture — архитектура, управляемая данными.
— Architecture as a Team Sport — архитектурура больше не задача “Архитекторов”, а командная работа. Широкое признание ADR как способ работы команды над архитектурой приложения.
— WebAssembly (Server-side and Client-side)
— Design for Security
— Design for Resilience
— Design for Observability
— Micro Frontends
— AsyncAPI
— Workflow and Decision Automation Platforms
— Low Code / No Code

https://www.infoq.com/articles/architecture-trends-2023/
https://danielfoo.medium.com/software-architecture-and-design-trend-2023-f55ecfbcfcc0

What’s next?

В октябре прошлого года я оставил Яндекс позади. Наверное, пришло время сформулировать продолжение...
Я, в роли технического директора, присоединился к очень крутой команде AI-Center Тинькофф.

Мы делаем какие-то фантастические штуки — от умной камеры и секретаря, который может отвечать за вас на звонки, до умной поддержки пользователей, которая экономит миллиарды, и где нужно задизайнить LLM революцию.
У нас очень архитектурно сложные системы (представьте себе, как спроектировать бота, который должен отвечать на звонки) с огромным количеством интеграций и (спойлер) проблемами с этими интеграциями, сложности с обеспечением надежности и деливери, и при этом очень крутая команда. В общем, за эти первые 3 месяца у меня понабралось контент — присаживайтесь поудобнее =)

GPT как оркестратор микросервисной архитектуры?

Мы знаем, что GPT-модели могут писать SQL-запросы или код. Новая парадигма — А что если GPT будет формировать пользовательский флоу в архитектуре нашего сервиса?

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

Что если мы опишем базовые функции нашего сервиса и дадим GPT возможность самому конструировать пользовательские сценарии?

Я решил сделать сервис заказа еды. У меня есть несколько функций системы, про которые я рассказываю ассистенту:
- make_order([{item, count}])
- cancel_order…
Дальше я прошу ассистента обслужить пользователя — GPT может самостоятельно составить цепочку вызовов, которые нужно совершить для того, чтобы понять, что хочет пользователь, и сходить в нужные сервисы.
GPT выступает как замена части бизнес-логики приложения, отвечающей за формирование пользовательского пути по вашей архитектуре.
Просто посмотрите пример.

Такое становится доступным благодаря подходу RAG (Retrieval-Augmented Generation), когда обученной на большой базе знаний модели (GPT) на вход подсовывают динамический контекст (описание сервиса заказа еды). Если хочется начать углубляться — можно начать отсюда: https://habr.com/ru/articles/779526/

Как вы используете GPT-ассистентов? Спрашиваете советы или строите поверх системы и продукты?

Подход Change Data Capture как способ реактивного взаимодействия сервисов.
https://habr.com/ru/companies/yandex_cloud_and_infra/articles/754802/

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

Для решения подобных задач на помощь приходит подход Change Data Capture (CDC) или “Захват изменения данных”.

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

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

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

Какую функциональность можно реализовать с помощью этого подхода:
— Репликация (Другая БД? DWH?)
— Обновление и инвалидация кэшей
— Экспорт данных в поисковые движки (Elastic?)
— Аудит изменений в БД
— Передача состояния другим сервисам

https://habr.com/ru/companies/yandex_cloud_and_infra/articles/754802/
https://en.wikipedia.org/wiki/Change_data_capture