автордың кітабынан сөз тіркестері Микросервисы. От архитектуры до релиза
подход к разработке единого приложения в виде набора небольших сервисов, работающих в отдельных процессах и взаимодействующих с применением упрощенных механизмов. [...] построенных вокруг бизнес-потребностей и развертываемых независимо с помощью полностью автоматизированного механизма»
2 Ұнайды
Микросервисная архитектура — это стиль проектирования высокоавтоматизированных, эволюционирующих программных систем, состоящих из микросервисов, ориентированных на потребности»
1 Ұнайды
# OPM1: Использовать ADRS для документирования решений
## Статус
Принято
## Контекст
## Решение
Одни решения верны в определенное время, но устаревают, когда меняются технологии, люди или ситуации. Другие не были хорошими с самого начала. В любом случае нам нужен способ фиксировать важные решения, чтобы со временем мы могли их переоценить и улучшить.
Чтобы удовлетворить эту потребность, мы воспользуемся инструментом под названием реестр архитектурных решений (architecture decision record, ADR). Мы точно не знаем, кто изобрел термин ADR и когда он был впервые использован, но идея документирования проектных решений существует давно. Проблема заключается в том, что большинство людей не тратят на это время. По нашему опыту, ADR — чрезвычайно полезный инструмент, позволяющий прояснить принимаемые решения.
Хотелось бы иметь проект, требующий минимум координации между автономными командами, работающими над небольшими изолированными задачами. Именно это предлагает микросервисная архитектура.
Важно понимать, что работа по созданию хороших микросервисов направлена на минимизацию координации
существует множество способов увеличить скорость разработки ПО, и организация программного обеспечения в виде микросервисов — лишь один из вариантов. Например, можно быстро создать систему, выполнив работу поверхностно и накопив «технический долг» (https://oreil.ly/PBMHU), с которым предполагается разобраться позже. Или же можно меньше внимания уделить стабильности и безопасности и просто выпустить свой продукт в мир. В отдельных ситуациях и для некоторых предприятий это разумные подходы.
Но в системах, разрабатываемых, в частности, для финансового, медицинского и государственного секторов, непозволительно ради повышения скорости идти на компромисс с безопасностью. И все же рынок требует от этих отраслей более высокой скорости, как и от любых других. Именно здесь микросервисы могут проявить себя во всей красе. Они предлагают архитектурный подход, позволяющий увеличить скорость разработки без ущерба для безопасности. И дают возможность делать это в широком масштабе.
Несмотря на то что микросервисы обладают множеством потенциальных преимуществ, мы считаем, что лучшая причина создавать программное обеспечение с применением этого подхода — снижение затрат на координацию (взаимодействие).
Правда в том, что практически любую систему на базе API можно назвать микросервисной архитектурой, если очень постараться. Основное внимание должно быть сосредоточено на цели вашей системы. Мы думаем, что вопрос о том, зачем создаются микросервисы, гораздо важнее, чем вопрос о том, что они собой представляют.
«подход к разработке единого приложения в виде набора небольших сервисов, работающих в отдельных процессах и взаимодействующих с применением упрощенных механизмов. [...] построенных вокруг бизнес-потребностей и развертываемых независимо с помощью полностью автоматизированного механизма».