Рефакторинг ООП, добавил инфу про микросервисы и картинки

Author: eugene.kalashnikov

img/OOP10.png

@@ -236,7 +236,13 @@ __Принцип инверсии зависимостей (DIP)__<br>
 + Повышенные требования к Continuous Integration/Continuous Delivery (деплою)
 
 Непрерывная интеграция (CI) — процесс автоматического принятия изменений. Первичный процесс обновления ПО, в рамках которого все изменения на уровне кода вносятся в единый центральный репозиторий. Такое внесение принято называть слиянием. После каждого слияния (которое проходит по несколько раз в день) в изменяемой системе происходит автоматическая сборка (часто приложение упаковывается в Docker) и тестирование (проверка конкретных модулей кода, UI, производительности, надёжности API). Таким образом разработчики страхуются от слишком поздних обнаружений проблем в обновлениях.
++ Возможность локальной сборки проекта
++ На каждый коммит в кдаленный репо запускаем сборки проекта в системе (Jenkins, TravisCI)
++ Сломанная сборка запрещает слияние
+
 Непрерывная доставка (CD) — CI + CD. Автоматизированый процесс доставки изменений до продакшена. Теперь новая версия не только создаётся и тестируется при каждом изменении кода, регистрируемом в репозитории, но и может быть оперативно запущена по одному нажатию кнопки развёртывания. Однако запуск развёртывания всё ещё происходит вручную — ту самую кнопку всё же надо кому-то нажать. Этот метод позволяет выпускать изменения небольшими партиями, которые легко изменить или устранить в случае необходимости.
++ Поддерживаем артефакты стабильными
++ Развертываем по кнопке
 
 Сложности проектирования Микросервисов
 + Сложно разделить предметную область на части
@@ -350,7 +356,100 @@ __Способы взаимодействия__
 На основе polling: Kafka
 ![Image alt](https://github.com/Shell26/Java-Developer/raw/master/img/OOP7.png)
 
+Микросервисы могут работать одновеременно с разными диалектами БД. При этом есть __сильная согласованность__, когда изменения сразу видны всем, с момента их применения и __конечная согласованность__ когда изменения будут видно, но не сразу, а доставляются асинхронно  
+
+__Сильная согласованность__ - всегда актуальные данные, но высокие задержки при получении
+
+В таких случаях используются __Распределенные транзакции__. Но это сложно, дорого и есть не везде. Можно эмулировать распределенную транзакцию с помощью вложенных локальных транзакций
+![Image alt](https://github.com/Shell26/Java-Developer/raw/master/img/OOP8.png)
+ 
+При этом возврат ошибки не гарантирует, что запись не была вставленна в БД. А откат первой транзакции не приводит к откату второй.
+
+Saga паттерн: Для решения нужно разбивать одну большую распределенную транзакцию на последовательность локальных транзакций и предоставить возможность отката всех локальных транзакций.
+ ![Image alt](https://github.com/Shell26/Java-Developer/raw/master/img/OOP9.png)
+ 
+Особенности: нужно уметь восстанавливаться после сбоев любого участка и повторять сагу с определенного шага + отличать финальные ошибки от нефинальных
+Хореография
+  ![Image alt](https://github.com/Shell26/Java-Developer/raw/master/img/OOP10.png)
+  
+  + Нет единой точки отказа
+  + Легко менять кусочек процесса
+  + Сложно понять процесс целиком и отслеживать ошибки
+ 
+ Оркестрация
+ ![Image alt](https://github.com/Shell26/Java-Developer/raw/master/img/OOP11.png)
+ 
+ + Есть единая точка отказа
+ + Сложнее вносить изменения в места
+ + Легко понять процесс и отслеживать ошибки
+ 
+ ![Image alt](https://github.com/Shell26/Java-Developer/raw/master/img/OOP12.png)
+ 
+__Конечная согласованность__ - могут быть неактуальные данные, зато низкие задержки
+ 
+  ![Image alt](https://github.com/Shell26/Java-Developer/raw/master/img/OOP13.png)
+  
+  __Взаимоисключения__
+  
+  Иногда требуется выполнять какой-то процесс эксклюзивно. Например используя распределенный консенсус - алгоритмы, которые сложно и медленно работают. etcd, Consul, Zookeeper. Зато отказоустойчивы
+  
+  Альтернатива - red lock, когда БД используется в качестве хранилища блокировок. Блокировка не захватывается, а арендуется на время. Чтобы в случае блокировки и отказа системы блокировка не осталась навсегда Добавляем версию блокировки для контроля ее корректности
+  ![Image alt](https://github.com/Shell26/Java-Developer/raw/master/img/OOP14.png)
+
+[к оглавлению](#ООП)
+
+## 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
+ 
 [к оглавлению](#ООП)
 
 # Источники

img/OOP11.png

@@ -2,6 +2,7 @@
 
 # Тестирование
 + [Что такое _«модульное тестирование»_?](#Что-такое-модульное-тестирование)
++ [Что такое _«компонентное тестирование»_?](#Что-такое-компонентное-тестирование)
 + [Что такое _«интеграционное тестирование»_?](#Что-такое-интеграционное-тестирование)
 + [Чем интеграционное тестирование отличается от модульного?](#Чем-интеграционное-тестирование-отличается-от-модульного)
 + [Какие существуют виды тестовых объектов?](#Какие-существуют-виды-тестовых-объектов)
@@ -10,6 +11,8 @@
 + [Какие аннотации фикстур существуют в JUnit?](#Какие-аннотации-фикстур-существуют-в-junit)
 + [Для чего в JUnit используется аннотация `@Ignore`?](#Для-чего-в-junit-используется-аннотация-ignore)
 
+![Image alt](https://github.com/Shell26/Java-Developer/raw/master/img/Test1.png)
+
 ## Что такое _«модульное тестирование»_?
 __Модульное/компонентное тестирование (unit testing)__ - процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.
 
@@ -21,6 +24,13 @@ __Модульное/компонентное тестирование (unit tes
 
 [к оглавлению](#Тестирование)
 
+## Что такое _«компонентное тестирование»_?
+Проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.). Обычно проводится вызывая код, который необходимо проверить и при поддержке сред разработки, таких как фреймворки (frameworks - каркасы) для модульного тестирования или инструменты для отладки. 
+
+По-существу компонентные и модульные тестирования представляют одно и тоже, разница лишь в том, что в компонентном тестировании в качестве параметров функций используют реальные объекты и драйверы, а в модульном тестировании - конкретные значения.
+
+[к оглавлению](#Тестирование)
+
 ## Что такое _«интеграционное тестирование»_?
 __Интеграционное тестирование (integration testing)__ — это тестирование, проверяющие работоспособность двух или более модулей системы в совокупности — то есть нескольких объектов как единого блока. В тестах взаимодействия же тестируется конкретный, определенный объект и то, как именно он взаимодействует с внешними зависимостями.