Должен ли я использовать микросервисы при разработке системы самостоятельно?

Я начинаю новый проект на работе и, вероятно, буду едва ли не единственным разработчиком проекта, хотя одному или двум другим разработчикам потребуется интегрировать существующие приложения или простые сценарии в основной проект. Проект должен обрабатывать небольшие объемные и потоковые данные, обрабатывать и обрабатывать их, а также выполнять код по запросу. Некоторые части платформы будут сильно связаны с процессором, а некоторые части могут быть сильно связаны с вводом / выводом; Большая часть данных должна храниться на одной машине, но мы можем создать кластер и подключить виртуальные машины для увеличения доступной вычислительной мощности. Вероятно, будет одно или несколько небольших веб-приложений, которые зависят от услуг, предоставляемых этой базовой платформой. Основным языком будет Python практически для всего.

Мой вопрос заключается в том, должен ли я использовать подход с микросервисами для таких усилий или придерживаться монолитного приложения, учитывая, что большую часть разработки я буду выполнять сам. Я считаю, что микросервисы (использующие Nameko) обеспечивают естественное разделение между элементами инфраструктуры, которые имеют разные модели выполнения (конвейеры данных, запуск событий, веб-приложения по требованию и т. Д.) И четким способом распределения рабочей нагрузки и связь между несколькими процессами. Меня беспокоит то, что я, вероятно, в конечном итоге получу кластер Kubernetes для управления (я знаком с Docker, но все еще довольно плохо знаком с Kubernetes), несколькими службами (rabbitmq, redis и т. Д.), Необходимыми только для облегчения работы системы, и потенциально много маленьких кусочков кода для реализации всех необходимых возможностей, которые мы

Для проекта с чуть более чем одним разработчиком микросервисы все еще упрощают разработку и обслуживание такой сложной системы, как эта? Существуют ли методы / системы / структуры, которые я должен рассмотреть вместо этого, или чтобы уменьшить накладные расходы, связанные с проектированием системы таким образом?

Микросервисы, как правило, нежелательны, потому что они превращают ваше программное обеспечение в распределенную систему, а распределенные системы делают все намного сложнее. Но сервис-ориентированная архитектура имеет ряд важных преимуществ:

• разные службы могут разрабатывать и развертывать независимо друг от друга
• разные услуги можно масштабировать независимо

Поскольку вы будете единственным разработчиком, вам не потребуется гибкость для самостоятельного развития сервисов.

Но обратите внимание, что некоторые части могут быть связаны с процессором. Поэтому было бы желательно масштабировать их независимо от остальной части приложения. Если это так, это не значит, что вы должны превратить весь проект в микросервисную архитектуру. Вам нужно только переместить эту часть, интенсивно использующую процессор, в ее собственную службу, а остальные можно хранить в удобном монолите. По каким направлениям система должна быть разделена, сказать трудно, но в целом идея DDD о «ограниченном контексте» является хорошим ориентиром.

Обратите внимание, что монолиты не плохие. Монолиты не равняются огромному грязному, не подлежащему ремонту проекту. Там, где вы можете разделить систему на разные микросервисы, вы также можете разделить систему на разные компоненты в рамках монолита. Разделение между этими компонентами становится более наглядным и более четко реализуемым в сервис-ориентированной архитектуре. Это также означает, что для хорошо спроектированной системы должно быть довольно легко превратить компонент в сервис на более позднем этапе. Поэтому вам не нужно решать прямо сейчас, вы можете перейти на микросервисы, если и когда монолит зарекомендовал себя как неподходящий.

Рассмотрим также концепцию Microservice Premium (2015), предложенную Мартином Фаулером : микросервисы вносят существенную сложность в дополнение к базовой сложности вашей системы. Вы должны заплатить эту «премию» с точки зрения снижения производительности. Это означает, что для простых проектов микросервисы делают вас менее продуктивными. Это меняется для более сложных проектов: хотя с монолитным решением становится все труднее работать, микросервисная архитектура масштабируется намного лучше и требует примерно постоянных усилий. Вы должны знать, стоят ли дополнительные начальные усилия микросервисов с учетом вашей программной системы. Поскольку вы задаете этот вопрос, ответ, вероятно, «нет». Фаулер продолжает:

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