Микро серверная архитектура что это
Что такое микросервисы: особенности архитектуры, примеры использования, инструменты
Авторизуйтесь
Что такое микросервисы: особенности архитектуры, примеры использования, инструменты
Архитектурный стиль микросервисов — это подход, при котором система строится как набор независимых и слабосвязанных сервисов, которые можно создавать, используя различные языки программирования и технологии хранения данных. Концепция микросервисов позволяет поддерживать слабую связанность сервисов в процессе работы над системой, что определяют паттерны Low Coupling и High Cohesion.
Подробности — в видео и текстовой расшифровке ниже.
Монолит vs микросервисы
При монолитной архитектуре система обычно состоит из 3 блоков: пользовательский интерфейс, хранилище данных и серверная часть. Серверная часть обрабатывает запросы, выполняет бизнес-логику, работает с БД, заполняет HTML-страницы. Любое изменение в системе приводит к обновлению версии серверной части приложения.
В случае с микросервисной архитектурой обновляется только изменённый сервис. Если изменения затрагивают интерфейс сервиса, это потребует координации всех его клиентов. Цель хорошей микросервисной архитектуры — максимально уменьшить необходимость координации сервисов.
Что такое контракт
Контракт — это формализация возможностей взаимодействия с микросервисом. В случае с REST API эндпоинты сервиса и схема данных являются контрактом. Первоначальная разработка архитектуры — это декомпозиция системы на слабосвязанные сервисы, создание интерфейсов и связей между ними, поддержка целостности данных без потери производительности. Помочь с решением данной задачи могут шаблоны Tolerant Reader и Consumer-Driven Contracts.
Микросервисная команда
Команда не должна включать в себя больше людей, чем можно насытить двумя пиццами. Такое правило использовала компания Amazon при распиливания своего монолита в 2002 году. Вполне допустимо и правило developer per service, то есть один разработчик на один микросервис.
Когда большая система разбивается, часто происходит так, что образовываются команды на базе технологий. При такой ситуации команды размещают логику на тех слоях системы, к которым имеют доступ. Закон Конвея в действии:
«Любая организация, которая проектирует какую-то систему (в широком смысле) получит дизайн, чья структура копирует структуру команд в этой организации»
Микросервисный подход предполагает разбиение системы на сервисы по бизнес-требованиям. Сервисы включают в себя полный набор технологий: UI, storage, backend. Это приводит к созданию кросс-функциональных команд, имеющих достаточно компетенций для реализации всех необходимых сервисов, покрывающих 100% бизнес-функционала. Команды должны отвечать за все аспекты ПО, которое они разрабатывают, включая поддержку его в режиме 24/7. В таком случае возможность проснуться от звонка в 3 часа ночи — это очень сильный стимул писать хороший код.
Насколько большим должен быть микросервис
Логика работы сервиса должна полностью уместиться в голове одного разработчика, независимо от количества кода и людей. Проектируя систему, мы имеем выбор, как разработать каждый микросервис. Например:
Архитектура микросервиса даёт полную свободу в выборе технологий и инструменария.
Инструментарий для реализации микросервисов
В процессе реализации микросервисной архитектуры существенным упрощением будет использование систем CI/CD, системы оркестрации, Service Discovering, мониторинга и сбора логов.
Необходимо быть уверенным в том, что приложение работает правильно. Для этого запускаются автоматические тесты, при этом система разворачивается в отдельной среде (Automated Deployment).
Цепочка синхронных вызовов микросервисов приведет к ожиданию ответов от всех сервисов по очереди. Поэтому используйте правило «Один синхронный вызов на один запрос пользователя», как это сделали в The Guardian, либо полностью асинхронный API, как в Netflix. Один из способов сделать асинхронный API — использовать систему обработки очередей, например, RabbitMQ, Apache Kafka или ActiveMQ.
Просто о микросервисах
Вступление
Чуть ли не каждый второй, кто впервые сталкивается с MSA (Micro Service Architecture), на первых порах восклицает: «Да я эти микросервисы еще …надцать лет назад». Отчасти они правы. И я тоже был из этой самой половины, и не понимал — почему такой шум?
В самом деле! Ведь MSA — это тоже про разработку софта. Какие здесь могут быть революции? Все методики знакомы. В некоторых местах можно даже удивиться: «А разве бывает по-другому»? Фанаты Agile и DevOps тоже скажут, что это всё наше, родное.
Но всё же прошу вас набраться терпения и продолжить читать дальше.
Что такое микросервисная архитектура (MSA)
MSA — принципиальная организация распределенной системы на основе микросервисов и их взаимодействия друг с другом и со средой по сети, а также принципов, направляющих проектирование архитектуры, её создание и эволюцию.
Что такое микросервис (MS)
Понять суть микросервиса проще всего на сравнении, или даже противопоставлении его крупному приложению — монолиту. В отличии от MSA, я не буду давать определение микросервису, а перечислю его наиболее важные характеристики.
А дальше мы рассмотрим каждую из них подробнее.
Я выделил восемь свойств микросервиса:
Небольшой
Что такое «небольшой»? Такая малоинформативная формулировка! На самом деле, по-другому не скажешь. Каждый должен самостоятельно определиться с размером. Лучше всего на практике. В качестве индикативных оценок можно ориентироваться на рекомендации экспертов. Размер микровервиса должен быть таким, чтобы выполнялось одно из условий:
Независимый
Микросервисная архитектура — воплощение паттернов High Cohesion и Low Coupling. Всё, что противоречит этому, отвергается беспощадно. В противном случае команду ждут большие проблемы. Так что микросервис обязан быть независимым компонентом.
Здесь попрошу вас не начинать холивар о том, что же такое «компонент». Давайте в рамках этой статьи сойдемся на том, что
Компонент — это единица ПО, код которой может быть независимо заменен или обновлен.
Конечно любая мало-мальски серьезная программа пишется с разбиением на компоненты, которые, безусловно, основываются на тех же принципах. Но в монолите общая кодовая база открывает возможности для нарушения низкой связанности. И при слабой дисциплине рано или поздно код превращается в спагетти.
Под такую формулировку компонента подходят и сторонние библиотеки. Здесь сложнее с нарушением границ произвольными связями, но не на много.
В то же время методология разбиения на отдельные микросервисы вынуждает придерживаться жесткого их разделения, ведь они должны отвечать более жестким критериям независимости.
Так, каждый микросервис работает в своем процессе и поэтому должен явно обозначить свой API. Учитывая, что другие компоненты могут использовать только этот API, и к тому же он удаленный, минимизация связей становится жизненно важной.
Такое разделение дает явный выигрыш с точки зрения независимого развития разных компонентов. И с учетом этого различные языки вводят конструкции, позволяющие явное создание независимых компонентов (например, модули в Java 9), и это перестает быть прерогативой микросервисного подхода.
Не хочу, чтобы создалось впечатление, будто в микросервисной архитектуре запрещено использование библиотек. Их использование не приветствуется, поскольку так или иначе приводит к зависимостям между микросервисами, но всё же допускается. Как правило, это допущение распространяется на инфраструктурные функции вроде логирования, вызова удаленного API, обработки ошибок и тому подобного.
Независимость микросервисов позволяет организовать независимый жизненный цикл разработки, создавать отдельные сборки, тестировать и развертывать.
Поскольку размер микросервисов невелик, то очевидно, что в крупных системах их будет немало. Управлять ими вручную будет сложно. Поэтому команда обязана иметь приемлемый уровень автоматизации согласно Continuous integration и Continuous Delivery.
Где же микросервис (бизнес-потребность)
Итак, вы решили спроектировать новый микросервис.
Определение его границ — самый важный шаг. От этого будет зависеть вся дальнейшая жизнь микросервиса, и это серьёзно повлияет на жизнь команды, отвечающей за него.
Основной принцип определения зоны ответственности микросервиса — сформировать её вокруг некоторой бизнес-потребности. И чем она компактнее, чем формализованней её взаимоотношения с другими областями, тем проще создать новый микросервис. В общем, довольно стандартный посыл. На нем основывается создание любых других компонентов. Вопрос только в том, чтобы в дальнейшем выдержать эту зону ответственности, что мы и обсуждали в предыдущем параграфе.
Когда границы микросервиса заданы и он выделен в отдельную кодовую базу, защитить эти границы от постороннего влияния не составляет труда. Далее внутри микросервиса создают свой микромир, опираясь на паттерн «ограниченного контекста». В микросервисе для любого объекта, для любого действия может быть своя интерпретация, отличная от других контекстов.
Но что делать, если границы оказались неправильными? В этом случае изменение функциональности в новом микросервисе ведет к изменению функциональности в других микросервисах. В результате «поплывут» интерфейсы всех зависимых микросервисов, а за ними интеграционные тесты. И всё превращается в снежный ком. А если эти микросервисы ещё и принадлежат разным командам, то начинаются межкомандные встречи, согласования и тому подобное. Так что правильные границы микросервиса — это основа здоровой микросервисной архитектуры.
Чтобы минимизировать ошибки при определении границ, нужно вначале их продумать. Поэтому оправданным является подход Monolith First, когда вначале систему развивают в традиционной парадигме, а когда появляются устоявшиеся области, их выделяют в микросервисы. Но всё течет и меняется. И границы тоже могут меняться. Главное, чтобы выигрыш от разбиения превышал сложности пересмотра этих границ. Такой подход к постепенному формированию набора микросервисов похож на итерационное развитие, используемое в Agile, ещё его называют «эволюционным проектированием» (Evolutionary Design).
Есть ещё одно интересное следствие создания микросервисов, соответствующее закону Конвея (Conwey Law).
Если организация использует монолитное приложение, то оно нарушает соответствие структуре и коммуникациям внутри организации. А команды разработчиков строятся вокруг архитектурных слоев монолита: UI, серверная логика, база данных.
Микросервисная архитектура приводит IT и бизнес в гармонию, с точки зрения Конвея. Поскольку микросервисы формируются вокруг бизнес-потребностей конкретных бизнес-подразделений, то архитектура предприятия начинает повторять оргструктуру и каналы социальной и бизнес-коммуникации. А команды становятся кроссфункциональными и формируются вокруг этих бизнес-потребностей / бизнес-подразделений.
Поскольку разные микросервисы получаются независимыми не только логически, но и технологически, а создавать их могут разные команды, ничто не мешает для каждого случая подбирать подходящие языки программирования, фреймворки и даже операционные системы.
Интеграция. Smart endpoints and dumb pipes
Интеграция микросервисов обходится без ESB, как центрального промежуточного звена. Наверное, комьюнити уже натерпелось от неудачных вариантов реализации этого подхода. То, что были и удачные — не принимается в расчет. Впрочем, ESB ещё и противоречит таким критериям как децентрализация и независимость. Таким образом, сложность интеграции распределяется с центрального звена в виде ESB непосредственно на интегрируемые компоненты: «умные конечные точки».
Здесь есть дилемма. Конечно бинарные протоколы гораздо эффективнее. Но, во-первых, появляются технологические ограничения. Во-вторых, на бинарных протоколах сложнее реализовывать шаблон Tolerant Reader, сохраняя эффективность. В-третьих, опять появляется зависимость провайдера и потребителей, поскольку они оперируют одними и теми же объектами и методами, то есть связаны по кодовой базе.
Другая отличительная черта взаимодействия микросервисов — синхронные вызовы не приветствуются. Рекомендуется использовать один синхронный вызов на один запрос пользователя, или вообще отказаться от синхронных вызовов.
И еще пара замечаний.
Design for failure для распределенной системы
Одно из наиболее критичных мест в микросервисной архитектуре — необходимость разрабатывать код для распределенной системы, составные элементы которой взаимодействуют через сеть.
А сеть ненадежна по своей природе. Сеть может просто отказать, может работать плохо, может вдруг перестать пропускать какой-то тип сообщений, потому что изменились настройки файрвола. Десятки причин и видов недоступности.
Поэтому микросервисы могут вдруг перестать отвечать, могут начать отвечать медленнее, чем обычно. И каждый удаленный вызов должен это учитывать. Должен правильно обрабатывать разные варианты отказа, уметь ждать, уметь возвращаться к нормальной работе при восстановлении контрагента.
Дополнительный уровень сложности привносит событийная архитектура. А отладку такой системы — не одного микросервиса, а системы, где много потоков разнонаправленных неупорядоченных событий — даже трудно представить. И даже если каждый из микросервисов будет безупречен с точки зрения бизнес-логики, этого мало. По аналогии со спортом, «звёзды» не гарантируют звездную команду, ведь в команде важнее не «звезды», а слаженность всех её игроков.
И поскольку сложность таких систем очень высока, то проблему решают так.
Децентрализация данных
Каждому микросервису по своей базе данных!
Лозунг популиста на выборах.
На самом деле и в монолите можно побороться за изолированность компонентов, например, на уровне серверного кода. Если время от времени изоляция даёт течь, современные инструменты предлагают продвинутые инструменты рефакторинга. Пользуйтесь. Хотя, как правило, на это находится время, только когда дела уже совсем плохи.
Теперь опустимся ниже, на уровень базы данных. Почему-то здесь на изолированность обращают внимание гораздо реже. В результате через пару тройку лет активного развития в базе данных монолита образуется если не хаос, то энтропия продвинутого уровня. Чтобы её побороть, мало уже одной строчки в бэклоге. Необходимы месяцы кропотливого и долгого труда.
В микросервисной архитектуре это решается гильотиной. Общей базы данных просто нет.
Помимо изолированности есть и побочные плюсы. Например, легче реализовать Polyglot Persistence, когда база подбирается под конкретные цели. Ничто не мешает делать это и без микросервисов, и так часто делают. Но всё же в одном случае это закон, в другом — исключение.
У этой медали есть оборотная сторона. Много баз, много контекстов, как их все согласовать? Старая техника распределенных транзакций сложна и обладает низкой скоростью. Возможно это иногда можно пережить. А вот необходимость синхронного взаимодействия нескольких микросервисов не может устраивать, и это не побороть.
Проблема решается нетрадиционно для монолита: отказом от постоянной согласованности данных. Добро пожаловать в мир Eventual consistency. На первых порах это вызывает волну «справедливого» гнева. Но если разобраться, то нужна ли повсеместно немедленная согласованность данных по окончании транзакции? При детальном рассмотрении значительную часть случаев можно отбросить. Где возможно, заменяют одну распределённую транзакцию серией локальных с компенсационными механизмами. Где-то мирятся с временной несогласованностью. А возможные ошибки либо обрабатывают за счет более сложной архитектуры, либо благодаря данным мониторинга. Если ничего не получается, то в особо экстремальных случаях всё же используют распределенные транзакции. Но это, с моей точки зрения, нарушение принципов MSA.
Монолит против микросервисов
Микросервисный подход несет довольно много проблем. Их найти не трудно и каждый может поупражняться.
Например, организационные вопросы. Как удержать в согласованном по версиям состоянии сотню микросервисов, которые еще и постоянно и непредсказуемо редеплоятся. А доступ к средам у каждого инженера каждой команды? Какая команда напишет интеграционные тесты? И если кто-то согласится, то попробуй еще их напиши для такой запутанной конфигурации. А если возникает ошибка, то чья она? Только той команды, у которой сломалось? Как не узнать вечером в пятницу, что версия API N-го сервиса, которой вы пользуетесь, вдруг стала deprecated?
Да, это действительно проблемы. Но команды, которые практикуют Agile и DevOps, уже знают решение. Поэтому начинать путь к микросервисной архитектуре стоит с внедрения этих практик.
Кроме организационных есть и чисто архитектурные. Как перейти от монолита, где всё синхронно, согласованно и едино, к распределенной событийной архитектуры, основанной на множестве мелких элементов, в которой надо учитывать возможную неконсистентность данных? Одного этого достаточно, чтобы задуматься: а стоит ли игра свеч? На этом фоне, например, падение скорости обработки одного запроса кажется мелочью. Хотя бы работает!
Тогда зачем? Если у вас нет проблем с вашим «монолитом», то не надо их искать.
Но если проблемы есть, то посмотрите на плюсы MSA, и возможно она спасет вас.
Разбиение на независимые компоненты даёт безусловные и неоспоримые преимущества: легкое понимание контекста, гибкость развития, управления и масштабирования. Независимость и небольшой размер дают и неожиданные плюсы с точки зрения инфраструктуры. Вам теперь не нужна монструозная машина за 100500 долларов. Микросервисы можно устанавливать на обычные дешевые машинки. И окажется, что даже все вместе они будут стоить на порядок меньше, но работать эффективнее той самой супермашины, на которую у вас в организации, наверняка, молятся и сдувают с неё пылинки.
Здесь уместен другой лозунг от популиста. Хотя, как и предыдущий, он вполне серьезен.
Каждому микросервису по своему серверу!
Продолжим агитировать за микросервисы. Посмотрим на лидеров IT-индустрии: Amazon, Netflix, Google и другие показывают впечатляющие результаты. Их гибкость и скорость вывода новых продуктов поражают. Поэтому игра точно стоит свеч! Здесь уместно вспомнить, что в упомянутых организациях команд «уровня бог» не одна и не две. Им сложности микросервисной архитектуры вполне по зубам. И если предложить создать монолит, то они и его сделают так, что он будет сверкать путеводной звездой.
А, например, Amazon вполне себе работал на монолите, уже будучи гигантом и имея миллиардные обороты. Сайт газеты Guardian до сих пор, а возможно и навсегда, базируется на микросервисах вокруг монолита. Это говорит о том, что значительная часть задач успешно, а зачастую и легче, решается без привлечения микросервисов.
И всё же это не значит, что микросервисы не для вас. Не боги горшки обжигают. Но бросаться с головой в омут тоже не стоит. Для микросервисной архитектуры команда должна быть достаточно зрелой. Один из главных критериев: использует ли она Agile и DevOps? Команда должна быть грамотной. Это сложно формализовать, но всё же попробуйте трезво оценить возможности. Например, насколько команда продвинута в Reactive и Event-Driven Architecture? К тому же команда должна иметь подготовленную инфраструктуру для поддержки микросервисной системы.
Впрочем, достаточно. Просто попробуйте. Надеюсь, получится и понравится.
Микросервисы
Что такое микросервисы?
Микросервисы (или микросервисная архитектура) — это облачный подход, при котором единое приложение строится из множества слабосвязанных компонентов меньшего размера (так называемых сервисов), поддерживающих независимое развертывание. Как правило, эти сервисы:
Несмотря на то что обсуждения часто сводятся к определениям и характеристикам архитектуры, ценность микросервисов можно легко определить по следующим коммерческим и организационным преимуществам:
Чтобы лучше понять, что такое микросервисы, важно разобраться, чем они не являются. Чаще всего микросервисную архитектуру сравнивают с монолитной архитектурой и сервис-ориентированной архитектурой (SOA).
При использовании микросервисов приложение строится из множества слабосвязанных компонентов меньшего размера, в то время как в приложении с монолитной архитектурой все компоненты имеют сильные связи.
Более подробно об отличиях между микросервисами и монолитной архитектурой рассказывается в следующем видеоролике (6:37):
Отличия между микросервисами и SOA не столь очевидны. Разница между микросервисами и SOA существует как с технической точки зрения, особенно в отношении роли сервисной шины предприятия (ESB), так и с точки зрения охвата. SOA — инициатива в масштабах предприятия, направленная на стандартизацию взаимодействия и интеграцию всех веб-сервисов организации, в то время как микросервисная архитектура ориентирована на конкретное приложение.
Более подробная информация приведена в публикации «SOA и микросервисы: в чем отличия?».
Преимущества микросервисов для организации
Микросервисы могут быть востребованы не только среди разработчиков, но и среди руководителей и менеджеров проектов. Это одна из самых необычных особенностей микросервисной архитектуры, поскольку за выбор той или иной архитектуры обычно отвечают команды разработчиков программного обеспечения. Популярность микросервисов среди руководящего персонала объясняется тем, что данный подход в большей степени отражает их стремление структурировать процессы разработки и команды.
Другими словами, архитектурная модель на основе микросервисов облегчает реализацию требуемой операционной модели. Согласно недавнему опросу, проведенному IBM среди 1200 разработчиков и ИТ-руководителей, 87% пользователей микросервисов согласны с тем, что этот подход стоит того, чтобы инвестировать в него время и средства. Дополнительная информация о преимуществах и сложностях микросервисов представлена на следующем интерактивном изображении:
Вот лишь несколько примеров преимуществ микросервисов для предприятий.
Независимое развертывание
Одной из самых важных особенностей микросервисов, вероятно, является то, что для изменения одной строки кода или добавления новых функций в приложение не требуется получать множество разрешений, так как каждый компонент имеет небольшой размер и поддерживает независимое развертывание.
Микросервисы могут помочь справиться с глубоким чувством безысходности, когда даже незначительные изменения требуют огромных затрат времени. Не нужно обладать научной степенью в области компьютерных наук, чтобы понять преимущества подхода, обеспечивающего скорость и гибкость.
Однако у этого подхода к проектированию существует и ряд других преимуществ. Новая организационная модель направлена на объединение межфункциональных команд вокруг определенной бизнес-задачи, услуги или продукта. Модель микросервисов аккуратно вписывается в эту тенденцию, поскольку позволяет организациям собирать небольшие, межфункциональные команды вокруг одной услуги или набора услуг и обеспечивать их работу в соответствии с методологией Agile.
Кроме того, слабые связи между компонентами позволяют изолировать неполадки, повышая отказоустойчивость приложений. Небольшой размер сервисов в сочетании с четкими границами и паттернами взаимодействия упрощает понимание кода для новых участников команды и позволяет им быстрее приступить к работе, что дает очевидные преимущества с точки зрения скорости разработки и настроя в коллективе.
Оптимальный инструмент для работы
В традиционной многоуровневой архитектуре основой приложения обычно является общий стек и большая реляционная база данных. Такой подход имеет ряд очевидных недостатков, самым значимым из которых является совместное использование всеми компонентами приложения общего стека, модели данных и базы данных, даже если для отдельных элементов рациональнее было бы использовать другой, более понятный и эффективный инструмент. Так появляются плохие архитектуры, а у разработчиков опускаются руки из-за невозможности использовать более эффективные инструменты для создания отдельных компонентов.
В противоположность этому микросервисная архитектура поддерживает независимое развертывание компонентов и взаимодействие посредством определенной комбинации REST API, потоков событий и агентов сообщений. Это дает возможность оптимизировать стек для каждого отдельного сервиса. Технологии постоянно меняются, при этом модернизация приложений, состоящих из множества небольших сервисов, обходится намного дешевле и требует меньше усилий.
Точное масштабирование
С помощью микросервисов можно не только развертывать, но и масштабировать отдельные сервисы. Выгода очевидна: при правильной реализации для микросервисов требуется меньше ресурсов инфраструктуры, чем для монолитных приложений. Это достигается за счет точного масштабирования только необходимых компонентов, а не всего приложения.
Но есть и трудности
Обладая ощутимыми преимуществами, микросервисы также требуют решения сложных задач. Переход от монолитного приложения к микросервисам добавляет сложности к процессам управления вследствие роста количества сервисов, команд и сред развертывания. Проблемы с одним сервисом могут распространиться на другие сервисы. Для мониторинга и устранения неполадок необходимо регистрировать огромные объемы данных и согласовывать процессы ведения журналов на уровне сервисов. Появление новых версий может привести к проблемам совместимости с предыдущими версиями. Поскольку приложения используют больше сетевых соединений, появляется риск увеличения времени отклика и проблем связи. Принцип DevOps (как будет сказано ниже) позволяет решить многие из этих проблем, однако внедрение DevOps также сопряжено с определенными трудностями.
Тем не менее, ни одна из этих причин не останавливает энтузиастов от внедрения микросервисов или расширения их использования. Согласно данным нового опроса IBM, 56% организаций, не использующих микросервисы, с высокой или очень высокой вероятностью планируют внедрение микросервисов в ближайшие два года. При этом 78% организаций, которые уже используют микросервисы, планируют вкладывать больше времени, денег и усилий в развитие микросервисов (см. Рис. 1).
Рис. 1: Микросервисы — всерьез и надолго. В течение ближайших двух лет 56% организаций планируют внедрение микросервисов; 78% организаций, которые уже используют микросервисы, планируют вкладывать еще больше средств в развитие микросервисов; 59% всех приложений будут создаваться на основе микросервисов. (Источник: «Микросервисы на предприятии: реальные преимущества, превосходящие усилия», 2021 г.)
Микросервисы и DevOps нуждаются друг в друге
Говоря о микросервисной архитектуре, обычно упоминают, что она оптимизирована для DevOps и стратегии непрерывной интеграции и доставки (CI/CD), в контексте высокой частоты развертывания небольших сервисов.
Если же взглянуть на взаимосвязи между микросервисами и DevOps под другим углом, то на самом деле DevOps — необходимое условие для успешной реализации микросервисной архитектуры. Несмотря на отмеченные выше недостатки монолитных приложений, к их преимуществам относится отсутствие сложной распределенной системы с множеством динамичных компонентов и независимых стеков технологий. Учитывая же значительный рост сложности, динамичные компоненты и зависимости, характерные для микросервисов, было бы недальновидно обойти вниманием необходимость инвестиций в инструменты автоматизации развертывания, мониторинга и управления жизненным циклом.
Андреа Кроуфорд помогает детальнее разобраться с DevOps в следующем видеоролике:
Опорные технологии и инструменты
Несмотря на то что микросервисная архитектура поддерживает практически любой современный инструмент или язык, существует также ряд базовых инструментов, которые стали важнейшим определяющим элементом микросервисов:
Контейнеры, Docker и Kubernetes
Одной из ключевых идей микросервисов является их небольшой размер (стоит отметить, что число строк в «микросервисе» ничем не стандартизировано и приставка «микро» — всего лишь часть названия).
Появление Docker в 2013 году ознаменовало новую эру контейнеров и стало основой для вычислительной модели, которая наиболее близко связана с микросервисами. Отсутствие издержек, связанных с собственной операционной системой, позволяет сделать отдельные контейнеры меньше и проще по сравнению с традиционными виртуальными машинами. Благодаря ускоренному развертыванию контейнеры идеально отвечают требованиям микросервисной архитектуры.
В результате стремительного роста количества сервисов и контейнеров координация работы больших групп контейнеров быстро превратилась в одну из сложнейших проблем. Kubernetes, платформа координации контейнеров с открытым исходным кодом, позволила эффективно справиться с поставленными задачами, став одним из самых популярных решений в этой области.
В видеоролике «Kubernetes в деталях» Сай Веннам подробно рассказывает обо всех тонкостях Kubernetes:
Шлюзы API
Микросервисы часто взаимодействуют между собой посредством API, в особенно при первоначальной установке состояния. Несмотря на возможность непосредственного обмена данными между клиентами и сервисами, шлюзы API часто выполняют роль важного промежуточного уровня, особенно с увеличением количества сервисов в составе приложения. Шлюз API предоставляет обратный прокси для клиентов, обеспечивая маршрутизацию запросов, разветвление запросов по нескольким сервисам и дополнительные средства защиты и идентификации.
Для реализации шлюзов API можно использовать различные технологии, включая платформы управления API. Однако если микросервисная архитектура основана на контейнерах и Kubernetes, то в качестве шлюза обычно применяется Ingress или, с недавнего времени, Istio.
Обмен сообщениями и потоки событий
Хотя передовые методики рекомендуют проектировать сервисы без сохранения состояния, состояние все же существует, и сервисы должны определять его. Вызов API не очень подходит для обновления состояния, при том что он позволяет достаточно эффективно установить первоначальное состояние для определенного сервиса. Применять непрерывные опросы состояния сервисов нерационально.
Вместо этого необходимо объединить вызовы API для установки состояния с системой обмена сообщениям или потоками событий, чтобы сервисы могли транслировать изменения состояния, а другие компоненты отслеживать такие изменения и вносить необходимые коррективы. С этой задачей лучше всего справляется агент сообщений общего назначения, однако в некоторых случаях оптимальным выбором может оказаться платформа потоковой обработки событий, например Apache Kafka. Объединив микросервисы с архитектурой на основе событий, разработчики могут создавать легко масштабируемые, отказоустойчивые и расширяемые системы, способные принимать и обрабатывать очень большое количество событий или информации в режиме реального времени.
Бессерверные решения
Бессерверные архитектуры являются логическим завершением некоторых базовых паттернов облачных вычислений и микросервисов. При таком подходе единицей выполнения является не просто небольшой сервис, а функция, которая может состоять всего из нескольких строк кода. Граница между бессерверными функциями и микросервисами размыта, однако считается, что функции обычно имеют меньший размер, чем микросервисы.
Общим для бессерверных архитектур и платформ FaaS («функция как услуга») с одной стороны и микросервисов с другой стороны является выгода от создания более мелких единиц развертывания и точное масштабирование по запросу.
Микросервисы и облачные услуги
Микросервисы необязательно должны быть неразрывно связаны с облачными вычислениями, однако есть ряд важных причин для их совместного использования. И объясняется это не только тем, что микросервисы — популярный стиль архитектуры для новых приложений, а облако — популярный вариант размещения новых приложений.
К числу основных преимуществ микросервисной архитектуры относится оптимизация эффективности и затрат за счет развертывания и масштабирования отдельных компонентов. Эти преимущества в определенной степени доступны и в локальной инфраструктуре, однако, объединив небольшие, независимые компоненты с инфраструктурой на основе модели оплаты по факту использования, можно добиться существенного снижения расходов.
Во-вторых, и это главное, преимуществом микросервисов является то, что каждый отдельный компонент может использовать оптимальный стек для каждого конкретного задания. Широкое применение разных стеков может существенно увеличить сложность и накладные расходы на управление, однако реализация стека в виде облачных услуг позволяет кардинально минимизировать проблемы управления. Другими словами, развертывать собственную инфраструктуру микросервисов, особенно на начальных этапах проекта, не рекомендуется, хотя и не запрещено.
Базовые паттерны
Микросервисные архитектуры предлагают множество базовых и полезных паттернов проектирования, взаимодействия и интеграции, которые помогают решать распространенные проблемы и задачи, а именно:
Более подробная информация об этих паттернах приведена в статье «Применение паттернов разработки на основе микросервисов (часть 4)». На веб-сайте IBM Developer также можно найти много полезной информации о паттернах разработки с помощью микросервисов.
Антипаттерны
Наряду с паттернами правильного проектирования на основе микросервисов существует не менее важная группа антипаттернов, которые могут быстро привести команду разработчиков к негативному результату. Некоторые из запрещенных приемов работы с микросервисами приведены ниже:
Учебники: формирование навыков работы с микросервисами
Если вы готовы узнать больше об использовании микросервисов или хотите повысить свою квалификацию, просмотрите следующие учебники:
Микросервисы и IBM Cloud
Микросервисы обеспечивают разработку инновационных приложений со скоростью развития бизнеса. Узнайте, как реализовать преимущества масштабируемости и гибкости облачной среды с помощью независимых микросервисов. Узнайте, как модернизировать ваши приложения при содействии экспертов IBM.
Сделайте следующий шаг: