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

В этом уроке мы обсудим самые популярные вопросы на собеседовании по микросервисам.

В этом руководстве обсуждаются наиболее часто задаваемые вопросы на собеседованиях. Он служит богатым ресурсом для быстрого обновления или обзора микросервисов.

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

Итак, начнем!

Лучшие вопросы и ответы на собеседовании по микросервисам

00:0011:13УЗНАТЬ БОЛЬШЕ

Wiremock-stubbing&Proxying_211:14

Введение в Java для начинающих (учебник №1 — часть 2)15:01

Как запустить Selenium Webdriver в IE и Chrome…12:33

Методы утверждения и их реализация… 13:57

Покрытие кода Jest и создание отчетов в формате HTML10:18

Идеальное руководство по интеграции Spring Spock08:16

Что такое шутка? — Значение и введение16:49

Типы данных Python (учебник № 3, часть 2)16:35

Учебник по отладке Jest06:50

Wiremock: заглушки и проксирование_112:38

Ниже приведен рисунок, изображающий архитектуру микросервисов:

[изображение источник ]

Вопрос 1. Что такое микросервисы?

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

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

Вопрос 2. Каковы преимущества микросервисной архитектуры?

Ответ: Преимущества включают в себя:

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

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

b) Выявление ошибок. Если конкретная микрослужба выходит из строя, это не влияет на работу других служб. Если одна служба выходит из строя, это никак не влияет на работу других служб.

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

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

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

Вопрос 3. Каковы особенности микросервисов?

Ответ: Особенности:

  • Развязка: приложения могут быть легко отделены или, скорее, разделены, чтобы иметь индивидуальную функциональность, что подразумевает простоту разработки, обслуживания и развертывания.
  • Компонентизация. При компонентизации каждый микросервис рассматривается как отдельный компонент, который отвечает или управляет всеми сложностями, касающимися конкретной службы. Он фокусируется только на этом. Он слабо связан с другими услугами. Вот почему каждый из них можно рассматривать как отдельный компонент или контейнер.
  • Бизнес-возможности. Мы можем гораздо лучше сфокусировать бизнес-возможности, поскольку вы устанавливаете более мелкие цели и фокусируетесь на отдельных функциях. Становится проще разрабатывать приложения, отвечающие этим требованиям, с точки зрения вашего бизнеса.
  • Автономность. Разработчики теперь свободны, потому что благодаря небольшим групповым кластерам они могут свободно разрабатывать приложения. Это означает, что другие команды и разработчики не зависят друг от друга. Это обеспечивает ускоренное выделение программного обеспечения.
  • Непрерывная поставка: поскольку у вас так много функций, которые мы только что обсудили, это гарантирует, что у вас будут постоянные и частые выпуски программного обеспечения, а система может постоянно обновляться и модифицироваться в соответствии с потребностями конкретной компании или конкретной области бизнеса.
  • Ответственность. При таком подходе каждый домен или каждый проект рассматривается как продукт. Это означает, что команда возьмет на себя ответственность за так называемый продукт и воплотит его в жизнь, и это будет ответственность, то есть его создание, тестирование и продолжение всего жизненного цикла.
  • Гибкость. Поскольку у вас децентрализованная архитектура, вы можете легко создавать приложения и отказываться от них, если они больше не нужны.

Вопрос 4. Каковы характеристики микросервисов?

Ответ:

a) Организация на основе бизнес-возможностей. Поскольку у вас есть отдельные микросервисы, это означает, что у вас есть приложение, которое работает само по себе. У вас также есть база данных, соответствующая отдельным микрослужбам. Это означает, что если у вас есть 10 микрослужб, у вас будет 10 отдельных баз данных, которые соответствуют или отвечают только на эту конкретную микрослужбу.

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

б) Продукты, а не проекты. Предположим, у вас есть 10 микросервисов, у вас будут небольшие кластеры команды, которая создаст это приложение, а также будет его поддерживать. Amazon считает, что у вас должна быть команда из двух пицц. Это означает, что у вас должна быть такая маленькая команда, которая может выжить на двух пиццах, и вы также должны быть в состоянии поддерживать программное обеспечение.

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

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

