микро серверная архитектура что это
Микросервисная архитектура: теория и практика
Представьте, вы создали компанию и заказали для неё сайт. Вы оказались неплохим бизнесменом: продажи растут, клиентов все больше, открываете новые филиалы. Приходится добавлять на сайт все новые и новые функции, чтобы удовлетворить запросы посетителей.
В какой-то момент объём кода вырос до полного собрания сочинений Толстого. Как следствие – обновления разрабатываются все дольше, а тестировать их все сложнее. Это стандартная проблема для сложного программного обеспечения. Решить проблему узких мест на проекте можно используя микросервисы: везде, где есть «тяжелые» процессы, теоретически их можно вынести в специальное окружение.
Простыми словами – вы берете тяжелый и неповоротливый процесс. Убираете его из приложения, и запускаете в отдельном контейнере, где он работает сам по себе. А потом обращаетесь к нему при необходимости.
Микросервис (или сервис, называют по-разному) может быть как большим, так и совсем маленьким – это не принципиально. Для каких-то языков программирования это реализуется проще, для других – сложнее.
Монолитный подход считается классическим и подразумевает, что вся работа приложения реализуется на одной кодовой базе. Так проще в разработке. Можно реализовывать необходимый функционал не задумываясь над проблемами коммуникации компонентов.
Приложения, построенные на монолитной архитектуре (или просто монолиты) – это не обязательно приложения с одной функцией. Они содержат отдельные классы и функции, однако те крепко связаны друг с другом. Изъятие одного модуля неизбежно вызывает изменения в работе всей системы. Отсюда – ряд значимых недостатков:
Сложности возникают и с командой проекта. Каждому участнику необходимо владеть экспертизой по всем бизнес-функциям, что со временем все труднее. Намного больше требуется времени и для добавления нового программиста в работу – ему потребуется изучить весь километровый код.
Распространение облачных сервисов к началу 2010-х годов привело к разочарованию разработчиков в классическом варианте архитектуры приложений. В качестве альтернативы предложили архитектуру микросервисов как распределенную систему простейших и легко заменяемых модулей. Они должны работать, как рабочие у конвейера: выполнять одну элементарную функцию и передавать задачу дальше. При этом микросервисы выстраиваются не иерархично, а симметрично.
Сервисы связываются между собой и с клиентами с использованием лёгких протоколов, например, HTTP. В результате создается простая для настройки система, которую проще регулярно обновлять. Ключевая идея микросервиса – независимость от окружающей среды и высокий уровень повторного использования.
Каждый отдельный сервис можно программировать на том языке, который будет удобен команде. Такая независимость позволяет делить разработку компонентов системы между самостоятельными командами. Пришедший в команду разработчик осваивает функциональные особенности только того микросервиса, с которым ему предстоит работать, а не изучает систему целиком.
Отказ одного сервиса не приводит к остановке системы в целом. Когда же ошибка исправлена, необходимое изменение можно развернуть только для соответствующего сервиса — вместо повторной настройки всего приложения. Правда, для этого на этапе проектирования требуется продумать связи между сервисами для достижения максимальной независимости друг от друга. В случае ошибки пользователи должны получать корректные оповещения о временной недоступности определенного сервиса без ущерба для всей системы.
Работать с микросервисами мы умеем уже очень давно. Году так в 2014 мы разрабатывали на Symfony логистический проект – расчет маршрутов доставки. Когда пользователь выбирает, например, доставку из Копенгагена в Токио, и ему предлагается несколько маршрутов по разным ценам.
Сначала маршруты рассчитывались откровенно долго: на поиск одного маршрута уходило от десяти до тридцать секунд, а маршрутов получалось несколько. Чтобы решить проблему, мы использовали одновременно несколько сервисов (демонов) расчета маршрута плюс сервер очередей.
Демон — компьютерная программа в UNIX-подобных системах, запускаемая самой системой и работающая в фоновом режиме без прямого взаимодействия с пользователем.
Пользователь выбирал город. Задача попадала на сервер очередей. Демоны забирали эту задачу и рассчитывали каждый свой маршрут. То, что в один поток рассчитывалось бы 5-10 минут, мы получали в среднем за 15 секунд за счет параллельного расчета. Для сегодняшних реалий это очень много, но на момент разработки проекта – это был прорыв.
Микросервисы удобно реализуются при разработке на фреймворках – мы любим Laravel, Symfony – тоже ок. А вот для сайтов на Битрикс – все не так просто. Интернет-магазин нашего постоянного клиента Ormatek работает именно на Битриксе. На начало 2021 года там было около 200 тысяч товарных предложений.
Товарное предложение (или SKU) – это вариант товара. Например, кровать модели Dario Classic. Чтобы её купить, надо выбрать размер, основание и вариант исполнения (цвет и материал обивки). Товарное предложение – это кровать, для которой уже выбраны все доступные параметры.
Может показаться странным, что у магазина матрасов и мебели такой объемный каталог. Но каждая кровать может быть представлена в десятке размеров. С десятком вариантов оснований. А еще в 40+ вариантах исполнения. Если всё это перемножить – получается 4000+ вариантов на одну кровать. Очень серьезно.
Такой объем каталога создавал две проблемы:
Мы вынесли поиск, фильтрацию, сортировки и импорт в микросервисы. Для этого внедрили поисковую систему Elasticsearch. При старой архитектуре (использовался штатный модуль поиска 1С-Битрикс) поиск занимал около 10 секунд, что для обычного пользователя слишком много.
При поиске на такой объемной базе товаров Битрикс генерирует очень тяжелые запросы, которые нельзя поменять. Такие запросы получаются, например, когда Битриксу надо сформировать страницу списка кроватей из 120 тысяч SKU. Или при фильтрации, когда по свойствам надо сформировать и вывести нужные карточки товаров. Помимо свойств товаров, запрос должен учитывать ещё и их изображения. Какую именно картинку для товара выводить, заказчик задает через отдельное свойство-флаг.
Да, сначала мы пытались оптимизировать битриксовый поиск. И даже довели его скорость до 8 секунд. Но уперлись в ограничения Битрикса. Начали думать в сторону кеширования, но в случае с фильтром кеширование бесполезно, так как каждую комбинацию и каждый параметр фильтрации (малейшее движение ползунка) кешировать нецелесообразно.
Итак, мы решили перенести сортировку и фильтры в Elasticsearch. Если очень примитивно и схематично, то вот что у нас происходит теперь:
В рамках оптимизации мы написали каждому параметру фильтрации/сортировки во всех разделах товаров свой запрос в Elastic. Суммарно, страницы списка товаров, в том числе кроватей, стали загружаться менее, чем за 3 секунды.
У нас есть собственный продукт, разработкой которого занимается отдельная команда – SingularityApp, планировщик дел и задач. Десктоп, iOS, Android и PWA-версия. Он состоит из множества различных решений для пользователей, которых становится все больше – новые фичи добавляются несколько раз в месяц.
Изначально мы реализовали для Singularity монолитную архитектуру. Но в какой-то момент, года так через полтора от начала разработки, это стало серьезным ограничением. Нам потребовалось значительно переработать один из логических блоков программного кода на сервере. Чтобы пользователи со старыми версиями приложения продолжали работать, для них нужно было сохранить старую серверную архитектуру, а для новых версий – использовать новую. Варианта было два: или разворачивать для них второй сервер, либо менять архитектуру.
Вариант со вторым, дублирующим, сервером мы сразу (почти) отбросили – были риски дублирования пользовательских данных. Например, расписание у пользователя могло выдать два раза одну и ту же задачу.
Мы начали переводить SingularityApp на микросервисную архитектуру. Разбили функционал приложения на блоки, которые вынесли в отдельные сервисы. Да, так немного сложнее, так как для каждого сервиса нужен интерфейс, по которому с ним можно взаимодействовать. Но это позволило увеличить скорость разработки, так как теперь каждый сервис может делать отдельная команда и его можно тестировать изолированно. А значит, мы можем разрабатывать фичи параллельно.
Заодно решили проблему «узких мест» – часто выполняемых участков кода, которые своей производительностью ограничивали работу всей системы в целом. Весь функционал, который требует много ресурсов, например поиск или оптическое распознавание (OCR), мы также вынесли в отдельные сервисы, работающие в изолированной среде. Чтобы они не отбирали ресурсы у остальных частей проекта.
Появилась возможность гибко управлять серверными ресурсами, на которых работает проект. Для критичных сервисов всегда можно выделить отдельный сервер. Если функционал не очень важен и не хочется позволять ему сильно много – пожалуйста. Можно дать ему, скажем, один процессор и полмегабайта памяти и сказать: «Крутись, как можешь». При монолитной архитектуре ограничить по ресурсам какую-то функциональность проекта было нельзя – там работает принцип «кто первый встал – того и тапки.
Кроме отдельных физических серверов для выделения ресурсов под отдельные сервисы может использоваться специальное программное обеспечение, так называемые докеры.
Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации, контейнеризатор приложений.
По сути докер – это виртуальный сервер. Можно создать в рамках одного физического сервера (компьютера) много виртуальных серверов и разделить ресурсы между ними так, как надо нам. А потом разместить микросервисы в докерах, чтобы они не толкались и не дрались друг с другом за ресурсы.
В качестве бонуса – в каждом докере можно использовать свое программное обеспечение. Например, у нас есть сервер разработки – dev. Там докеры используются, в том числе, для сайтов с разными версиями PHP, чтобы ничего не конфликтовало.
Еще добавилась такая такая штука, как балансировщик нагрузки (мы используем Docker Swarm). Это, по сути, система-оркестратор, которая позволяет управлять всем зоопарком микросервисов и гибко перераспределять ресурсы между ними.
Теперь мы при необходимости можем запускать на сервере несколько экземпляров одного сервиса (если это потребуется для распределения нагрузки), а низконагруженные сервисы оставлять по одному. Даже можем поднимать на нескольких серверах разные сервисы. А балансировщик нагрузки позволяет это делать практически без вмешательства человека.
Кстати, использование микросервисной архитектуры позволяет повысить отказоустойчивость. Вы, наверное, слышали о масштабных авариях в дата-центрах в последний год. Когда данные на серверах десятков тысяч их клиентов безвозвратно утрачивались? Естественно, нам захотелось (и мы сделали), чтобы даже если дата-центр сгорит, приложение продолжало работать – просто плавно переключилось на резервную копию.
Все было готово. Но у нас были пользователи в SingularityApp. Огорчать и терять их было нельзя. Надо было перевести их на новую архитектуру так, чтобы они ничего не заметили, кроме того, что все стало работать лучше и быстрее.
Сначала мы оставили одновременно два сервера SingularityApp: новые устройства пользователей автоматически заходили на микросервисный сервер, а старые – на монолитный. Никакой практической разницы для пользователей не было, приложение на обоих серверах работало одинаково.
Постепенно пользователи обновляли свои приложения и автоматически перетекали на новый сервер. В начале 2021 года последний из них незаметно для себя перестал пользоваться монолитом. Сейчас монолитный сервер отключен.
P.S. Все уже с ними поигрались, споткнулись десятки раз и снова возвращаются к монолитам там где надо, а не как раньше лендинг на 100 сервисов (утрирую).
P.S. видимо люди на VC пишут, когда для хабра слишком глупы
P.S. писал статью видимо менеджмент, который не шарит, что юзеры смотрят на UI, а не на сервер и его архитектуру
Позвольте полюбопытствовать, а по сравнению с какими протоколами Http вдруг стал «лёгким»?
Сервисы связываются между собой и с клиентами с использованием лёгких протоколов, например, HTTP. В результате.
Каждый сервис тратит процессорное время на кодирование-декодирование данных. Это вроде бы мизер в рамках одного сервисе, но когда их становится слишком много.
есть MySQL (база данных сайта), в нём по прежнему хранятся SKU,
есть Elasticsearch, в него мы тоже поместили все SKU, когда нам нужны определенные SKU с определенными свойствами, мы эти параметры передаем в Elasticsearch и за 0,5 сек. получаем не сами SKU, а список их id-шников. Эти id мы отдаем в MySQL и говорим: «Выведи их на страницу».
Я не спорю, что микросервисы где-то и в чем-то хороши, но это не абсолютно. Честно говоря, я как-то затруднюсь себе представить более-менее крупную 100% монолитную систему. Это вообще как? Одна программа, которая делает все-все-все? Такое вообще бывает?
Это микросервисы? Если да, то «изобрели» их очень давно. Еще во времена System/36..38 и всяких разных ЕС ЭВМ и БЭСМ. Если нет, то что это? Уж точно не монолит.
Микросервисы
Что такое микросервисы?
Микросервисы (или микросервисная архитектура) — это облачный подход, при котором единое приложение строится из множества слабосвязанных компонентов меньшего размера (так называемых сервисов), поддерживающих независимое развертывание. Как правило, эти сервисы:
Несмотря на то что обсуждения часто сводятся к определениям и характеристикам архитектуры, ценность микросервисов можно легко определить по следующим коммерческим и организационным преимуществам:
Чтобы лучше понять, что такое микросервисы, важно разобраться, чем они не являются. Чаще всего микросервисную архитектуру сравнивают с монолитной архитектурой и сервис-ориентированной архитектурой (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.
Сделайте следующий шаг: