Микросервисы / распределенные системы

Продолжение

Здесь стоит сделать отсылку с CAP-теореме, но чтобы не усложнять, приведу пример. У вас была одна команда. Вы добавили вторую. Обе команды разрабатывают разные части системы, но используют одно тестовое окружение. Им нужно договориться (добиться согласованности) о внесении изменений в это окружение. CAP теорема говорит, что достижение одновременно 100%-й согласованности, 100%-й доступности и устойчивости к разделению невозможно. То есть, пока команды не имеют возможности договориться, но им требуется 100%-я согласованность, они теряют свойство доступности, – просто не могут начать тестировать. В распределенных системах, в том числе в структуре команд, необходимо при проектировании закладывать такие принципы и свойства, которые позволят принимать максимальное число решений автономно (в данном случае – собственные тестовые среды), а оставшиеся зависимости должны быть неблокирующими (например, – выпуск частей солюшена разными командами в удобном им ритме, но с испоьзованием версионирования API и Feature Toggle). Это и есть обеспечение устойчивости к разделению с использованием согласованности в конечном счете.

Какие еще аналоги можно встретить в компаниях?
Архитектурные комитеты, если они блокируют работу, общие тестовые среды на несколько команд, если для того, чтобы протестировать необходимо вставать в очередь, интеграционные компоненты, вроде ESB, в которых реализована бизнес-логика и команда поддержки ESB становится таким компонентом системы, сдерживающим масштабирование.

В действительности, проектируя микросервисное решение, мы проектируем организацию, потому что если автономность и независимость микросервисов не поддерживается автономостью и неблокирующими зависимости на уровне структуры организации, польза от микросервисов будет крайней ограниченной, а вот всю привносимую ими дополнительную сложность бонусом компания получит в любом случае.

Обобщая вышесказанное, – говоря о масштабировании микросервисов чаще всего подразумевается возможность технически поддержать возрастающую нагрузку. Но это половина правда. Особенность этого стиля в том, что он явным образом поддерживает и масштабируемость разработки (производственной системы), что для компании иногда даже более важно, а этого добиться без организационных изменений в общем случае невозможно.

👍23❤4🔥3👏1

www.tgoop.com/microservices_arch/548

7.07K viewsSergey Baranov, Mar 7, 2024 at 19:34

Продолжение

Здесь стоит сделать отсылку с CAP-теореме, но чтобы не усложнять, приведу пример. У вас была одна команда. Вы добавили вторую. Обе команды разрабатывают разные части системы, но используют одно тестовое окружение. Им нужно договориться (добиться согласованности) о внесении изменений в это окружение. CAP теорема говорит, что достижение одновременно 100%-й согласованности, 100%-й доступности и устойчивости к разделению невозможно. То есть, пока команды не имеют возможности договориться, но им требуется 100%-я согласованность, они теряют свойство доступности, – просто не могут начать тестировать. В распределенных системах, в том числе в структуре команд, необходимо при проектировании закладывать такие принципы и свойства, которые позволят принимать максимальное число решений автономно (в данном случае – собственные тестовые среды), а оставшиеся зависимости должны быть неблокирующими (например, – выпуск частей солюшена разными командами в удобном им ритме, но с испоьзованием версионирования API и Feature Toggle). Это и есть обеспечение устойчивости к разделению с использованием согласованности в конечном счете.

Какие еще аналоги можно встретить в компаниях?
Архитектурные комитеты, если они блокируют работу, общие тестовые среды на несколько команд, если для того, чтобы протестировать необходимо вставать в очередь, интеграционные компоненты, вроде ESB, в которых реализована бизнес-логика и команда поддержки ESB становится таким компонентом системы, сдерживающим масштабирование.

В действительности, проектируя микросервисное решение, мы проектируем организацию, потому что если автономность и независимость микросервисов не поддерживается автономостью и неблокирующими зависимости на уровне структуры организации, польза от микросервисов будет крайней ограниченной, а вот всю привносимую ими дополнительную сложность бонусом компания получит в любом случае.

Обобщая вышесказанное, – говоря о масштабировании микросервисов чаще всего подразумевается возможность технически поддержать возрастающую нагрузку. Но это половина правда. Особенность этого стиля в том, что он явным образом поддерживает и масштабируемость разработки (производственной системы), что для компании иногда даже более важно, а этого добиться без организационных изменений в общем случае невозможно.

BY Микросервисы / распределенные системы