d) Децентрализованное управление: обсуждалось ранее.

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

f) Автоматизация инфраструктуры. Поскольку у нас уже есть так много микросервисов, важно обеспечить надлежащую автоматизацию. Это обеспечивает быстрое развитие, а также обслуживание.

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

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

Вопрос 5. Как лучше всего разрабатывать микросервисы?

Ответ:

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

Вопрос №6. Что такое DDD (Domain Driven Design)?

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

Три основных принципа DDD:

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

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

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

Вопрос 7. Что такое вездесущий язык?

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

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

Вопрос № 8. Зачем нужен дизайн, ориентированный на предметную область (DDD)?

Ответ:

  • Сопоставление с доменом: мы сопоставляем нашу архитектуру с конкретным доменом.
  • Тестируемость: Тестирование приложения становится проще.
  • Ремонтопригодность: обслуживание приложения также становится проще, потому что все находятся на одной странице.
  • Дизайн, основанный на знаниях: эти приложения очень требовательны к знаниям.
  • Он объединяет бизнес и сервис.
  • Контекстно-ориентированный: в значительной степени сосредоточен на конкретной области.
  • Использует вездесущую сосредоточенность.
  • Уменьшенная сложность.

Вопрос № 9. Как работает архитектура микросервисов?

[изображение источник]

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

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

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

Архитектура включает:

  • Клиент и поставщик удостоверений
  • Шлюз API
  • Статическое содержимое
  • SDN — сети доставки контента
  • Микросервисы
  • Управление
  • Портал обнаружения услуг или модель
  • Пользователь
  • Удаленное обслуживание
  • Поставщик удостоверений, удаленная служба и микрослужбы.

Этапы понимания работы:

  1. Если клиент хочет использовать конкретную услугу, клиент отправляет запрос. Задача поставщика удостоверений — проверить, является ли пользователь действительным.
  2. Как только поставщик удостоверений аутентифицирует пользователя, запрос перенаправляется на шлюз API. Поскольку клиент не может напрямую общаться со службой, должен быть посредник или какой-то промежуточный подход, который позволяет клиенту общаться.
  3. Вот тут-то и появляется шлюз API. Он находит каталоги, которые ищет клиент, и запрос перенаправляется в эту службу.
  4. Сервис взаимодействует с другими сервисами и видит, как генерируется решение для клиента.
  5. Как только решение сгенерировано, оно отправляется обратно клиенту с использованием CDN, т. е. сети доставки контента.
  6. Статическое содержимое — это любое содержимое, которое вводится и находится в статической форме и удерживается статическим содержимым.
  7. У порталов управления и обнаружения услуг также есть особая задача. Например, у меня есть несколько сервисов. Портал управления размещает эти службы на соответствующих узлах.
  8. Обнаружение служб, с другой стороны, отслеживает все эти службы, отмечает службы, которые отказали, и все такое.
  9. Эта запись передается обратно на портал управления, и задачей этого портала управления является устранение сбоев в соответствующей архитектуре или любой из служб.

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

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

Вопрос 10. Каковы преимущества и недостатки микросервисной архитектуры?

Ответ. Это объясняется в таблице ниже:

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

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

Ответ:

[изображение источник]

Монолитная архитектура

Здесь один контейнер содержит полную архитектуру всех ваших сервисов или баз данных.

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

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

У монолитной архитектуры было немало других проблем:

  • Масштабирование было проблемой.
  • Изоляция была проблемой.
  • Тогда не было индивидуального развития.
  • Размещение было большой проблемой.
  • Трудно развивать, так как это был один сложный блок.
  • Слишком много зависимости друг от друга, что плохо для разработки программного обеспечения.

S.O.A

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

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

Микросервисы

Это не относится к микросервисам, которые имеют отдельные модули или полную модульность.

Вопрос № 12. Каковы основные различия между микросервисной архитектурой и SOA?

Ответ:

