Однонедельная сердитая печень, миллион высококонкурентных систем｜Обзор проекта

В этой статье рассказывается об опыте, идеях и озарениях Юпи по поводу экстренного запуска миллионной высокопараллельной системы с нуля за одну неделю во время его стажировки в Tencent.

Потратьте 5 минут на прочтение этой статьи, и вы получите:

Углубить понимание фактической рабочей среды и условий труда
Изучите идеи дизайна, выбор технологий и понимание систем с высокой степенью параллелизма.
Узнайте, как общаться с несколькими сторонами на работе
Получите навыки работы с тестом
Научитесь справляться с чрезвычайными ситуациями
Как подвести итоги постфактум
Почувствуйте боль и борьбу авторского творчества

предисловие

Несколько лет назад я взялся за срочный проект с двумя менторами. После сверхурочной работы и завершения первого этапа проекта год назад эффект от проекта был замечательным. Поэтому второй этап был ускорен сразу после начала строительства, и цель состояла в том, чтобы запустить через неделю. Из-за сложной бизнес-логики проекта, плотного графика, нехватки рабочей силы и множества стыковочных партий это очень сложно и сложно, поэтому я начал работу с агентом 007 вместе со своим наставником.

Удаленная работа, несомненно, создавала благоприятные условия для круглосуточной работы системы агента 007. В то время я мечтал набирать коды.

Описание Проекта

Прежде всего, мы представим проект и ответственную систему. Естественно, бизнес-информация, связанная с проектом, не может быть раскрыта.Здесь бизнес разделяется и вводится только ключевая модель системы, как показано на следующем рисунке:

Как показано на рисунке, я отвечаю за систему передачи состояний и систему запросов, а также за службы баз данных, от которых они зависят.

Роль системы передачи статуса заключается в изменении поля статуса определенной части данных в базе данных в соответствии с логикой и отправке уведомления другим сторонам бизнеса в соответствии со статусом после успешного изменения.

Система запросов, как следует из названия, предназначена для запроса данных из базы данных, включая самые основные функции, такие как аутентификация и запрос.

Давайте сначала проанализируем некоторые трудности в системе:

Система запросов — это высокоэффективный сервис, к которому обращаются другие стороны бизнеса, и есть три проблемы:

Высокий параллелизм: Совокупный объем запросов каждой стороны бизнеса. После оценки он будет генерировать миллионы одновременных запросов с большим количеством запросов.

совместимость: Как разработать API, который отвечает потребностям каждой стороны бизнеса и прост для понимания.

Стыковка сложная: Очень сложно думать об общении со студентами из разных сторон бизнеса, чтобы обсудить интерфейс одновременно.
Бизнес-логика системы государственных переводов достаточно сложна.
Существует взаимодействие между системой передачи состояний, системой запросов и другими сторонами бизнеса (например, отправка уведомлений и вызовов друг другу), что требует высокой задержки, отказоустойчивости и согласованности.

Проанализировав трудности, перед написанием кода необходимоСначала напишите выполнимый технический план.

Идеи дизайна

В практической работе очень нужно написать подробную техническую схему. Отличные инженеры рассмотрят различные сценарии, оценят различные риски, оценят объем работы, зафиксируют различные проблемы и т. д. в технических решениях, которые не только помогут самим разобраться в своих идеях и обобщить, но и послужат ориентиром и убеждением для других (например, если вы рассчитываете быть онлайн через 7 дней, кто вам поверит без плана?).

Согласно теореме двадцати восьми, в сложной системе соотношение времени, затрачиваемого на написание технических решений, разбор дизайнерских идей и фактическое время разработки кода, составляет 8:2.

Принципы проектирования«Фит бизнес»,Нет лучшей архитектуры, есть только лучшая архитектура для бизнеса. Не переусердствуйте!

Кроме того, следует учитывать срочность проекта и стоимость рабочей силы, а также сначала гарантировать доступность, а затем стремление к конечному результату.

Некоторые простые конструкции здесь опущены.Вот несколько системных сложностей и бизнес-требований.Ключевой дизайн и выбор технологии:

1. Высокий параллелизм

Когда речь заходит о высоком уровне параллелизма, первое, что приходит на ум, — это кэширование и балансировка нагрузки, без которых не обойтись.

Проще говоря, балансировка нагрузки — это «потратить деньги и добавить машины!», но она экономит машины,Снижение затрат и повышение эффективностиЭто убеждение каждого бэкенд-инженера, которое зависит от выбора технологии, проектирования архитектуры и кодирования. Цель состоит в том, чтобы максимально использовать ограниченные ресурсы каждой машины, чтобы выдерживать самые большие одновременные запросы.

Технический отбор

Выбор следующий:

Среда программирования: выберите облегченную среду Restful Jersey с облегченной библиотекой внедрения зависимостей Guice.

Веб-сервер: выберите высокопроизводительный облегченный сервер NIO Grizzly

Кэш: Массивная распределенная система хранения CKV+ собственной разработки Tencent (поддерживает протокол Redis, с платформой мониторинга данных)

Подтаблица базы данных подтаблица базы данных: выбираем инфраструктуру собственной разработки компании, не вдаваясь в подробности

Балансировка нагрузки: Легкий обратный прокси-сервер Nginx и балансировка нагрузки L5, миллионы одновременных нужно добавить более десяти машин

CDN и прогрев: может поддерживать эффективную службу загрузки файлов

в,тайникЭто ключ к сопротивлению высокому параллельному трафику, и он должен быть разработан с особым вниманием.

схема кэширования

1. Дизайн структуры данных

Учащиеся, которые использовали кэш, знают, что конструкция ключа кэша очень важна. По мнению бизнеса, хорошо убедиться, что между ключами кеша нет конфликта, и его легко найти. Здесь я выбираю параметр запроса + уникальный идентификатор интерфейса для объединения ключа. И интерфейс запроса подкачки может повторно использовать кеш полного интерфейса запроса.

2. Понижение кэша

Если соответствующий ключ не найден/сбой соединения redis, проверьте базу данных напрямую.

3. Обновление кеша

При изменении базы данных кеш необходимо удалить. Ключ кэша может иметь неоднозначное значение из-за необязательных параметров запроса. Например, есть два параметра запроса a и b, а ключ может быть "a" или "ab".

Для интерфейсов с фиксированными полями запроса (обязательны все поля) при обновлении кеша просто выпилить уникальный ключ и удалить его.

Для интерфейсов, где поля запроса не фиксированы (есть необязательные поля), вы можете использовать команду сканирования redis для сканирования в диапазоне (не используйте команду keys!) или конкатенировать все возможные ключи через цикл. Например, используйте команду сканирования, чтобы очистить все кэши, ключи которых имеют префикс user1.

4. Проникновение в кэш

Независимо от того, пуст запрошенный список или нет, он записывается в кэш. Однако, когда бизнес возвращает несколько кодов ошибок, этот метод не рекомендуется из-за высокой сложности и высокой стоимости.

2. Совместимость

Совместимость в основном исследует дизайн интерфейса.Чтобы быть совместимым с несколькими сторонами службы, параметры запроса и параметры ответа должны быть установлены как можно более гибко. При разработке интерфейсаНе нужно согласовывать все стороны бизнеса, иначе неправильное оформление поля может привести к проигрышу всей игры!

здесь естьтри совета:

Документы с доступными ссылками предоставляются вызывающим абонентам для немедленного ознакомления (например, документы Tencent).
Параметров запроса не должно быть слишком много и они должны быть простыми для понимания, а также не следует задавать слишком сложные параметры для обеспечения совместимости, при необходимости интерфейс можно настроить под определенную сторону сервиса.
Параметров ответа должно быть как можно больше (в основном не огульно).Необходимо знать, что код должен модифицироваться каждый раз, когда добавляется поле возврата, а соответствующие избыточные поля позволяют избежать этой проблемы.

