0: НПФ, наша команда занимается сайтом, личным кабинетом для клиентов физических и юридических

1: В прошлом году мы стартовали с новым продуктом птс. В связи с этим у нас большое количество новых задач и в целом идёт такая цифровизация нашей, нашего личного кабинета сайта. Все.

2: Раньше было на битриксе, теперь мы переходим на новый стек. Угу. Хотелось бы узнать, Ярослав, тебе, чтоб ты рассказал подробнее, там о своём месте работы, чем занимаешься? Почему приняла решение?

3: Как альтернативу текущему месту? Давай пообщаемся. Николай. Наш технический руководитель. Прости, Коля, с места в карьер. Да, привет. Технические вопросы. Привет. Задавать Коле. Угу.

4: Так, ну сразу скажу про почему. Решил сменить, в общем то, не особо моё желание было. Я работал последний год как star разработчик на американскую компанию. Вот. И по сути, у нас просто закончился контракт. Вот.

5: Сам проект, ну вот последний проект, он был самым интересным. Клиентская компания изначально. То есть у них есть основной проект, он заключается в том, что они поставляют для кофейнь вообще все. То есть это и техника, и зерна, и сладости.

6: В общем, полная поставка для ведения бизнеса кофейного. Вот. И они у них там это все работает в нескольких крупных городах америки. Вот, и на базе этого они решили запустить, попробовать новый проект. Его суть это что-то

7: Маркетплейсы, среди вот этих вот кофейн, которые у них есть, с которыми договоры есть. Вот, и их основное. Основная цель это доставка, по сути, батчей. То есть это там на 5 тире 10 человек.

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

9: В начале, то есть вот у них был год на запуск, плюс несколько месяцев они закладывали на то, чтобы последить, посмотреть, насколько он наберёт популярность. То есть есть смысл его поддерживать или, или придётся свернуться. Вот, но планы были хорошие, то есть

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

11: Ожидали, хотели, по крайней мере, нагнать большой. Вот.

12: По команде в команде у нас было 6 человек, часть, половина примерно команды была из основного продукта. Их это 1 тимлид бэкенда, ещё 2 бэкэндера, тоже из основной команды, и 3.

13: Вот, как я ставка фронтенд, 3 человека. 1 из них тимли из основной и девопс тоже из основной команды. Вот по задачкам самые, наверное, такие, по крайней мере, запомнившиеся. Ну и

14: Интересные тоже задачки, которые мне пришлось делать. Нас изначально поделили, по сути, по доменным областям. По факту это означало несколько микросервисов на каждый микросервис где-то было в среднем 2 или максимум 3 разработчика. Вот.

15: Задачка была моя связана как раз с взаимодействием между этими сервисами, которые были у меня в подчинении. Это там по большей части каталог, доставка и наличие товаров. Вот взаимодействие мы строили через кафку был

16: Тоже у нас ну и только для синхронных очевидно мы использовали вот кафку подход мы использовали ОСАГО, вот и также ещё у нас был autox то есть ну на каждом микросервисе своя табличка была дополнительная, вот.

17: Потом следующая тоже задачка более менее интересная это redis мы как-то пропустили добавление редиса, вспомнили о нём буквально там за полтора месяца до того, как надо было в прод уже выпускать продукт, вот и добавляли его на поздних.

18: Случилось так, что к нам просто пришёл девопс и говорит, вот, типа у вас на вашем микросервисе, ну, намного больше нагрузка ожидается. Ну, после Тестов имеется ввиду, чем на остальных сервисах попросили проверить, что не так у нас с взаимодействием с базой данных. Тут мы заметил,

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

20: Тоже достаточно интересная была это подключение платёжных шлюзов изначально мы опять же подключили только 1, который был в основной клиентской компании, когда мы запустили уже prod, получилось так, что где-то через пару недель платёжный шлюз минут на 5 примерно.

21: Перестал полностью отвечать на запросы. И в связи с этим мы приняли решение добавить ещё 2 запасных платёжных шлюза. Вот сделали это все с помощью автопереключения. Ну и также настроили веса. Это было максимально

22: Достаточно примитивная система. То есть у нас максимальный вес 10, ну, от 1 до 10 было 10. У нас было основному платёжному шлюзу назначено, то есть, по сути, приоритет выдан максимально старались 1 платёжным шлюзом пользоваться.

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

24: Платёжный шлюз, мы сразу обратно переключаемся.

25: Ага, слушай, а разворачивались где постились?

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

27: Все, что нам нужно было для локальной разработки, нам скидывал девопс. Вот. Ну, то есть, например, из того, что я вот сейчас прям могу вспомнить. Изначально, когда я сам пытался настраивать кафку, у меня почему-то не получилось с зукипером её подружить. Вот, ну, я

28: Просто написал девопс, говорю, так, и так у меня не получается. И он там буквально в течение 30 минут скинул мне яму, файлы. Вот примерно так это было. Угу. Угу. Хорошо.

29: Как по бизнесовой части.

30: Да нет, наверное, в целом так.

31: Давайте перейдём к технической. Ну, я тогда немножко ещё это спрошу по задачкам, как, как поступали задачки, их наполнение там спринты ветвле.

32: Поставка, ну, цикл, как бы, от входа до выхода. Угу. Prod. Ну, вообще все задачки у нас поставлялись сверху. То есть, так как, я не знаю, возможно, это было связано с тем, что я работал как аутстаф, но

33: Прям обсуждение о том, какие задачки будут появляться в проекте. Тут я не принимал решения. Точно знаю, что об этом общались тимлиды команд, девопс и owner. Вот на таких закрытых встречах это было, к сожалению, недоступно мне. Вот

