Микросервисы

Беда микросервисов в том, что их разработчики не понимают одну вещь. Хотя формально микросервисы отделены друг от друга, на самом деле они связаны, потому что подчиняются общим требованиям.

Обычно об этом не думают и колбасят пачки сервисов. Доходит до того, что один сервис пишут на Питоне, второй на Ноде, а в третьей команде экстремисты протащили Хаскель. И все такие — а что такого, у нас микросервисы, общение по HTTP JSON, какая разница, что крутится в кубернетисе?

Не все равно хотя бы по следующим причинам.

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

На практике я наблюдаю, что документацию завозят только если продают апишку внешним потребителям. Для своих отношение другое — посмотришь исходник, не рассыпешься.

Далее трассировка. Каждый сервис трекает в общей базе request-id, с которым его вызвали. Записывается начало запроса, конец и статус. Должна быть админка, где вводишь request-id и система рисует граф вызовов с метриками. Опять же, где вы такое видели?

Лимиты. У каждого сервиса должен быть механизм рейт-лимита, чтобы его не ддосили. Как бывает обычно? Ты вызвал сервис 1000 раз, и начинаются крики “кто нас дидосит!!11”. Так ведь нигде не написано, сколько раз можно вызывать! Должна быть прокладка, которая считает число запросов в разрезе потребителей и внятно отвечает, сколько ждать до обнуления. Такое хоть где-то бывает?

Длины массивов. Сервис принимает список айдишников. Передаю 10 тысяч и получаю статус 500. Начинается восточный базар: передавай по сто. Нет, это мало, давай по тысяче? Нет, давай по пятьсот. Ну ок.

Разумеется, этого не должно быть. У каждого массива или строки должен быть верхний лимит — чего я не наблюдаю.

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

Здесь и кроется предубеждение: хотя формально микросервисы не связаны друг с другом, на практике это клоны одного проекта. Изменения в клоне отражаются в его копиях, поэтому ни о какой самобытности не может быть и речи. Правильные микросервисы — это унификация, полный отказ от самостоятельности.