QA_Bible
  • Введение
  • FAQ для новичков
    • Ответы на самые популярные вопросы новичков в чатах
    • Качества и навыки, которыми нужно обладать тестировщику?
    • Что должен знать и уметь Junior? Что спросят на собеседовании?
    • С чего начать обучение и куда развиваться?
    • Как составить резюме?
    • Где искать работу?
    • Как происходит процесс найма?
    • Как проходить собеседование?
    • Начало работы Junior-тестировщика
    • Ошибки в работе у начинающих тестировщиков
    • Как взаимодействовать с коллегами?
    • Перспективы профессии
  • Полезные ссылки
    • Список полезных ресурсов на разных платформах
    • Список ресурсов по инструментам тестировщика
  • Общее
    • QA/QC/Testing
    • Почему требуется тестирование ПО?
    • Качество ПО (Software Quality)
    • Принципы тестирования
    • Верификация и валидация (Verification and Validation)
    • Дефекты и ошибки
    • Серьезность и приоритет Дефекта (Severity & Priority)
    • Альфа- и бета- тестирование (Alpha Testing and Beta Testing)
    • Процесс тестирования (test process) (draft)
    • Техники оценки тестов/оценка трудозатрат на тестирование (Test Estimation)
    • Экономика тестирования/стоимость качества (Cost of quality)
    • Подход к тестированию (Test Approach)
    • Импакт анализ (анализ влияния, Impact Analysis)
    • Анализ первопричин (RCA - Root Cause Analysis)
    • Тестирование со сдвигом влево (Shift left testing)
    • Модель зрелости возможностей (CMM - Capability Maturity Model)
    • Тестовая среда и тестовый стенд (Test Environment/Test Bed)
    • Бизнес-логика (Business logic)
    • Политика отсутствия багов (ZBP - Zero Bug Policy)
    • Независимое тестирование (Independent testing)
    • Роли/должности в команде
    • Эвристики и мнемоники
  • Виды-методы-уровни тестирования
    • Методы тестирования (White/Black/Grey Box)
    • Тестирование методом черного ящика (Black Box Testing)
    • Тестирование методом белого ящика (White Box Testing)
    • Тестирование методом серого ящика (Grey Box Testing)
    • Статическое и динамическое тестирование (Static Testing, Dynamic Testing)
    • Пирамида / уровни тестирования (Test Pyramid / Testing Levels)
    • Модульное/юнит/компонентное тестирование (Module/Unit/Component testing)
    • Интеграционное тестирование (Integration testing)
    • Системное тестирование (System Testing)
    • Приемочное тестирование (AT - Acceptance testing)
    • Основные виды тестирования ПО
    • Функциональное тестирование (Functional/Behavioral testing)
    • Нефункциональное тестирование (Non-Functional testing)
    • Тестирование производительности (Performance testing)
    • Тестирование емкости (Capacity testing)
    • Нагрузочное тестирование (Load testing)
    • Стрессовое тестирование (Stress testing)
    • Тестирование масштабируемости (Scalability testing)
    • Объемное тестирование (Volume testing)
    • Тестирование выносливости/стабильности (Endurance/Soak/Stability testing)
    • Тестирование устойчивости (Resilience testing)
    • Тестирование надежности (Reliability Testing)
    • Тестирование на отказ и восстановление (Failover and Recovery testing)
    • Эталонное и базовое тестирование (Benchmark and Baseline Testing)
    • Тестирование хранилища (Storage testing)
    • Одновременное / многопользовательское тестирование (Concurrency/Multi-user testing)
    • Тестирование сервиса (Service Testing)
    • Тестирование безопасности (Security and Access Control testing)
    • Оценка уязвимости/защищенности (Vulnerability Assessment)
    • Фаззинг-тестирование (Fuzz testing)
    • Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тести
    • Тестирование совместимости/взаимодействия (Compatibility/Interoperability testing)
    • Конфигурационное тестирование (Configuration testing)
    • Инсталляционное тестирование (Installation Testing)
    • Тестирование на соответствие (Conformance/Compliance testing)
    • Тестирование удобства пользования (Usability testing)
    • Тестирование доступности (Accessibility testing)
    • Тестирование локализации, глобализации и интернационализации (Localization/ globalization/internatio
    • Исследовательское тестирование (Exploratory testing)
    • Свободное / Интуитивное тестирование (Adhoc, Ad-hoc Testing)
    • Тестирование поддержки (Maintenance testing)
    • Регрессионные виды тестирования (Regression testing)
    • Тестирование клиентской части и серверной (Frontend testing Vs. Backend testing)
    • Тестирование графического интерфейса/визуальное тестирование (GUI - Graphical User Interface testing
    • Тестирование API (API - Application Programming Interface)
    • A/B тестирование (A/B Testing)
    • Деструктивное и недеструктивное тестирование (DT - Destructive testing and NDT - Non Destructive tes
    • Выборочное/хаотическое тестирование (Random/monkey testing)
    • Тестирование рабочего процесса/воркфлоу (Workflow testing)
    • Тестирование документации (Documentation testing)
    • Как протестировать продукт без требований?
    • Кроссбраузерное тестирование (Cross-browser testing)
    • Тестирование, основанное на рисках (Risk-Based Testing)
    • Разница тестирования ПО и железа (Software Vs. Hardware testing)
    • Тестирование качества данных (Data Quality Testing)
  • Тест дизайн
    • Тест-дизайн и техники тест-дизайна (Test Design and Software Testing Techniques)
    • Static - Reviews
    • Static - Static Analysis
    • Dynamic - White box
    • Dynamic - Black box
    • Dynamic - Experience based
  • Тестовая документация и артефакты (Test Deliverables/test artifacts)
    • Виды тестовой документации
    • Политика качества и политика тестирования (Quality policy and Test policy)
    • Стратегия тестирования (Test strategy)
    • План тестирования (Test plan)
    • Тестовый сценарий (Test scenario)
    • Тест-кейс (Test case)
    • Чек-лист (Check List)
    • Баг-репорт (Defect/bug report)
    • Требования (Requirements)
    • Пользовательские истории (User stories)
    • Критерии приемки (Acceptance Criteria)
    • Виды отчетов (Reports)
    • Базис тестирования (Test basis)
    • Матрица трассируемости (RTM - Requirement Traceability Matrix)
    • Метрики тестирования (Software Test Metrics)
    • Тестовый оракул (Test oracle)
  • Мобильное тестирование
    • Android
      • Архитектура Android OS
      • Архитектура Android Application
      • Тестирование покупок в Android-приложениях
      • Android Developer Settings
      • Android Debug Bridge (ADB)
      • Android Studio для QA
    • iOS
      • Архитектура iOS
      • Архитектура iOS Application
      • Тестирование покупок в iOS-приложениях
      • iOS Developer Settings
    • Особенности в тестировании мобильных приложений
    • Покрытие девайсов
    • Типы мобильных приложений
    • Симуляторы и эмуляторы
    • Основные различия Android/iOS
    • Последнее обновление Android/iOS, что нового?
    • Основные проверки при тестировании мобильного приложения
    • Каким образом тестировщик получает приложение на тест?
    • Как успешно зарелизить продукт в App Store и Google Play
    • Тестирование требований к мобильным приложениям
    • Тестирование push-уведомлений
    • Тестирование дип линков (mobile deep links)
    • Тестирование сохраненных поисков
    • Тестирование рекламы
    • Тестирование просмотренных товаров
    • Middleware
    • Как проверить использование ресурсов на Android
    • Как протестировать приложение для другой страны?
  • Тестирование в разных сферах-областях (testing different domains)
    • Тестирование веб-сайта или веб-приложения (Web application)
    • Тестирование интернет-магазина (eCommerce)
    • Тестирование платежного шлюза (Payment Gateway)
    • Тестирование игр (Game testing)
    • Тестирование VR программного обеспечения
    • Тестирование мессенджера (Messenger)
    • Тестирование чат-бота (Chatbot)
    • Тестирование электронных писем (E-mail)
    • Тестирование интернета вещей (IoT - Internet of Things)
    • Тестирование облачных решений (Cloud testing)
    • Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture)
    • Тестирование микросервисной архитектуры (MSA/Microservices)
    • Тестирование платформы электронного обучения (E-learning platform)
    • Тестирование систем розничной торговли (POS - Point Of Sale)
    • Тестирование банковского ПО (Banking domain applications/BFSI)
    • Тестирование страхового ПО (Insurance)
    • Тестирование в сфере телекоммуникаций (Telecom)
    • Тестирование планирования ресурсов предприятия (ERP - Enterprise Resource Planning)
    • Тестирование миграции данных (ETL)
    • Тестирование баз данных (Database)
    • Другое
  • SDLC и STLC
    • Жизненный цикл разработки ПО (SDLC - Software Development Lifecycle)
    • Жизненный цикл тестирования ПО (STLC - Software Testing Lifecycle)
    • Модели разработки ПО
    • Agile
    • Scrum
    • Подходы к разработке/тестированию (... - driven development/testing)
  • Сети и около них
    • База по сетям
    • Клиент - серверная архитектура (Client-Server Architecture)
    • Микросервисная архитектура (Microservice Architecture)
    • Эталонные модели OSI и TCP/IP
    • HTTP
    • Идентификация ресурсов в сети (Identifying resources on the Web)
    • Веб-сервис (WS - Web service)
    • REST/SOAP/gRPC
    • Socket / WebSocket
      • Сокет/веб-сокет (socket/websocket)
      • Тестирование WebSocket на клиентах
    • Хранилище на стороне клиента (Client-side storage)
    • Кэш (Cache)
    • Аутентификация и авторизация (Authentication and authorization)
    • Рендеринг в интернете (Rendering on the Web)
  • Практическая часть
    • Логические задачи
    • Тестирование полей и форм
    • Примеры задач на собеседованиях и тестовых заданий
    • Платформы для тренировок и квизы
  • Автоматизация (beta)
    • Общее
    • Полезные ссылки
    • Как стать автоматизатором и вопросы с собеседований
    • Что нужно автоматизировать?
    • Виды и инструменты автоматизации
    • Инфраструктура и пайплайн (CI/CD)
    • Процессы и автоматизация проекта с нуля
    • Лучшие практики автоматизации
    • Что такое flaky tests?
    • Мутационное тестирование (Mutation testing)
    • Параллельное тестирование (Parallel testing)
    • Подкожный тест (Subcutaneous test)
    • Разница между coupling и cohesion
    • Другое (ссылки)
  • Контакты
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
  1. Сети и около них

Микросервисная архитектура (Microservice Architecture)

PreviousКлиент - серверная архитектура (Client-Server Architecture)NextЭталонные модели OSI и TCP/IP

Last updated 3 years ago

Was this helpful?

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

https://d2m6ke2px6quvq.cloudfront.net/uploads/2020/09/11/3f3de3fc-f3a8-4cd1-81cd-518496f59141.jpg
https://d2m6ke2px6quvq.cloudfront.net/uploads/2020/09/11/2381c271-4fde-4cc1-94d9-a2e2d72a81c0.jpg

Микросервисы имеют множество преимуществ для Agile- и DevOps-команд - как отмечает Мартин Фаулер, Netflix, eBay, Amazon, Twitter, PayPal и другие звезды технологий перешли от монолитной к микросервисной архитектуре. В отличие от микросервисов монолитное приложение строится как единая автономная единица. Это замедляет внесение изменений в приложение, поскольку влияет на всю систему. Модификация, внесенная в небольшой участок кода, может потребовать создания и развертывания совершенно новой версии программного обеспечения. Масштабирование определенных функций приложения также означает, что вам необходимо масштабировать все приложение. Микросервисы решают эти проблемы монолитных систем, будучи максимально модульными. В простейшей форме они помогают создать приложение в виде набора небольших служб, каждая из которых работает в своем собственном процессе и развертывается независимо. Эти сервисы могут быть написаны на разных языках программирования и могут использовать разные методы хранения данных. Хотя это приводит к разработке систем, которые являются масштабируемыми и гибкими, они нуждаются в динамическом преобразовании. Микросервисы часто подключаются через API и могут использовать многие из тех же инструментов и решений, которые выросли в экосистеме RESTful и веб-сервисов. Тестирование этих API может помочь проверить поток данных и информации во время развертывания микросервиса.

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

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

  2. Простая маршрутизация: Микросервисы действуют примерно так же, как классическая система UNIX: они получают запросы, обрабатывают их и генерируют соответствующий ответ. Это противоположно тому, как работают многие другие продукты, такие как ESB (Enterprise Service Buses), где используются высокотехнологичные системы для маршрутизации сообщений, хореографии и применения бизнес-правил. Можно сказать, что у микросервисов есть интеллектуальные конечные точки (endpoints), которые обрабатывают информацию и применяют логику, и тупые каналы (?dumb pipes), по которым информация течет;

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

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

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

Примеры

Netflix имеет широко распространенную архитектуру, которая превратилась из монолитной в SOA. Каждый день он получает более одного миллиарда вызовов с более чем 800 различных типов устройств на свой API потокового видео. Затем каждый вызов API запрашивает около пяти дополнительных вызовов серверной службы. Amazon также перешел на микросервисы. Они получают бесчисленное количество вызовов из различных приложений, включая приложения, которые управляют API веб-службы, а также самим веб-сайтом, которые были бы просто невозможны для их старой двухуровневой архитектуры. Аукционный сайт eBay - еще один пример, прошедший тот же переход. Их основное приложение состоит из нескольких автономных приложений, каждое из которых выполняет бизнес-логику для различных функциональных областей.

SOA vs. Microservices

«Погодите-ка, - могут бормотать некоторые из вас за утренним кофе, - разве это не просто другое название SOA?» Сервис-ориентированная архитектура (SOA), возникшая в первые несколько лет этого века, и микросервисная архитектура (сокращенно MSA) имеют ряд общих черт. Однако традиционная SOA представляет собой более широкую структуру и может означать самые разные вещи. Некоторые сторонники микросервисов вообще отвергают тег SOA, в то время как другие считают микросервисы просто идеальной, усовершенствованной формой SOA. В любом случае, мы считаем, что существует достаточно четких различий, чтобы оправдать отдельную концепцию «микросервиса» (по крайней мере, как особую форму SOA, как мы проиллюстрируем позже). Типичная модель SOA, например, обычно имеет более зависимые ESB, а микросервисы используют более быстрые механизмы обмена сообщениями. SOA также ориентирована на императивное программирование, тогда как архитектура микросервисов ориентирована на стиль программирования с гибким субъектом. Кроме того, модели SOA, как правило, имеют реляционную базу данных слишком большого размера, в то время как микросервисы часто используют базы данных NoSQL или micro-SQL (которые могут быть подключены к обычным базам данных). Но реальная разница в первую очередь связана с методами архитектуры, используемыми для получения интегрированного набора сервисов. Поскольку в цифровом мире все меняется, гибкие методы разработки, которые могут идти в ногу с требованиями эволюции программного обеспечения, бесценны. Большинство методов, используемых в архитектуре микросервисов, исходят от разработчиков, которые создавали программные приложения для крупных корпоративных организаций и знают, что сегодняшние конечные пользователи ожидают динамичного, но согласованного взаимодействия на самых разных устройствах. Масштабируемые, адаптируемые, модульные и быстродоступные облачные приложения пользуются большим спросом. И это заставило многих разработчиков изменить свой подход.

Источники:

Доп. материал:

Созданы для бизнеса: Стиль микросервисов обычно организован вокруг бизнес-возможностей и приоритетов. В отличие от традиционного монолитного подхода к разработке, когда разные команды уделяют особое внимание, скажем, пользовательскому интерфейсу, базам данных, технологическим уровням или логике на стороне сервера, в микросервисной архитектуре используются кроссфункциональные команды. В обязанности каждой команды входит создание конкретных продуктов на основе одного или нескольких отдельных сервисов, взаимодействующих через шину сообщений. В микросервисах команда владеет продуктом всю жизнь, как в часто цитируемой максиме Amazon: “”;

Вы создаете это, вы это запускаете
What is Microservices?
Современная Микросервисная архитектура в банковской сфере
Microservices
Pattern: Microservice Architecture
Microservices vs Monolith