Что означает «микро» в микросервисах?
Как вы определяете, что такое микросервис? Как вы определяете границы?
Это не точная наука. Однако, когда вы приблизитесь к границам нарушения того, что означает слово «микро», вы поймете и почувствуете беспокойство, внося изменения в эту службу, потому что это будет казаться неправильным. По-прежнему полезно иметь некоторые рекомендации по определению границ вашего микросервиса. Вот подход, который мне нравится использовать.
Заставьте себя записать на бумаге, чем занимается ваша служба. Напишите это от первого лица, чтобы придать ему немного больше выразительности.
Я микросервис А и существую для того, чтобы выполнять Х.
Это должно быть первым описанием в вашей документации по API, чтобы оно было понятно вашим клиентам, а также хорошим напоминанием для вашей команды.
Давайте посмотрим пример. Допустим, вы хотите разработать микросервис «Подписка» и после некоторых начальных обсуждений вы пишете определение для этого сервиса:
«Я — микросервис подписки, и я существую, чтобы создавать, читать, обновлять и удалять подписки, а также я существую, чтобы активировать и деактивировать преимущества и условия подписки. Я также существую, чтобы исправить неудачные подписки до хорошего состояния».
Это определение подавляющее. Если всю эту работу выполняет служба подписки, то это действительно не микрослужба. Это макро-сервис. Если в определении вашей услуги много «и» и «если» в предложениях, то вам следует побеспокоиться о размере этой услуги.
Вот как эту службу подписки можно превратить в микрослужбу.
«Я — микросервис подписки, и я существую, чтобы выполнять операции CRUD над подписками».
Теперь, когда ваша служба подписки является микрослужбой, вам нужно представить другие службы, которые будут выполнять оставшиеся действия. Например, вы можете добавить следующие службы для выполнения остальных действий:
«Я — микросервис Fulfillment, и я существую для того, чтобы организовать создание подписки и выполнение этой подписки, что на самом деле является активацией и деактивацией преимуществ данной подписки.”
«Я — микрослужба Fulfillment-Recovery, и я существую для того, чтобы восстановить ошибочную подписку до нормального состояния».
Это всего лишь один пример того, как можно определить границы для «микро» в микрослужбах. Кто-то может возразить, что вы можете разбить вышеперечисленные сервисы на более мелкие сервисы, и, на мой взгляд, именно здесь вы находитесь в другом спектре, где ваши микросервисы превращаются в наносервисы. Это нормально, если вы не перевозбудитесь и не повлияете на производительность. Если вы слишком сильно пойдете в этом направлении, вы начнете ощущать накладные расходы из-за слишком большого количества вызовов RESTful, соединенных вместе, и каждый HTTP-вызов по проводу складывается. Вот где вам нужно быть очень реалистичным и решить, сколько вы получаете, делая это, учитывая ваши варианты использования.
Еще один способ более точно определить «микро» в вашем микросервисе — определить маршруты API для всех действий, которые вы упомянули в определении вашего микросервиса. Если вы выполните это упражнение, вы быстро обнаружите, что маршруты API для исходного длинного определения микрослужбы Subscription не будут оставаться RESTful. Это ваш сигнал начать разбивать этот сервис на более мелкие сервисы.
В заключение представьте некоторые рекомендации в вашей компании о том, как определить, что такое микрослужба, и держать друг друга под контролем при добавлении новых служб и при добавлении функциональности к существующим микрослужбам.
Спасибо за чтение.
Альмир Мустафик.