Есть несколько отличий, указанных ниже:

  • SOA фокусируется на совместном использовании почти всего с другими модулями. Но когда вы говорите о микросервисах, цель состоит в том, чтобы делиться как можно меньшим количеством информации.
  • Подход совершенно другой. Кроме того, у вас есть модульные приложения в SOA, но все еще есть много взаимозависимостей. Это не относится к микросервисам.
  • Говоря о взаимосвязи между службами, в SOA вам нужно промежуточное программное обеспечение для связи. Но в микросервисах, которые полностью независимы и для этого не нужно промежуточное ПО, они напрямую взаимодействуют с остальными API.

Вопрос 13. Какие проблемы возникают с архитектурой микросервисов?

Ответ:

  • Автоматизация компонентов. Мы можем автоматизировать все компоненты, но поддерживать эти компоненты — огромная задача, а бесперебойная работа автоматизации требует постоянного внимания.
  • Управление конфигурацией. Что касается универсальности и управления конфигурацией, вы должны понимать, что это не что иное, как подход, который касается всего дизайна, о котором вы говорите. А настройка этих микросервисов и четкая архитектура могут стать проблемой.
  • Заметность
  • Отладка. Отладка или отладка — это еще одна проблема, потому что у нас есть изоляция ошибок, и если какое-то приложение дает сбой, это не влияет на работу любого другого приложения. Но это также означает, что вы также должны постоянно контролировать.

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

Вопрос 14. Что такое сплоченность?

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

Сплоченность — это не что иное, как связь между приложением или внутренняя связь внутри приложения. Например, молекула внутри молекулы состоит из атомов. Эти атомы, насколько тесно они связаны друг с другом?

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

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

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

Вопрос № 15) Что такое REST/RESTful и для чего он используется?

Ответ: это API, то есть интерфейсы прикладных протоколов.

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

Вопрос 16. Что такое привод в Spring Boot?

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

Вопрос 17) Что такое Spring Boot?

Ответ: Spring – это подход к разработке веб-сервисов. Он дает вам все ингредиенты, которые необходимы для веб-приложения. Думайте об этом как о магазине, где вы получаете все ингредиенты для веб-разработки. Spring Boot — это настроенная версия Spring. Чтобы получить ясную картину, подумайте о процессе приготовления и приема пищи.

Пока у вас есть весна, у вас есть все ингредиенты. Тем не менее, вам придется приготовить еду и съесть ее. Spring Boot — это индивидуальный подход, при котором у нас есть готовая еда в холодильнике. Spring Boot означает еду. Все ингредиенты и специи уже хорошо перемешаны. Все, что от нас требуется, это поместить еду в духовку, чтобы она разогрелась, чтобы мы могли поесть.

Вопрос 18. Что такое Spring Cloud?

Ответ: это то, что позволяет проводить анализ в реальном времени и выполнять ограниченный объем обработки данных. Это не что иное, как API, предоставляемый Spring, и он помогает вам избавиться от различной сложности в том, что касается архитектуры.

Вопрос №19) Какие проблемы решает Spring Cloud?

Ответ:

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

Вопрос 20. В чем разница между REST и микросервисами?

Ответ: Различия включают:

  • REST — это средство для реализации микросервисов.
  • Это архитектурный стиль, который может разрабатывать крупномасштабные приложения, которые можно довольно легко масштабировать.
  • Он используется в дизайне API, а также в веб-приложениях.
  • Нам нужно следовать определенным шаблонам, чтобы сделать микросервисы слабо связанными.
  • Через REST мы можем создавать микросервисы.

Вопрос № 21. Какие существуют типы тестов для микросервисов?

Ответ:

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

Вопрос № 22. Что такое распределенная транзакция?

Ответ.Если у вас есть несколько приложений или служб, эти службы будут фиксировать изменения. Таким образом, необходимость внесения изменений в конкретный план запроса. Необходимо убедиться, что все приложения находятся на одной странице.

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

Вопрос № 23) Что такое идемпотентность и где она используется?

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

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

Вопрос 24. Что такое ограниченный контекст?

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

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

Вопрос № 25. Что такое двухфакторная аутентификация?

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

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

Этот тип аутентификации известен как двухфакторная аутентификация.

Заключение

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

Всего наилучшего!

=›› Свяжитесь с нами, чтобы предложить размещение здесь.

Рекомендуемое чтение