34: То есть спускались к нам задачи в формате. Нужно добавить такую-то фичу. Вот, например, взаимодействие по кафке мы когда решали это все получается, спустили задачку мы обсуждали на планировании, нам сказали так и так нужно добавить взаимодействие. Вот будем добавлять

35: Ставку паттерны предложили на самом деле нам самим их как-то определить, но в итоге мы все сошлись, что мы все будем добавлять у себя Сагу. Вот сам оркестре. Тот подход у нас был на

36: На стороне микросервиса, то есть 1 микросервис, и у него бэкграунд. Задачке, по сути, проверялась кафка. То есть мы проверяли, какой event был последний, и в случае чего там откатывались или говорили, что дальше делать. То есть следующий ивент публиковали. Вот.

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

38: И нормально оценить не могли. Вот через несколько месяцев мы по итогу перешли просто на почасовую, просто в часах все оценивали. Вот так дальше по таскам, получается, мы получали Таску, это работало так, что кто взял Таску, тот брал на се.

39: По сути, лидерство в этой таске сначала составлялся, соответственно, план, то есть там мельку мы составляли, мы составляли список требований. Вот когда полностью был условный план готов, то мы сначала показывали коллегам из доменной области, вот.

40: После того, как коллега из доменной области утверждал если это крупный таска, ну вот, например, как saga, то мы ещё с тимлидом это обсуждали на отдельной встрече, вот и после его подтверждения уже Таску пускали в ход.

41: Угу. Угу. А по ветвлению?

42: По гиту. Ну, гид у нас был гитлаб, гитом, опять же, там был полностью весь настроенный девопс этим занимался. У нас был на каждый микросервис отдельный гит. Вот. То есть, ну вот у меня по факту было там 3 Гита plus 4.

43: Мы использовали для прото файлов отдельный гид. Угу. Вот. Ну да. Ну вот примерно так. Таска старались делать в 1 пре, полностью всю Таску. Но бывало такое, что, ну, очень большие таски мы делили.

44: Например, там вот когда мы внедряли аут бокс, то мы делали отдельный пр, на каждую, на каждый микросервис. Ну, потому что иначе никак, у нас в разных гитах оно было вот по, по review у нас как было там было

45: Вообще, автоматически, то есть, добавляла 1 человека из твоей доменной области и 1 человека из неё твоей доменной области. И если нужно было, опять же, надсмотр, то это выбиралось вручную. Угу.

46: Окей, а тесты, тесты, тесты мы писали в основном интеграционные. То есть у нас было очень мало юнит тестирования, в основном это были интеграционные тестирования. Вот тоже по большей части старались делать все через гид. Ну, через ccd.

47: Если честно, я не особо в это углублялся когда у себя тестировал, я просто у себя запускал локальные тесты через x. Вот только потом уже отправлял, то есть тесты, которые были на стороне запуска, я в этом особо не углублялся, не разбирался, как оно было настроено.

48: Тесты то сами интеграционные писали, тестировщики? Нет, писали их в основном мы. То есть тестировщиков у нас как таковых не было. Угу. Ну и если честно сказать, то Тестов тоже там не могу сказать, в общем, что прям

49: Сильно мы хотели за этим следить. Ну, в плане, понятно, сильно упирались по времени. То есть, вот у них был условный год, им надо было за год обязательно запустить, и это было главной целью. Поэтому тесты это был так, второстепенная вещь. Угу. Хоро.

50: Шо, давай тогда у меня вот есть задачка 1 поревьюить. Угу. Немного. Сейчас я в чатик скину ссылку.

51: Скинул.

52: Подключайся, посмотрим на сервисок и что с ним не так.

53: Или так?

54: Так, сейчас че то грузит долго.

55: Угу, угу. Так, вижу. Ну вот есть некий user service с несколькими методами, надо его отревьюить, предложить.

56: Какие-нибудь, ну, найти ошибки, предложить улучшения. Угу. Угу.

57: Так, user сервис у нас клиент логгер позитор.

58: Есть.

59: Берём user id, заходим в рай, из 3, вытаскиваем.

60: Так, ну вообще, вот то, что сразу вижу, тут возможно, точнее не возможно. Я бы сделал все это в асинхронном виде. Угу. По крайней мере, мне так кажется, что, ну, в принципе, любое обращение, как мне кажется, внешнего ресурса.

61: Лучше сделать в асинхронном виде. Вот. Но и мне кажется, тут, да, тут ни 1 её я не вижу асинхронного. Возможно, возможно, так задумывалось, но, мне кажется, это не очень вариант. Угу.

62: Хорошо. Ну да, допустим, мы синхронно делаем. Угу. Так, дальше проверяем юзера канал и ошибка request ресепшен. Ну, ошибка тоже, я бы сказал, неправильная, потому что тут

63: А у нас запрос был базу данных, вот я бы тут сделал просто reception. Ага. И статус. Да, в общем, в принципе, не очень правильно. Угу. Дальше мы ошибку.

64: Кладём её, блокируем.

65: Ну тут вроде бы все нормально, часто замечал, что на ревью сроу икс пишут x. Вот и обычно это приходилось указывать ошибку вот тут этого нет.

66: Так что дальше теперь по message апдейт юзер.

67: Или?

68: Так это.

69: Ой, ой, извиняюсь, это я, а то у меня Пальчик упал.

70: Так, я так понимаю, это из это создаётся и response, да, тут и отправляется. А синк, он отправляет запрос, да? Ну да, мы обновляем, типа пользователя.

71: Где-то в аппе каком-то внешнем. Ну я бы на самом деле сделал, ну выглядит так, как будто бы это внутреннее, потому что, ну по крайней мере, ну допустим, мне кажется, что

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

73: Если конкретно по ресту все работает, то ладно, пусть будет вот. Угу. Так, что-нибудь есть ну async, опять же асинк есть метод не синхронный, при этом асинхронная у нас реализация.

