Описывает верхнеуровневую архитектуру и технологии. Используется для понимания технологического стека и разделения зон ответственности.
Элементы: - контейнеры (например, веб-приложения, базы данных),
У вас пример в GetDelivery почему-то БД помещена на уровень компонентов, в то время как в других диаграммах она на уровне контейнеров. Примеры из интернета тоже помещают БД на уровень контейнеров. Да и ваши слова намекают на то, что БД должны быть на уровне контейнеров.
Почему тогда GetDelivery не содержит БД на уровне контейнеров?
Обеспечьте graceful shutdown контейнера с помощью SIGTERM
Не знаю как сейчас, а раньше в кубере была проблема с тем, что просто слушать SIGTERM недостаточно. Нужно было еще дополнительно подождать несколько секунд после завершения. Подробности раскрыты в докладе Артемия Рябинкова про graceful shutdown - https://youtu.be/me5iyiheOC8?list=PLknJ4Vr6efQHYJio6GSXdtYvW693En54B&t=1151
Кстати, кто-нибудь знает - исправили ли этот косяк в кубере или этот костыль до сих пор актуален?
Присоединюсь к комментарию, но еще добавлю из своего опыта.
Со второго курса уже занимался промышленным программированием параллельно с учебой. В частности, пытался решать уравнения в частных производных или цифровой обработки сигналов.
И я хочу сказать, что даже в программировании математики, на мой взгляд, нейминг одной-двумя буквами более оптимален: - Формулы, как правило, очень длинные. Поэтому если выбирать человекопонятные имена переменных (например, speed вместо v), то формула вылезет за пределы экрана и будет тяжела как в поддержке, так и чтении - Как правило, никто в математике не оперирует длинными названиями переменных. Поэтому та же самая v будет узнаваться быстрее. А вот speed - медленнее, т.к. мозгу нужно будет в голове смапить speed обратно в v, что отнимает ресурсы. Так что одно-двухбуквенные имена лучше оставлять в таких задачах как минимум ради ubiquituous language
Требований нет. Универсальный критерий - количество обращений в поддержку. Пока нам не жалуются на кейсы, связанные с регистрацией, мы считаем, что все ок.
Если речь о том, чтобы дождаться другой саги, то да - это уже более сложный кейс. Я согласен с тем, что описанный выше подход не очень хорошо ложится на него.
По поводу производительности оркестраций - со стороны бизнеса требования отсутствуют. Для нас как для разработчиков главное, чтобы количество обращений в поддержку был как можно меньше. Тут нет четких критериев, но выбранный выше критерий, который состоит в том, чтобы за час все необходимые шаги завершались, нас полностью устраивает.
По взаимодействию разных сценариев - если честно, не очень понял вопрос(
Если воркер саг завис в промежуточном состоянии, то зависшие саги "отпустит" другой воркер. Об этом я писал выше в разделе "Обработка ошибок зависших воркеров". Все выполненные шаги хранятся как раз в саге.
Кстати, по поводу workflow. Если я правильно понимаю, то мы как раз и сделали нечто подобное temporal, только без сторонней библиотеки. Разве не так?
Я заметил, что, похоже, у нас внутри не используют ни cadence, ни temporal.
Может быть дело было в неосведомленности. Но могут быть и трудности интеграции с инфраструктурой. Дело в том, что у нас используется внутренний фреймворк, который реализует паттерн "Микросервисные шасси" - https://microservices.io/patterns/microservice-chassis.html . Он решает многие вопросы интеграции инфраструктуры. Возможно, запуск стороннего сервиса может потребовать доработки напильником.
Как бы там ни было, спасибо за наводку! Решение выглядит интересным, особенно если нет каких-то инфраструктурных ограничений
Действительно, поскольку хореографическая сага на уровне одного сервиса - это всего лишь выполнение какого-либо действия по команде/сообщению, то порой бывает трудно сказать, где она есть, а где - нет.
А вот момент про монолит меня немного смутил. Почему оркестрационная сага является монолитом, если она обращается к другим сервисам? Мне казалось, такой подход позволяет инкапсулировать сложную логику в отдельных сервисах, разве не так?
Можете, пожалуйста, пояснить - в чем проблема с логикой?
Мне казалось, описанная выше логика проста - процесс максимально прямолинеен. Каждое условие посвящено вопросу - выполнен шаг или еще нет. Оно нужно исключительно для того, чтобы понять, с какого шага нужно допроходить сагу
Можете, пожалуйста, рассказать о своем подходе к решению задач по System Design?
А именно - почему расчет ресурсов идет до того, как выбираются технологии? Разве количество ресурсов (размер базы, количество серверов) не зависит от выбранных технологий и высокоуровнего дизайна?
Подскажите, пожалуйста, правильно ли я понимаю, что в картинке с индексом, построенном по сигнатурам документа, правым узлом на верхнем уровне должен быть 1111011, а не 111011 ? (т.е. потерялась первая единица)
Да, действительно. Я уже выше отметил, что переход на fasthttp решил бы проблему в том плане, что там более удачные настройки пула соединений по умолчанию.
Правда, я не очень понимаю, почему стандартная библиотека не рассчитана на полноценное использование в продакшне. Увы, я не смог найти мнения о том, что net/http вообще не стоит использовать. Буду рад, если подскажете, почему так не стоит делать)
Конкретно в данном случае использовался HTTP/1.1 с Keep-Alive.
В HTTP/2, насколько я знаю, проблема не стоит так остро, поскольку там используется мультиплексирование соединений. Однако чтобы использовать HTTP/2, нужно заморочиться с настройкой TLS. Полагаю, именно по этой причине в моей ситуации использовался HTTP/1.1
У вас пример в GetDelivery почему-то БД помещена на уровень компонентов, в то время как в других диаграммах она на уровне контейнеров. Примеры из интернета тоже помещают БД на уровень контейнеров. Да и ваши слова намекают на то, что БД должны быть на уровне контейнеров.
Почему тогда GetDelivery не содержит БД на уровне контейнеров?
Не знаю как сейчас, а раньше в кубере была проблема с тем, что просто слушать SIGTERM недостаточно. Нужно было еще дополнительно подождать несколько секунд после завершения. Подробности раскрыты в докладе Артемия Рябинкова про graceful shutdown - https://youtu.be/me5iyiheOC8?list=PLknJ4Vr6efQHYJio6GSXdtYvW693En54B&t=1151
Кстати, кто-нибудь знает - исправили ли этот косяк в кубере или этот костыль до сих пор актуален?
Присоединюсь к комментарию, но еще добавлю из своего опыта.
Со второго курса уже занимался промышленным программированием параллельно с учебой. В частности, пытался решать уравнения в частных производных или цифровой обработки сигналов.
И я хочу сказать, что даже в программировании математики, на мой взгляд, нейминг одной-двумя буквами более оптимален:
- Формулы, как правило, очень длинные. Поэтому если выбирать человекопонятные имена переменных (например,
speedвместоv), то формула вылезет за пределы экрана и будет тяжела как в поддержке, так и чтении- Как правило, никто в математике не оперирует длинными названиями переменных. Поэтому та же самая
vбудет узнаваться быстрее. А вотspeed- медленнее, т.к. мозгу нужно будет в голове смапитьspeedобратно вv, что отнимает ресурсы. Так что одно-двухбуквенные имена лучше оставлять в таких задачах как минимум ради ubiquituous languageDistinguished engineer - это высший грейд инженера в некоторых компаниях (например, Amazon)
Подробнее про грейды можно почитать вот здесь - https://www.levels.fyi/
Требований нет. Универсальный критерий - количество обращений в поддержку. Пока нам не жалуются на кейсы, связанные с регистрацией, мы считаем, что все ок.
Если речь о том, чтобы дождаться другой саги, то да - это уже более сложный кейс. Я согласен с тем, что описанный выше подход не очень хорошо ложится на него.
Да, только по таймеру
Либо такого пока еще нет, либо я о нем просто не осведомлен
По поводу производительности оркестраций - со стороны бизнеса требования отсутствуют. Для нас как для разработчиков главное, чтобы количество обращений в поддержку был как можно меньше. Тут нет четких критериев, но выбранный выше критерий, который состоит в том, чтобы за час все необходимые шаги завершались, нас полностью устраивает.
По взаимодействию разных сценариев - если честно, не очень понял вопрос(
Если воркер саг завис в промежуточном состоянии, то зависшие саги "отпустит" другой воркер. Об этом я писал выше в разделе "Обработка ошибок зависших воркеров". Все выполненные шаги хранятся как раз в саге.
Кстати, по поводу workflow. Если я правильно понимаю, то мы как раз и сделали нечто подобное temporal, только без сторонней библиотеки. Разве не так?
Действительно. Исправил, спасибо!
Честно говоря, не знаю)
Я заметил, что, похоже, у нас внутри не используют ни
cadence, ниtemporal.Может быть дело было в неосведомленности.
Но могут быть и трудности интеграции с инфраструктурой. Дело в том, что у нас используется внутренний фреймворк, который реализует паттерн "Микросервисные шасси" - https://microservices.io/patterns/microservice-chassis.html . Он решает многие вопросы интеграции инфраструктуры. Возможно, запуск стороннего сервиса может потребовать доработки напильником.
Как бы там ни было, спасибо за наводку!
Решение выглядит интересным, особенно если нет каких-то инфраструктурных ограничений
Действительно, поскольку хореографическая сага на уровне одного сервиса - это всего лишь выполнение какого-либо действия по команде/сообщению, то порой бывает трудно сказать, где она есть, а где - нет.
А вот момент про монолит меня немного смутил. Почему оркестрационная сага является монолитом, если она обращается к другим сервисам? Мне казалось, такой подход позволяет инкапсулировать сложную логику в отдельных сервисах, разве не так?
Можете, пожалуйста, пояснить - в чем проблема с логикой?
Мне казалось, описанная выше логика проста - процесс максимально прямолинеен. Каждое условие посвящено вопросу - выполнен шаг или еще нет. Оно нужно исключительно для того, чтобы понять, с какого шага нужно допроходить сагу
Можете, пожалуйста, рассказать о своем подходе к решению задач по System Design?
А именно - почему расчет ресурсов идет до того, как выбираются технологии? Разве количество ресурсов (размер базы, количество серверов) не зависит от выбранных технологий и высокоуровнего дизайна?
Подскажите, пожалуйста, правильно ли я понимаю, что в картинке с индексом, построенном по сигнатурам документа, правым узлом на верхнем уровне должен быть
1111011, а не111011? (т.е. потерялась первая единица)Правда, я не очень понимаю, почему стандартная библиотека не рассчитана на полноценное использование в продакшне. Увы, я не смог найти мнения о том, что net/http вообще не стоит использовать. Буду рад, если подскажете, почему так не стоит делать)
Насколько я вижу, в ней есть похожая настройка, однако параметр по умолчанию уже совершенно другой:
Поэтому, как вы верно заметили, описанная в статье проблема невозможна в случае использования FastHTTP.
Я посчитал, это позволит воспринять статью в более легком стиле.
Буду иметь в виду, что могут быть подобные проблемы при восприятии диаграммы.
В HTTP/2, насколько я знаю, проблема не стоит так остро, поскольку там используется мультиплексирование соединений. Однако чтобы использовать HTTP/2, нужно заморочиться с настройкой TLS. Полагаю, именно по этой причине в моей ситуации использовался HTTP/1.1