Если говорить прям про кросс-функциональные компоненты - то у нас нет такой практики, потому что не было пока такой потребности. Но ничего не мешает масштабировать такой подход и на них, особенно в случае если разработчик(-и) отвечают и за фронет и за бекенд (у нас просто эти роли разделены)
Компоненты это скорее просто про разделение зоны отвественности и этот подход может быть применен в любом направлении. В нашем случае изначально проблема была на стороне бекенда, поэтому не удивительно, что большинство компонентов тесно связаны с ним. Но помимо этого есть также компоненты у релиз инженеров, у команд мобильной разработки, у тестировщиков - просто не в таком масштабе.
Также компоненты у нас стали стандартом в большинстве внутренних систем там где требуется взаимодействие с людьми. Например, у нас есть своя система мониторинга, которая позволяет разработчикам писать свои проверки с учетом специфики своих компонентов и эта система работает только с компонентами т.к. по компоненту можно легко получить список получателей уведомлений.
Во-первых, компонент — это какой-то сервис, который имеет выделенную и самодостаточную бизнес логику (например, компонент регистрации) или это что-то более мелкое?
Да, компонентом может быть, как сервис, так и модуль в монолите. Мы при внедрении компонентного подхода сначала разбили все на довольно большие компоненты и со временем уже какие-то части выносились в отдельные компоненты. Тут нет какого-то правила и нужно исходить из конкретных сервисов/систем/модулей
Во-вторых, дежурный человек отвечает на все вопросы от других разработчиков, которым нужно внести какие-то измнения в этот компонент (имеют ли они право это делать, кстати), или это ответы по комопненту на вопросы всех желающих (QA, Поддержка, Маркетинг) и так далее?
Задача дежурного скорее быть входной точной для оперативных вопросов, советов, может быть пожеланий. Например, вы предоставляете некий сервис и у разработчика возник вопрос по его использование, который не покрыт документацией. Либо же сработал мониторинг и нужно поресерчить проблему. Важно понимать, что дежурный это не один в поле воин и остальные члены команды всегда на подхвате.
Если кто-то не из списка ответственных за компонент хочет внести правки в код компонента, то на мой взгляд самый лучшим тут будет попросить поставить задачу в трекере и уже предметно обсуждать ее. Можно назначить отдельную встречу, где обсудить саму задачу и может ли она быть сделана силами "со стороны" с ревью ответственными за компонент.
Вообще мне кажется самый оптимальный подход - это определиться в рамках своей команды, что должно входить в задачи дежурного и постепенно либо расширять этот список, либо наоборот что-то убирать.
Решили следующим образом: у нас есть лишь источник истины — это система компонентов. Предположим мне потребовалось в рамках моей задачи отправлять push уведомления. Я иду в Интранет, ищу компонент отвечающий за push-ы, смотрю кто дежурный и задаю свой вопрос ему.
Может получиться так, что дежурный не знает ответа на мой вопрос, и это нормальная ситуация (нет человека который все обо всем знает). Цель дежурства — это в первую очередь решить проблему смены контекста. И в случае, если я как дежурный, не могу сразу ответить на вопрос, то вместо того, чтобы «скинуть» вопрос тому, кто больше погружен в детали конкретного компонента, я начинаю разбираться в проблеме, начинаю задавать уточняющие вопросы коллегам, тем самым пополняя свой багаж знаний.
Дежурства конечно не помогут в случае, если автор кода уволился и не передал компонент другому человеку. Но это уже признак того, что есть проблемы с обменом знаниями внутри команды и тут никакие компоненты проблему не решат :) Но как минимум система компонентов может показать, что есть компоненты у которых Bus factor = 1 и это маркер того, что в этот компонент нужно инвестировать время и увеличить bus factor как минимум до 2
А примеров каких компонентов? Не связанных с кодом? На самом деле их не так много у нас и все они связаны с каким либо внутренним процессом. Компонент в данном случае используется как способ обозначить ответственных и внедрить практику дежурств.
Если из выдуманных, то может быть компонент «Маркетинг» или компонент «Дизайн внутренних интерфейсов». Но понятно, что основной профит от компонентов виден в привязке к коду/фичам/сервисам.
Не работал с этой файловой системой, поэтому не могу сказать насколько она бы зашла тут. Да и как я уже писал ранее наша задача была найти альтернативный транспорт используя существующую инфраструктуру. Учитывая, что консул агент уже был на всех серверах, то не было необходимости настраивать/поднимать что-то новое
Все верно говорите. Только вот заранее городить такую схему не хотелось, учитывая что изначально система делалась под конкретную задачу (выключалка хостов), и только со временем превратилась в систему общего назначения. На мой взгляд любая система должна развиваться итерационно. Учитывая, что сам транспорт скрыт от пользователя, мы можем прозрачно перейти на новый траспорт (например, тот же s3)
Основной посыл статье про сам подход — pull модель, вместо push модели (а не показать насколько хороша схема с Consul-ом)
Конфиг это не что-то требующее миллисекундных задержек. Все равно роллинг апдейты, пробы, блю грин, да и вообще и на прошлом конфиге сервис тоже неплохо работал. Рестарт требует хорошо если минут, а то и десятки минут могут выйти.
конфиги бывают разные и для каждого типа есть свои требования к скорости доставки на сервера. AutoConfig используется там где важна именно скорость, а для остальных конфигов мы продолжаем использовать традиционный подход (mcode в нашем случае)
вообще само по себе выглядит странным поднимать кластер C*/scylladb ради хранения конфигов. Но если без привязки к этому, то мы пока только присматриваемся к scylladb, но пока не больше этого. У нее есть свои на количество нод в кластере для open-source версии
Так ведь схема с Consul это и есть инвертированный подход и в качестве абсолютно надежного хранилища выступает Consul (у нас насколько знаю 5 серверных нод консула)
Просто у Consul-а есть свои ограничения, которые постепенно всплывали в процессе эксплуатации и нужно было адаптироваться под них.
Основной же акцент в статье именно на событийную модель, когда данные читаются из хранилища только тогда когда они обновились, а не в цикле с заданной периодичностью (хотя и это тоже рабочий вариант и я об этом написал)
Ну и немаловажный аргумент: мы изначально хотели сделать новый транспорт используя существующую инфраструктуру. Если делать задачу из расчета, что можно засетапить отдельный кластер редиса/кассандры/т.п., то и подход к решению задачи был бы другим.
Мы одно время думали перевести часть конфигов на mdk, но в данном случае это не решило бы проблемы с залипающими серверами, потому что у mdk тоже 2 фазы (копирование нужных файлов и переключение симлинка). Нужна была именно pull модель, а тут хорошо подошел Consul. Все подводные камни и ограничения всплывали по мере того, как AutoConfig набирал популярность. При этом не все ограничения изначально были отражены в документации Consul, какие то вещи я находил уже в исходниках.
На самом деле это я назвал это «магией» потому, что вся логика скрыта в сервисе, который разрабатывали наши android разработчики, а я лишь вызываю его из кода.
Я посмотрел исходный код и логика примерно следующая:
— разбиваем стек трейсы на фреймы
— отфильтровываем все системные фреймы (например, то что начинается с com.android)
— дальше если у нас остались НЕ системные фрейсы, то беремся N из них, в противном случае берем в прицнипе первые N фреймов
Сейчас используется 3 фрейма, но я так понимаю это подбиралось эмпирически
Пока все работает на базе LSD «as is» т.е. доезжает на конечные тачки в облаке и этого более чем хватает. Сейчас мы сконцентрировались на улучшении UI/UX и интеграции с внутренними системами. Переход на Кафку пока лишь пока в виде идеи т.к. у нее тоже свои особенности.
Пока никак не обрабатывается, но опять же это осознанный выбор т.к. в первой версии мы сконцетрировались на реализации MVP, чтобы мы могли полноценно съехать с AppCenter.
LSD файлы обрабатываются в порядке возрастания, поэтому в случе резкого роста ошибок система будет постепенно все обрабатывать. На моей памяти было лишь пара инцидентов, когда мы реально не успевали все обрабатывать и данные доезжали с задержкой.
По сути да — это вызов сервисов деобфускации/символикации (самая долгая операция), плюс насыщение данных дополнительно информацией. Например, для iOS мы определяем по человечкское название девайса по его модели (что iPhone12,3 это iPhone 11 Pro)
Мы храним все события без схлопывания, даже если их навалило миллионы. Это упрощает систему, хоть и требует дополнительных накладных расходов.
Если вы пишите код не думая об освобождении ресурсов, то рано или поздно придет «наемный убийца» и убьет ваше приложение во благо других. А все из-за НЕЕ
Если говорить прям про кросс-функциональные компоненты - то у нас нет такой практики, потому что не было пока такой потребности. Но ничего не мешает масштабировать такой подход и на них, особенно в случае если разработчик(-и) отвечают и за фронет и за бекенд (у нас просто эти роли разделены)
Компоненты это скорее просто про разделение зоны отвественности и этот подход может быть применен в любом направлении. В нашем случае изначально проблема была на стороне бекенда, поэтому не удивительно, что большинство компонентов тесно связаны с ним. Но помимо этого есть также компоненты у релиз инженеров, у команд мобильной разработки, у тестировщиков - просто не в таком масштабе.
Также компоненты у нас стали стандартом в большинстве внутренних систем там где требуется взаимодействие с людьми. Например, у нас есть своя система мониторинга, которая позволяет разработчикам писать свои проверки с учетом специфики своих компонентов и эта система работает только с компонентами т.к. по компоненту можно легко получить список получателей уведомлений.
Да, компонентом может быть, как сервис, так и модуль в монолите. Мы при внедрении компонентного подхода сначала разбили все на довольно большие компоненты и со временем уже какие-то части выносились в отдельные компоненты. Тут нет какого-то правила и нужно исходить из конкретных сервисов/систем/модулей
Задача дежурного скорее быть входной точной для оперативных вопросов, советов, может быть пожеланий. Например, вы предоставляете некий сервис и у разработчика возник вопрос по его использование, который не покрыт документацией. Либо же сработал мониторинг и нужно поресерчить проблему. Важно понимать, что дежурный это не один в поле воин и остальные члены команды всегда на подхвате.
Если кто-то не из списка ответственных за компонент хочет внести правки в код компонента, то на мой взгляд самый лучшим тут будет попросить поставить задачу в трекере и уже предметно обсуждать ее. Можно назначить отдельную встречу, где обсудить саму задачу и может ли она быть сделана силами "со стороны" с ревью ответственными за компонент.
Вообще мне кажется самый оптимальный подход - это определиться в рамках своей команды, что должно входить в задачи дежурного и постепенно либо расширять этот список, либо наоборот что-то убирать.
Может получиться так, что дежурный не знает ответа на мой вопрос, и это нормальная ситуация (нет человека который все обо всем знает). Цель дежурства — это в первую очередь решить проблему смены контекста. И в случае, если я как дежурный, не могу сразу ответить на вопрос, то вместо того, чтобы «скинуть» вопрос тому, кто больше погружен в детали конкретного компонента, я начинаю разбираться в проблеме, начинаю задавать уточняющие вопросы коллегам, тем самым пополняя свой багаж знаний.
Дежурства конечно не помогут в случае, если автор кода уволился и не передал компонент другому человеку. Но это уже признак того, что есть проблемы с обменом знаниями внутри команды и тут никакие компоненты проблему не решат :) Но как минимум система компонентов может показать, что есть компоненты у которых Bus factor = 1 и это маркер того, что в этот компонент нужно инвестировать время и увеличить bus factor как минимум до 2
Если из выдуманных, то может быть компонент «Маркетинг» или компонент «Дизайн внутренних интерфейсов». Но понятно, что основной профит от компонентов виден в привязке к коду/фичам/сервисам.
Основной посыл статье про сам подход — pull модель, вместо push модели (а не показать насколько хороша схема с Consul-ом)
конфиги бывают разные и для каждого типа есть свои требования к скорости доставки на сервера. AutoConfig используется там где важна именно скорость, а для остальных конфигов мы продолжаем использовать традиционный подход (mcode в нашем случае)
Просто у Consul-а есть свои ограничения, которые постепенно всплывали в процессе эксплуатации и нужно было адаптироваться под них.
Основной же акцент в статье именно на событийную модель, когда данные читаются из хранилища только тогда когда они обновились, а не в цикле с заданной периодичностью (хотя и это тоже рабочий вариант и я об этом написал)
Ну и немаловажный аргумент: мы изначально хотели сделать новый транспорт используя существующую инфраструктуру. Если делать задачу из расчета, что можно засетапить отдельный кластер редиса/кассандры/т.п., то и подход к решению задачи был бы другим.
Я посмотрел исходный код и логика примерно следующая:
— разбиваем стек трейсы на фреймы
— отфильтровываем все системные фреймы (например, то что начинается с com.android)
— дальше если у нас остались НЕ системные фрейсы, то беремся N из них, в противном случае берем в прицнипе первые N фреймов
Сейчас используется 3 фрейма, но я так понимаю это подбиралось эмпирически
LSD файлы обрабатываются в порядке возрастания, поэтому в случе резкого роста ошибок система будет постепенно все обрабатывать. На моей памяти было лишь пара инцидентов, когда мы реально не успевали все обрабатывать и данные доезжали с задержкой.
Мы храним все события без схлопывания, даже если их навалило миллионы. Это упрощает систему, хоть и требует дополнительных накладных расходов.
Говорят, что они питаются мозгами. А еще они могут появиться в системе, когда тот кто их породил завершился раньше времени