74: Лизация синхронно вызывается. Угу. Вот это тоже следовало бы исправить.

75: Media type вроде бы нормально дальше.

76: Не могу понять, какая это умка или типа, просто custom просто. Угу, понял.

77: Так мы получили, можно даже тут, знаешь, как написать, че.

78: Угу. Дапер используется. Угу.

79: User.

80: Ну, тоже самое с синхронностью, думаю, тоже стоило бы сделать, потому что это само обращение к базе данных. Потом у нас, у нас возвращается юзер.

81: Nothing очевидно. Наверное, должен вернуть нам юзера. Угу.

82: А тут её звёздочкой.

83: Вот get single ну наверное нормально, но не знаю, что-то мне душа не лежит к Такому написанию, вот.

84: А че смущает? Ну, допустим, ты с чем работал? На последнем месте мы работали. Ну да, мы так и писали. Да, я к тому, что, ну, я просто get single не видел. Вот, и как

85: Как, как называется? Да просто как незнание того, что может метод вернуть. И поэтому я так на это и посмотрел косо. А вы че использовали вместо сингла? А вот вот я че то не помню, по мо.

86: Мы вообще просто экзет это делали, вот я не помню, но экзекьют мы точно добавляли. Угу. Добавляли. А как получали, блин, ну капец, я забыл.

87: Так, ну ладно, в общем, я думаю, это не сильно важно.

88: Что тут ещё есть ещё есть ну если db connection мы получаем то наверное а ну тут connection не закрывается вообще.

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

90: Так, допустим, ну смотри, вот если мы юзинг добавляем, а connection снаружи принимаем. Ну да, да, это по хорошему здесь connection факторе. Ну как вот у нас было, у нас была коннекшн фактор, мы передавали просто коннекшн фактор.

91: Вот, коннекшн нам возвращал уже открытый коннекшн, и внутри юзинга мы получали все данные и за пределами возвращали результат. Вот. Угу. Я бы сделал примерно так. Угу. А если, допустим,

92: Ну, мы без фабрики делаем. Ну вот в текущей реализации.

93: Что можно навернуть сюда?

94: Текущая реализация.

95: Блин, ну именно про коннекшн. Угу.

96: Мне кажется можно было бы просто его закрыть ну во первых трайкэч добавить на всякий случай, вдруг какая ошибка будет. Вот ну и i finally просто закрывать коннекшн, я думаю этого было бы достаточно.

97: Смущает меня, конечно, передавать прям напрямую, напрямую коннекшн, но коннекшн явно тоже не лучше будет. Угу. Вот. Что мы ещё можем использовать для высвобож.

98: Ресурсов. А, ну, можем финализатор ещё использовать. Вот, но мне, ка, ну, хорошим же является подход, когда мы одновременно, у нас есть финализатор и диспози, и мы везде стараемся через диспози это делать.

99: Скорее так. Запасной вариант. Угу.

100: Ну, то есть мы можем, типа диспос добавить. Ну да, да. Можем диспос добавить. Угу. Хорошо.

101: А вот, допустим, звёздочка в селекте.

102: Норм это.

103: Ну вот, звёздочка нам вернёт вообще все. Угу.

104: Я думаю, что есть ли тут риски. Да, да, да, тут есть риски конкретно с юзерами, например, что если у нас в той же таблице может храниться там, не знаю, какие-нибудь условные пароли, вот в этом конкретном случае это будет не очень. То есть нужно следить за тем, что конкретно ты получаешь. Вот

105: В данном, например, варианте у нас используется, ну, user, у нас только 1 name. Угу. В таком случае, я думаю, что, в принципе, наверное, ничего страшного не было бы, но я бы все-таки указал, что конкретно я хочу получить, потому что в дальнейшем мы, возможно, расши,

106: Класс. Вот и будут данные какие-либо, которые нам вообще не нужны.

107: Угу.

108: А вот если, допустим, ну вот у вас сервис нагруженный был.

109: База же была, получается, данных под ним. Угу. У вас посгря была или, да, по, у нас был. Ага, хорошо. Ну вот у нас нагруженный сервис и запросы в базу.

110: И допустим,

111: Ну, нам надо сделать так, чтобы это прям, ну, прям быстро работало.

112: Угу.

113: В какую сторону мы можем копнуть? Ну, сначала в сторону индекса, то есть можем посмотреть индекс. Ну, например, в данной ситуации на айдишку. Это будет очевидно, потому что мы только по айдишке

114: Сможем как-то их идентифицировать. Вот. И поиск будет. Ну, если на имя, если есть поиск по имени, то, возможно, можно было подумать. Но, по крайней мере, кластер только 1 есть, только 1 можно накинуть. Угу. Вот. Поэтому это

115: По id. Угу. А не кластерный, чем они отличаются?

116: Так, кластеры не кластерные. Вот на самом деле, не сильно помню кластерные вообще как работают, они работают, так что это отдельная табличка, при этом сами данные таблицы хранятся просто по порядку.

117: Были добавлены. Вот, а табличка с индексами, она отдельная.

118: Вот.

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

120: По би, 3 строится, да? Угу. Вот. Там ещё есть, точно помню, с хэшем связанный. И есть всякие такие экзотические, по типу, как для называются данных, ну, там, для джейсона, и

121: Там что-то есть для данных, как они называются, данные. Ну, в общем, отдельный тип данных. Угу. Вот.

122: Hash. Он используется у нас для поиска по рейнджу. Вот здесь, в этом запросе, нам хэш индекс точно не понадобится по количеству. Вот я не вспомню, сколько можно хэш индексы на таблицу.

123: Угу. Вот что, что ещё есть такого?