3. Уведомление о сообщении

При представлении описанных выше трудностей было упомянуто, что существует взаимодействие между системой передачи состояний, системой запросов и другими бизнес-сторонами для отправки уведомлений друг другу. Когда состояние передается, другие службы должны быть уведомлены, а система запросов должна немедленно обновить кеш. Требования к сообщениям в режиме реального времени очень высоки.

Здесь в началеЕсть два варианта:

Каждая система предоставляет интерфейс обратного вызова для получения уведомлений. Это может обеспечить производительность в режиме реального времени, но тесная связь между системами не способствует расширению.
Используйте очереди сообщений для разделения приложений и асинхронного обмена сообщениями.

В конце концов, был принят второй вариант, и было выбрано TubeMQ (промежуточное ПО для распределенного обмена сообщениями триллионного уровня, которое было инкубировано с Apache с открытым исходным кодом), разработанное Tencent, по следующим причинам:

После уведомления данных системы передачи состояний могут быть другие потребители.Использование очередей сообщений способствует расширению и менее навязчиво к коду.
Очереди сообщений сохраняют сообщения
TubeMQ поддерживает балансировку потребительской нагрузки с высокой производительностью
TubeMQ обладает большой емкостью и может хранить триллионы сообщений.
Поддержка самостоятельно разработанных компонентов компании для облегчения формирования унифицированных спецификаций

При выборе технологий и определении решений мы должны ориентироваться не только на текущие потребности бизнеса, но и иметь определенный передовой взгляд.

4. Оценка риска

Не стоит, прежде чем выбрать промежуточное ПО/фреймворк, узнать как можно больше и оценить возможные риски. Как правило, компании имеют свои собственные базы знаний, и вы можете эффективно использовать внутренние ресурсы или найти Google, чтобы помочь вам.

Здесь я оценил риски, связанные с TubeMQ, и проанализировал их с точки зрения надежности сообщений, последовательности сообщений, повторения сообщений, мониторинга аварийных сигналов и т. д. и обнаружил некоторые возможные риски. Например, когда потребитель не может использовать сообщение об изменении состояния данных, кеш не обновляется вовремя, что приводит к несогласованности данных в базе данных и кеше.

Итак, как избежать рисков? Я разработал решение для обеспечения надежности сообщений и согласованности данных с точки зрения производителей и потребителей очередей сообщений.

решение

Надежность сообщения производителя:

Tube может гарантировать, что сообщение будет доставлено, и оно будет автоматически повторно отправлено, если оно не будет отправлено.
При отправке сообщения срабатывает обратный вызов.В обратном вызове можно судить о статусе отправки сообщения и подтверждении.Сообщение, которое не удалось отправить, может быть поставлено в очередь, и следующая отправка будет иметь приоритет от очередь.

Надежность потребительских сообщений и согласованность данных:

Повторите попытку до трех раз, если потребление не удается
Если потребление по-прежнему не удается после повторной попытки, журнал записывается, чтобы гарантировать, что сообщение не будет потеряно.
Прочитайте журнал через запланированное задание, попробуйте снова использовать сообщение о сбое и подать сигнал тревоги.

процесс разработки

Собственно о процессе разработки и говорить нечего, это набирать код по установленному техническому плану.

здесь тожеНесколько советов по развитию:

При одновременной разработке нескольких проектов вы можете иметь независимую ветку Git для каждого проекта, отправлять и объединять в пакетном режиме, иначе другие будут очень уставать при чтении отправленного вами кода!
Делайте отчеты о данных для каждого запроса, таких как объем запроса, время запроса и количество невыполненных запросов, чтобы облегчить мониторинг и статистику.
Запись большего количества журналов, подробных и четких журналов может помочь нам быстро найти неисправности.

проблема решена

