Напомню, что изначально речь шла о стеке и цепочке вызовов. И я на примере классического backend показал, что длинные цепочки вызовов усложняют отладку.
Вы приводите хороший пример, где запись не попадает в БД. Но зачем-то предлагаете тыкаться в БД дебагом. Это нужно делать в последнюю очередь. Для начала нужно глянуть, что поступает на вход сервиса БД, текст запросов. Да, это традиционно делается через логи. И включить запись логов намного проще, чем влезать в сервис дебагом. Кроме того, нужно еще глянуть, что приходило на вход сервиса бизнес-логики.
То есть, первый уровень отладки — это проверка входящих-выходящих данных каждого сервиса, чтобы определить, в каком сервисе проблема и на каких исходных данных. И уже потом лезть в конкретный сервис, ставя брейкпоинты и ассерты на конкретный тип данных.
В этом случае не придется изучать сотни запросов в дебагере. И не придется каждый раз перезапускать после сеанса отладки всю монолитную систему, достаточно перезапускать только конкретный сервис. Сфабриковать и подсунуть тестовые данные (mock) тоже проще в отдельный компонент системы, чем монолитную систему.
Согласен насчет java, там все хорошо с отладкой. А что вы называете архитектурой? Свойства языка, железа или дизайн программы? Судя по дальнейшему тексту — свойства языка, платформы разработки.
стектрейс и дебаг вот вообще никак не связаны. Стектрейс описывает проблему и выдаёт данные, которые догодался запросить программист (в виде сообщения исключения)
Стектрейс это часть дебага, важный инструмент. Без него все намного сложнее. Позволяет видеть истоки проблемы, откуда она пришла.
Насчет отладки распределенной архитектуры. Простой пример: отдельно сервис (или сервер) БД, сервис HTTP и сервис приложения. В этом случае не нужно забивать голову деталями БД и HTTP при отладке приложения, это отдельные «черные ящики». В случае сбоя в БД или HTTP достаточно перезапустить только отдельный сервис, и область поиска причины сбоя значительно сужается. А представьте, что будет, если HTTP и БД обрабатываются в одном приложении, в одной цепочке вызовов? Малейший сбой уронит всю систему. Какой бы хороший ни был язык программирования, проблема будет в дизайне системы.
Может вы и правы. Когда-то разбирался в тонкостях работы асинхронных вызовов, а сейчас уже забыл. Потому что перестал их использовать и ломать голову над асинхронностью однопоточного по сути приложения.
Угу. А чтобы избежать ошибок достаточно их не совершать. Все просто! =) Но ошибку все-таки совершили и catch в нужном месте не поставили. Да и не всегда try… catch помогает поймать проблему, обычно ловится уже последствие, факт поломки. Например, когда образовался dead pointer, вроде все работает, но ломается где-то при закрытии программы. Или в конце «всплытия» из длинной цепочки вызовов. А ограничивая длину цепочки вызова, гораздо проще локализовать проблему.
Это если классический синхронный event loop и message queue, как в винде. А в Андроиде, например, таймеры и activities стреляют не дожидаясь завершения предыдущего вызова, как будто в новом потоке. Да и JS вроде тоже. В винде проблемы возникали при банальном переключении визуальной иконки по таймеру. Вроде все нормально работает, а через час падает. А когда смотришь через профилировщик, то виден постоянный рост стека и поглощение какого-то ограниченного ресурса, например, дескрипторов в Windows. Потому что где-то стоял WaitForMultipleObjects, который не блокировал event loop, а тупо ждал выхода из какой-то функции.
Дело не в формате стекстрейса, а в его размере, глубине. И это сильно влияет на качество и скорость отладки, а также на устойчивость системы при незначительных сбоях.
Например. Настолькое приложение. Форма ввода с кнопкой ОК, выполняются какие-то проверки, вычисления, записи, чтения, и в итоге выполняется COMMIT в базу данных. Если происходит исключение где-то между ОК и COMMIT, то оно всплывает аж на уровень кнопки ОК, то есть обработчика событий GUI. И не факт, что перехватывается и обрабатывается должным образом. В результате, в программе проблема, но о ней могут не догадываться долгое время, а на поиск и исправление уйдет уйма времени.
А если внутренняя архитектура разбита на несколько коротих «конвееров» команд, то все намного проще и надежнее. Например, нажатие ОК не выполняет какой-то код, а только кладет команду и данные формы в очередь. Отдельный обработчик берет данные из очереди, проверяет и передает в следующую очередь. Затем следующий обработчик берет данные из очереди, производит вычисления, помещает результат в следующую очередь. Казалось бы, так все намного сложней и медленней. Но на деле, такая «микросервисная» архитектура намного проще в отладке, устойчивей и производительней на многозадачном железе. Исключение всегда всплывает на уровень консьюмера конкретного конвеера, значительно уменьшая размер контекста, сужая область и глубину поиска причины сбоя. Особенно ценно это в хардкорном продакшене, где нет доступа для отладки и приходится работать по продиктованному голосом адресу исключения. Даже не всегда есть возможность посмотреть логи и стектрейс.
Например, по асинхронному таймеру происходит вызов функции не дожидаясь выхода. При высокой нагрузке такие вызовы накапливаются. Конечно, тут вопросы к проектированию такого решения, но ведь в нормальных условиях все работает.
Допустим, есть такая технология. Что вы с ней будете делать, как использовать? Готовы ли вы за нее платить и кому? Готовы ли вы к тому, что не только вы можете связаться с любым человеком без всякого контроля, но и любой человек может связаться с вами и предложить censored?
Предлагается, грубо говоря, 9 заповедей:
Правительствам:
1. Дать каждому доступ в интернет
2. Весь интернет доступен в любое время
3. Уважать и защищать основные права и безопасность данных людей в интернете
Компаниям:
4. Делать интернет доступным всем и каждому
5. Уважать и защищать права и безопасность данных людей в интернете, строить систему доверия
6. Разрабатывать технологии, которые поддерживают хорошее и мешают плохому.
Гражданам:
7. Творить и помогать другим в Сети
8. Строить сильные сообщества, которые уважают чужое мнение и человеческое достоинство
9. Бороться за Сеть
То есть, это Греф лично сделал на сайте сбербанка форму для входа в «личный кабинет» по номеру паспорта и коду SMS, чтобы зэки могли имитировать «колл-центр банка»?
В 1997 даже готовились к производству, а я в то время обучался в техникуме для работы на том самом заводе, и нам показывали, как это работает на примере голографических сувениров, выжженых лазером в акриле.
Мировой рынок готовится к появлению нового поколения информационных носителей DVD. Массовый их выпуск ожидается весной. Тем временем в России разворачивается проект, который в случае успеха сделает DVD технологией вчерашнего дня. Проект под названием «Трехмерная память» попал под контроль правительства РФ: с подачи Егора Строева Виктор Черномырдин подписал распоряжение о промышленном производстве в России сначала опытных образцов, а затем и серийном выпуске принципиально нового носителя информации — трехмерной оптико-электронной памяти. Производство должно развернуться на родине Егора Строева — в Орле.
Microsoft и Warner Bros. представили новую технологию хранения фильмов, которые теперь могут быть записаны на кварцевое стекло размером 75x75 мм и толщиной 2 мм. Первым фильмом, который был использован для создания кварцевой и почти вечной копии, стал оригинальный «Супермен» 1978 года. Данная технология является частью Project Silica от Microsoft Research, в ней используются специальные лазеры и искусственный интеллект для создания элемента хранения данных в кварцевом стекле.
В новом способе хранения данных Microsoft использует последние открытия в области сверхбыстрой лазерной оптики и искусственного интеллекта для хранения данных на кварцевом стекле. Лазер кодирует данные в стекле, создавая слои трехмерных наноразмерных решеток и деформаций на разных глубинах и под разными углами. Алгоритмы машинного обучения считывают записанные данные, декодируя узоры, которые создает поляризованный свет, проходящий через кварцевое стекло.
Вы приводите хороший пример, где запись не попадает в БД. Но зачем-то предлагаете тыкаться в БД дебагом. Это нужно делать в последнюю очередь. Для начала нужно глянуть, что поступает на вход сервиса БД, текст запросов. Да, это традиционно делается через логи. И включить запись логов намного проще, чем влезать в сервис дебагом. Кроме того, нужно еще глянуть, что приходило на вход сервиса бизнес-логики.
То есть, первый уровень отладки — это проверка входящих-выходящих данных каждого сервиса, чтобы определить, в каком сервисе проблема и на каких исходных данных. И уже потом лезть в конкретный сервис, ставя брейкпоинты и ассерты на конкретный тип данных.
В этом случае не придется изучать сотни запросов в дебагере. И не придется каждый раз перезапускать после сеанса отладки всю монолитную систему, достаточно перезапускать только конкретный сервис. Сфабриковать и подсунуть тестовые данные (mock) тоже проще в отдельный компонент системы, чем монолитную систему.
Стектрейс это часть дебага, важный инструмент. Без него все намного сложнее. Позволяет видеть истоки проблемы, откуда она пришла.
Насчет отладки распределенной архитектуры. Простой пример: отдельно сервис (или сервер) БД, сервис HTTP и сервис приложения. В этом случае не нужно забивать голову деталями БД и HTTP при отладке приложения, это отдельные «черные ящики». В случае сбоя в БД или HTTP достаточно перезапустить только отдельный сервис, и область поиска причины сбоя значительно сужается. А представьте, что будет, если HTTP и БД обрабатываются в одном приложении, в одной цепочке вызовов? Малейший сбой уронит всю систему. Какой бы хороший ни был язык программирования, проблема будет в дизайне системы.
Например. Настолькое приложение. Форма ввода с кнопкой ОК, выполняются какие-то проверки, вычисления, записи, чтения, и в итоге выполняется COMMIT в базу данных. Если происходит исключение где-то между ОК и COMMIT, то оно всплывает аж на уровень кнопки ОК, то есть обработчика событий GUI. И не факт, что перехватывается и обрабатывается должным образом. В результате, в программе проблема, но о ней могут не догадываться долгое время, а на поиск и исправление уйдет уйма времени.
А если внутренняя архитектура разбита на несколько коротих «конвееров» команд, то все намного проще и надежнее. Например, нажатие ОК не выполняет какой-то код, а только кладет команду и данные формы в очередь. Отдельный обработчик берет данные из очереди, проверяет и передает в следующую очередь. Затем следующий обработчик берет данные из очереди, производит вычисления, помещает результат в следующую очередь. Казалось бы, так все намного сложней и медленней. Но на деле, такая «микросервисная» архитектура намного проще в отладке, устойчивей и производительней на многозадачном железе. Исключение всегда всплывает на уровень консьюмера конкретного конвеера, значительно уменьшая размер контекста, сужая область и глубину поиска причины сбоя. Особенно ценно это в хардкорном продакшене, где нет доступа для отладки и приходится работать по продиктованному голосом адресу исключения. Даже не всегда есть возможность посмотреть логи и стектрейс.
Правительствам:
1. Дать каждому доступ в интернет
2. Весь интернет доступен в любое время
3. Уважать и защищать основные права и безопасность данных людей в интернете
Компаниям:
4. Делать интернет доступным всем и каждому
5. Уважать и защищать права и безопасность данных людей в интернете, строить систему доверия
6. Разрабатывать технологии, которые поддерживают хорошее и мешают плохому.
Гражданам:
7. Творить и помогать другим в Сети
8. Строить сильные сообщества, которые уважают чужое мнение и человеческое достоинство
9. Бороться за Сеть
185.147.37.91/doc/171853
В новом способе хранения данных Microsoft использует последние открытия в области сверхбыстрой лазерной оптики и искусственного интеллекта для хранения данных на кварцевом стекле. Лазер кодирует данные в стекле, создавая слои трехмерных наноразмерных решеток и деформаций на разных глубинах и под разными углами. Алгоритмы машинного обучения считывают записанные данные, декодируя узоры, которые создает поляризованный свет, проходящий через кварцевое стекло.
habr.com/ru/news/t/474616