124: Ну, там, насколько я помню, можно несколько индексов навешивать, там с этим все нормально. И плюс автоматически сам перестраивает таблицу каждый раз. Вот. То есть там вся таблица в принципе, хранится не как, как добавляли, а при вставке все.

125: Сортируются по индексу. Угу. По класс. Да, да, да.

126: Угу.

127: А если, ну, допустим, мы добавим в условия айди и имя

128: Ну, допишем там from the idea. And name равен там. Угу. Какому-то имени.

129: Вот и нам надо индекс сделать.

130: Так, ну да, тут вопрос в том, как он будет делать. Ну, насколько я помню, он сначала будет использовать для поиска поле, которое с индексом. Вот. Ну, тут на самом деле, не уверен тут, да, тут такой вопрос, как он будет?

131: Как он будет выбирать, в общем, приоритет ему поиск делать по индексу или не делать? Мне кажется, что он сделает поиск по индексу и потом будет применять 2 условие. Угу. Вот, по моему, так работает.

132: Причём, по моему, если сделать наоборот, если, по моему, передать 1 параметром имя, a2, ну, то есть 1 передать без индекса, a2 индекс, то он будет делать поиск без индекса. По моему, это так работает. Угу.

133: Хорошо. Так, давай тогда вернёмся. Так.

134: Мы тут закончили. Да, давай ещё верхнюю часть посмотрим.

135: Есть ли тут?

136: Что ещё? Ну, вообще тут так, типа, у нас просто, он просто есть, он у нас никак не неся. Угу. Вот. Там, там, вообще же, с там тоже есть проблема.

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

138: Даже не создался. А во вторых, нужно следить за тем, как он работает, потому что он ж когда создаётся, он проверяет доменные имена днс. Вот если, например, мы его будем слишком редко создавать, он может, например, потерять там какую-то

139: Вот просто потому, что днс у него будет старый.

140: Угу. Так что ещё с ним есть?

141: Ну, вроде бы, вроде бы все с ним. Угу.

142: Ну да, наверное, на этом все, что ещё можно. Ну, с ним, да, давай, все.

143: Кстати, вот сейчас, да, увидел. Репозиторий у нас передаётся не этим, не интерфейсом, а прям типом. Угу. То есть мы жёстко привязываемся к тому, что это вот конкретно. Тип тут тоже, конечно, лучше контейнером.

144: Угу. Вот. Передать сюда интерфейс реализации. Ага. А какие жизненные, жизненные циклы? Ага, циклы диая.

145: Всего их 3. Самый длинный это синглтон, он живёт у нас по сколько живёт у нас приложение, столько живёт синглтон, то есть на все время на время жизни, да, равно времени жизни приложения. Вот, потом идёт скоуп скоуп рабо.

146: В пределах 1 запроса в веб сервисе. Это аштипи запрос. Ну, либо мы можем его вручную создать. Угу. И поехали. И 3 это transit создаётся новый инстанс. Каждый раз, когда мы запрашиваем

147: Угу. Ну и плюс есть, нужно следить за тем. Сейчас уже на это ругается компилятор. Если попробовать скопом сервиса скоуп сервис создавать внутри синглтона. Вот. Но, в общем то, суть в том, что если

148: Не будет этого предупреждения или если за этим не следить, то синглтон может хранить в себе Скоп экземпляр просто все время жизни приложения. То есть он будет просто занимать лишнюю память. Вот поэтому внутри него нужно создавать

149: Они уже coca. Использовать о сервисы. Ага. А обычно какого типа создаёшь, регистрируешь сервисы? Ну, я думаю, что чаще всего скоупы там всякие.

150: Для тех же репозиториев, например. То есть обычно этого достаточно. Ну, то есть, но нам точно не нужен, потому что нам не нужно, но состояние передавать между запросами. Вот для 1 запроса и запроса обычно достаточно 1 Скопа для обращения.

151: Базу данных, например. Угу. Вот. Но бывают и такие сервисы, которые создаём сингл тоном. Вот, например, из того, что я делал, это как мы создавали консьюмера сингл тоном, вот, и продюсер, по моему, тоже сингл тоном создавали.

152: Потому что, ну да, потому что вот он просто сидит у нас в бэкграунде, и он должен либо слушать, либо отправлять туда. А нет, по моему, продюсера мы делали, да, мы продюсера, вроде бы мы делали с коупом, но это не точно, а консьюмера мы делали с тоно.

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

154: Окей. Так, давай перейдём, наверное, к микросервисам.

155: Ты говорил, у вас Сага используется. Угу. Как её реализовывали? Какую проблему она решает, когда вот целесообразно её подключать?

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

157: Вот, то есть от начала, например, там, от начала заказа до последнего этапа заказа и для обработки ошибок. То есть для того, чтобы можно было откатить состояние предыдущее. Вот. Ну то есть, по факту это как поддержка ассистента, видео и Зада.

158: Реальных собеседований на сайте собесов точка ком фактуда. Хватит гадать, что вас ждёт на интервью переходите и получите преимущество перед другими кандидатами. Прямо сейчас достаточно сложно было, ну, работать в том плане, что полностью всю архитектуру

159: Поддерживать. Угу. Ну, опять же, это, на мой взгляд. Ну, из плюсов это очень удобно было. Наш формат мы выбрали, потому что у нас была единая точка, которая управляла всем процессом. Там же есть ещё

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

161: Микросервисы будут просто слушать ивенты и на них как-то реагировать. Угу. Вот эта точка оркестрации, это тоже микросервис хотели изначально, да, предла.

162: Пыталось сделать микросервисом. Вот. Но по итогу решили сделать просто background процессом. То есть у нас вот большая часть была в order сервисе, там был отдельный бэкграунд сервис, который за этим следила.