Многие проблемы не замечаются при локальной разработке, а обнаруживаются только при тестировании и онлайн-средах. Процесс решения проблемы похож на катание на американских горках: обычное состояние: тестирование => разработка => тестирование => запуск => разработка => тестирование, и цикл идет туда и обратно.

Два теплых совета:

Когда вы сталкиваетесь с проблемой, не паникуйте, вы можете сначала сделать несколько глубоких вдохов, потому что проблема должна быть решена, если вы не можете ее решить, вы можете быть решены!
После решения проблемы не волнуйтесь, вы можете сначала сделать несколько глубоких вдохов, потому что вы создадите новые проблемы, а часто новые проблемы более серьезны!

Вот несколько вопросов, которые впечатляют рыбью шкуру.

1. Сообщается об ошибке при отправке транзакции?

Причина: В функции, вызываемой в транзакции, также есть транзакция, поэтому транзакция встроена в транзакцию, что разрушает изоляцию.

Решение. Измените код, чтобы обеспечить изоляцию транзакций.

2. Пакет зависимостей существует, но при запуске проекта сообщается об ошибке?

Причина: существуют пакеты jar с несколькими версиями, из-за чего код Java использует механизм отражения для динамического создания классов, не зная, какой пакет jar использовать.

Решение. Удалите пакет jar избыточной версии.

3. Кэш обновляется не сразу

Причина: После расследования это связано с тем, что реальное количество ключей кеша может достигать десятков миллионов, что приводит к низкой эффективности сканирования командой сканирования при обновлении кеша, которое длится более 20 секунд!

Решение: Изменить схему обновления кеша, больше не использовать команду сканирования, а собрать воедино все возможные ключи в бизнес-коде и удалить их по очереди.

Думали, на этом вопрос закончился? Не забывайте советы выше:

«После решения проблемы не горячитесь, вы можете сначала сделать несколько глубоких вдохов, потому что у вас появятся новые проблемы, а часто новые проблемы более серьезные!»

4. Кэш все равно сразу не обновляется?

Причина: бизнес-сторона требует строгой согласованности данных, а состояние в кеше и базе данных должно быть абсолютно одинаковым! Хотя кэш обновляется за миллисекунды, он не может быть согласованным в режиме реального времени.

Решение: Настройте интерфейс для бизнес-стороны.Этот интерфейс не запрашивает кэш, а напрямую запрашивает базу данных, чтобы убедиться, что найденные данные должны быть самыми последними значениями.

5. Запрос завис

После того, как служба поработает некоторое время, обнаруживается, что все запросы заблокированы! Сердце не выдержит.

Причина: после использования jstack для вывода информации о потоке и анализа файла thread_dump было обнаружено, что количество соединений исчерпано, поскольку библиотека кэша Jedis не освобождает соединение вручную, в результате чего создается новый поток запроса, который будет продолжать ожидать Соединение джедаев должно быть разорвано, таким образом застряв.

Решение: Просто добавьте код, чтобы освободить соединение Jedis.

6. Когда онлайн-среда анализирует журнал, внезапно возникает тревога, и использование дискового ввода-вывода превышает 99%!

Причина: неправильное использование команды cat для просмотра исходного неразделенного файла журнала, так как файл журнала слишком велик (десятки ГБ), что приводит к прямому всплеску дискового ввода-вывода!

Решение. Используйте такие команды, как less, tail, head и т. д. вместо команды cat, и удалите большие файлы журналов, для которых были созданы резервные копии.

7. Сбой процесса

Устранение неполадок: обычно есть журнал ошибок, когда процесс JVM возвращается, но он не найден, и устранение неполадок находится в безвыходной ситуации. Нет другого пути, кроме как молиться, чтобы проблема не повторилась. После этого проблема действительно не появлялась, спасибо!

Причина: Позже, по запросу, кто-то вручную убил процесс. В ПОРЯДКЕ,***.

8. Уведомление о сообщении онлайн-среды было успешно отправлено, почему нет ожидаемого эффекта обновления данных?

