Speaker A
Начнём с интеграции. Есть система А, есть система Б.
Разбор собеседования на системного аналитика в банк: REST vs SOAP, идемпотентность методов HTTP, PUT и PATCH, DELETE, stateless/stateful и вопросы интеграций.
Key Takeaways
- Для собеседования на системного аналитика важно уверенно знать HTTP-методы и их идемпотентность
- PUT и PATCH различаются по полноте изменения ресурса, и это важно для проектирования API
- REST и SOAP отличаются гибкостью, форматом данных и областями применения
- Кандидат показывает неуверенность в базовых понятиях, что ведёт к выводу о необходимости подготовки
What the video covers
- Кандидат разбирает типы интеграций между системами: REST, SOAP, веб-хуки, брокеры сообщений, прямой доступ к БД
- Объясняется REST как архитектурный стиль взаимодействия систем по HTTP и его ограничения (stateless, единообразие интерфейса)
- Разбирается идемпотентность методов: GET, DELETE, PUT идемпотентны, POST и PATCH — нет (в зависимости от реализации)
- Обсуждается разница между PUT (полная замена ресурса) и PATCH (частичное изменение)
- Рассматривается массовое удаление объектов через DELETE с передачей списка идентификаторов
- Сравниваются REST (гибкий, чаще JSON) и SOAP (строгий, XML, WSDL, чаще в банковских системах)
- Упоминаются контракты API через Swagger/OpenAPI и JSON Schema
- Обсуждается идемпотентность POST через ключ идемпотентности
- Затрагиваются микросервисные паттерны, гарантии доставки (at least once, exactly once, at most once) и реляционные/нереляционные БД
- Разбираются практические задачи на масштабирование чтения данных и обработку событий
Chapters
Full Transcript — Download SRT & Markdown
Speaker A
Что ещё есть? Можно использовать вебху, когда нужно какое-то уведомление, допустим, по событию. Что [откашливается] ещё? Ну так, тактак, тактак.
Speaker A
Угу. Как можно их соединить?
Speaker A
Угу. А есть ещё синхронная синхронная синхрон SUAP у нас синхронный, а синхронные брокеры. Угу. А могу лисинхронными методами реализовать асинхронную интеграцию?
Speaker A
Угу. Так. Система 7Б. Ну, по сути, какие у нас есть интеграции? У нас [фыркает] м, есть СТ, есть SUAP, есть брокеры сообщений, там Кавкарабит.
Speaker A
Ну, смотри, так что надо подумать. То есть нам ответ сразу вот у меня есть только рестовые методы.
Speaker A
Что ещё есть? Можно использовать вебхуки, когда нужно какое-то уведомление, допустим, по событию. Что [откашливается] ещё? Ну так, так, так.
Speaker A
Ну да, хорошо. А что такое рест вообще? Так, ну рест архитектурный стиль. М получается так. Ну смотри, - это архитектурный стиль, ну для взаимодействия, ну банальной систем по HTTP. Вот у нас выделяют методы там, не знаю, ну, точнее знаю get
Speaker A
Ну вот так пока что в голову пришло. А БД ещё, условно, тоже можно вызвать.
Speaker A
Так, по ограничениям ну ипотентность, наверное. А или ты, может, имеешь в виду типа или или что?
Speaker A
Угу. А есть ещё синхронные... синхронные, синхрон. SUAP у нас синхронный, а брокеры... Угу. А могу ли синхронными методами реализовать асинхронную интеграцию?
Speaker A
единообраз [откашливается] интерфейса. Вот так вот. Угу. Ну, наверное, так. Хорошо. А если я не буду соблюдать ограничение реста, вот эти правила, будет ли это считаться рестапи?
Speaker A
Угу. Ээ, да. Ээ, можно, то есть ну да, думаю, можно. Ну, к примеру. Угу.
Speaker A
английскими буквами русское слово написать и типа всё новое будет. Угу. О'кей. Хорошо. У меня есть чат на сайте. Он statless или stateful?
Speaker A
Ну, смотри, так что надо подумать. То есть нам ответ сразу... вот у меня есть только рестовые методы.
Speaker A
ну, контекст такой какой-то у нас существует, поэтому должен быть стать. Угу. О'кей. [откашливается] Statless - это просто бы, наверное какая-нибуд формочка была бы. Э там вот так, то есть было быстрее.
Speaker A
Могу я синхронно как-то глобально интеграцию с помощью них сделать? Ну, с помощью вебхуков, может быть, можно здесь... ро.
Speaker A
Но получается у нас ещё с у нас чаще работает с жесоном. Ну, смлем тоже, но чаще жесоном SUAP с XМ. Ээ так. Что ещё?
Speaker A
Ну да, хорошо. А что такое REST вообще?
Speaker A
Ну да, в общем, рест такой более гибкий. А SUAP более строгий и чаще он используется на каких-то ээ ну типа банковских системах, что-то такое. Ну я имею в виду, да, вот так.
Speaker A
Так, ну, REST — архитектурный стиль. М, получается так. Ну смотри, это архитектурный стиль для взаимодействия систем по HTTP. Вот у нас выделяют методы: там, не знаю, ну, точнее, знаю: GET, DELETE — это у нас идемпотентные; POST, PATCH — неидемпотентные. Ну, сейчас другие методы, но пока так, если... Угу.
Speaker A
Вот. Да, для Сапи весь день. А ты спросил? Ой, да, [откашливается] хорошо. Могу ятом что-то создать на сервере, не получить информацию, а именно создать ресурс какой-нибудь методом get.
Speaker A
А какие есть ограничения в REST?
Speaker A
Типа задания тампу. Хорошо. Э, [фыркает] а вот в чём разница между пт и патч?
Speaker A
Так, по ограничениям — ну, идемпотентность, наверное. А или ты, может, имеешь в виду типа... или что?
Speaker A
То есть точечное изменение такое. А есть ли какие-то уникальные кейсы, когда я должен использовать только пуд вместо патч или наоборот?
Speaker A
Ну, я имею в виду кэширование. [фыркает] Ну, правила REST... Ага. Ну, stateless, ну, единообразие этого...
Speaker A
только если отдельно что-то уникальное? Не знаю, наверное. Угу. Ну, о'кей, хорошо. Как методом Delete удалить множество объектов с сервера?
Speaker A
Единообразие [откашливается] интерфейса. Вот так вот. Угу. Ну, наверное, так. Хорошо.
Speaker A
И так удаляем. Угу. На что в параметрах мы будем передавать? [фыркает] Ну, мы будем передавать это ещё раз мы удаляем с сервера какую-то Ещё раз повтори, пожалуйста, вопрос.
Speaker A
А если я не буду соблюдать ограничения REST, вот эти правила, будет ли это считаться RESTful?
Speaker A
Или мне нужно на каждой на каждое удаление свой deleteт дёргать? Угу. [фыркает] Так, ну мы можем, получается, список вот всех вот этих вот в тех объектов, которые нужно удалить в параметры, там в айдишники, в скобочках вставить эти, ну, которые нужно удалить.
Speaker A
Э, да. То есть можно по сути даже использовать другие методы, не те, которые у нас заданы, но это тоже будет REST. То есть мы можем какой-то [откашливается] другой вообще метод придумать, типа не GET, а, например, получить русское слово английскими буквами, написать — и типа всё, новое будет. Угу. О'кей. Хорошо.
Speaker A
Я правильно сказал? Все дептетные методы безопасны. Ну, смотри, ээ, иноплатетный метод значит, что при выполнении этого действия у нас ээ состояние будет одним и тем же. То есть ээ значит этот метод он, ну, не будет нам никак ну будет
Speaker A
У меня есть чат на сайте. Он stateless или stateful?
Speaker A
О'кей. Вот ты сказал, что патч недемпотентный, да? Угу. Всегда [фыркает] так всегда ли пач непотентный.
Speaker A
Чат на сайте. Ээ, так, смотри, ээ, если это фронт у нас, то будет так... [тяжело вздыхает] [вздыхает] Думаю, stateless... То есть сейчас — а, нет, подожди, у нас есть диалог какой-то, то есть контекст, тогда, наверное, stateful. Вот, потому что на, ну, контекст такой какой-то у нас существует, поэтому должен быть stateful. Угу. О'кей. [откашливается] Stateless — это просто бы, наверное, какая-нибудь формочка была бы. Э, там вот так, то есть было бы быстрее.
Speaker A
есть в путеликом ты спросил, ээ, всегда ли он недепотентный? И почему, кстати, он немпотентный?
Speaker A
Угу. Хорошо. [фыркает] А в чём принципиальное различие SOAP с REST?
Speaker A
100, и тогда будет всё время добавляться, как бы, изменяться. Это будет не депо. Угу. А когда мы 200 на 300 меняем?
Speaker A
Угу. Так, ну, вообще, ээ, REST он более гибкий, SOAP более строгий. Это если так просто объяснять. Но получается, у нас ещё, ну, у нас чаще работает с JSON. Ну, смол тоже, но чаще JSON. SOAP с XML. Ээ, так. Что ещё?
Speaker A
Смотри, да, 200 мы меняем. Не, подожди. Ну, смотря, смотри, ес если у нас частичное изменение, то есть мы пачем если полное, то путом.
Speaker A
А в этом в чего ещё? В SOAP у нас есть ВСДЛ. Э, так.
Speaker A
У, да. Что единственное применение такого метода, то есть, а если я просто хочу заменить 200 на 300 и дальше каждый раз буду менять на 300, 300 на 300, 300 на 300, тогда потно будет патч.
Speaker A
Ну да, в общем, REST такой более гибкий, а SOAP более строгий, и чаще он используется на каких-то ээ, ну, типа банковских системах, что-то такое. Ну, я имею в виду, да, вот так.
Speaker A
время будем менять на одно и то же число, как так получается? То есть он когда-то идумпотентный когда-то нет или как?
Speaker A
О'кей, хорошо. А мы при использовании REST можем где-то контракт описать?
Speaker A
Ладно, я понял. Да, вот это правильный ответ. Он может быть либо импотентным, либо нет. Это не исключение. Это просто разные варианты используется просто. Да. То есть, ещё раз повторю, то есть, если мы 200 на 300 меняем, это будет у нас и депотетным. Если мы
Speaker A
Угу. Да, контракт можем описать. Ну, наверное, Swagger, ты имеешь в виду?
Speaker A
Да, пост можно сделать потентентом с помощью ключа патентности. А где он формируется ключ импотентности?
Speaker A
Вот. Да, для SOAP — WSDL. А ты спросил?
Speaker A
Слышал что-нибудь про полиморфизм в джисон схемах? [вздыхает][тяжело вздыхает] Так, такое, наверное, не слышал. Ну, [откашливается] такие конструкции one of any of all of Не я знаю, что такое Jсон схема, но полиморфизм.
Speaker A
Ой, да, [откашливается] хорошо. Могу ли я что-то создать на сервере, не получить информацию, а именно создать ресурс какой-нибудь методом GET?
Speaker A
Смотри, да, то есть у нас есть реляционные, нереляционные базы данных. Реляционные - это у нас база данных, которая у нас есть связи между таблицами, то есть там строки-столбцы ээ из известных, там, не знаю, Mysql, Postg, там Oracle, например, [фыркает]
Speaker A
Угу. Так, ну, вообще, нам нужен для запроса создать. Ну, думаю, нет, я не встречал такого. Типа задания там...
Speaker A
ключей значений, графов. Вот так вот. Угу. [фыркает] А правда ли я скажу, что большинство СУБД отвечают только за манипуляцию данными?
Speaker A
Хорошо. Э, [фыркает] а вот в чём разница между PUT и PATCH?
Speaker A
Манипуляцию. Угу. Ну я думаю, все точно, большинство точно отвечают за манипуляцию, но они как бы в манипуляции ещё точно тоже отвечают за хранение и за поиск.
Speaker A
Смотри, ээ, PUT у нас создаёт объект, ээ, а, точнее, не так, нет, подожди, не тот сказал. PUT у нас получается полностью заменяет ресурс целиком, а PATCH только какую-то конкретную часть. То есть точечное изменение такое.
Speaker A
Угу. О'кей, хорошо. А продисхау, да? Редис - это у нас кэш. Кликхаус. Ну, слышал, но не работает.
Speaker A
А есть ли какие-то уникальные кейсы, когда я должен использовать только PUT вместо PATCH или наоборот?
Speaker A
Угу. О'кей. Смотри, а вот, например, он используется для кэша. Так, я могу в пазгре точно такую же структуру создать, но как бы да, вот, но м редис он м вопрос в чём типа почему мы всё-таки используем дис, а не
Speaker A
Так, подумать надо. PUT или PATCH, или наоборот. Ээ, ну смотри, да, то есть если нам нужно, ну, это не уникально, ещё раз, наверное, повторю: если у нас полностью мы меняем ресурс, то мы используем PUT, потому что PATCH мы не сможем использовать, а PATCH только если отдельно что-то уникальное? Не знаю, наверное. Угу. Ну, о'кей, хорошо.
Speaker A
Угу. О'кей хорошо. Ну, неправильно. [фыркает][смех] Пройдёт хранит данные в операционке. Аз гря на диск пишет. Ну, это так на будущее. Окей.
Speaker A
Как методом DELETE удалить множество объектов с сервера?
Speaker A
Это так. Я понимаю, что ты не не работал, поэтому можешь не знать. О'кей. Хорошо.
Speaker A
[фыркает] Так, методом DELETE удаляем множество с сервера. Ээ, так, ну, ты, может, про query-параметры тут говоришь. То есть можем передавать query-параметрами. И так удаляем. Угу.
Speaker A
А единый сект или единый апдейт является транзакцией или должен быть только набор? Типа ты имеешь в виду, если у нас в селекте несколько сказал, что это набор подзапросов, типа, да, что это набор запросов, которые выполняется как единое целое. Да,
Speaker A
На что в параметрах мы будем передавать? [фыркает] Ну, мы будем передавать... это ещё раз: мы удаляем с сервера какую-то... Ещё раз повтори, пожалуйста, вопрос.
Speaker A
А если у меня две транзакции обращаются в одно и то же время к одному объекту базы данных? Как решать такую ситуацию?
Speaker A
Ну вот мы удаляем не конкретную запись с сервера, а я хочу сразу много ресурсов удалить, но дёрнуть один метод. Как мне это сделать? Могу я где-то это всё передать? Или мне на каждое удаление свой DELETE дёргать?
Speaker A
Э, ну, с помощью, наверное, изоляции или, может быть, как-то можем блокировать ээ один запрос, чтобы выполниться другой.
Speaker A
Угу. [фыркает] Так, ну, мы можем, получается, список всех вот этих объектов, которые нужно удалить, в параметры, там в айдишники, в скобочках вставить эти, которые нужно удалить. Ну да, в целом окей.
Speaker A
[вздыхает] [тяжело вздыхает] Ну а, ну, возможно, тут про то, что м что-то может быть закомичено, что-то может быть не закомичено, там грязное чтение, что-то вот такое.
Speaker A
[фыркает] Я скажу тебе такую фразу: все идемпотентные методы безопасны. Я правильно сказал? Все идемпотентные методы безопасны.
Speaker A
Вот так. Угу. А фантомное чтение что такое? Это не слышал. Угу. Хорошо. А что такое?
Speaker A
Ну, смотри, ээ, идемпотентный метод значит, что при выполнении этого действия у нас состояние будет одним и тем же. То есть этот метод не будет нам никак... ну, будет безопасным.
Speaker A
Угу. [откашливается] Ну, вот так вот. Окей. А в нереаляционных БД есть что-то похожее на такая же аббревиатурка какая-нибудь.
Speaker A
А ты сказал: все безопасные методы идемпотентны или все идемпотентные методы безопасны? Да, тогда правильно.
Speaker A
Или может я придумал это? Ну, что-то, может быть, ээ, мм, может быть, ты имеешь в виду, что, мм, у нас в баз в неравнных базы данных как бы как бы всё равно у нас ээ ээ будет сохраняться то, что у нас данные
Speaker A
О'кей. Вот ты сказал, что PATCH неидемпотентный, да? Угу. Всегда [фыркает] ли PATCH неидемпотентен? Вообще, как он работает конкретно? Давай ещё раз проговорим.
Speaker A
[фыркает] Мм, ну, я думаю, если мы хотим, например, смотри да ээ как бы, если мы хотим, [фыркает] мм, не знаю, если система у нас какая-то там ээ жёсткая, там критичная там, не знаю, в банке, то нам и там цифры у У нас
Speaker A
Ну, смотри, PATCH у нас не удаляет, заменяет часть, ээ, частично обновляет ресурс. То есть ээ мы в нём отправляем только, ну, типа, те поля, которые нам нужно изменить. То есть в PUT целиком ты спросил, ээ, всегда ли он неидемпотентен? И почему, кстати, он неидемпотентен?
Speaker A
от консистентности. У нас будет ээ тогда медленней. Что-то что-то напутал. Ну, в общем, короче, консистентность там, мы отказываемся от консистентности, у нас будет медленнее.
Speaker A
Потому что, смотри, да, допустим, мы можем так сказать: допустим, нам нужно обновить сумму, допустим, к чеку добавить какую-то сумму. Вот. И мы можем, ээ, смотри, можем частично заменить: просто 200 на 300, а можем, ээ, написать «плюс 100», и тогда будет всё время добавляться, как бы, изменяться. Это будет не идемпотентно. Угу.
Speaker A
А если мы немножко отходим к концентности, тогда мы будем быстрее делать. Угу. Ну да.
Speaker A
А когда мы 200 на 300 меняем? [фыркает] Когда 200... А, стоп, стоп, стоп, стоп, стоп. Так. Ещё раз. 200 на 300 мы меняем.
Speaker A
О'кей, хорошо. А как ускорить работу с базой данных? Угу. Есть, да? Смотри, у нас есть горизонтальные и вертикальные пути масштабирования по горизонтальным или не давай.
Speaker A
Мм. У нас ээ каким методом? Не почему.
Speaker A
мы будем ускоряться. Можем добавить кэш, ээ, будем тоже ускоряться. Ээ, что ещё? Можем как-то оптимизировать запросы?
Speaker A
Смотри, да, 200 мы меняем. Не, подожди. Ну, смотря, смотри: если у нас частичное изменение, то есть мы PATCH, если полное, то PUT.
Speaker A
А репликация - это если мы вот полностью репрецируем данные. Угу. А партицирование. Что такое партицирование - это мм мы разделяем BD на части ээ и тоже раскидываем. Так, подожди, за запутался. Ну, смотри, партицинировани мы тоже, получается, делим BД на части. Вот. И
Speaker A
[вздыхает][тяжело вздыхает] Так, ну ты поменял. О'кей. Ты сказал, что ээ 200 на 300 — мы сделаем плюс 100 фактически, и тогда он неидемпотентен, потому что каждый раз будет снова плюс 100 прибавляться при каждом дёргании такой ручки.
Speaker A
Угу. Угу. Ну, что-то самые эти лёгкие не сказал. индексы, денормализация, что-нибудь такое. Знаешь, что такое индекс, да? То есть индекс это у нас условно такая структура, с помощью которой мы можем быстрее там искать данные там по колонкам, например.
Speaker A
У, да. Что единственное применение такого метода... То есть а если я просто хочу заменить 200 на 300 и дальше каждый раз буду менять на 300, 300 на 300, 300 на 300, тогда идемпотентно будет PATCH.
Speaker A
Угу. О'кей. Угу. А индексация? Вот у меня 50 колонок, я на все повешую индексы. Быстрее будет работать?
Speaker A
Э, смотри, так, давай ещё раз. Если это обновление в ресурсе, в каком-то, и вот там одна часть, вот 200 мы меняем на 300, это будет PATCH, и он будет ээ, получается, идемпотентным тогда. Ну, типа, если мы всё время будем менять на одно и то же число, как так получается? То есть он когда-то идемпотентен, когда-то нет, или как?
Speaker A
поиск. В маленькой подо, а в большой не будет. В большой будет в большой будет. Ну, с индексами будем ускоряться, потому что так система читала бы полностью всю BD, а с индексами сразу понимает, где чего искать.
Speaker A
Ну, получается, да, вот может быть вот исключение. Ну, короче, он может быть, то есть может быть идемпотентным, может быть неидемпотентным.
Speaker A
Ну и вообще как бы понятнее, логичнее становится структура. А нормализация - это всегда хорошо?
Speaker A
Ладно, я понял. Да, вот это правильный ответ. Он может быть либо идемпотентным, либо нет. Это не исключение. Это просто разные варианты использования. Да. То есть, ещё раз повторю: если мы 200 на 300 меняем, это будет у нас идемпотентно. Если мы добавляем плюс 100, то будет неидемпотентно. Да. Да. О'кей. Хорошо.
Speaker A
Угу. О'кей. Хорошо. Давай перейдём к Кавке. Угу. Мм, что это такое вообще? Кавка. брокер, не брокер.
Speaker A
А можно сделать POST идемпотентным?
Speaker A
позволяет, ну, асинхронно передавать события между сервисами. То есть там какой вообще какой ещё прикол [фыркает] условно? То есть у нас ээ продюсер отправляет сообщение в топик, потом ээ Кавка его м ну получается сохраняет ээ и ну как бы распределяет по консюмерам и
Speaker A
Да, POST можно сделать идемпотентным с помощью ключа идемпотентности. А где он формируется, ключ идемпотентности? На клиенте или на сервере?
Speaker A
консюмеры вычитывают инфу, типа сами у тебя. А в ребите там как вычитывают? [вздыхает][тяжело вздыхает] То есть ещё раз у нас последнее сообщение вычитывают или первое сообщение. Да. То есть, наверное, про офсет говоришь. Угу. Хорошо. Да.
Speaker A
Так, ну, смотри, можем ключ идемпотентности на клиенте, думаю. Угу. О'кей. Хорошо.
Speaker A
А разные партиции можно, короче, их можно параллельно разные консур могут параллельно их вычитывать. Вот так. То есть это как бы распределяем.
Speaker A
Слышал что-нибудь про полиморфизм в JSON Schema? [вздыхает][
Speaker A
Угу. Вот так. А у группы консюмеров один устат на всех [фыркает][вздыхает] или у каждого свой?
Speaker A
[тяжело вздыхает] Так. Ну, смотри, у них, ээ, думаю да один. То есть, если у нас групка зиров, то они по сути читают ээ Ну да, типа с одного места.
Speaker A
Угу. О'кей. А как подключить нового консюмера или подключить новую партицию? Будут у меня какие-то проблемы? [фыркает] Так, смотри, если мы подключаем нового консюмера, ээ, не знаю, может, у нас происходит какой-то мм ну, типа перераспределение ээ с Ещё раз мы подключаем консюмера.
Speaker A
Куда? Просто нового в группу, да? А просто нового, даже не в группу, а может надо в группу.
Speaker A
Угу. [фыркает] Мы, наверное, будем перераспределять, ээ, ну, в плане как будем перераспределять ээ сообщения между консюмерами, если мы новые добавляем.
Speaker A
Угу. А если новую партицу добавляем? Так, если мы добавляем партицию, так, ну, по сути, у нас старые, ну, как бы все, все консюмеры как бы читали старые, сейчас мы добавли новую, то по сути тоже мы будем переспрелять.
Speaker A
[откашливается] Угу. А как устроена репликация в кавке? Так, репликация, то есть, по сути, репликация, ну, на уровне партий, то есть мы можем, ээ, каждую партицию м ну типа реплетировать [откашливается] и Ну, ты знаешь ээ что такое лидер, партия
Speaker A
догоняющая? [фыркает] Ну, могу предположить, что у нас ещё раз мы добавляем новую партицию или подожди, повтори ещё раз, пожалуйста, вопрос. Именно вот долици нет. Как устроена репликация ээ на уровне лидер партиции, догоняющий партицы?
Speaker A
Ну, смотри, наверное, а, ну да, наверное, нас как бы сначала идёт в в лидер, а потом уже в, ну догоняющих.
Speaker A
Угу. О'кей. А как можно масштабировать Кавку? Угу. Так, вот у меня есть кавка, например, и сообщений всё больше и больше. Всё больше и больше. Смотри, да? То есть мы можем портиться ещё банально добавить можем топики ээ реплицировать.
Speaker A
Чего ещё? [откашливается] Угу. Можем ещё брокера какого-нибудь добавить. Угу. А устроены ээ гарантии доставки кафки.
Speaker A
Смотри, да? То есть у нас по гарантиям есть ээ at least ones есть ээ ээ так у нас есть э Так, смотри, у нас есть atlist ones есть Так ладно давай короче э exactly ones, есть, at most on exactly
Speaker A
это мы, ну, только один раз, короче, добавляем без дублей. Вот at least once - это минимум один раз, но возможно будут у нас какие-то дубликаты.
Speaker A
А это most, то есть, наверное, да, то есть типа максимум один раз, но ээ могут потеряться по пути.
Speaker A
Угу. [откашливается] А эти гарантии доставки, они для продюсера или для консюмера? Так, ээ, листкавки. Ну, в основном для, думаю, для продюсера основном.
Speaker A
Угу. О'кей. Хорошо. Вот знаешь ну, в практике часто, э, встречается такая задача разбиение монолита на микросервисе.
Speaker A
Угу. А может провести ситуации, когда мы делаем обратное? Угу. Когда мы начали с микросервисной архитектуры, а потом поняли, что нам нужен монолит.
Speaker A
Угу. Так. Мм, ну например ээ, если мы, э-э, не знаю, вот у нас, допустим, мм, есть какой-то Так, давай так по-другому, э, тактактак. М, если у нас, например, может быть, я придумал эту ситуацию.
Speaker A
Может такого не бывает никогда. Мм. Ну, если у нас микросервисы как-то можно до, ну, если они какие-то нам дорого их как бы разрабатывать и они ээ сложно поддерживать, то мы можем, ну, как обычно так никто не делает, но как бы
Speaker A
вернуться к монолиту, и тогда будет проще. Но обычно такого не происходит. О'кей. А какие паттерны микросервисные знаешь? У нас есть монолит, есть микросервисы, есть сервисная ориентированная архитектура. Сервис ориентированная, это тоже микросервисы, но там они немножко побольше. Есть ещё
Speaker A
бессервисная. Это так из бессервисная есть ещё вроде бы ивент Divйн, то есть когда у нас они общаются ээ по событиям, то есть типа события происходят и они так вот общаются.
Speaker A
А слышал что-нибудь про оркестрирование, хореографию? Да, смотри, то есть ээ а оркестрация и хореография. Мм, в оркестрации у нас есть какой-то центральный координатор, который управляет всем процессом. А в хореографии у нас сервисы, ну, сами на друг другу реагируют, и нет у нас
Speaker A
какого-то единого центра. Угу. О'кей. Хорошо. Э, давай задачки порешаем. [откашливается] Начнём с такой. Смотри, у меня есть база данных, в ней миллиард записей транзакций, там хранятся транзакции.
Speaker A
И есть контрагент у меня, который хочет с этой базы к этой базе какие-то запросы через меня выполнять.
Speaker A
Я по середине между вот контрагентом, а, который у которого есть база данных, контрагента Б, который хочет запросы.
Speaker A
выполнять. Я говорю контрагенту, а, что типа мне нужно будет делать запросы к вашей базе данных. Он говорит: "Не вопрос, ээ, ты можешь делать запросы, но вычитывать я буду только Ну, я позволю тебе вычитывать только 100 млн в час.
Speaker A
Угу. Записигу. Миллиард нельзя. А контрагенту Б не пойдёт такое. Это что, мне нужно 10 часов паузу высчитывать?
Speaker A
Угу. Что делать? [фыркает] Так, то есть у нас тот, которого мы вычитываем, он нам запрещает вычитывать 1 млрд.
Speaker A
Ээ, так. Ну, вообще запрещает доступ к 1 млрду. То есть ты можешь получить доступ только к 100 млн.
Speaker A
Угу. А нам нужно миллиард по-любому, да? Там 100 100% нужны миллиард, да? Хорошо. Ну не знаю, ээ может быть мы можем как-то фильтровать. Ээ а подождите, у нас нет доступа вообще к этому миллиарду. У нас есть доступ только к 100 этим миллионам.
Speaker A
Ну 100 млн в час можем вычитать, а дальше делать с ним, что хочешь. А, ну так у нас же есть доступ. Мы можем вычитать ээ 100, но у нас есть доступ к миллиарду или у нас 100 доступ только к
Speaker A
100. И их мы вычитаем. Ну мы можем 100 в час вычитать. Ну именно доступ. [фыркает] Так, ладно, смотри, давай. Ладно, по 100 любых 100 любых Ну, может, какие-то можем добывать фильтры, ээ, чтобы нам Хотя нет, тут нам же нужно
Speaker A
вычитывать всё сразу. А и контрагент А он не идёт ни на какие уступки. У так можем, может как-то можно попробовать ээ м там уже хотят вообще это всё обойти. Мт мы можем на своей стороне ээ как-то сделать так,
Speaker A
чтобы мы вычитывали больше. Так, говорить, что он контрагент не даёт нам вычитывать сразу миллиард.
Speaker A
Ээ, так, ну интересно. Ну, давай я тебе облегчу задачку. У меня есть 200 млн записей у контрагента.
Speaker A
[откашливается] А, и новых не добавляет. Угу. Но читать я могу 100 млн в час.
Speaker A
За сколько часов я вычитаю эту базу? Ну, за два, типа, если у нас будет вот так.
Speaker A
О'кей, с этим мы разобрались. И что мы каждый раз будем 2 часа вычитывать базу?
Speaker A
При каждом запросе от контрагента Б нам нужно подождать 2 часа, вычитать базу, а потом делать какие-то его запросы. Так, а у нас новые данные добавляются какие-то, всего 200.
Speaker A
Ну, можно, может, добавляются. Не, немножко не по 100 млн. Мы, мы можем вот смотри, старые, которые мы вычитали, как-то с, не знаю, кэшировать условно, [фыркает] а потом обрабатывать уже только новые.
Speaker A
У. Угу. Но в целом, да, но кашировать [откашливается] ты будешь 200 млн. Угу. Ну да. То есть нам нужно как-то ээ за эти данные, которые мы вычитали, их как-то сохранить у себя, условно, чтобы Ну, ты в целом правильно говоришь, не
Speaker A
широки. К этому не возвращались. Э-э, мы себе их запишем к себе на БД, да. Да, реплицируем базу. Да, в первые 10 часов мы ничего не сможем сделать, но мы просто считаем её и дальше уже будем действительно только новое себе
Speaker A
заносить. О'кей. Хорошо. Играешь в игрушки какие-нибудь? Игрушки онлайн. [фыркает] Я играл раньше в танки.
Speaker A
Угу. Так, типа, условно в какую-то контру или там, во что обычно играю, там World of Warcraft. Такое я не играл. Угу.
Speaker A
В го ещё типа знаешь игру такую китайскую. Да, не слышал. А, ну это да, знаю, но играть не умею.
Speaker A
Давай вот смотри про танки. Угу. А как вообще вот это всё работает? Смотри, то есть у меня там есть условно 20 игроков. Они сидят в разных точках мира.
Speaker A
Угу. Но видят действия друг друга практически ну с какой-то с каким-то пингом, но практически в реальном времени, да. Извини, всё сразу понял. Это у нас про сидента говоришь? То есть у нас распределение по разным этим точкам мира. И у нас
Speaker A
меньше типа из пинг становится. Ну, потому что меньше времени нужно. Угу. Ну, это тоже, да. А вопрос Угу.
Speaker A
А что летит на сервер примерно? Вот какие какой это тип соединения? Как так получается, что я выстрелил и все сразу это увидели?
Speaker A
Так, ну когда ты выстреливаешь, это у нас идёт какая-то [вздыхает][тяжело вздыхает] или ну даже не выстрелил, я поехал просто танком, но все это видят, что я еду.
Speaker A
У нас есть какой-то постоянный обмен данными. Э, то есть это как webсокет, то есть у нас время времени.
Speaker A
Угу. А какие примерно данные вот летят? Так ну наверное данные именно, ну, понятно, что скорее всего координаты какие-нибудь, ну, типа факт выстрела, наверное, там ээ.
Speaker A
А факт попадания где рассчитывается? Факт, наверное, уже на сервере, может быть, у другого клиента. На севе, я думаю, рассчитывается, потому что, ну, смотри, мы отправили за прош, что мы выстрелили и дальше уже мм как-то по механике как бы вы пролетел вот этот вот
Speaker A
выстрел, эта пуля, и она попала в другой танк. Ээ, ну да, я думаю, на сервере типа уже это будет типа не у нас.
Speaker A
У, что? А ещё ещё можно, смотри, извини, типа там, когда башня, например, поворачивается, не знаю, или если танк уничтожен.
Speaker A
Угу. Есть пробитие. О'кей, хорошо. Смотри, а вот если, например, у тебя есть вот этот клиент, вот этот World of Tanks, я не знаю, как какие там сейчас, может, какой-то другой клиент на это всё есть, да?
Speaker A
Э, и вот мне нужно, ты поросишь у меня, например, деньги золото на какой-нибудь скин какого-нибудь, не знаю, там какие там танки есть, маус там, в общем, но я тебе даю 10.000 руб.
Speaker A
перекидываю. Допустим, там есть такой функционал, я тебе дам 10.000 руб. Ввожу там твоё имя с телефона, например, ввожу 10.000 руб.
Speaker A
Нажимаю отправить. И в этот момент в 5 км от меня летят беспилотники. Угу. И связь просто наглухо пропадает. Я вот так делаю. Вот так. Тык-тык-тык.
Speaker A
Так, понятно, да? И отправляю тебе 100.000 руб. вместо десяти. Так, что делать? Смотри, ну, эта классическая задача, она обычно там про лифт и службу доставки.
Speaker A
Это про ключ это потентности. То есть в каждом запросе, если будет ключ отпотентности, то мы сможем от этого избавиться. То есть у нас каждый вопрос будет уникальным.
Speaker A
Угу. Ну да, правильно. Так, ну в целом всё. Ээ, как тебе собес?
Topics:системный аналитиксобеседованиеRESTSOAPидемпотентностьPUT PATCHHTTP методыинтеграция системмикросервисыбанк