163: Прям кастом писали или библиотеку использовали, писали кастомно, не знаю. Библиотеку мы посмотрели буквально 1 или 2 библиотечки мы посмотрели и решили, что для начального этапа должно хватить.

164: Вот. Угу. Угу. Также, ну, на самом деле, мне кажется, что тут, опять же, тут, наверное, повлияло ещё и то, что, например, когда я предлагал, когда нужно было логику делать для платёжных,

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

166: Собственное решение, потому что, ну, опять же, библиотечки это библиотечки. Не факт, что их будут поддерживать. И проект тоже неизвестно, сколько он будет жить. В общем, решили, что на первых этап этапах пусть будет так. Угу.

167: Окей.

168: Какие вообще у нас взаимодействия? Вот между микросервисами? Ну, возможны и какие у каждого из них плюсы и минусы. Угу. Вообще делят их на 2 типа на синхронный и

169: Синхронный вот синхронный у нас grpc рест по моему, тоже считается синхронным с рестом я на самом деле не работал с подходом, ну там, в ресте, на мой взгляд, достаточно много минусов в том плане.

170: То у нас нету жёсткого контракта, что именно будет приходить, получать и так далее. То есть нужно прям договариваться. Это нужно просто держать в голове. Угу. В то время, как и, например, мы подписали контракт, и мы точно знаем, что

171: Какие конкретно данные придут? Плюс он будет побыстрее. Вот. И синхронный вариант это, ну, например, брокеры сообщений используются, их плюсы в том, что это какает. То есть мы просто отправил

172: Сообщение, и мы свою работу выполнили. То есть все мы за эту часть больше не отвечаем. Мы просто понимаем, что кто то когда-то его обработает и сделает все, что ему нужно, с теми данными, которые мы ему передали, с нашим сообщением. Угу. Вот.

173: По времени, если так брать теорию, то, конечно, синхронные взаимодействие может длиться сколько угодно. То есть, если, например, у нас сервис лежит, то он обработает только тогда запрос, когда он поднимется. Ага, там, не знаю, супер какая-то критичная

174: Ситуация там, не знаю, 1 sword, не знаю. Ну то есть на каком-то конкретном соде произошла проблема. Там была только часть сервисов. Вот эта часть функционала нам будет, по сути недоступна, но когда они снова станут доступны, все,

175: Они прочитают и все задачки выполнят. Угу. Синхронны же взаимодействуем. Это 1 длинная цепочка. То есть мы отправляем ответ, и мы, по сути, ой, мы отправляем запрос, и мы ожидаем какой-то ответ. То есть там, не знаю, все получилось. Урааа. Спасиб.

176: Вот ваша заявка обработана, плюсы его, ну, это скорость опять же, использовали, например, мы, джесси, вот 1, что пришло в голову, это для расчёта доставки. То есть нам нужно прям сейчас, в моменте показать циферку. Соответственно, мы дёргали

177: Endpoint запрашивали, производилась доставка, расчет доставки. Вот. Угу. И заканчивался спиннер. Появлялась. В таком случае нам асинхронно не подойдёт, потому что, ну, сколько его ждать, этот ответ?

178: А потом как-то это надо опять же, синхронизировать между сервисами. То есть нужно, чтобы было понятно какое сообщение, на какой ответ. То есть, ну обычно это делается опять же, айдишкой. То есть мы уникальный id для ивента делали. Вот, но тем не менее, мы

179: Не можем гарантировать, точнее мы не знаем, будет ли ответ, когда он будет а с gpc ну, с синхронным взаимодействием мы сразу знаем ответ либо будет, либо у нас какие-то проблемы, ага.

180: К примеру, ну вот ты говоришь, что мы в кафку ту же бросили событие, и, ну и как бы, типа, другой сервис, когда обработает, тогда обработает. Угу. А если не обработает?

181: Допустим, он ошибка там. Угу. Ну да, тут вот как раз-таки это и решалось. Решала эту проблему у нас ОСАГО. То есть она следила за тем, у кого как идёт, в принципе, ход обработки общей. То есть следила

182: По сути, за бизнес логикой. То есть закончилось ли действие для пользователя. Например, там заказ, мы проверяем, там, отправили, сделали заказ, там, на order сервисе. Вот. Угу. Например, послали запрос.

183: На оплату, что нужно его оплатить. И если случается ошибка, то нам микросервис должен об этом сообщить. Вот. То есть появится сообщение об ошибке, о том, что не получилось обработать этот заказ, там, оплатить ещё что-нибудь. Вот. Угу. Угу.

184: Забыл вопрос, если честно, не, а вот че будет, к примеру, ну вот микросервис такой читает сообщение из кафки, начинает обрабатывать его и

185: И у него out of memory а, все понял да ну тут с кафкой там есть offset, мы пока полностью не обработаем конкретное сообщение, мы офсет не двигаем, когда мы его обработали, мы офсет двигаем, вот это работало.

186: Опять же, у нас ещё использовалось как условная подстраховка. Это тбокс. То есть перед тем, как, например, отправить сообщение, мы сначала ложили бокс, а потом, опять же, такой же background, процесс, он из таблички подтягивал новые сообщения. Угу, угу.

187: Так, окей, а если мы дубликат поймали, вот с дубликатом работало так, что если есть дубликаты, то мы проверяем их по айдишке. То есть у нас уникальная айдишка и была всегда ивента. Вообще, у нас там ещё был time.

188: Там, но я не сильно, опять же, углублялся в область обработки платежей именно в этом моменте. Но я из того, что я точно знаю, из того, что я там смотрел, ревьювил, у нас был time stamp, то есть. Угу. Если у нас операции были

189: Какие-то условные со счётом. Ну то есть я не знаю, до конца не разбирался, как работала там система, но суть в том, что там могли быть деньги на балансе. Вот. И за ними тоже надо было следить, там был time. То есть мы по time проверяли.

