Да, тут нужно прояснить свою мысль. Есть такой бед-паттерн «Ivory Tower» у архитекторов, когда перестаёшь что-то делать «руками». Одна из моих задач это держать свои навыки актуальными. И тут я многому учусь у своей команды. С другой стороны, работодатель ожидает от меня проработки высокоуровневых решений с заданными ограничениями. И тут нужны совершенно другие навыки и знания, которые я заимствую из вне. Просто потому что у меня есть задача и мне её нужно решать.
Не только самообучение. Вокруг, в коллективе я постоянно чему-то учусь. Менторство. Выступать ментором как самому, так и искать ментора внутри или снаружи. Для себя слежу за несколькими инженерами / менеджерами / архитекторами зарубежными. Они очень много делятся опытом и матчастью. Lamoda достаточно крупная компания со сложными процессами, чтобы на её базе учиться. Пока мне хватает =)
Тогда вы переросли команду, и стоит найти ту, где есть у кого поучиться.
Это очень хорошая мысль и я не мало думал как решать такую проблему. Со временем понял, что пора снова сесть за учебники (только теперь совсем сам и чаще за научные статьи). Т.е. опыт уже есть, главное приложить услиля чтоб его натягивать на правильную матчасть.
Если делать важное, то через время замечаешь, что разоблачать тебя уже некому.
Это про то, что люди вокруг не знают больше. Скорее они знают по-другому. И если начать разбираться, то через время становишься таким же экспертом. По крайней мере на том же уровне. Я хотел сказать, что не нужно бояться что чего-то не знаешь, ведь этому можно научиться.
Позже, к концу года, ко мне перешло техлидство всего проекта вместе с задачей восстановить баланс сил после ухода части команды.
Справедливости ради отмечу, что часть команды ушла каждый по своим обстоятельствам. И с каждым мы общаемся и до сих пор.
Звучит как «я крутой, сейчас все понимаю и пронесло что мне ничего не сделали».
Перевожу что я сказал — а по русски? )
Англицизмы непростая тема :) стараюсь их использовать когда нужна определённая коннотация, как в данном случае с «импактом» – отрицательные последствия ошибки. Мы с такими ошибками работаем и стараемся копать глубже человеческого фактора. Что нам нужно поменять в нашем процессе, чтоб такого не происходило. Но в тот момент моя ошибка оставила эмоциональный отклик. Что конкретно я могу сделать, чтоб минимизировать со своей стороны такие ошибки.
Тут, пожалуй, два варианта:
1. проектировать коммуникацию между сервисами с учётом минимизации нарушения согласованности данных;
2. предоставлять механизмы, которые позволяют «прокрутить» состояние заново до нужного состояния;
По первому пункту я немного упомянул в комментарии выше, как мы обеспечиваем консистентность бизнес-транзакций. В дополнение приведу ссылку на доклад Bernd Rücker (Camunda BPM) youtu.be/jjYAZ0DPLNM?t=647 [Eng], где он очень хорошо расписывает подходы, как жить в Event-driven парадигме.
По второму пункту нас спасает наше хранилище с возможностью перечитать заново и восстановить состояние.
Конечно, не везде всё так гладко работает, но это те подходы, которые мы стараемся использовать и одна из моих задач это нести в команды эти подходы. Потому что только когда сами команды будут придерживаться этих принципов, тогда можно говорить об успешности реализации.
Мы храним проекции данных о клиенте (кастомере) в сервисах (фича-сервисы). Т.е. у нас есть шина данных в которой есть общие доменные объекты (точнее их лог). Сервис подписывается на интересующий его поток доменных событий и строит свою проекцию исходя из потребностей. Важно, что этими данными сервис не владеет, а только может обращаться к ним за чтением.
При проектировании всегда нужно держать в голове, что есть консистентность в конечном итоге. Если нужна строгая, то тут мы используем другие механизмы для гарантированной доставки транзакционных изменений. У нас нет единого менеджера транзакций, но эта ответственность лежит внутри каждого сервиса, где нужно обеспечить строгую консистентность. Saga в частности или Outbox в общем случаи. Тут зависит от конкретного контектса. Далеко не всегда и не везде нужна строгая консистентность. Но важно иметь механизмы, которые её обеспечивают в том или ином виде.
Schema registry используется для валидации событий между продюсером (build DTO) -> (validate DTO) хранилище событий -> консюмером (build DTO)
Взяли OpenAPI немногим раньше, чем у нас появилась событийная архитектура в разрезе всей ИТ системы. Один из ключевых моментов в принятии решений в ИТ Lamoda это преемственность стандартов. И чем больше агентов решение затрагивает, тем больше мы обращаем на это внимание. Когда нам станет нехватать текущего решения, то AsyncAPI будет первым кандидатом на рассмотрение.
Спасибо. Это хороший вопрос, т.к. ответ многогранный. Одна грань это наша орг.структура – Data&Analytics у нас это целый департамент и ребята используют внутри себя много интересных решений специфичных для своих задач. У нас же в департаменте разработки, мы себя называем ecommerce платформой – go сервисы, k8s и классика postgres. Из самого, возможно, экзотичного Aerospike. То, что мы хорошо знаем, и что в подавляющем большинстве случаев отвечает нашим требованиям. Задача, описанная в статье скорее исключение.
Ещё одна грань это предсказуемость поведения при изменениях, возможность бесшовно катать изменения вперёд и назад. Т.к. процессинг данных напрямую влияет на критичные бизнес-метрики. Поэтому тут у нас требование как и к стандартным продуктовым фича-сервисам.
Возвращаясь к вопросу, скорее мы как ecommerce платформа будем перенимать опыт и практику из DA. Например, сейчас присматриваемся, как и где мы сможем использовать Spark.
Я попробую в паре абзацах рассказать как мы подходим к дизайну данных и сервисов. Надеюсь отвечу этим на вопросы.
Мы активно используем DDD и далеко не всегда вместе с OOP. Больше упор на стратегические паттерны. Другими словами, первое с чего мы начинаем это проектирование контрактов (контекстов) через спецификации. Это может быть и API сервиса и события. Каждый раз на ревью новой спецификации мы обсуждаем как это укладывается в уже существующую картину. В каких местах и какие контексты взаимодействуют. Вот этот контекст лучше разбить на два и в случае необходимости композировать. А вот эти два лучше объединить в один, т.к. есть транзакционная зависимость и разбивать на более мелкие только себе дороже.
В дальнейшем определяем какой профиль использования контекста. Вот здесь нам необходима строгая консистентность и синхронное взаимодействие по сети, скорее всего мы не будем гонять большой агрегат, а сделаем композицию из простых и последовательных. С возможностью компенсации изменений. А вот здесь для масштабирования мы выберем консистентность в конечном итоге и уйдём от синхронных запросов, передавая контекст сообщением через шину событий.
В итоге, это может быть и микросервис и модульный монолит. Главное, оставлять возможность гибко управлять изменениями и взаимодействовать через описанные контексты.
Json-rpc поверх http. Текстовый протокол для общения между микросервисами это наше осознанное решение. Пока необходимость перехода на бинарный не стоит.
Когда у нас был Nomad, то был Consul как service discovery. Но после пары инцидентов с Nomad, мы спешно от него отказались и перешли полностью в K8s. В нём сейчас внутри ходим по dns, а для взаимодействия снаружи используется ingress-nginx.
Уже в следующем году собираемся рассматривать построения service-mesh и там же будем выбирать какой service discovery взять. Необходимость чувствуется уже сейчас.
Да, у нас свой кодогенератор, который по шаблону строит клиент и сервер со всеми обвязками. Выше я отвечал про количество уровней абстракций. И проблема, с которой мы тоже столкнулись именно в этом. Как написать код, который можно без боли читать и поддерживать. Считаю что в какой-то мере нам это удалось.
Про трейсинг. Это ведь не что-то специфичное для Go, а скорее необходимость в мире распределённых систем.
P.S. Я тот phpшник, который перешёл на Go и остался доволен :)
Да, во многих местах у нас остаётся php и python. Как раз там, где есть развесистая бизнес-логика и её сложное конфигурирование. Чаще всего. Но точно могу сказать (на примере сервиса из статьи) что и на Go можно описать сложную логику, которую потом без боли можно поддерживать и развивать.
Речь про количество уровней абстракции, которые используются. Мысль была в том, что далеко не все шаблоны проектирования, используемые в PHP, у нас получилось применить в Go. Что и логично. Многое пришлось переосмыслить. В этом и был наш сдвиг парадигмы.
Очень знакомая ситуация с првязкой к сервисам AWS. Сначала поднимаешь одни только EC2, а потом понимаешь, что весь проект в сервисах Amazon уже. Есть и обратная сторона злоупотребления их сервисами, сам столкнулся с тем, что на RDS они режут конкурентные соединения до определённого лимита в зависимости от типа инстанса (что явно не прописано в прайсах).
Docker для каждого пользователя и реальная среда выполнения это круто — каким и должно быть обучение. Спасибо за обзор!
У нас было 2 спутниковые тарелки, с десяток конвертеров и дайсек-переключателей, полтора рабочих ресивера и целое множество крепежей всех сортов и расцветок, а также компас и «тамагочи». Не то что бы это был необходимый запас для сёрфинга сети. Но если занялся sky-грабингом, становится трудно остановиться. Единственное что вызывало у меня опасение — это наземный канал. Нет ничего более беспомощного, безответственного и испорченного, чем мобильный GPRS. Я знал, что рано или поздно мы перейдем и на эту дрянь.
Мне нравится как в этой статье написано про the five responsibilities of architects.
Это очень хорошая мысль и я не мало думал как решать такую проблему. Со временем понял, что пора снова сесть за учебники (только теперь совсем сам и чаще за научные статьи). Т.е. опыт уже есть, главное приложить услиля чтоб его натягивать на правильную матчасть.
Это про то, что люди вокруг не знают больше. Скорее они знают по-другому. И если начать разбираться, то через время становишься таким же экспертом. По крайней мере на том же уровне. Я хотел сказать, что не нужно бояться что чего-то не знаешь, ведь этому можно научиться.
Справедливости ради отмечу, что часть команды ушла каждый по своим обстоятельствам. И с каждым мы общаемся и до сих пор.
Англицизмы непростая тема :) стараюсь их использовать когда нужна определённая коннотация, как в данном случае с «импактом» – отрицательные последствия ошибки. Мы с такими ошибками работаем и стараемся копать глубже человеческого фактора. Что нам нужно поменять в нашем процессе, чтоб такого не происходило. Но в тот момент моя ошибка оставила эмоциональный отклик. Что конкретно я могу сделать, чтоб минимизировать со своей стороны такие ошибки.
1. проектировать коммуникацию между сервисами с учётом минимизации нарушения согласованности данных;
2. предоставлять механизмы, которые позволяют «прокрутить» состояние заново до нужного состояния;
По первому пункту я немного упомянул в комментарии выше, как мы обеспечиваем консистентность бизнес-транзакций. В дополнение приведу ссылку на доклад Bernd Rücker (Camunda BPM) youtu.be/jjYAZ0DPLNM?t=647 [Eng], где он очень хорошо расписывает подходы, как жить в Event-driven парадигме.
По второму пункту нас спасает наше хранилище с возможностью перечитать заново и восстановить состояние.
Конечно, не везде всё так гладко работает, но это те подходы, которые мы стараемся использовать и одна из моих задач это нести в команды эти подходы. Потому что только когда сами команды будут придерживаться этих принципов, тогда можно говорить об успешности реализации.
При проектировании всегда нужно держать в голове, что есть консистентность в конечном итоге. Если нужна строгая, то тут мы используем другие механизмы для гарантированной доставки транзакционных изменений. У нас нет единого менеджера транзакций, но эта ответственность лежит внутри каждого сервиса, где нужно обеспечить строгую консистентность. Saga в частности или Outbox в общем случаи. Тут зависит от конкретного контектса. Далеко не всегда и не везде нужна строгая консистентность. Но важно иметь механизмы, которые её обеспечивают в том или ином виде.
Взяли OpenAPI немногим раньше, чем у нас появилась событийная архитектура в разрезе всей ИТ системы. Один из ключевых моментов в принятии решений в ИТ Lamoda это преемственность стандартов. И чем больше агентов решение затрагивает, тем больше мы обращаем на это внимание. Когда нам станет нехватать текущего решения, то AsyncAPI будет первым кандидатом на рассмотрение.
Ещё одна грань это предсказуемость поведения при изменениях, возможность бесшовно катать изменения вперёд и назад. Т.к. процессинг данных напрямую влияет на критичные бизнес-метрики. Поэтому тут у нас требование как и к стандартным продуктовым фича-сервисам.
Возвращаясь к вопросу, скорее мы как ecommerce платформа будем перенимать опыт и практику из DA. Например, сейчас присматриваемся, как и где мы сможем использовать Spark.
Мы активно используем DDD и далеко не всегда вместе с OOP. Больше упор на стратегические паттерны. Другими словами, первое с чего мы начинаем это проектирование контрактов (контекстов) через спецификации. Это может быть и API сервиса и события. Каждый раз на ревью новой спецификации мы обсуждаем как это укладывается в уже существующую картину. В каких местах и какие контексты взаимодействуют. Вот этот контекст лучше разбить на два и в случае необходимости композировать. А вот эти два лучше объединить в один, т.к. есть транзакционная зависимость и разбивать на более мелкие только себе дороже.
В дальнейшем определяем какой профиль использования контекста. Вот здесь нам необходима строгая консистентность и синхронное взаимодействие по сети, скорее всего мы не будем гонять большой агрегат, а сделаем композицию из простых и последовательных. С возможностью компенсации изменений. А вот здесь для масштабирования мы выберем консистентность в конечном итоге и уйдём от синхронных запросов, передавая контекст сообщением через шину событий.
В итоге, это может быть и микросервис и модульный монолит. Главное, оставлять возможность гибко управлять изменениями и взаимодействовать через описанные контексты.
Когда у нас был Nomad, то был Consul как service discovery. Но после пары инцидентов с Nomad, мы спешно от него отказались и перешли полностью в K8s. В нём сейчас внутри ходим по dns, а для взаимодействия снаружи используется ingress-nginx.
Уже в следующем году собираемся рассматривать построения service-mesh и там же будем выбирать какой service discovery взять. Необходимость чувствуется уже сейчас.
Про трейсинг. Это ведь не что-то специфичное для Go, а скорее необходимость в мире распределённых систем.
P.S. Я тот phpшник, который перешёл на Go и остался доволен :)
Docker для каждого пользователя и реальная среда выполнения это круто — каким и должно быть обучение. Спасибо за обзор!
У нас было 2 спутниковые тарелки, с десяток конвертеров и дайсек-переключателей, полтора рабочих ресивера и целое множество крепежей всех сортов и расцветок, а также компас и «тамагочи». Не то что бы это был необходимый запас для сёрфинга сети. Но если занялся sky-грабингом, становится трудно остановиться. Единственное что вызывало у меня опасение — это наземный канал. Нет ничего более беспомощного, безответственного и испорченного, чем мобильный GPRS. Я знал, что рано или поздно мы перейдем и на эту дрянь.
support.google.com/mail/answer/1075549?hl=ru