Если вы участвовали в процессе принятия решений и испытывали разумные сомнения относительно того, чтобы начать следующий большой программный проект с использованием микросервисов, вы не одиноки. Нас вдохновляют истории успеха таких гигантов программного обеспечения, как Amazon, Netflix, eBay, которые переходят на микросервисы. Когда вы слышите такие слова, как гибкость, скорость и масштаб, кто не хочет пробовать микросервисы, верно?
Мы не часто слышим историю о том, как они туда попали. Если мы посмотрим почти на всех этих гигантов программного обеспечения, ни один из них не начал разрабатывать микросервисы с самого начала, как мы это знаем. Но одно можно сказать наверняка: когда они вырастут, они в конечном итоге останутся с микросервисами по очевидным причинам.
Совет: используйте Bit, чтобы делиться и сотрудничать с вашей командой над многократно используемыми модулями JS и компонентами пользовательского интерфейса.
Ускорьте время разработки и повысьте ремонтопригодность с помощью повторно используемых компонентов, которые были инкапсулированы вместе со своими зависимостями и протестированы изолированно. Освободите свои компоненты - поделитесь ими из любого репо и импортируйте их в любое репо либо в виде исходного кода, либо в виде пакетов. Попробуйте.
Определить ограниченный контекст сложнее, чем вы думаете
Что ж, прежде чем приходить к каким-либо суждениям, давайте разберемся с ситуацией. Предположим, мы решили использовать микросервисы для следующего крупного программного проекта. Обычно мы начинаем с определения ограниченных контекстов для разбивки микросервисов. Один из важных вопросов, на который нам нужно ответить, - достаточно ли у нас информации, чтобы идентифицировать ограниченные контексты в начале? Кто-то может сказать, что мы знаем требования и сферу бизнеса, и почему мы не можем определить ограниченные контексты, которые приводят к границам услуг. Имейте в виду, что для распознавания ограниченных контекстов требуется гораздо больше, помимо понимания домена, поддоменов и даже подробных требований.
Мысленный эксперимент с ограниченным контекстом
Предположим, что мы разделили домен приложения на три ограниченных контекста, образуя вначале три микросервиса. Предположим также, что два микросервиса зависят от третьего. Эта установка может хорошо работать в разработке. Но что, если, когда приложение находится в рабочей среде, общая группа микросервисов получает множество запросов на изменение от двух других, что замедляет общий прогресс проекта? Этот сценарий представляет собой практический пример, который трудно предсказать, когда вы начинаете разработку нового приложения, если оно не находится в производстве. Помните, что мы хотим, чтобы каждая команда микросервисов самоорганизовывалась и управляла работой с минимальными зависимостями за пределами службы. Подобные проблемы не складываются в философию самоорганизованных команд, работающих в рамках микросервисов.
Так какое же решение? Конечно, реальное решение зависит от того, что вызвало фактическую задержку для третьей команды. Но это также может быть связано с тем, что мы не смогли точно идентифицировать ограниченный контекст. Мы могли бы сформировать два микросервиса только вначале, вбирая в себя функциональность общей службы, не имея в первую очередь зависимости. Этот опыт приходит со временем, запуском программных приложений в производстве. Также важно отметить, что эти знания в равной степени применимы к монолитам.
Нарушение того, что у вас есть, отличается от нарушения абстракции
Если у нас уже есть полноценный монолит, запущенный в производство, то мы лучше оснащены, имея достаточно неявных знаний для определения ограниченного контекста. К сожалению, эти знания не всегда доступны, когда мы начинаем новый проект.
Когда мы начинаем новый программный проект с помощью микросервисов и ожидаем достижения гибкости и скорости, прежде чем перейти к нужному масштабу, это сложнее, чем вы думаете. Настоящая проблема заключается в самой сути микросервисов, которые представляют собой распределенные системы. Построение распределенной системы с самого начала, скорее всего, замедлит вас, если вы не в нужном масштабе. Если вы считаете, что это инвестиции в будущее, я думаю, вам следует знать, что вы делаете, и иметь достаточный опыт создания полноценных решений микросервисов в прошлом. Это связано с тем, что разделение микросервисов сопряжено со всевозможными проблемами при управлении несколькими средами выполнения, базами данных и точками интеграции.
Позвольте мне привести простой пример, чтобы объяснить дополнительную сложность распределенных систем. Просто подумайте о сложности обработки последовательности действий, охватывающей микросервисы. Вы должны знать, как сложно и сложно реализовать саги или распределенные транзакции. Для сравнения: аналогичная функциональность может быть легко достигнута с помощью блока транзакции в монолите.
Если вы решили начать новый проект с микросервисами
Каким-то образом, если вы решили начать новый проект с помощью микросервисов, убедитесь, что вы знаете о возможных рисках. Доступные шаблоны и практики ориентированы на технические решения, а не на решение имеющихся практических проблем. Так что имейте в виду, что нет никакой гарантии, что то, что работает для них, будет работать для вас.
Кроме того, вначале не стоит слишком сильно зацикливаться на следовании точным шаблонам и методам, имеющим отношение к микросервисам. Используйте свой здравый смысл и опыт, чтобы спроектировать архитектуру, чтобы ускорить работу. Как вы уже знаете, некоторые проблемы лучше решать позже, не прилагая больших усилий. Поэтому чаще принимайте разные решения и не попадитесь в ловушку создания слишком большого количества микросервисов в начале, если у вас нет реальных причин для этого. И мой последний совет: начните с малого и постепенно увеличивайте количество микросервисов, сохраняя минимальную зависимость между микросервисами.