190: Например, было последним. Вот, по event id мы проверяли, что мы не обработали этот ивент. То есть в самом микросервисе, который принимает сообщения. У него есть ещё отдельная табличка, которая хранит ивенты и тоже его статус. Вот. Соответственно, если пришла, пришёл к нам.

191: Дубликат, мы считали, дубликат, мы проверили по айдишке статус уже выполнено, мы просто отбрасываем это сообщение. Угу, угу. Окей, смотри, а вот grpc мы, ну удобно, что мы контракт типа сделали его Поша.

192: Как бы не является это тем, что мы жёстко сцепили свои микросервисы.

193: Ну, формально у нас такой монолитик распределённый получается. Ну да, да, по факту это на самом деле так и есть, что некая связь у нас есть жёсткая.

194: Но, на мой взгляд, все-таки это это лучше, чем монолит как минимум, потому что мы этот контракт более простым способом можем изменить. То есть мы можем прийти там к коллеге или просто прийти самому в другой сервис, посмотреть, какие данные нам нужно изменить, там добавить, убрать.

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

196: Ну, тут получается, что если у нас в контракте брикен чейнджес какой-нибудь или, допустим, мы не можем без

197: Исправлений в другом сервисе. Поменять его, то нам автоматически нужно. Все микрочиповые там зависят на этом контракте синхронно обновлять, да?

198: Окей, а с точки зрения обсервабилити сервисов?

199: Микросервисы, они же как бы

200: Система распределённая, и нам надо как-то на какие-то инциденты как-то разбираться и смотреть. А че там произошло то на самом деле? Угу. А что использовали, как вообще? Угу. Смотрели?

201: Grafana и prometheus вот на самом деле ну, для Логов там, по моему, локи была. Вот опять же этой часть, по большей я почти не занимался. То есть из того, что я знаю, там у нас был, писался мидлвар вот опять же метрика использовалась

202: Метрики очень были важны бизнесу, чтобы просто, ну это ж, по сути, у них был эксперимент пойдёт, не пойдёт у них бизнес. Вот. Поэтому за эту часть метрик, метрики мы собирали, вот логи тоже собирали. Все было там в дашборде.

203: Большей части это, как мы сами их редко смотрели. Скорее, это были запросы от до. То есть он пришёл, говорит, типа, у вас там много ошибок. Пойдите проверьте, че у вас там происходит. Угу. Сама графа, она, конечно, красиво выглядит. Вот.

204: Ошибка там произошла, и говорят, ну, типа, ребят, вот ошибка, давайте разберитесь. Угу. А у нас там взаимодействие между, там, 4 микросервисами. И как нам концы с концами сыскать? Ну, какая-то общая инфо.

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

206: Какой-то след у нас, конечно же, был, но вообще, когда такое случалось, это сразу надо было находить человека. То есть как-то было, к кому написали, тот Шёл искать всех, кто ему нужен. То есть, например, если кто выходит за пределы моей доменной области,

207: Я Шёл к тому человеку, говорил, вот такая-то ошибка. То есть если это пришла, например, от него ошибка, я спрашивал, типа вот такая-то, такая-то ошибка, он в ней разбирался и говорил, ну то есть, если не было вообще понятно, откуда, как так получилось, то сначала разбирался.

208: Тот человек, кто был источником, то есть начиналось у нас не с конца, по сути, а с головы. Вот. Угу.

209: Ага.

210: Так, хорошо. Ща, ща, ща, че-нибудь. Так, давай поговорим ещё быстренько, наверное, про.

211: Блокировки. Угу. Про конструкцию лок. Какие альтернативы есть, какими пользовался и для чего? Угу. Ну, лок это вообще обёртка над монитором.

212: Разница только в том, что loc разворачивается в try, finally тоже и файле у нас монитор экзит у нас в начале монитора угу, вот вообще блокировки делятся на 2 типа, это по уровню уровень ядра и

213: Уровень приложения lock и монитор по моему оба у нас. Да они оба на уровне приложения по моему блокируют у точно блокируют на уровне ядра, обычная тоже умеет на уровне ядра блоки.

214: Делать и симафор на уровне приложения. Вот разница между ними. Ну, например, Сима у нас имеет в многопоточность, то есть там это, по сути, ограничение максимального параллелизма.

215: Лог, если в логе писать эвейты, будет ошибку выдавать. В мониторе можно сделать такое, но не стоит, потому что мы стоим дедлок. Угу. Просто выйдем из потока, заблокируем его и не вернёмся никуда туда. Угу.

216: Вот что ещё. А ещё есть ивенты с ивентами. Я вообще не работал и даже не видел их никогда. Вот. Но там все заключается в сигнальном состоянии. То есть 1 event, по моему, авто ивент, он автоматически переключается в сигнальное состояние. Манол, наоборот, вот.

217: Или, собственно, наоборот. Вот. Угу. Вот так они работают.

218: Ага. А с ченелами, с каналами? Нет, тоже не работал. Угу. Вообще то видел вот так, если честно говорить, только с ним работал. Ну, в принципе, да, согласен. Слушай, а на уровне базы данных?

219: Допустим ну на уровне базы данных есть select date. Если нам нужно конкретно ну то есть там опять же разделение идёт это уровни там транзакции есть у нас 4 всего этих вида 1 никогда нигде не используется и не советуется это.

220: Грязное чтение вот потом идёт у нас ритка метод потом repeat it сериал вот насколько я помню все вот эти вот они блокируют таблицу целиком есть у нас селект фор он блокирует конкретно.

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

222: То есть, если у нас 2 транзакции, рит, комитет, то мы делаем, по сути, слепок таблицы, делаем в ней какие-то изменения, и пока мы их не закоммитил, другие транзакции с таким же уровнем не увидят никаких изменений. Угу. Грязное чтение, потому

223: Грязное, что оно читает. Ему вообще все равно, кто там что делает. Оно просто берет данные, которые в текущий момент существуют. Угу. А фантомы?

224: Да, фантомы. Они ж, по моему, как раз-таки возникают, когда, когда 2 транзакции одновременно у нас вносят изменения.

225: Вот. Ну да, но только на рейндже каком-то. Угу. Вот. Я, если честно, подзабыл, какая разница между реком, сериал сериалал. Я точно знаю, что она прям полностью приостанавливае.

226: Насколько я помню, все вообще транзакции, которые с данной таблицы идут. Угу. Вот. А то, насколько я помню, она не останавливает другие транзакции. Вот. Но при этом, если я правильно помню, она может тупо перезаписать данные. Угу. Вот.

227: То есть та транзакция, которая последняя закончится, она перезапишет данные, но при этом сама она получит данные, которые были актуальны на момент, когда она заходила без учёта изменений. А репита рит

228: О, а я кого-то из них перепутал да, read, committed репита рит получается пот да, ну или угу угу. Так, ну да, вообще да, там получается рид комитет это мы.

229: Просто читаем только данные, которые у нас закоммичены были. А репит рит.

230: Блин, а вот я и запутался, они работают.

231: Ну, мне кажется, если я правильно помню, то как раз-таки разница была в них, в том, что beat, он старается избежать этих вот атомных чтений, которые могут быть при read, committed, мы же можем их прочитать, но изменить в таком

232: То есть мы читаем только личные изменения, а изменяем любые. Вот репит рит, наверное, все-таки читает и изменяет данные как-то согласованно.

233: Не помню, не помню, запутался я в том, как они работают.

234: Угу. Ну, мы перечитаем, да, потом ещё данные и сравним. Угу. Че было main собесов, точка ком, эйчар. Полюбят вас тайком. Так, ну, наверное.

235: Давай классику, наверное, ещё про словарь не знаю. Угу. Дикшенери и хэш таблицы. Угу. Ну, дикшенери у нас хорош тем, что мы достаём из него по сложности. Он всегда за одинаковое время.

236: Даём по хэшу, погоди, не, за он зао от 1, да? Ага. Вот если мы берём самый плохой вариант, если у нас в дикшнери будут лежать все элементы с одинаковым хэшем, тогда у нас

237: Вот как раз-таки сложность растёт до, от. Угу. Мы от этого потеряется. А че там будет, кстати, если мы одинаковый хэш получим на ключе? Угу. Ну,

238: Вообще, он же эту цепочку строит, чейн, вот как он внутри работает. Я на самом деле недавно хотел прочитать, но че то я вообще не понял, как он конкретно понимает. Если я правильно все это осознал, то он просто начинает сравнивать их, собственно,

239: Проверять, совпадают ли элементы. То есть когда ты запрашиваешь у него элемент, то вот он вот так вот это сделает. И также настроите внутри каждого хеша.

240: Угу. Ну, типа, именно для этого мы переопределяем хэш код для того, чтобы мы указали, во первых, чтобы как можно сильнее снизить вероятность того, что у нас будет одинаковый хэш, и, во вторых, для того, чтобы, ну, выделяя

241: Просто самые важные поля, по которым мы хотим различать объекты. Угу.

242: Угу. А это хэш, таблица.

243: Ну, про это не особо знаю.

244: Угу.

245: А какие структуры вот обычно используешь в работе данных? Ну вот, чаще всего дикшенери и листы. Вот. Угу. Также туда же можно приписать рядышком энумерейт. Вот.

246: Если использовал, когда у нас был кор на предыдущих проектах, там был ещё акорбут.

247: Для того, чтобы просто выполнять действий. Угу.

248: Вот. Ну, Кокка ещё есть, там тоже там есть coca и, и много ещё чего интересного для безопасности потоков. Вот. Ну, там же рядом у нас интерлок, ремент есть. Угу.

249: Ага, так.

250: Ну, в целом, наверное, я все просил.

251: Так, давай расскажу, что мы делаем. У нас есть старый сайт, ну как старый, он не то чтобы старый, но, но старый.

252: Угу. Публичный Сбер НПФ. Он на битриксе. Есть личный кабинет тоже на битриксе. Мы битрикс, как бы не наша целевая технология. Мы переезжаем на

253: Новый стек получается у нас фронты это next джис с реактом, а backend дотнетовский, веб апишки с рестами для клиента соответственно.

254: Личный кабинет мы распиливаем на микросервисы, сайт тоже.

255: Микросервисы взаимодействуют у нас, ну, как синхронно через ресты, так и асинхронно через кафку. Угу. Также есть там.

256: Кварц для запуска джобов, которые периодически задания выполняют.

257: Ну, заворачиваемся, собственно, в докер и

258: Развёртываемся там на 3 плечах для отказа устойчивости. Ну, получается у нас 3 ноды своих, на которых мы разворачиваемся под балансиром.

259: Для, ну вот для отказоустойчивости и чтоб можно было ееще бесшовно обновляться. Дотнеткор у нас 8 версии сейчас

260: Переехали? Ну, наверное, давно, да, переехали на него уже исходники лежат у нас в битбакете тёк. По сути, у нас jira контакт, возможно, битбакет. Мы сейчас

261: С него съедем на gitlab пока в процессе обсуждения а. Конфлюенс там жирой останутся работаем с крамом двухнедельными спринтами.

262: Утром дейлики ретро демо, по сути, у нас мгновенное по готовности, функциональности. Угу.

263: Вот там Катя у нас как business owner этих решений и мы сразу и показываем на бэке у нас сейчас 4 человека, на фронте 5.

264: Есть аналитик, который системный, и 2 менеджера, которые работают с бизнес, с бизнес задачами, наверное, принимают, в общем.

265: Запросы от бизнеса и их транслируют нам че-нибудь типа пользовательских.

266: Старей. Угу. В середине спринта мы обычно грумим, я, нам дают задачки, мы их командой отдельно, бэком, отдельно фронтом, грумим. Смотрим, достаточно ли нам там

267: Информации если нет, ну, дозапрашиваем у них, если все окей, расписываем планчик, как это сделать, и ставим оценку. Оценку проставляем часами. Угу. Ну, приблизительно.

268: Есть тестировщик автоматизатор, который на плейрайте пишет апишные тесты и and тесты, прям сквозные от фронта через бэк.

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

270: Скоро devops сейчас у нас в команде 1 1 жертва выполняет роль девопса и настраивает там пайпы угу. И инфраструктуру ну.

271: Соответственно, у него там есть продовский доступ, он как бы развёртывает релиз, туда развёртываемся мы через дженкинс, у нас получается деф тест уат и прод контура ну what?

272: Вот то препрод, где мы там уже пси юзер acceptance тесты проходим. Угу. Также, наверное, скоро хот фикс и loud.

273: Нагрузочный стенд. Угу. Появится.

274: Так, кафка, сказал редис. Ну, ещё и 3 мы разворачиваем для статики. Угу. С проксей на энджинксе. Возможно, потом поверх добавим сидиэн, чтобы статику сайта.

275: Туда отдавать и не нагружать с 3. Угу. Инфраструктура у нас своя. То есть мы на своих серваках это все разворачиваем.

276: И, ну, сидиэн только, наверное, не свой будет, это уже провайдер нам его даст. Вот, но его пока он только в проработке.

277: Так, так, так.

278: Наверное, все, давай вопросы. Я, наверное, ну, может, я че то забыл, конечно. И, ну, по вопросам, да, мне кажется, как раз на все ответил. У меня вот был

279: Только про внутренние процессы. Вот, и про доменную область. И это, в принципе, все было сказано. Угу. Ну, доменная область это негосударственный пенсионный фонд, по сути.

280: Можно перевести свою пенсию государственную, которая, типа, отчисляется с зарплаты. Угу. В негосударственный. И там сейчас может государство софинансировать, когда ты сам

281: Откладываешь себе на пенсию какую-то сумму. Угу. Тебе государство докидывает, там в зависимости от твоего уровня дохода. Софинанс какой-то есть, ну, у нас ещё в компании получается, как

282: Benefits для сотрудников корпоративная есть пенсионная программа, когда тебе компания зеркально докидывает столько же, сколько ты себе докидываешь. Угу. Вот. Если ты там 20000 в месяц себе откладываешь, то она тебе 20 тоже докидывает. Угу. И

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

284: Месячно при выходе на пенсию эту сумму распределяли. Угу. Соответственно, на те деньги, которые ты там откладываешь, их используют как в инвестиционных целях. Допустим, там, офз.

285: Государственные покупают, тебе начисляют с этого доход от инвестиций, они, типа, низко низкорисковые. Ну, в общем, офз там, в принципе, гособеспечение. Вот.

286: У нас, получается, есть публичный сайт, который он по сути больше статика, вот он на серваке рендерится там через next джис, и чтобы он там хорошо был, сео.

287: Оптимизирован, продвигался и там в принципе маркетинговая информация с описанием там программ, как перейти и также есть ссылочки уже на более

288: Динамические части, где ты там можешь подать заявление, чтобы перевестись угу. Вот там у нас интеграция со SberID и с госуслугами там авторизуешься, мы получаем информацию, там заполняется заявле.

289: Ну, отправляется форма, подписывается смской, там дальше формируются заявления, у них есть там какой-то воркфлоу, статусы, они там рассматриваются, утверждаются и клиенту.

290: Создаётся там личный кабинет. Угу. Вот как раз наш 2 сайт, и в этом личном кабинете уже отображаются. Ну, информация по

291: По отчислениям по договорам можно поменять программу, можно там отправить заявку, там на изменение каких-то перс данных. Можно посмотреть статусы, уведомления по начислениям, доходности. Ну,

292: Такая финансовая часть получается. Вот, ну и под эти процессы у нас микросервисы и подключены и сейчас как раз там

293: Мы редизайнить такая активная фаза, переносимся с битрикса и, ну, постепенно. Угу.

294: И редизайн мся.

295: Ну вот, ну да, интересно, я так понимаю то, что относящийся к финтеху, да, по факту?

296: Ну, по сути, да, но там, типа, получается, что мы внутри под капотом, там много ещё автоматизированных систем, которым мы передаём информацию и часть воркфлоу финал.

297: Допустим, там с платежами, оно там в специальной финансовой системе, типа диасофта обрабатывается, мы там получаем уже статусы, как это обработалось, и показываем пользователю, вот, и трекаем там.

298: Состояние заявления его

299: Но, по моему, у нас ещё есть вот интеграция с эквайрингом, где мы, ну вот эти пополнения обрабатываем. Угу. Вот. И автоплатежи не сказал бы, что этого типа много. Прям нота.

300: Какая часть есть? Угу. Понял.

301: Так, ещё какой вопрос?

302: Да, вроде бы все из того, что записывал, да, я все узнал хорошо, но если ещё вопросы там появятся, то полине можно написать, она передаст.

303: Я отвечу. Угу. Хорошо. Вот по обратной связи. Сегодня пятница уже. Ну, вряд ли сегодня че то ответят. Я думаю, что где-то Середина следующей недели ориентир. Угу. Вот.

304: Тогда спасибо за интервью. Угу. Тебе спасибо, что провёл. Да, взаимно. Хорошего дня. Пока. Пока и тебе.