Идея позиционирования: сначала проверьте, потребляется ли сообщение, а затем проверьте, правильно ли оно обрабатывается.

Устранение неполадок: проверьте онлайн-журнал и обнаружите, что сообщение не используется, но проверьте интерфейс мониторинга и обнаружите, что сообщение используется машиной в тестовой среде!

Причина: Поскольку тестовая среда и онлайн-среда принадлежат к одной и той же группе потребителей, когда сообщение поступает, только один потребитель в той же группе потребителей может успешно обработать сообщение, которое используется тестовой средой, в результате чего данные онлайн-среды не обновляется.

Когда я обнаружил эту проблему, была уже поздняя ночь накануне запуска. Слишком поздно подавать заявку на другую группу потребителей, в спешке мы можем только сначала отказаться от услуги тестовой среды. После подачи заявки на группу потребителей на следующий день вы можете определить, какую группу потребителей использовать в соответствии со средой, чтобы каждая группа потребителей могла потреблять сообщения независимо, успешно избегая конкуренции сообщений.

9. Сообщить! Трафик слишком большой, я не могу его удержать!

Причина: Машин не хватает, требуется экстренное расширение

Решение: Аварийное новое приложение для 10 машин завершено, первоначальная конфигурация завершена, а параллелизм успешно увеличен после успешного развертывания новой машины.

Советы: Когда вам нужно выполнить одну и ту же операцию на нескольких машинах, есть два ярлыка.

Используйте функцию параллельной работы инструмента подключения SSH для автоматического ввода команд для всех машин (поддержка программного обеспечения XShell).
После настройки одной машины вы можете использовать команду rsync для синхронизации конфигурации с другими машинами.

10. За день до запуска вы сказали мне, что возникла проблема с дизайном интерфейса?

Причина: Серьезная проблема со связью!

На работе некоторые коллеги могут не обращать внимания на проверку дизайна интерфейса из-за своей занятости. Когда они закончат, они будут неоднократно общаться с вами @you и приватно общаться с вами, чтобы задать вопрос. Мы не должны этого делать!

Решение: экстренный конференц-связь, группа по запросу для проверки плана

11. Ошибка онлайн!

Онлайн-ошибки — это большая проблема, и на них нужно реагировать срочно. Ты должен вставать за меня даже во сне!

Причина: тестовая среда и онлайн-среда могут не совпадать, и тестовая среда может не обнаруживать все проблемы. Поэтому для проверки обычно требуется предварительная среда, а данные используют онлайн-данные, но это независимый сервер, чтобы гарантировать, что он не влияет на онлайн.

Решение: Аварийное устранение неполадок и проблемы с позиционированием, успешно устраненные за три минуты!

Есть определенные навыки для исправления ошибок, поделитесь следующими личными путями устранения неполадок:

Скриншоты/проблемы => запрос => можно ли воспроизвести ошибку, и тесно сотрудничать с тестом => данные => источник данных (соответствуют ли реальные данные данным интерфейса) => обработка данных

объяснять:

Обычно это эксплуатация и обслуживание, пользователи или тесты, которые находят проблему.Они будут кидать скриншот проблемы или проблемы.В это время нам нужно быстро придумать функцию, соответствующую проблеме (т.е. соответствующий запрос/ интерфейс), а затем дайте описание проблемы Предоставьте как можно больше информации (например, параметры запроса, время возникновения проблемы и т. д.).

Если проблема занимает много времени, трудно проверить журнал и мониторинг, вы можете спросить, можете ли вы создать кейс для воспроизведения проблемы, чтобы вам нужно было наблюдать только последний журнал, что удобно для устранения неполадок.

После обнаружения запроса нам нужно проанализировать, какие данные запроса и ответа являются ненормальными, то есть найти ключевые данные, а затем найти источник данных (будь то из базы данных или из кеша) и посмотреть, являются ли данные ответа и реальный источник данных являются согласованными. Если оно несовместимо, может возникнуть проблема с обработкой данных в бизнес-логике, и потребуется дополнительный анализ.

Предложения по эффективному общению: опишите проблему, попытайтесь говорить с данными и предоставьте полные данные, запросы и другую информацию, предоставляя скриншоты, чтобы помочь другим проанализировать.

12. В сети есть неверные данные

Это предсказуемая проблема. К счастью, в проекте настроены оповещения по электронной почте, которые могут сообщать информацию о некорректных данных, а количество некорректных данных невелико.

Решение: после исправления ошибки, из-за которой были получены неверные данные, напишите программу, которая перебирает все сообщения об ошибках и генерирует код запроса, а затем вручную выполняет код запроса для обновления асинхронных данных в режиме онлайн.

Предложение: При проектировании следует максимально учитывать риски, и можно разработать иерархическую стратегию оповещения (SMS>Электронная почта>Коммуникационное программное обеспечение) в соответствии с серьезностью проблемы.

13. Онлайн машина ООМ!

Проблема была обнаружена через три дня после подключения к Интернету: на некоторых онлайн-машинах возникает OOM (переполнение кучи памяти), из-за чего служба становится недоступной. После расследования было обнаружено, что текущая версия используемого стороннего промежуточного программного обеспечения содержит ошибки, поэтому необходимо полностью изучить и оценить риск перед использованием компонента и выбрать правильную версию.

Уроки крови и слез

Если есть проблема, то ее нужно максимально решать в тестовой среде, иначе онлайн-проблема очень недружелюбна к сердцу.
Не стоит быть слепо оптимистичным, думая, что проблем с выходом в интернет не будет, нужно больше верифицироваться и быть бдительным.
При использовании сторонних зависимостей обязательно строго проверяйте номера версий зависимостей, чтобы обеспечить стабильную версию. Использование старых или несовместимых версий может привести к серьезным ошибкам!

Если вы обнаружите проблему после выхода в Интернет, вы пройдете следующий процесс, который я называюсчастливый процесс.

Например, когда вы обнаружите ошибку в службе БД, вам нужно изменить только одну строку кода в службе БД.Еще предстоит сделать:

Строка кода для изменения службы БД
запускать модульные тесты
Служба БД упакована как пакет зависимостей
Измените пакеты зависимостей «системы передачи состояния» и «системы запросов» в службе БД (измените номер версии/обновите локальный кеш, чтобы получить последний пакет)
Повторно опубликуйте «систему передачи состояния» и «систему запросов» в тестовую среду.
Он также может быть повторно передан тестируемым для регрессионного тестирования.
Если тест пройден, снова отправьте код «системы передачи состояния» и «системы запросов» и инициируйте CR (просмотр кода).
Найдите коллегу или Лидера, чтобы прочитать код и пройти CR
объединить ветвь
Опубликуйте «систему передачи состояния» и «систему запросов» в онлайн-среду, и каждый раз, когда машина отправляется, требуется проверка (последовательное развертывание).
Снова найти новые ошибки

Это отвратительно, но на шагах 2, 6 и 8 есть запасное время ожидания. В это время мы можем выполнять другую работу, записывать содержание работы, проблемы и т. д.

Резюме мышления

Во-первых, суммируйте затраты времени на каждый этап проекта:

Понимание потребностей: 5%

Развитие: 15%

Проблема подтверждения связи: 30%

Тестирование и проверка: 30%

Листинг и проверка: 20%

Среди них исправление ошибок проходит через следующие процессы, на которые приходится около 60% общего времени.

Проблемы в процессе проекта:

Я не участвовал в обзоре требований на ранней стадии и узнал меньше информации.
В ночь перед запуском он еще временно выравнивал интерфейс? Это должно быть подтверждено на этапе плана коммуникации.
Около 80% времени тратится на общение, запросы данных, предоставление данных и их проверку.
Прежде чем закончить тест, я начал тестировать вместе, в результате чего одна и та же ошибка была обнаружена несколькими сторонами, и повторил @, что привело к низкой эффективности исправления ошибок.
Незнание самостоятельно разработанного промежуточного программного обеспечения приводит к большим затратам времени и средств.
Общей картины недостаточно, чтобы заранее предвидеть некоторые возможные проблемы.
Недостаточное исследование промежуточного программного обеспечения, отсутствие проверки номера версии зависимости в начале привело к OOM онлайн-машины.

Почувствуйте себя хорошо:

Тесно сотрудничайте с одноклассниками, понимайте друг друга, и эффективность теста высока.
Для системы запросов пишется подробный интерфейсный документ, который загружается в базу знаний компании для просмотра в режиме реального времени.
Быстро исправляйте онлайн-ошибки всего за 3 минуты
Всего 30 минут с момента принятия запроса до запуска
При обнаружении проблемы промежуточного программного обеспечения немедленно свяжитесь с стыковочной стороной и разработайте недорогое решение без какого-либо воздействия на нее.
Активно помогайте другим учащимся запрашивать данные и устранять проблемы
Напишите сценарии для эффективного разрешения некоторых ошибочных данных

Рост и урожай:

Способность противостоять стрессу и поздно ложиться спать ↑
Навыки дизайн-мышления ↑
Коммуникабельность ↑
Навыки решения проблем ↑
Знакомство с расширенными командами ↑
Знакомство с промежуточным ПО ↑
Возможности управления кластером ↑
Способность отказать в спросе ↑
Способность Тукао ↑
Удар 🐂 Способность ↑

следовать за

После того, как проект был запущен, путем подведения итогов и обзора я нашел области, которые стоит оптимизировать в проекте, а также подумал о еще каких-то надежных механизмах, которые будут постепенно внедряться. Например:

1. В обеих системах есть несколько одинаковых конфигураций

В настоящее время одна и та же конфигурация синхронизируется путем копирования и вставки.Преимущество этого метода заключается в его относительной простоте. Но очевиден и недостаток: если изменить конфигурацию одной системы и забыть изменить конфигурацию другой системы, произойдет ошибка.

Фактически, можно ввести центр конфигурации для централизованного управления файлами конфигурации нескольких систем и поддержки таких функций, как ручное изменение, мультисреда, оттенки серого и откат версии конфигурации.

Вы можете использовать Nacos от Ali или Apollo от Ctrip, которые предоставляют интерфейс для управления конфигурацией.

2. К проблеме сбоя предыдущего процесса нужно отнестись серьезно!

Нет никакой гарантии, что процесс не вернется обратно, но он может отслеживать процесс в режиме реального времени и автоматически перезапускать процесс обратного воспроизведения.

Есть две реализации:

Используйте инструменты, такие как супервизор или monit и т. д., для управления и перезапуска процесса.
Напишите сценарии оболочки, а затем периодически наблюдайте за состоянием процесса и перезапускайте его с помощью запланированных задач. Рекомендуется подключать временные задачи к платформе распределенного планирования задач, особенно когда задач много, необходимо визуальное управление и удобный контроль и планирование!

3. Гарантия надежности очереди сообщений

Механизм повторной передачи сообщения: как указано в плане, спроектируйте очередь повторной передачи (или очередь недоставленных сообщений) и отдайте приоритет сообщению в очереди повторной передачи при повторной отправке. Но обратите внимание, чтобы избежать бесконечных повторных передач в очереди, для каждого сообщения должен быть установлен порог количества повторных передач.
Оповещение по электронной почте: если количество повторных передач сообщения превышает пороговое значение, оповещение по электронной почте будет отправлено напрямую, и сообщение не будет помещено в очередь.

Работа действительно простая но не простая, кто сказал что бэкенд это просто CRUD (CRUD)?

Это почти 7000 слов, надеюсь, вы поддержите эту статью большим количеством лайков!

Эта статья участвует в «Весенней рекрутинговой кампании Nuggets 2021», нажмите, чтобы просмотретьподробности о мероприятии