1. Предпосылки
Для интернет-приложений и крупномасштабных корпоративных приложений большинству из них требуется 7*24 часа непрерывной работы, насколько это возможно, но можно сказать, что для достижения полной бесперебойной работы «трудно подняться в небо». По этой причине для измерения степени доступности приложений обычно используется от трех до пяти девяток.
| Показатели доступности | Расчет | Время недоступности (минуты) |
|---|---|---|
| 99.9% | 0.1%*365*24*60 | 525.6 |
| 99.99% | 0.01%*365*24*60 | 52.56 |
| 99.999% | 0.001%*365*24*60 | 5.256 |
Для приложения с растущими функциями и объемом данных непросто поддерживать относительно высокую доступность. Чтобы достичь высокой доступности, платежная система CreditEase провела много исследований и практик, чтобы избежать единой точки отказа, обеспечить высокую доступность самого приложения и решить проблему роста объема транзакций.
Сервисная мощность платежной системы CreditEase может достигать 99,999% без учета внезапных отказов внешних зависимых систем, таких как сетевые проблемы, сторонние платежи и масштабная недоступность банков.
В этой статье основное внимание уделяется тому, как повысить доступность самого приложения, а как избежать единых точек отказа и решить проблему роста объема транзакций будет рассмотрено в других сериях.
Чтобы улучшить доступность приложения, первое, что нужно сделать, это максимально избежать отказа приложения, но сделать это полностью невозможно. Интернет – это место, где легко возникает «эффект бабочки»: любая, казалось бы, маленькая случайность с вероятностью 0 может произойти, а затем бесконечно усилиться.
Все знают, что RabbitMQ сам по себе очень стабилен и надежен, платежная система CreditEase с самого начала использует одноточечный RabbitMQ, и он никогда не сталкивался со сбоями, поэтому все думают, что эта вещь вряд ли пойдет не так.
Пока в один прекрасный день физическое оборудование хоста, на котором располагалась нода, не вышло из строя из-за того, что долгое время не ремонтировалось, тогда RabbitMQ не мог предоставлять услуги, в результате чего системные службы были мгновенно недоступны.
Неисправность не страшна, главное вовремя найти и устранить неисправность. Требование платежной системы CreditEase к собственной системе заключается в том, чтобы находить неисправности за считанные секунды, быстро диагностировать и устранять неисправности, чтобы уменьшить негативное влияние сбоев.
Во-вторых, проблема
Учитесь у истории. Прежде всего, давайте кратко рассмотрим некоторые проблемы, с которыми сталкивается платежная система CreditEase:
(1) Когда новые коллеги по разработке имеют дело с новым трехсторонним каналом доступа, они игнорируют важность установки времени ожидания из-за отсутствия у них опыта. Именно такая маленькая деталь вызывает блокировку всех транзакций в трехсторонней очереди, и одновременно влияет на транзакции других каналов;
(2) Платежная система CreditEase развертывается распределенным образом и поддерживает публикацию в оттенках серого, поэтому среда и модули развертывания очень многочисленны и сложны. Один раз был добавлен новый модуль, так как окружений несколько, а каждое окружение является двухузловым, то количество подключений к БД после выхода нового модуля в онлайн становится недостаточным, что влияет на функции других модулей;
(3) Та же проблема с тайм-аутом: трехсторонний тайм-аут приводит к исчерпанию всех сконфигурированных в данный момент рабочих потоков, так что у других транзакций нет потоков, которые можно было бы обработать;
(4) Третья сторона А обеспечивает одновременно аутентификацию, оплату и другие интерфейсы.Один из интерфейсов запускает DDoS-ограничение третьей стороны А на оператора сети из-за внезапного увеличения объема транзакций платежной системы CreditEase. Обычно исходящий IP-адрес компьютерного зала является фиксированным, что оператор сети ошибочно принимает за атаку трафика с исходящего IP-адреса, что в конечном итоге приводит к одновременной недоступности стороннего интерфейса аутентификации и оплаты A.
(5) Другая проблема с базой данных также вызвана внезапным увеличением объема транзакций платежной системы CreditEase. Верхний предел последовательности, указанный коллегой, создавшим последовательность, составляет 999, 999, 999, но длина этого поля в реестре данных составляет 32 бита.При небольшом объеме транзакции значение, сгенерированное системой, соответствует 32 бита поля, и последовательность не будет продвигаться. Однако с увеличением объема транзакций количество цифр в последовательности увеличивается по незнанию, и в результате 32 бита недостаточно для хранения.
Подобные проблемы очень распространены в интернет-системах и скрыты, поэтому очень важно, как их избежать.
3. Решения
Давайте посмотрим на изменения, внесенные платежной системой CreditEase, с трех сторон.
3.1 Избегайте ошибок, насколько это возможно
3.1.1 Проектирование отказоустойчивой системы
Например, при рероутинге, для пользовательской оплаты, пользователю все равно, с какого канала выплачиваются деньги, пользователю важно только успешность или нет. Платежная система CreditEase подключена к более чем 30 каналам.Возможно, что платеж по каналу А не удался.В это время его необходимо динамически перенаправить на канал B или C, чтобы можно было избежать сбоя платежа пользователя за счет перенаправления системы. и отказоустойчивость оплаты может быть реализована.
Существует также отказоустойчивость для OOM, например Tomcat. Системная память всегда исчерпана.Если вы резервируете часть памяти для самого приложения с самого начала, когда происходит системный OOM, вы можете поймать исключение и избежать этого OOM.
3.1.2 Некоторые ссылки быстро выходят из строя (принцип быстрого отказа)
Принцип Fail fast заключается в том, что при возникновении проблемы на каком-либо этапе основного процесса весь процесс должен быть завершен быстро и обоснованно, а не ждать устранения негативных последствий.
Приведу несколько примеров:
(1) При запуске платежной системы в кеш необходимо загрузить некоторую информацию об очереди и информацию о конфигурации.Если загрузка не удалась или конфигурация очереди неверна, процесс обработки запроса не будет выполнен. Лучший способ справиться с этим - загрузите данные.Выйдите, чтобы последующие запуски не были недоступны;
(2) Время отклика платежной системы при обработке транзакций в реальном времени составляет до 40 с. Если оно превышает 40 с, интерфейсная система больше не будет ждать, освободит поток и сообщит продавцу, что транзакция обрабатывается. О результатах последующей обработки будет сообщено в виде уведомления или бизнес-линия возьмет на себя инициативу запроса для получения результата;
(3) Платежная система CreditEase использует Redis в качестве базы данных кеша, где она имеет такие функции, как сигнал тревоги в реальном времени, закопанная точка и проверка веса. Если подключение к redis превысит 50 мс, операция redis будет автоматически прервана, в худшем случае влияние этой операции на платеж составляет 50 мс, что контролируется в допустимом системой диапазоне.
3.1.3 Разработка системы с возможностями самозащиты
Система обычно имеет сторонние зависимости, такие как базы данных, сторонние интерфейсы и т. д. При разработке системы необходимо сохранять подозрительность к третьей стороне, чтобы избежать цепной реакции, когда у третьей стороны возникают проблемы, приводящие к простоям.
(1) Разделить очередь сообщений
Платежная система CreditEase предоставляет продавцам различные платежные интерфейсы.Обычно используемые из них: экспресс, личный онлайн-банкинг, корпоративный онлайн-банкинг, возврат, отзыв, пакетный платеж, пакетный вычет, разовый платеж, разовый вычет, голосовой платеж, запрос баланса, ID аутентификация карты, аутентификация банковской карты, аутентификация секрета карты и т. д. Соответствующие платежные каналы включают WeChat Pay, ApplePay, Alipay и более 30 платежных каналов, а также доступ к сотням продавцов. В соответствии с этими тремя аспектами, как гарантировать, что различные предприятия, третьи стороны, продавцы и типы платежей не влияют друг на друга, платежная система CreditEase разделяет очередь сообщений. На следующем рисунке представлена разделенная диаграмма некоторых очередей бизнес-сообщений:
(2) Ограничить использование ресурсов
Ограничение использования ресурсов является наиболее важным моментом системы высокой доступности, но это также момент, который легко упустить из виду. Ресурсы относительно ограничены. Чрезмерное использование, естественно, приведет к простою приложения. С этой целью платежная система CreditEase проделала следующую домашнюю работу:
- Ограничьте количество подключений
При распределенном горизонтальном масштабировании необходимо учитывать количество подключений к базе данных, а не бесконечную максимизацию. Количество подключений к базе данных ограничено, и все модули необходимо рассматривать глобально, особенно увеличение, вызванное горизонтальным расширением.
- Ограничить использование памяти
Чрезмерное использование памяти приведет к частому GC и OOM.Использование памяти в основном связано со следующими двумя аспектами:
A: Емкость сбора слишком велика;
B: Объекты, на которые больше нет ссылок, не освобождаются.Например, объекты, помещенные в ThreadLocal, будут повторно использоваться до тех пор, пока поток не завершит работу.
- Ограничить создание темы
Неограниченное создание потоков в конечном итоге приводит к неконтролируемости, особенно метода создания потоков, скрытого в коде.
Когда значение SY системы слишком велико, это означает, что Linux нужно тратить больше времени на переключение потоков. Основная причина этого явления в Java заключается в том, что создается много потоков, и эти потоки постоянно блокируются (ожидание блокировки, ожидание ввода-вывода) и находятся в процессе изменения состояния выполнения, что приводит к большому количеству переключений контекста.
Кроме того, приложения Java будут использовать физическую память за пределами кучи JVM при создании потоков, и слишком много потоков будут использовать слишком много физической памяти.
Для создания потоков лучше всего использовать пулы потоков, чтобы избежать переключения контекста, вызванного слишком большим количеством потоков.
- Ограничение параллелизма
Те, кто занимался платежными системами, должны знать, что у некоторых сторонних платежных компаний есть требования к параллельности мерчантов. Количество параллелизма, открытого третьей стороной, оценивается в соответствии с фактическим объемом транзакций, поэтому, если параллелизм не контролируется и все транзакции отправляются третьей стороне, третья сторона ответит только «Пожалуйста, уменьшите частоту отправки».
Поэтому особое внимание следует уделить стадии проектирования системы и стадии проверки кода, чтобы ограничить параллелизм диапазоном, разрешенным тремя сторонами.
Мы упомянули, что в платежную систему CreditEase было внесено три изменения, чтобы добиться доступности системы, одно из которых заключается в том, чтобы максимально избежать сбоев, а затем мы поговорим о последних двух пунктах.
3.2 Вовремя находить неисправности
Ошибки подобны чертям, проникающим в деревню, и их застают врасплох. Когда линия защиты прорвана, как вовремя подтянуть вторую линию защиты и найти неисправности для обеспечения доступности, то тут начинает играть роль система мониторинга сигнализации. В машине без приборной панели невозможно узнать скорость и уровень топлива, включен ли поворотник, даже если уровень «старого водителя» высок, это достаточно опасно. Точно так же система также нуждается в контроле, и лучше всего заранее вызвать полицию, когда есть опасность, чтобы неисправность могла быть устранена до того, как возникнет реальный риск.
3.2.1 Система оповещения в реальном времени
Без сигналов тревоги в режиме реального времени неопределенность рабочего состояния системы может привести к неизмеримым бедствиям. Показатели системы мониторинга платежной системы CreditEase следующие:
-
В режиме реального времени - для достижения мониторинга второго уровня;
-
Полнота охвата — охват всех системных операций, чтобы исключить охват мертвых зон;
-
Практичность - раннее предупреждение разделено на несколько уровней, и контролирующий персонал может удобно и практично принимать точные решения в зависимости от серьезности предупреждения;
-
Разнообразие - режим раннего предупреждения обеспечивает режим push-pull, включая SMS, электронную почту и визуальный интерфейс, что удобно для наблюдения за персоналом для своевременного обнаружения проблем.
Тревоги в основном делятся на автономные тревоги и кластерные тревоги, а платежная система CreditEase относится к кластерному развертыванию. Раннее предупреждение в режиме реального времени в основном основано на статистическом анализе встроенных точечных данных различных бизнес-систем в реальном времени, поэтому сложность заключается в основном в системе внедрения и анализа данных.
3.2.2 Данные о захороненных точках
Чтобы выполнить анализ в реальном времени, не влияя на время отклика системы транзакций, платежная система CreditEase использует Redis для встраивания данных в реальном времени в каждый модуль, а затем агрегирует встроенные данные в систему анализа, и система анализа анализирует и будильники по правилам.
3.2.3 Система анализа
Самое сложное для аналитической системы — это точка бизнес-сигнала тревоги, например, какие сигналы тревоги должны вызываться, как только они появляются, а какие требуют внимания только тогда, когда они появляются. Ниже мы даем подробное введение в систему анализа:
(1) Архитектура работы системы
(2) Процесс работы системы
(3) Точка мониторинга системного бизнеса
Точки бизнес-мониторинга платежной системы CreditEase суммируются по крупицам в процессе ежедневной работы и делятся на две категории: тип тревоги и тип беспокойства.
A: Класс сигнализации
-
Предупреждение о сетевых аномалиях;
-
Тайм-аут одного ордера и предупреждение о незавершенности;
-
Предупреждение об успешности транзакций в реальном времени;
-
Предупреждение об аномальном состоянии;
-
Нет предупреждения о возврате;
-
Предупреждение об отказе;
-
Предупреждение о ненормальном сбое;
-
Код ответа часто выдает раннее предупреждение;
-
Проверьте предупреждение о несоответствии;
-
специальное государственное предупреждение;
B: класс внимания
-
предупреждение об аномальном объеме торгов;
-
Предупреждение об объеме транзакции превышает 500 Вт;
-
СМС-уведомление о тайм-ауте обратной засыпки;
-
Предупреждение о недопустимом IP-адресе;
3.2.4 Необслуживаемые точки контроля
Точки мониторинга, не относящиеся к бизнесу, в основном относятся к мониторингу с точки зрения эксплуатации и обслуживания, включая сеть, хост, хранилище, журнал и т. д. детали следующим образом:
(1) Мониторинг доступности услуг
Используйте JVM для сбора такой информации, как количество и время Young GC/Full GC, память кучи и трудоемкие стеки 10 лучших потоков, включая длину кэш-буфера.
(2) Мониторинг трафика
Агент развертывается на каждом сервере с помощью агента мониторинга агентов, и информация о ситуации с трафиком собирается в режиме реального времени.
(3) Внешний мониторинг системы
Наблюдайте за стабильностью трехсторонней сети или сети с помощью прерывистого обнаружения.
(4) Мониторинг промежуточного программного обеспечения
-
Для очередей потребления MQ с помощью обнаружения сценария RabbitMQ анализ глубины очереди в реальном времени;
-
Для части базы данных, установив подключаемый модуль xdb, мониторинг производительности базы данных в режиме реального времени.
(5) Мониторинг журнала в реальном времени
Сбор распределенных журналов выполняется с помощью rsyslog, а затем мониторинг и анализ журналов в режиме реального времени выполняются с помощью системного анализа и обработки. Наконец, он отображается пользователям путем разработки визуальной страницы.
(6) Мониторинг системных ресурсов
Используйте Zabbix для мониторинга загрузки ЦП хоста, использования памяти, восходящего и нисходящего трафика каждой сетевой карты, скорости чтения и записи каждого диска, количества операций чтения и записи (IOPS) каждого диска и использования дискового пространства.
Вышеизложенное - это то, что делает система мониторинга в реальном времени платежной системы CreditEase.Она в основном делится на два аспекта: мониторинг бизнес-точек и мониторинг эксплуатации и обслуживания.Хотя система развернута распределенным образом, каждая точка раннего предупреждения является второй ответ уровня. Кроме того, точка тревоги бизнес-системы также имеет трудности, то есть некоторые тревоги сообщаются в небольшом количестве, что не обязательно может вызвать проблемы, но большое количество тревог вызовет проблемы, то есть так- количественные изменения вызывают качественные изменения.
Например, на примере сетевой аномалии одна транзакция может быть вызвана дрожанием сети, но если происходит несколько транзакций, необходимо обратить внимание на то, есть ли реальная проблема с сетью.Пример тревоги платежной системы CreditEase для сетевой аномалии выглядит следующим образом:
-
Предупреждение об аномалии в одноканальной сети: 12 последовательных аномалий в сети произошли в канале А в течение 1 минуты, что привело к срабатыванию порога предупреждения;
-
Предупреждение об аномалии многоканальной сети 1: в течение 10 минут каждую минуту подряд возникали 3 аномалии в сети, затрагивающие 3 канала, что приводило к срабатыванию порога предупреждения;
-
Предупреждение о сбое в многоканальной сети 2: в течение 10 минут произошло 25 сбоев в сети, включая 3 канала, что привело к срабатыванию порога предупреждения.
3.2.5 Система регистрации и анализа
Для большой системы сложно записывать большое количество логов и анализировать логи каждый день. Платежная система CreditEase имеет в среднем 200W заказов в день.Транзакция проходит через более десятка модулей.Предположим, что заказ записывает 30 логов.Не исключено, что каждый день будет огромное количество логов.
Анализ журналов платежной системы CreditEase имеет две функции: одна — предупреждение об аномалиях в журнале в режиме реального времени, а другая — предоставление трассировки заказов для использования операторами.
(1) Предупреждение журнала в реальном времени
Предупреждение журнала в реальном времени предназначено для всех журналов транзакций в реальном времени, захватывая ключевые слова с исключениями или ошибками в реальном времени, а затем выдавая тревогу. Преимущество этого в том, что если в коде есть какая-либо аномалия, она будет обнаружена с первого раза. Платежная система CreditEase обрабатывает предупреждения журналов в реальном времени, сначала используя rsyslog для завершения сбора журналов, а затем собирая их в реальном времени с помощью системы анализа, а затем выдавая предупреждения в реальном времени.
(2) Отслеживание заказа
Для торговой системы очень важно знать поток статуса ордера в режиме реального времени. Первоначальный подход платежной системы CreditEase заключался в записи трека заказа через базу данных, но после прогона в течение определенного периода времени было обнаружено, что таблица базы данных была слишком большой из-за быстрого увеличения объема заказа, что не способствовало поддержание.
Текущая практика платежной системы CreditEase заключается в том, что каждый модуль печатает трассировки журналов в формате структуры таблицы базы данных.После печати всех журналов rsyslog завершает сбор журналов, а система анализа захватывает и печатает в режиме реального времени.Нормативные журналы анализируются. а затем ежедневно сохраняются в базе данных и отображаются оператору в визуальном интерфейсе.
Спецификация печати журнала выглядит следующим образом:
2016-07-22 18:15:00.512||pool-73-thread-4||Адаптер канала||Адаптер канала-трехсторонняя почта||CEX16XXXXXXX5751||16201XXXX337||||||04||9000|| 【 Сообщение расчетной платформы] Обработка||0000105||98XX543210||GHT||03||11||2016-07-22 18:15:00.512||Чжан Чжан||||01||tunnelQuery||true|| ||В ожидании||||10.100.140.101||8cff785d-0d01-4ed4-b771-cb0b1faa7f95||10.999.140.101||O001||||0,01||||||||http://10.100.444.59: 8080/регрессия/уведомление||||240||2016-07-20 19:06:13.000xxxxxxx
||2016-07-22 18:15:00.170||2016-07-22 18:15:00.496xxxxxxxxxxxxxxxxxxxx
||2016-07-2019:06:13.000||||||||01||0103||111xxxxxxxxxxxxxxxxxxxxxxxxx
||8fb64154bbea060afec5cd2bb0c36a752be734f3e9424ba7xxxxxxxxxxxxxxxxxxxx
||622xxxxxxxxxxxxxxxx||9bc195a59dd35a47||f2ba5254f9e22914824881c242d211
||||||||||||||||||||6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx010||||||||||
Краткая трассировка визуализации журнала выглядит следующим образом:
Помимо двух вышеперечисленных пунктов, система логирования и анализа также обеспечивает загрузку и просмотр сообщений о транзакциях и ответах.
3.2.6 Комната наблюдения 7*24 часа
Элементы сигналов тревоги над платежной системой CreditEase предоставляют операторам два метода push-pull: один — SMS и электронная почта, а другой — отображение отчета. Кроме того, из-за важности платежной системы по сравнению с другими системами в Интернете, платежная система CreditEase использует круглосуточную комнату мониторинга 7 * 24 для обеспечения безопасности и стабильности системы.
3.3 Своевременно устранять неисправности
После возникновения сбоя, особенно в производственной среде, первое, что нужно сделать, — это не найти причину сбоя, а как можно быстрее устранить сбой, чтобы обеспечить доступность системы. Общие неисправности и меры обработки платежной системы CreditEase следующие:
3.3.1 Автоматический ремонт
Что касается части автоматического ремонта, общие сбои платежной системы CreditEase вызваны нестабильностью трех сторон.В ответ на эту ситуацию упомянутая выше система автоматически выполнит перенаправление.
3.3.2 Понижение уровня обслуживания
Ухудшение обслуживания означает отключение некоторых функций, чтобы обеспечить использование основных функций, когда неисправность не может быть быстро устранена. Когда платежная система CreditEase продвигает продавцов, если объем транзакций продавца слишком велик, она будет корректировать трафик продавца в режиме реального времени, так что качество обслуживания продавца ухудшится, чтобы другие продавцы не пострадали. Аналогичные сценарии. Функция понижения версии конкретной услуги будет представлена в следующих сериях.
4. Вопросы и ответы
Q1: Можете ли вы рассказать нам конкретные детали и решения для простоя этого RabbitMQ?
A1: Время простоя RabbitMQ заставило задуматься о доступности системы.В то время наш RabbitMQ сам по себе не был отключен (RabbitMQ был еще очень стабилен), простоем была аппаратная машина, на которой располагался RabbitMQ, но проблема заключалась в развертывании RabbiMQ в то время это развертывание в одной точке, и все думают, что RabbitMQ не выйдет из строя, таким образом игнорируя контейнер, в котором он находится.Поэтому мы думаем об этой проблеме, что все предприятия не могут иметь единую точку, включая серверы приложений , промежуточное ПО, сетевое оборудование и т. д. Единую точку нужно рассматривать не только из самой одной точки, например, весь сервис дублируется, а потом АБ-тест, конечно, есть и двухместные компьютерные залы.
Q2: DevOps в вашей компании работает вместе?
A2: Наша разработка, эксплуатация и техническое обслуживание разделены.Сегодняшнее совместное использование в основном основано на доступности всей системы.Есть много развития, и есть часть эксплуатации и обслуживания. Я был свидетелем путешествия этих платежных систем CreditEase.
Q3: Все ли вы используете Java в своей серверной части? Рассматривались ли другие языки?
A3: Большинство наших текущих систем - это java, и есть несколько python, php и C++. Это зависит от типа бизнеса. В настоящее время java является наиболее подходящим для нас на данном этапе, и другие языки могут учитывать по мере расширения бизнеса.
Q4: Я скептически отношусь к сторонним зависимостям, можете ли вы привести конкретный пример, чтобы объяснить, как это сделать? Что делать, если третья сторона совершенно бесполезна?
A4: Система обычно имеет сторонние зависимости, такие как базы данных, сторонние интерфейсы и т. д. При разработке системы необходимо сохранять подозрительность к третьей стороне, чтобы избежать цепной реакции, когда у третьей стороны возникают проблемы, приводящие к простоям. Все мы знаем, что как только в системе возникает проблема, она будет разрастаться как снежный ком и становиться все больше и больше. Например, если есть только один сканирующий канал, при возникновении проблемы с этим сканирующим каналом ничего не сделать, поэтому я сомневаюсь с самого начала. система мониторинга запускает сигнал тревоги, она автоматически переключает канал маршрутизации, чтобы обеспечить доступность услуги; во-вторых, разделяет асинхронные сообщения для разных типов платежей, продавцов и типов транзакций, чтобы гарантировать, что если один тип транзакции произойдет непредсказуемо после возникновения аномалии , другие каналы не будут затронуты. Это похоже на шоссе с несколькими полосами движения, где быстрые и медленные полосы не влияют друг на друга. На самом деле общая идея — отказоустойчивость + разделение + изоляция, и эта конкретная проблема рассматривается подробно.
В5: После истечения срока платежа будут проблемы с сетью, будут ли уже выплаченные деньги, потерянные заказы, как сделать аварийное восстановление и целостность данных, а также были ли воспроизведены журналы и восстановлены ли данные?
A5: Самое главное при совершении платежа - это безопасность, поэтому мы консервативны в обработке статуса заказа.Поэтому для заказов с ненормальной сетью мы устанавливаем статус обработки, а затем, наконец, завершаем транзакцию с банком или третьей стороной через активный запрос или пассивное принятие уведомлений. В платежной системе, помимо проблемы со статусом заказа и кодом ответа, мы все знаем, что банк или третье лицо отвечает кодом ответа, и перевод кода ответа и статуса заказа также должен быть консервативной стратегией. чтобы не было переплаты и недоплаты средств.И другие вопросы. Если коротко, то общая идея этого пункта в том, что безопасность средств стоит на первом месте, а все стратегии строятся по принципу вайтлиста.
В6: Как только что упоминалось, если срок действия канала оплаты истекает, стратегия маршрутизации будет распространена на другой канал.Согласно диаграмме каналов видно, что существуют разные способы оплаты, такие как оплата Alipay или WeChat, тогда, если Я хочу оплатить только через WeChat Для оплаты, почему бы не повторить попытку, а переключиться на другой канал? Или сам канал означает запрашивающий узел?
A6: Во-первых, переадресация не может быть выполнена по тайм-ауту, потому что тайм-аут сокета не может определить, была ли транзакция отправлена третьей стороне, была ли она успешной или неудачной, и в случае успеха повторить попытку. это переплата.В этом случае потеря средств не приемлема для компании;во-вторых,для функции маршрутизации ее нужно разделить на виды бизнеса.Если это разовая платежная транзакция,пользователю все равно,какой канал деньги уходят, и их можно маршрутизировать. Это канал сканирования. Если пользователи сканируют код с помощью WeChat, они обязательно будут использовать WeChat в конце, но у нас много промежуточных каналов. WeChat выходит через промежуточные каналы. Вот мы можем маршрутизировать различные промежуточные каналы, так что, в конце концов, WeChat по-прежнему платит пользователям.
Q7: Можете ли вы привести пример автоматического процесса восстановления? Как узнать детали нестабильности для перенаправления?
A7: Автоматическое восстановление заключается в том, чтобы сделать отказоустойчивую обработку путем перенаправления.Эта проблема очень хороша.Если обнаружится, что она нестабильна, она примет решение о перенаправлении. При перенаправлении должно быть ясно, что текущая перенаправленная транзакция не может быть успешно маршрутизирована, иначе это вызовет проблему переплаты и переплаты. В настоящее время перемаршрутизация нашей системы в основном определяется двумя методами: после события и во время события, например, если через систему раннего оповещения в реальном времени в течение 5 минут после события обнаруживается нестабильный канал, то транзакции после текущего периода будут перенаправлены на другие каналы. ; Для тех, кто находится в процессе, в основном путем анализа кода ответа об отказе, возвращаемого каждым заказом, сортировки статуса кода ответа и повторной маршрутизации, если ясно, что это можно возмутить. Здесь я имею в виду перечисление этих двух моментов.Есть много других бизнес-моментов.Из-за недостатка места я не буду вдаваться в подробности,но общая идея такова,что должна быть система анализа в реальном времени в памяти для принятия решений в и автономный анализ для поддержки принятия решений, наша система раннего предупреждения второго уровня в режиме реального времени делает это.
Q8: Существуют ли какие-либо правила для рекламных акций продавцов? Насколько будет отличаться пик во время акции от обычного? Есть ли технические упражнения? Каков приоритет понижения?
A8: Что касается рекламных акций продавцов, мы часто заранее общаемся с продавцами, заранее понимаем время и объем рекламных акций, а затем делаем что-то целенаправленное; разрыв между пиковой рекламной акцией и обычным временем очень велик, и рекламные акции обычно сравниваются. в течение 2 часов.Например, при продаже некоторых продуктов по управлению капиталом продвижение сосредоточено в течение 1 часа, поэтому пиковое значение очень велико; техническая тренировка заключается в том, что мы понимаем объем продвижения продавца, а затем оцениваем вычислительную мощность система, а затем сделать сверло заранее, понизить Приоритет в основном для продавцов.Поскольку у продавцов, обращающихся к нам, есть много сценариев оплаты, есть управление капиталом, сбор и оплата, быстрое сканирование кода и т. д., поэтому наша общая Принцип заключается в том, что между разными продавцами не должно быть никакой разницы, они могут влиять друг на друга, потому что вы не можете влиять на другие предприятия из-за своего продвижения.
Q9: Как хранятся журналы коллекции rsyslog?
A9: Это хороший вопрос.Вначале наш лог,то есть лог отслеживания заказов, был записан в таблицу базы данных.Оказалось, что для обращения заказа требуется очень много модулей. такого порядка около 10 транзакций.Если 400w в день Если есть транзакция,то есть проблема с этой таблицей БД.Даже если она будет разделена,то это повлияет на производительность БД,а это вспомогательное дело и не следует делать. Затем мы обнаружили, что запись журнала лучше, чем запись базы данных, поэтому мы печатаем журнал реального времени в виде таблицы и распечатываем его на жесткий диск.Поскольку это только журнал реального времени, объем журнала невелик и находится в фиксированном каталоге сервера журналов. Поскольку все журналы находятся на распределенных машинах, а затем собираются в централизованное место, эта часть сохраняется путем монтирования, а затем программа, написанная специальной командой по эксплуатации и обслуживанию, анализирует эти табличные журналы в режиме реального времени и, наконец, передает страница визуализации отображается на странице операции, так что трек заказа, видимый оператору, почти в реальном времени.Как вы его храните, на самом деле не проблема, потому что мы разделили журналы в реальном времени и автономные журналы, и автономные журналы, которые превысит определенный период времени, будет отображаться сокращение и, в конечном итоге, удаление.
Q10: Как работают системный мониторинг и мониторинг производительности?
A10: Мониторинг системы, как я понимаю, включает мониторинг производительности системы. Мониторинг производительности системы является частью общего мониторинга системы, и здесь нет проблем с координацией. Мониторинг производительности системы имеет несколько измерений, таких как уровень приложений, промежуточное программное обеспечение и контейнеры. Для некоммерческого мониторинга системы вы можете просмотреть обмен статьями.
Автор: Фэн Чжунци
Источник: Технологический институт CreditEase.