[Вопросы для собеседования](README.md)
# ООП + Микросервисы
+ [Что такое _ООП_?](#Что-такое-ООП)
+ [Назовите основные принципы _ООП_.](#Назовите-основные-принципы-ООП)
+ [Что такое _«инкапсуляция»_?](#Что-такое-инкапсуляция)
+ [Что такое _«наследование»_?](#Что-такое-наследование)
+ [Что такое _«полиморфизм»_?](#Что-такое-полиморфизм)
+ [Что такое _«абстракция»_?](#Что-такое-абстракция)
+ [Что представляет собой _«обмен сообщениями»_?](#Что-представляет-собой-обмен-сообщениями)
+ [Расскажите про основные понятия ООП: _«класс»_, _«объект»_, _«интерфейс»_.](#Расскажите-про-основные-понятия-ООП-класс-объект-интерфейс)
+ [В чем заключаются преимущества и недостатки объектно-ориентированного подхода в программировании?](#В-чем-заключаются-преимущества-и-недостатки-объектно-ориентированного-подхода-в-программировании)
+ [Что подразумевают в плане принципов ООП выражения _«является»_ и _«имеет»_?](#Что-подразумевают-в-плане-принципов-ООП-выражения-является-и-имеет)
+ [В чем разница между _композицией_ и _агрегацией_?](#В-чем-разница-между-композицией-и-агрегацией)
+ [Что такое _статическое_ и _динамическое связывание_?](#Что-такое-статическое-и-динамическое-связывание)
+ [Принцип SOLID?](#Принцип-SOLID)
+ [Что такое Монолит, Микросервис?](#Что-такое-Монолит,-Микросервис)
+ [Что такое Continuous Integration, Continuous Delivery/Deployment?](#Что-такое-Continuous-Integration,-Continuous-Delivery/Deployment)
+ [Что выбрать Монолит или Микросервис?](#Что-выбрать-Монолит-или-Микросервис)
+ [Взаимодействие между микросервисами](#Взаимодействие-между-микросервисами)
+ [OpenAPI](#OpenAPI)
+ [Тестирование микросервисов](#Тестирование-микросервисов)
+ [Распределенная трассировка](#Распределенная-трассировка)
## Что такое _ООП_?
__Объектно-ориентированное программирование (ООП)__ — методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования.
+ объектно-ориентированное программирование использует в качестве основных логических конструктивных элементов объекты, а не алгоритмы;
+ каждый объект является экземпляром определенного класса
+ классы образуют иерархии.
Программа считается объектно-ориентированной, только если выполнены все три указанных требования. В частности, программирование, не использующее наследование, называется не объектно-ориентированным, а программированием с помощью абстрактных типов данных.
Согласно парадигме ООП программа состоит из объектов, обменивающихся сообщениями. Объекты могут обладать состоянием, единственный способ изменить состояние объекта - послать ему сообщение, в ответ на которое, объект может изменить собственное состояние.
[к оглавлению](#ООП)
## Назовите основные принципы _ООП_.
+ _Инкапсуляция_ - сокрытие реализации.
+ _Наследование_ - создание новой сущности на базе уже существующей.
+ _Полиморфизм_ - возможность иметь разные формы для одной и той же сущности.
+ _Абстракция_ - набор общих характеристик.
+ _Пересылка сообщений_ - форма связи, взаимодействия между сущностями.
+ _Переиспользование_- все что перечислено выше работает на повторное использование кода.
Это единственно верный порядок парадигм ООП, так как каждая последующая использует предыдущие.
[к оглавлению](#ООП)
## Что такое _«инкапсуляция»_?
__Инкапсуляция__ – это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя, открыв только то, что необходимо при последующем использовании.
Цель инкапсуляции — уйти от зависимости внешнего интерфейса класса (то, что могут использовать другие классы) от реализации. Чтобы малейшее изменение в классе не влекло за собой изменение внешнего поведения класса.
[к оглавлению](#ООП)
## Что такое _«наследование»_?
__Наследование__ – это свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью.
Класс, от которого производится наследование, называется _предком_, _базовым_ или _родительским_. Новый класс – _потомком_, _наследником_ или _производным_ классом.
[к оглавлению](#ООП)
## Что такое _«полиморфизм»_?
__Полиморфизм__ – это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта. Т.е. использовать разные объекты одинаково, через общий интерфейс.
Пример: у нас есть метод draw(). Для круга он рисует окружность, для квадрата — квадрат. Но мы обращаемся к ним одинаково: figure.draw().
Преимуществом полиморфизма является то, что он помогает снижать сложность программ, разрешая использование одного и того же интерфейса для задания единого набора действий. Выбор же конкретного действия, в зависимости от ситуации, возлагается на компилятор языка программирования. Отсюда следует ключевая особенность полиморфизма - использование объекта производного класса, вместо объекта базового (потомки могут изменять родительское поведение, даже если обращение к ним будет производиться по ссылке родительского типа).
Полиморфизм бывает _динамическим_ (переопределение методов в потомках) и _статическим_ (перегрузка методов -одинаковое имя, разные параметры).
_Полиморфная переменная_, это переменная, которая может принимать значения разных типов, а _полиморфная функция_, это функция у которой хотя бы один аргумент является полиморфной переменной.
Выделяют два вида полиморфных функций:
+ _ad hoc_, функция ведет себя по разному для разных типов аргументов (например, функция `draw()` — рисует по разному фигуры разных типов);
+ _параметрический_, функция ведет себя одинаково для аргументов разных типов (например, функция `add()` — одинаково кладет в контейнер элементы разных типов).
[к оглавлению](#ООП)
## Что такое _«абстракция»_?
_Абстрагирование_ – это способ выделить набор общих характеристик объекта, исключая из рассмотрения частные и незначимые. Соответственно, __абстракция__ – это набор всех таких характеристик.
Пример: когда мы говорим «машина», нам важно, что у неё есть двигатель и колёса, а цвет ковриков внутри — неважно.
[к оглавлению](#ООП)
## Что представляет собой _«обмен сообщениями»_?
Объекты взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение действия + данные.
В ООП посылка сообщения (вызов метода) — это единственный путь передать управление объекту. Если объект должен «отвечать» на это сообщение, то у него должна иметься соответствующий данному сообщению метод. Так же объекты, используя свои методы, могут и сами посылать сообщения другим объектам.
[к оглавлению](#ООП)
## Расскажите про основные понятия ООП: _«класс»_, _«объект»_, _«интерфейс»_.
__Класс__ – шаблон описания сущности, определяющий состояние и поведение, зависящее от этого состояния, а также правила для взаимодействия с данной сущностью (контракт).
С точки зрения программирования класс можно рассматривать как набор данных (полей, атрибутов, членов класса) и функций для работы с ними (методов).
С точки зрения структуры программы, класс является сложным типом данных.
__Объект (экземпляр)__ – это отдельный представитель класса, имеющий конкретное состояние и поведение, полностью определяемое классом. Каждый объект имеет конкретные значения атрибутов и методы, работающие с этими значениями на основе правил, заданных в классе.
__Интерфейс__ – это набор методов класса, доступных для использования. Интерфейсом класса будет являться набор всех его публичных методов в совокупности с набором публичных атрибутов. По сути, интерфейс специфицирует класс, чётко определяя все возможные действия над ним.
[к оглавлению](#ООП)
## В чем заключаются преимущества и недостатки объектно-ориентированного подхода в программировании?
✅ Ближе к человеческому восприятию мира.
✅ Код разбивается на логичные части.
✅ Удобнее поддерживать и расширять.
✅ Код можно переиспользовать.
✅ Легко добавлять новые объекты и изменять поведение программы.
❌ Иногда сложно понять, где что наследуется.
❌ Методы могут быть «размазаны» по разным классам.
❌ Документировать сложнее. Поскольку любой метод может быть переопределен, в документации должно говориться не только о том, что делает данный метод, но и о том, в каком контексте он вызывается.
❌ Дополнительные расходы памяти и производительности.
❌ Избыточность. Часто содержится больше методов, чем это реально необходимо текущей программе. А поскольку лишние методы не могут быть удалены, они становятся мертвым грузом.
[к оглавлению](#ООП)
## Что подразумевают в плане принципов ООП выражения _«является»_ и _«имеет»_?
__«является»__ подразумевает наследование. Класс _cat_ является потомком класса _animal_
__«имеет»__ агрегация или композиция. Класс _car_ имеет класс _engine_
[к оглавлению](#ООП)
## В чем разница между _композицией_ и _агрегацией_?
Ассоциация обозначает связь между объектами.
Агрегация — «часть» может существовать отдельно и принадлежать нескольким «целым». (Книга находится в библиотеке, её можно перенести в другую).
Композиция — «часть» жёстко привязана к «целому». (Страница принадлежит конкретной книге).
[к оглавлению](#ООП)
## Что такое _статическое_ и _динамическое связывание_?
Связывание означает наличие связи между ссылкой и кодом. Например, переменная, на которую вы ссылаетесь, привязана к коду, в котором она определена. Аналогично, вызываемый метод привязан к месту в коде, где он определен.
_Статическим_ или _ранним связыванием (early binding)_ — компилятор заранее знает, какой метод будет вызван. (Напр. перегрузка методов).
_Позднее связывание (late binding) или динамическое_ проводимое непосредственно во время выполнения программы, в зависимости от типа объекта (Напр. переопределение методов в наследниках). Механизм позднего связывания зависит от конкретного языка
Итак, фундаментальное различие между статическим и динамическим связыванием в Java состоит в том, что первое происходит рано, во время компиляции на основе типа ссылочной переменной, а второе – позднее, во время выполнения, с использованием конкретных объектов.
В Java почти все методы — динамические, кроме `static`, `final` и `private`.
Ключевые различия между ранним и поздним связыванием в языке Java:
1) Статическое связывание используется в языке Java для разрешения перегруженных методов, в то время как динамическое связывание используется в языке Java для разрешения переопределенных методов.
2) Аналогично, приватные, статические и терминальные методы разрешаются при помощи статического связывания, поскольку их нельзя переопределять, а все виртуальные методы разрешаются при помощи динамического связывания.
3) В случае статического связывания используются не конкретные объекты, а информация о типе, то есть для обнаружения нужного метода используется тип ссылочной переменной. С другой стороны, при динамическом связывании для нахождения нужного метода в Java используется конкретный объект.
[к оглавлению](#ООП)
## Принцип SOLID?
Пять основных принципов дизайна классов:
+ Single Responsibility Principle (Принцип единственной ответственности).
+ Open Closed Principle (Принцип открытости/закрытости).
+ Liskov’s Substitution Principle (Принцип подстановки Барбары Лисков).
+ Interface Segregation Principle (Принцип разделения интерфейса).
+ Dependency Inversion Principle (Принцип инверсии зависимостей).
__Принцип единственной ответственности (SRP)__
Никогда не должно быть больше одной причины изменить класс.
Класс должен быть ответственен лишь за что-то одно. Если класс отвечает за решение нескольких задач, его подсистемы, реализующие решение этих задач, оказываются связанными друг с другом. Изменения в одной такой подсистеме ведут к изменениям в другой.
Представьте себе модуль, который обрабатывает заказы. Если заказ верно сформирован, он сохраняет его в базу данных и высылает письмо для подтверждения заказа. Принцип единственной обязанности подразумевает, что три аспекта этой проблемы на самом деле — три разные обязанности. А значит, должны находиться в разных классах или модулях. Объединение нескольких сущностей, которые могут меняться в разное время и по разным причинам, считается плохим проектным решением. Гораздо лучше разделить модуль на три отдельных, каждый из которых будет выполнять одну единственную функцию.
__Принцип открытости/закрытости (OCP)__
Программные сущности (классы, модули, функции и т.п.) должны быть открыты для расширения, но закрыты для изменения.
Это означает, что должна быть возможность изменять внешнее поведение класса, не внося физические изменения в сам класс. Следуя этому принципу, классы разрабатываются так, чтобы для подстройки класса к конкретным условиям применения было достаточно расширить его и переопределить некоторые функции. Поэтому система должна быть гибкой, с возможностью работы в переменных условиях без изменения исходного кода. Используются интерфейсы
__Принцип подстановки Барбары Лисков (LSP)__
Объекты в программе можно заменить их наследниками без изменения свойств программы.
Это означает, что класс, разработанный путем расширения на основании базового класса, должен переопределять его методы так, чтобы не нарушалась функциональность с точки зрения клиента. То есть, если разработчик расширяет ваш класс и использует его в приложении, он не должен изменять ожидаемое поведение переопределенных методов. Если оказывается, что в коде проверяется тип класса, значит принцип подстановки нарушается.
__Принцип разделения интерфейса (ISP)__
Клиенты не должны быть вынуждены реализовывать методы, которые они не будут использовать.
Принцип разделения интерфейсов говорит о том, что слишком «толстые» интерфейсы необходимо разделять на более мелкие и специфические, чтобы клиенты мелких интерфейсов знали только о методах, необходимых в работе.
Рассмотрим пример. Разработчик Алекс создал интерфейс "отчет" и добавил два метода: generateExcel() и generatedPdf(). Теперь клиент А хочет использовать этот интерфейс, но он намерен использовать отчеты только в PDF-формате, а не в Excel. Он должен будет реализовать два метода, один из которых по большому счету не нужен и существует только благодаря Алексу — дизайнеру программного обеспечения. Клиент воспользуется либо другим интерфейсом, либо оставит поле для Excel пустым. Так в чем же решение? Оно состоит в разделении существующего интерфейса на два более мелких. Один — отчет в формате PDF, второй — отчет в формате Excel. Это даст пользователю возможность использовать только необходимый для него функционал.
__Принцип инверсии зависимостей (DIP)__
Зависимости внутри системы строятся на основе абстракций. Объектом зависимости должна быть абстракция, а не что-то конкретное. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. Программное обеспечение нужно разрабатывать так, чтобы различные модули были автономными и соединялись друг с другом с помощью абстракции.
Классическое применение этого принципа — Spring framework. В рамках Spring framework все модули выполнены в виде отдельных компонентов, которые могут работать вместе. Они настолько автономны, что могут быть быть с такой же легкостью задействованы в других программных модулях помимо Spring framework. Это достигнуто за счет зависимости закрытых и открытых принципов. Все модули предоставляют доступ только к абстракции, которая может использоваться в другом модуле.
[к оглавлению](#ООП)
## Что такое Монолит, Микросервис?
Монолитная архитектура - система с одним сервисом, который отвечает за работу со всей предметной областью бизнеса (приложения)
При начале работы над монолитным проектом Достоинства:
✅ Быстрая разработка
✅ Возможность внесения радикальных изменений (например изменить архитетуру, класс-дизайн, схему бд)
✅ Безболезненое тестирование
✅ Легкое развертывание
✅ Простое hardware масштабирование
С увеличением размера проекта и команды разработки появляются Минусы:
❌ Медленное внесение изменений
Команды А и Б работают не пересекаясь. Выкатывается новая версия проекта с багами в коде команды Б. Откатывается на предыдущуюю версию весь код и команды Б и команды А.
❌ Уязвимая надежность - если падает часть кода, то не работает все приложение.
❌ Трудности в hardware масштабировании.
Одна часть требует оперативу, другая ядра. Приходится апгрейдить "вертикально" - покупать больше оперативных планок и процессоры с большим кол-вом ядер для всех сервисов. А не по потребностям
❌ Дороговизна обновления технологического стека. Например переход на новую версию Java. Чтобы проверить эффективность, нужно переписывать весь проект
Микросервисная архитектура — система, которая содержит больше одного обособленнго сервиса. Размер значения не имеет.
Обособленный сервис — является независимой единицей развертывания, имеет своё хранилище, свою БД (?), отвечает за свою часть предметной области
Достоинства:
✅ Возможность масштабирования разработки
✅ Дешевизна эксперементов с новым стеком
✅ Инкрементальное обновление технолошического стека
✅ Повышенная надежность и отказоустойчивость
Минусы:
❌ Сложность проектирования архитектуры
❌ Долгое внесение радикальных изменений
❌ Нетривиальное тестирование
❌ Повышенные требования к Continuous Integration/Continuous Delivery (деплою)
Сложности проектирования Микросервисов
+ Сложно разделить предметную область на части
Не стоит делить монолит на микросервисы по функциональным возможностям. Это приведет к распределенному монолиту - архитектура, включающая недостатки и того и другого. Монолит нужно разбивать по пренадлежности к какой-то области бизнеса. Отличить одно от другого довольно сложно. Т.е. по принципу единой ответственности.
Соответствие принципам Low coupling, high cohesion способствует быстрому внесению изменений и легкому тетсированию.
Сильная связанность high cohesion - части системы, которые изменяются вместе, должны находиться ближе друг к другу
Слабая связанность low coupling - части системы, которые изменяются параллельно, должны иметь как можно меньше зависимостей друг на друга b внутри сервиса и между сервисами
+ Задержки при межсервисном взаимодействии влияют на производительность + сеть ненадежна
+ Межсервисное взаимодействие влияет на доступность
+ Сложно добиться согласованности данных
[к оглавлению](#ООП)
## Что такое Continuous Integration, Continuous Delivery/Deployment?
Непрерывная интеграция (CI) — процесс автоматического принятия изменений. Первичный процесс обновления ПО, в рамках которого все изменения на уровне кода вносятся в единый центральный репозиторий. Такое внесение принято называть слиянием. После каждого слияния (которое проходит по несколько раз в день) в изменяемой системе происходит автоматическая сборка (часто приложение упаковывается в Docker) и тестирование (проверка конкретных модулей кода, UI, производительности, надёжности API). Таким образом разработчики страхуются от слишком поздних обнаружений проблем в обновлениях.
+ Возможность локальной сборки проекта
+ На каждый коммит в кдаленный репо запускаем сборки проекта в системе (Jenkins, TravisCI)
+ Сломанная сборка запрещает слияние
Непрерывная доставка (CD) — CI + CD. Автоматизированый процесс доставки изменений до продакшена. Теперь новая версия не только создаётся и тестируется при каждом изменении кода, регистрируемом в репозитории, но и может быть оперативно запущена по одному нажатию кнопки развёртывания. Однако запуск развёртывания всё ещё происходит вручную — ту самую кнопку всё же надо кому-то нажать. Этот метод позволяет выпускать изменения небольшими партиями, которые легко изменить или устранить в случае необходимости.
+ Поддерживаем артефакты стабильными
+ Развертываем по кнопке
[к оглавлению](#ООП)
## Что выбрать Монолит или Микросервис?
Микро если:
+ Предметная область хорошо делится на части
+ Много направлений, которые нужно развивать параллельно
+ "Особенности" монолита не устраивают бизнес
Монолит если:
+ Нужно быстро сделать прототип
+ Вашу задачу можно решить одним сервисом
+ Непонятно, как разделить предметную область
+ Низкие нагрузки, мало разработчиков, нет ресурсов на поддержание микросервисов
https://microservices.io/
https://martinfowler.com/
"microservices patterns" chris richardson
"clean architecture" robert martin
[к оглавлению](#ООП)
## Взаимодействие между микросервисами
Межсервисное взаимодействие = сетевое взаимодействие, т.е. система управляется сообщениями
+ Производительность = задержки и пропускная способность
+ Доступность и отказоустойчивость
+ Архитектура
__Транспорт__
+ стандарт JSON внутри HTTP (REST, RPC, GraphQL). Простой, множество инструментов, человекочитаемость. Из-за текстового формата большие объемы и нужно оптимизировать
+ бинарные протоколы: gRPC, Thrift, Avro и т.д.
Выше производительность, оптимизированно представление данных, можно определить схему сообщения из коробки, но меньше инструментов и не читаемы человеком
Что выбрать?
+ Начинать с HTTP
+ Бинарные не бесплатные
+ Большинство проблем не из-за протокола!
+ Для публичных API всегда HTTP либо несколько реализаций одна из которых HTTP
__API__
Application Programming Interface - интерфейс, определяющий способ и схему взаимодействия с сервисом
+ Remote Procedure Call (RPC)
Только POST метод. Все параметры в теле запроса. Любой статус !=200, считается ошибкой
Выбирают: Простая реализация, Внутренние API, HTTP только как транспорт
+ Representational State Transfer (REST)
Архитектурный стиль, в основе которого лежат ресурсы и их идентификация, изменение их состояния через представление. REST != HTTP
Выбирают: Своего рода стандарт, Внутренние API, Публичные API, HTTP как протокол
+ GraphQL
Язык запросов для API. Например можно задать конкретный набор полей, которые хотим получить в ответе на запрос
Выбирают: Типо-безопасность, API для Web и мобильных клиентов, тут свой инструментарий
__Проектирвоание__
+ Клиент-сервер
+ Stateless - сервис не должен хранить состояние в памяти, это важно для масштабирования
+ Кеширование
__Типы сообщений__
+ Команды
+
Императивное управление (звучит как "сделать что-то"), вызывают сильную связанность, зато понятны - названия обычно отражают логику
+ События
+
Декларативное управление (звучит как "что-то произошло"), снижают связанность, менее понятны - не знаем что скрыто в notifyOrderCreated
__Виды взаимодействия__
+ Синхронные - отправляем запрос и блокируемся, ожидая результата.
Просто и понятно, быстрые операции и низкие задержки (ок), низкая пропускная способность (не ок), вызывает низкую доступность (не ок)
+ Ассинхронные - не блокируемся ожидая ответ
Сложнее в реализации, выше задержки (не ок), выше пропускная способность (ок), повышает доступность (ок)
Short polling - вызываем операцию и получаем ссылку на ресурс с результатом операции. Переодически опрашиваем этот ресурс на предмет текущего статуса операции
Пользователь должен ждать как можно меньше, и нужно выполнять как можно меньше запросов на опрос
Стратегии опроса:
+ Фиксированное время (раз в секунду) - просто, но время запроса может чуть отличаться, что приведет к лишним запросам
+ Прогрессия (геометрическая/алгебраическая) - сокращает кол-во запросов, но возможен вариант когда придется долго ждать
+ На основе статистического распределения - например, знаем, что запрос выполняется 50% за 1.5с, 90% за 3с и 99% за 5с, мы можем распределить запросы во времени
Callbacks - вызываем операцию и получаем идентификатор операции. Сервис, выполняющий операцию, отправляет уведомление вызвавшему сервису о результате выплонения операции
__Способы взаимодействия__
+ Прямой обмен А->Б - просто, легкая эксплуатация, но сильная связанность сервисов. Хорошо для Команд
+ Обмен через брокеры сообщений А->Брокер->Б - сложнее, позволяет снизить связанность сервисов. Хорошо для Событий
На основе callback: RabbitMQ
На основе polling: Kafka
Микросервисы могут работать одновеременно с разными диалектами БД. При этом есть __сильная согласованность__, когда изменения сразу видны всем, с момента их применения и __конечная согласованность__ когда изменения будут видно, но не сразу, а доставляются асинхронно
__Сильная согласованность__ - всегда актуальные данные, но высокие задержки при получении
В таких случаях используются __Распределенные транзакции__. Но это сложно, дорого и есть не везде. Можно эмулировать распределенную транзакцию с помощью вложенных локальных транзакций
При этом возврат ошибки не гарантирует, что запись не была вставленна в БД. А откат первой транзакции не приводит к откату второй.
Saga паттерн: Для решения нужно разбивать одну большую распределенную транзакцию на последовательность локальных транзакций и предоставить возможность отката всех локальных транзакций.
Особенности: нужно уметь восстанавливаться после сбоев любого участка и повторять сагу с определенного шага + отличать финальные ошибки от нефинальных
Хореография
+ Нет единой точки отказа
+ Легко менять кусочек процесса
+ Сложно понять процесс целиком и отслеживать ошибки
Оркестрация
+ Есть единая точка отказа
+ Сложнее вносить изменения в места
+ Легко понять процесс и отслеживать ошибки
__Конечная согласованность__ - могут быть неактуальные данные, зато низкие задержки
__Взаимоисключения__
Иногда требуется выполнять какой-то процесс эксклюзивно. Например используя распределенный консенсус - алгоритмы, которые сложно и медленно работают. etcd, Consul, Zookeeper. Зато отказоустойчивы
Альтернатива - red lock, когда БД используется в качестве хранилища блокировок. Блокировка не захватывается, а арендуется на время. Чтобы в случае блокировки и отказа системы блокировка не осталась навсегда Добавляем версию блокировки для контроля ее корректности
[к оглавлению](#ООП)
## OpenAPI
OpenAPI - спецификация для описания REST API.
https://habr.com/ru/post/541592/
Swagger - это фреймворк для спецификации RESTful API, цель которого - поддерживать документацию в актуальном виде. Его прелесть заключается в том, что он дает возможность не только интерактивно просматривать спецификацию, но и отправлять запросы – так называемый Swagger UI.
+ Code first - сначала пишем код, потом генерируем спецификацию
+ Schema first - сперва спецификация, затем генерируем по ней код
+ Публикуем спецификацию (отделный артефак или Swagger)
+ Строго следовать этой спецификации
Документирование БД
Database Schema as a Code - текущая схема должна быть представлена последовательностью патчей, хранимых как код
+ Возможность восстановить БД на любом окружении
+ Аудит, контроль, валидация
+ Flyway, Liquibase
[к оглавлению](#ООП)
## Тестирование микросервисов
+ Компонентные тесты проверяют работу сервисов и их взаимодействие
+ Модульные тесты для тестирования отдельных функций
Компонентных должно быть больше, чем модульных, т.к. изменяемая среда, много зависимочти между классами
Тесты должны быть независимыми и уметь работать параллельно.
Для тестирования API лучше делать реальные HTTP вызовы, валидировать ответ согласно схеме (JSON). RESTAssured как пример инструмента.
При тестирование взаимодействия с БД на каждый запуск тестов локально поднимается БД. Embedded или TestContainers. Тесты не должны очищать БД или буффер брокера сообщений перед/после своего запуска/завершения
При тестировании взаимодействия микросервисов на каждый запуск тестов локально HTTP-сервер, создаем моки операций сервисов, выполняем, моки валидируем. WireMock, MockServer
При тестировании аинхронных процессов стараемся приблизить тестовый сценарий к реальному, запускаем операцию и ждем завершения выполнения. Awaitility
Для автоматизации развиваем Continuous Integration/Continuous Delivery - помогает быстрее развивать сервисы и доставлять их на production. Но дорого.
[к оглавлению](#ООП)
## Распределенная трассировка
При межсервисном взаимодействии сложно отследить весь путь запроса по системе
+ К каждому внешнему запрсос прикрепляем "идентификатор операции"
+ Пробрасываем его по всей системе
+ Добавляем его в логовые сообщения для отслеживания. Elastic APM, OpenTracing
Для HTTP: Прикрепляем HTTP-заголовок с этим идентификатором - Используем его при обработке запроса - Поллинг делаем с тем же индентификаторо - Обраный вызов с ним же - В брокер сообщений также отправляем этот индентификатор
Для Саги: Исходный запрос теряется при обработке асинхронных процессов - В задачу на продолжение саги кладем исходный идентификатор операции (в БД) - При возобновлении саги используем этот идентификатор
Визуализация трасс помогает построить схему взаимодействия между сервисами. Можно это делать атоматически и динамически. Zipkin, Jaeger
[к оглавлению](#ООП)
# Источники
+ [DevColibri](http://devcolibri.com/720)
+ [Хабрахабр](https://habrahabr.ru/post/87119/)
+ [Википедия](https://ru.wikipedia.org/wiki/Объектно-ориентированное_программирование)
[Вопросы для собеседования](README.md)