Статьи

Микросервисы: пять архитектурных ограничений

Microservices — это новая программная архитектура и парадигма доставки, в которой приложения состоят из нескольких небольших сервисов времени выполнения.

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

С Microservices программный модуль поставляется как независимая служба времени выполнения с четко определенным API. Микросервисный подход обеспечивает более быструю доставку небольших дополнительных изменений в приложение.

Есть несколько компромиссов, чтобы рассмотреть с архитектурой Microservices. С одной стороны, подход Microservices основан на нескольких лучших практиках и шаблонах для проектирования программного обеспечения, архитектуры и организации стиля DevOps. С другой стороны, Microservices требует опыта в распределенном программировании и может стать операционным кошмаром без надлежащего инструментария на месте. Есть несколько хороших постов, в которых рассказывается о плюсах и минусах Microservices, и я добавил их в раздел ссылок.

В оставшейся части этого поста я определю пять архитектурных ограничений (принципов, определяющих желаемые свойства) для архитектурного стиля Microservices. Чтобы быть микросервисом, услуга должна быть:

  1. Эластичный
  2. жизнерадостный
  3. наборный
  4. Минимальный и;
  5. полный

Микросервисное ограничение № 1 — эластичное

Микросервис должен иметь возможность масштабирования вверх или вниз независимо от других служб в том же приложении.

Это ограничение подразумевает, что в зависимости от нагрузки или других факторов вы можете точно настроить производительность, доступность и использование ресурсов ваших приложений.

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

Микросервисное ограничение № 2 — Эластичный

Микросервис должен давать сбой, не влияя на другие сервисы в том же приложении.

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

Адриан Кокрофт описывает микросервисы как слабо связанные сервис-ориентированные архитектуры с ограниченным контекстом [3]. Чтобы быть устойчивой, служба должна быть слабо связана с другими службами, а ограниченный контекст ограничивает область отказа службы.

Микросервисное ограничение № 3 — Композитный

Микросервис должен предлагать единый интерфейс, предназначенный для поддержки состава услуг.

Микросервисные API должны быть разработаны с общим способом идентификации, представления и управления ресурсами, описания схемы API и поддерживаемых операций API. Ограничение Uniform Interfaces архитектурного стиля REST описывает это подробно.

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

Ранее я обсуждал ограничения и элементы REST в виде поста из двух частей:  REST не относится к API

Микросервисное ограничение № 4 — минимальное

Микросервис должен содержать только очень сплоченные объекты

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

Микросервис должен выполнять единую бизнес-функцию, что подразумевает высокую степень согласованности всех его компонентов. Это также Единый принцип ответственности (SRP) объектно-ориентированного проектирования [5]

Микросервисное ограничение № 5 — завершено

Микросервис должен быть функционально завершен

Бьярн Страуструп, создатель C ++, заявил, что хороший интерфейс должен быть «минимальным, но полным», то есть как можно меньшим и не меньшим.

Аналогично, микросервис должен предлагать полную функцию с минимальными зависимостями (слабой связью) с другими службами в приложении. Это важно, так как в противном случае становится невозможным версия и обновление отдельных сервисов.

Это ограничение предназначено для противодействия минимальному ограничению. Микросервис должен быть «минимальным, но полным».

Выводы

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

Например, ограничение Microservices # 1 — Elastic направляет реализации к отделению уровня данных от уровня приложения и ведет к услугам без сохранения состояния.

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

Если вы используете или заинтересованы в использовании микросервисов, я хотел бы услышать от вас.

Основатель и генеральный директор
Нирмата

— Для получения дополнительной информации и статей следуйте за нами на  @NirmataCloud .
— Если вы находитесь в районе залива Сан-Франциско,  присоединяйтесь к нашей группе по встречам с Microservices .

Ссылки

[1] Microservices, Martin Fowler and James Lewis,
http://martinfowler.com/articles/microservices.html
[2] Microservices Are Not a free lunch!, Benjamin Wootton, 
http://contino.co.uk/microservices-not-a-free-lunch/
[3] State of the Art in Microservices, Adrian Cockroft, 
http://thenewstack.io/dockercon-europe-adrian-cockcroft-on-the-state-of-microservices/
[4] The Principles of Object-Oriented Design, Robert C. Martin,
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod