dannc/netology-devops
1
0
Fork 0
mirror of https://github.com/Dannecron/netology-devops.git synced 2025-12-25 23:32:37 +03:00
Code Issues Packages Projects Releases Wiki Activity

homework 11.1: complete homework

Browse Source
This commit is contained in:
dannc
2022-10-24 09:50:43 +07:00
parent 3eccbe572e
commit 6aec724e6f
2 changed files with 26 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
readme.md
View File

@@ -53,3 +53,4 @@
* [10.4. ELK](/src/homework/10-monitoring/10.4)
* [10.5. Sentry](/src/homework/10-monitoring/10.5)
* [10.6. Инцидент-менеджмент](/src/homework/10-monitoring/10.6)
* [11.1. Введение в микросервисы](/src/homework/11-microservices/11.1)

25
src/homework/11-microservices/11.1/readme.md Normal file
View File

@@ -0,0 +1,25 @@
Выполнение [домашнего задания](https://github.com/netology-code/devkub-homeworks/blob/main/11-microservices-01-intro.md)
по теме "11.1. Введение в микросервисы"
## Q/A
### Задание 1
> Руководство крупного интернет магазина у которого постоянно растёт пользовательская база и количество заказов рассматривает возможность переделки своей внутренней ИТ системы на основе микросервисов.
>
> Вас пригласили в качестве консультанта для оценки целесообразности перехода на микросервисную архитектуру.
>
> Опишите какие выгоды может получить компания от перехода на микросервисную архитектуру и какие проблемы необходимо будет решить в первую очередь.
Самая главная проблема, которую предстоит решить - это разделение функционала интернет-магазина на домены.
На основе этих доменов будут создаваться микросервисы.
После решения данной проблемы можно получить следующие выгоды:
- изолированность доменов и сервисов. Это означает, что при отказе одного микросервиса или целого домена остальные будут работать.
Например, при отказе сервиса оплат останется работать витрина и корзина, что положительно скажется на пользовательском опыте.
- упрощённое горизонтальное масштабирование. В отличие от монолита, микросервисы легче масштабировать при возникновении нагрузки.
Достаточно только поднять количество реплик сервисов, которые испытывают нагрузку, в то время, как количество других сервисов останется без изменения.
- построение структуры разработки на основе схемы доменов. Это означает, что для каждого домена (набора микросервисов)
будет выделена своя команда разработки и поддержки. Таким образом, можно развивать функционал каждого домена максимально независимо друг от друга.
- вытекает из предыдущего: уменьшение значения TTM (time to market), то есть количество времени, прошедшее
с момента взятия задачи в работу до её реального релиза на продуктовое окружение.