Не так давно компания друга потерпела относительно крупный крах. Причина сбоя также легко объяснима, так как используется высокий уровень доступности ActiveMQ (архитектура MS, ACK с двойной записью), в результате чего в пиковый период сообщения на стороне производства перегружены, многие запросы не могут быть обработаны. , и данные неупорядочены.
задний план
По его словам, их прикладной уровень выше, чем у телекоммуникационных приложений (коров надо продуть), поэтому система сообщений требует, чтобы сообщение нельзя было потерять. Он сделал это, но сервис не работал.
Откуда взялся этот случай? Говорят, что это произошло на совещании высшего руководства, и некий руководитель был взволнован одной из небольших проблем: определенный фрагмент данных, проверенный в его тестовой среде, просто исчез, а производственная среда не воспроизводилась. Копье в итоге указало на систему сообщений, которая напрямую поднялась к тому, что делать после отключения электричества.
Лидеры показывают свою силу, и все нужно делать по-особому. Команда архитекторов не спала допоздна, чтобы обсудить план улучшения, от Kafka до RocketMQ, от размещения БД до обновления до плана StoreHA, и это было очень весело. Конечным результатом обсуждения является использование подхода с очень высокой доступностью. Условия лидерства соблюдены, и система сообщений обладает высокой доступностью, но не весь бизнес. Конечная пропускная способность MQ не так хороша, как даже у БД.
Ошибка оптимизации из-за типичных требований к стволу оружия. Должен быть редким.
считать
Высокая доступность — это ложное утверждение, хотя оно и поддерживается известными теориями, такими как CAP, все еще есть много людей, которые впадают в это заблуждение, в том числе лица, принимающие технические решения. Как общий контроллер, архитектура может допустить такую ошибку, чисто низкоуровневую. Ниже приведены мои собственные размышления о высокой доступности.
Высокая доступность — это не высокая доступность компонентов, а высокая доступность бизнеса.
Взяв за пример очередь сообщений, это не означает, что выживание очереди сообщений и надежность сообщения гарантированы, а работа завершена. Также необходимо учитывать топологии и высокую доступность на стороне производителя и потребителя. Например, аварийное отключение производственной стороны, обработка буфера, чрезмерная обработка сообщений в среде с низкой пропускной способностью, задержка сообщений на стороне потребителя, и обработка недоставленных писем.
Если вы заранее не проводите анализ возможностей бизнеса и не имеете соответствующих мер по расширению, не говоря уже о мониторинге склонных к проблемам звеньев, то дело ваше, и у вас нет выбора.
Сначала бизнес полезен, а потом уже надежен
Бизнес больше не может работать, независимо от того, насколько надежны ваши серверные компоненты, они впустую. Возьмем, к примеру, систему seckill, вам не потребуется сначала надежно приземляться, но вы будете использовать некоторые ненадежные системы кэширования для буферизации, которая так называемая полезная. Только при обеспечении нормального течения бизнеса можно говорить о надежности.
Основной процесс не может быть заблокирован, и надежность снижается
Это то, что часто называют предохранителем. Например, кассовая система не будет ждать, пока ваш сервер действительно обработает различную бухгалтерскую логику, прежде чем вернуть успех. Его основная цель - собрать деньги, позволить вам сначала потратить деньги, а затем вы не можете потребовать, чтобы платеж не прошел только потому, что сообщение не было отправлено. В настоящее время сообщение существует как обходное приложение, и для предохранения необходимо установить разумный тайм-аут.
Другим примером являются очень трудоемкие операции, помещенные в транзакции, которые ужасно портят геймплей.
Если не можешь играть, ограничь поток, не держись
Текущее регулирование позволяет пользователям блокировать на самом внешнем уровне и предотвращать поступление запросов. Пользователь увидит неудачные запросы, но не вредоносные запросы (повреждение данных при выполнении с логическим чередованием). Если не можешь удержать, просто признай это, и запрос уходит на второй план, убивая некий базовый компонент, что еще серьезнее.
Данные не могут быть потеряны, я все еще могу их восстановить
Наиболее обсуждаемая распределенная система — это консистентность в конечном счете, но мало кто знает, что консистентность в конечном счете включает ручные ссылки и даже вмешательство службы поддержки клиентов. Как правило, вероятность генерации аномальных данных относительно мала, и с ней можно справиться вручную. Кроме того, существуют и другие методы оптимизации:
1. Отформатированный подробный лог, который можно восстановить по логу 2. Идемпотентный бизнес, запрос гарантирует хотя бы один раз семантику 3. Выполнять аномальную обработку данных путем сканирования, повторных попыток и других средств.
Не говорите о высокой доступности, это очень плохо.
Круто ли говорить о высокой доступности? Не обязательно. надо уметь анализировать提出方характер и познавательная способность анализировать последствия различных технологических средств. Дело не в том, что у того, у кого больше власти, есть правильное мнение. Многие лидеры забыли о 2/3 палки после того, как взяли палку в руки. Это не существенный вопрос, о котором вам не нужно заботиться.
Распределенная система — это сложное целое, не обобщайте, получение определенного компонента не означает получение всей системы. Лидеры будут думать, что вы не можете.
End
Некоторые контрпримеры всегда наводят на полезные размышления. Проанализируйте потребности вокруг вас, которые являются потребностями ствола оружия и которые являются потребностями микрофона, вы можете сказать нет, придерживайтесь своего профессионального познания! Если вы не знаете, как это сказать, вы можете передать ему эту статью о Мисс Сестра Вкус, и пусть он увидит последствия.
Больше отличных статей.
«Микросервисы — это не все, а лишь подмножество определенного домена».
С таким количеством компонентов мониторинга всегда найдется подходящий для вас
«Наиболее часто используемый набор навыков «vim» в производственной среде Linux.
«С Нетти, что мы разрабатываем? 》
Линукс из пяти частей и тому подобное.
«Остальная часть необитаемого острова» Linux (1) Подготовка»
«Linux« Остальная часть необитаемого острова »(2) Глава CPU»
«Linux« Остальная часть необитаемого острова »(3) глава памяти»
«Linux« Остальная часть необитаемого острова »(4) глава ввода-вывода»
«Сетевая глава Linux« Оставшаяся жизнь на необитаемом острове »(5)»