Microservices — это новая программная архитектура и парадигма доставки, в которой приложения состоят из нескольких небольших сервисов времени выполнения.
Текущий основной подход к поставке программного обеспечения заключается в создании, интеграции и тестировании целых приложений в качестве монолита. Этот подход требует любого изменения программного обеспечения, даже небольшого, для полного цикла тестирования всего приложения.
С Microservices программный модуль поставляется как независимая служба времени выполнения с четко определенным API. Микросервисный подход обеспечивает более быструю доставку небольших дополнительных изменений в приложение.
Есть несколько компромиссов, чтобы рассмотреть с архитектурой Microservices. С одной стороны, подход Microservices основан на нескольких лучших практиках и шаблонах для проектирования программного обеспечения, архитектуры и организации стиля DevOps. С другой стороны, Microservices требует опыта в распределенном программировании и может стать операционным кошмаром без надлежащего инструментария на месте. Есть несколько хороших постов, в которых рассказывается о плюсах и минусах Microservices, и я добавил их в раздел ссылок.
В оставшейся части этого поста я определю пять архитектурных ограничений (принципов, определяющих желаемые свойства) для архитектурного стиля Microservices. Чтобы быть микросервисом, услуга должна быть:
- Эластичный
- жизнерадостный
- наборный
- Минимальный и;
- полный
Микросервисное ограничение № 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