гусеничный дизайн - вызов асин c работы вместо вызова службы

Question

Я смотрю на дизайн Донна Мартина для веб-сканера . служба искателя обрабатывает недавно просканированный URL, а затем:

• Добавляет задание в очередь службы обратного индекса для генерации обратного индекса
• Добавляет job в очередь Службы документов для генерации stati c title и сниппета

, что произойдет, если вместо этого служба искателя будет синхронно вызывать эти 2 службы ? Я все еще смогу горизонтально масштабировать все 3 службы в соответствии с нагрузкой на каждую, верно? то, что мне пришло в качестве возможной причины, это просто более сложное управление потоком, если один из них выходит из строя. Есть ли другие более веские причины для этих асин c рабочих мест?

Answer 1

что произойдет, если вместо этого служба искателя будет синхронно вызывать эти 2 службы?

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

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

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

Этот подход не гибкий. Обычно вы можете добавлять столько новых служб, сколько хотите, чтобы легко масштабировать рабочую нагрузку без каких-либо изменений в коде. Таким образом, «управление потоком» не должно существовать как код, который требует модификации каждый раз, когда вы добавляете или удаляете экземпляры службы. В реальных приложениях, которые могут увеличиваться и уменьшаться, все эти действия выполняются автоматически без повторного развертывания приложения.

Answer 2

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

• Модульность: это облегчает понимание приложения , разрабатывать, тестировать и становиться более устойчивыми к разрушению архитектуры. [6] Это преимущество часто аргументируется в сравнении со сложностью монолитных c архитектур. [33]
• Масштабируемость: поскольку микросервисы внедряются и развертываются независимо друг от друга, то есть работают в независимых процессах, их можно отслеживать и масштабируются независимо. [34]
• Интеграция гетерогенных и унаследованных систем: микросервисы рассматриваются как жизнеспособное средство для модернизации существующего программного приложения monolithi c. [35] [36] Имеются сообщения об опыте нескольких компаний, которые успешно заменили (частично) свое существующее программное обеспечение на микросервисы или находятся в процессе. [37] Процесс модернизации программного обеспечения унаследованных приложений выполняется с использованием поэтапного подхода. [38]
• Распределенная разработка: она распараллеливает разработку, позволяя небольшим автономным группам независимо разрабатывать, развертывать и масштабировать свои соответствующие службы. [39] Это также позволяет архитектуре отдельной службы появляться в результате непрерывного рефакторинга. [40] Микросервисные архитектуры облегчают непрерывную интеграцию, непрерывную доставку и развертывание. [41] [42]

Все это применимо в этом случае. Действительно, четко определенный API делает модули отдельными, многократно используемыми, простыми для понимания. Скорее всего, каждый из трех модулей будет иметь разное время выполнения и требования к процессору / памяти, поэтому масштабирование их по отдельности имеет большой смысл. Некоторые компании, такие как Amazon, упомянутые на странице, могут go значительно разделить эти модули на микросервисы на основе номера группы, поэтому такое разделение на 3 службы может быть очень хорошо выбрано, исходя из предположения о наличии 3 команд, а не из-за технических ограничений.

На странице также описана критика техники.