Использование микросервисов связано с потребностями реального мира, и для того, чтобы добиться построения качественной SOA, требуется лучше разбираться в системах и архитектурах. Поэтому о микросервисах лучше думать как о конкретном подходе к SOA, в том же ключе, в котором XP или Scrum являются конкретными подходами к разработке гибких программных систем.
Другие технологии декомпозиции
Если разобраться, многие преимущества архитектуры на основе микросервисов возникают из присущей ей детализированности и того факта, что она дает намного больше вариантов решения проблем. Но можно ли достичь таких же преимуществ с помощью подобных технологий декомпозиции?
Совместно используемые библиотеки
Эта весьма стандартная технология декомпозиции, встроенная практически в любой язык программирования, предусматривает разбиение исходного кода на несколько библиотек. Эти библиотеки могут предоставляться сторонними разработчиками или создаваться вашей собственной организацией.
Библиотеки обеспечивают способ совместного использования функциональных возможностей различными командами и службами. Например, я могу создать пригодный для повторного использования набор полезных утилит для сбора данных или, возможно, библиотеку создания статистических данных. Команды могут сосредоточиться на разработке таких библиотек, а сами библиотеки могут использоваться повторно. Но есть в их применении и некоторые недостатки.
Во-первых, утрачивается технологическая разнородность. Как правило, библиотеки должны быть написаны на том же языке или в крайнем случае запускаться на той же самой платформе. Во-вторых, утрачивается та легкость, с которой можно расширять части системы независимо друг от друга. Далее, если только не используются динамически подключаемые библиотеки, вы не можете развернуть новую библиотеку, не свернув весь процесс, поэтому сокращается возможность изолированного развертывания измененного кода. И, возможно, критики отметят отсутствие явных стыков, на основе которых можно предпринять безопасные для архитектуры меры обеспечения отказоустойчивости системы.
У совместно используемых библиотек есть свое место применения. Когда вы поймете, что создаете код не конкретно для своей области бизнеса, а для решения более общей задачи и этот код захочется повторно использовать в рамках всей организации, он станет явным кандидатом на превращение в совместно используемую библиотеку. Но делать это нужно с известной долей осторожности. Общий код, используемый для обмена данными между сервисами, может стать той самой точкой, которая создаст их неразрывную связь. Этот вопрос еще будет рассматриваться в главе 4.