Советы

Лучшие практики микросервисов

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

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

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

Лучшие практики микросервисов

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

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

Из-за большого количества открытых API, портов и компонентов традиционные межсетевые экраны не могут обеспечивать адекватной безопасности для них. Эти проблемы делают развертывание микросервисов более уязвимым для различных киберугроз, таких как «man-in-middle», инъекционные атаки, межсайтовый скриптинг, DDoS.

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

  • Хотя защита микросервисов сложнее, чем монолитных приложений, человек может эффективно обезопасить себя, разработав хорошую стратегию и задействуя лучшие практики.
  • В идеале архитектура требует распределенного подхода, который должен охватывать различные компоненты.
  • Среди них можно выделить следующие пункты системы безопасности:
  • Защита приложений, микросервисов и пользователей;
  • Обеспечение безопасности идентификации и управления доступом;
  • Защита данных;
  • Повышение безопасности связи между службами;
  • Мониторинг микросервисов и систем безопасности.

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

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

Настала пора рассмотреть некоторые эффективные методы обеспечения безопасности микросервисов.

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

Глубокая защита (DiP) — это метод, при котором человек применяет несколько уровней безопасности в отношении своих сервисов и данных. Эта практика затрудняет проникновение злоумышленников в систему, создавая несколько слоев защиты и обеспечивая тем самым безопасность услуг и данных пользователя.

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

Лучшие практики микросервисов

При таком подходе необходимо сначала определить чувствительные зоны сервиса, после чего можно будет применить соответствующие уровни защиты (=создать определенные «стены безопасности» вокруг них).

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

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

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

Среди типичных инструментов сканирования изображений можно выделить Clair и Anchore,

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

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

При развертывании микросервисов большое количество приложений и служб потребует безопасной авторизации и контроля доступа. Платформы авторизации, такие как OAuth 2.

0 и OpenID, позволяют безопасно обрабатывать токены и, следовательно, защищать свои микросервисы.

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

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

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

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

Раскрытие микросервисов повышает уязвимость и риски для безопасности всей системы.

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

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

Шлюз API расположен между клиентскими приложениями и микросервисами.

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

Шлюз API координирует все внешние службы и микрослужбы, а также поддерживает многоуровневую защиту системы, соблюдая принципы безопасности.

Лучшие практики микросервисов

Среди типичных шлюзов API можно выделить NGINX, Kong, Tyk, Ambassador, AWS API gateway.

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

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

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

  • Ethernet API – интерфейсы для сервисов, открытых миру за пределами центра обработки данных;
  • Corporate Zone API – предназначен для внутреннего частного трафика;
  • DMZ API – предназначен для обработки трафика, идущего из Интернета;
  • Hybrid Zone API – предназначен для развертывания центров обработки данных.

Эффективная практика включает в себя аутентификацию и авторизацию запросов при взаимодействии двух микросервисов.

Как правило, существует три основных метода, которые можно использовать для обеспечения безопасности межуслугных коммуникаций. Это Trust the network, JSON Web Token (JWT) и Mutual Transport Layer Security (mTLS или Mutual TLS).

Лучшие практики микросервисов

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

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

Хотя протокол TLS обеспечивает целостность и конфиденциальность передаваемых данных, он также позволяет клиенту идентифицировать микросервис.

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

С другой стороны, mTLS предоставляет средства, с помощью которых каждый из микросервисов может идентифицировать другой.

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

Следует настроить свои службы на ограничение работы, если они обнаружат несколько неудачных попыток входа в API или любую другую подозрительную активность.

Лучшие практики микросервисов

Медленная система отпугнет злоумышленников, и, вероятно, они откажутся от попыток получить доступ к услугам. Человек может ограничить скорость с помощью шлюза API, через код или использовать любой другой метод. Обычно большинство сред SaaS имеют ограничение по скорости API, чтобы свести к минимуму злоупотребления со стороны пользователей, а также предотвратить возможные атаки.

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

Читайте также:  ТОП-9 стажировок для программиста в 2023 году

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

Двумя наиболее часто используемыми методами эффективной оркестровки микросервисов являются:

  • Кодирование оркестрации как микросервиса;
  • Использование шлюза IP.

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

Лучшие практики микросервисов

Среди типичных менеджеров оркестрации можно выделить Kubernetes, Istio, Azure Kubernetes Service (AKS).

Поскольку микросервисы основаны на распределенных системах, необходимо иметь надежную и эффективную стратегию мониторинга для всех отдельных компонентов.

Развертывание непрерывного мониторинга позволяет своевременно обнаруживать и устранять риски безопасности. Для этого существует широкий спектр решений по мониторингу микросервисов, в том числе Prometheus, Statsd, InfluxDB, Logstash.

Лучшие практики микросервисов

Мониторинг внутри архитектуры микросервисов

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

  • Ведение журналов на уровне приложения. Человек может использовать Splunk, Graphana, ELK stack и другие инструменты, которые создают журналы на уровне приложений, контейнеров, сетей и инфраструктуры;
  • Мониторинг метрики использования сети;
  • Контроль таких компонентов, как процессор, память, время отклика, ошибки, уведомления, чтобы обнаружить необычные действия, указывающие на существующую или потенциальную атаку;
  • Проверка журналов в таких областях, как входящие запросы клиентов, записи базы данных, контейнеры, чтобы выявить несоответствия или необычные действия пользователей.

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

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

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

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

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

Автор переведенной статьи: Аmos Kingatua.

Секреты разработки высокопроизводительных приложений и микросервисов

Лучшие практики микросервисов

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

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

Ниже представлены общие преимущества микросервисной архитектуры.

  • Незначительное взаимовлияние и высокая согласованность.
  • Поддержка горизонтального и вертикального масштабирования: их легко расширять и сокращать.
  • Диверсифицированный и современный стек технологий: каждый микросервис может быть реализован на разных языках программирования и развернут на разнородных серверах или в облаке.
  • Модульность и распределенность: это небольшие индивидуальные компоненты, организованные с учетом бизнес-возможностей.
  • Быстрый вывод на рынок: их разработка, тестирование и развертывание выполняются намного быстрее, чем при монолитном сервисе.
  • Простое развертывание, тестирование и обслуживание.

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

Поддержание общей производительности приложения становится первостепенной задачей по мере добавления микросервисов в приложение (или проект). Еще одна непростая задача  —  устранение сбоев в работе микросервисов.

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

Хорошая разработка  —  это привычка, а не разовая работа.

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

Вот некоторые методы, которых я придерживаюсь при написании и анализе кода.

  • Для разработки микросервиса выбирайте наиболее подходящую технологию и используйте рекомендованные методы.

Выберите стек технологий на основе функционального назначения и бизнес-функций/вариантов использования. У некоторых разработчиков формируются технологические предубеждения (эмоциональная привязанность) к любимому стеку технологий. Затем они пытаются разрабатывать на нем все микросервисы.

Например, сервисы на основе ИИ и МО можно создавать на Python или аналогичном языке. Если попытаться создать модели ИИ и МО на JAVA, их рабочая производительность может оказаться ниже ожидаемой.

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

  • Проектируйте микросервисы с использованием принципов SOLID.

Принципы проектирования SOLID являются основой для разработки хорошей и эффективной объектно-ориентированной программы или приложения. Я сторонник использования принципов SOLID при разработке микросервисов.

  • Разрабатывайте архитектуру микросервисов с целью повышения производительности и безопасности.

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

  • Обеспечьте обмен данными между микросервисами с помощью асинхронных (неблокируемых) запросов.

Синхронные запросы блокируются и могут вызывать проблемы с производительностью. Асинхронный обмен данными/информацией/сообщениями между двумя или более сервисами не требует от них немедленного ответа. Проще говоря, во время сеанса связи не требуется запуск и работа взаимодействующих сервисов.

Добиться этого можно с помощью очередей сообщений (Messaging queues) и опроса базы данных (Database polling). Kafka  —  одно из широко используемых решений для обмена данными между микросервисами внутри веб-сервиса.

  • Ограничивайте объем доступной памяти.

Размеры доступной памяти и основного кода микросервисов должны быть небольшими и с быстрым доступом. Микросервис должен решать конкретный сценарий использования и ничего более. Производительность в этом случае возрастает.

Хороший микросервис не должен раскрывать методы/функции, не связанные с ним напрямую (например, продажи и закупки).

Если мы интегрируемся с микросервисом для конкретного сценария использования, задействуя при этом менее 30-40% его функций, то, вероятно, это не вызов микросервиса. Это больше похоже на низкопроизводительные мини-монолитные сервисы.

  • Кэшируйте токены OAuth и Kerberos.

Создание токенов безопасности требует затрат времени и усилий. При вызове систем рекомендуется кэшировать токены OAuth и/или Kerberos, чтобы избежать частого обращения к генерирующему токены API. Я предпочитаю время кэширования от 60 до 180 минут, но это зависит от уровня безопасности, который нужно обеспечить в микросервисах.

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

  • Выбирайте подходящий тип/технологию базы данных.

Время отклика микросервисов напрямую зависит от источника данных и времени отклика основной базы данных. Выбор и моделирование базы данных очень важны. Архитектура микросервисов может включать реляционную базу данных (RDBMS), хранилище ключ-значение и/или неструктурированные данные (например, изображения, видео) и пр.

Для повышения производительности структурированные данные должны храниться в реляционных базах данных, а неструктурированные  —  в хранилищах NoSQL, например Mongo DB и Cassandra.

Тип базы данных (RDBMS, No-SQL, Object DB и др.) должен выбираться исходя из требований проекта. Не следует придерживаться принципа “одно решение на все случаи”.

Нужно кэшировать запросы и ответы на редко изменяемые (или справочные) значения в базе данных. Это уменьшит количество обращений к базе данных и предотвратит ее перегрузку. EHCache  —  сервис с открытым исходным кодом, который хорошо интегрируется с Hibernate, Spring и JPA.

Кроме того, нужно подобрать подходящую стратегию индексации/разделения в таблицах базы данных. Для соотношения размеров база данных/кэш я предпочитаю значения 80/20 или 70/30. Таким образом, хранение 20-30% извлекаемых данных повышает производительность.

  • Оптимизируйте вызовы/запросы к базе данных.

Избегайте извлечения из базы данных всей строки (кортежа). Предположим, API обращается к таблице базы данных и предоставляет 10 атрибутов, а таблица содержит 40 атрибутов (или более). Если выполнить запрос “Выбрать все” или “Выбрать * по id”, он вернет всю строку/кортеж.

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

  • Обеспечьте пул соединений с базой данных.

Поддержка DBCP (Database Connection Pool) позволяет сэкономить на издержках создания и закрытия соединений. Создание нового соединения по каждому запросу требует ресурсов и времени, а DBCP позволяет использовать одно и то же соединение с базой данных для нескольких запросов.

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

  • Используйте кластеризацию базы данных.

Кластеризация с балансировкой нагрузки позволяет базе данных быстрее реагировать на запросы. Для этого есть следующие способы.

1. Конфигурация Master-Slave, в которой подчиненные устройства доступны только для чтения и в конечном итоге согласованы.

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

2. Конфигурация Master-Master  —  она немного медленнее по сравнению с Master-Slave.

  • Настройте базу данных и выберите подходящую стратегию индексации и/или разделения.

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

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

  • Настройте кэширование на стороне сервера.

Правильная стратегия кэширования способствует повышению производительности. Я рекомендую кэшировать отклик микросервисов в зависимости от запроса и его параметров.

Редко изменяющиеся отклики (например, изображения, видео и детали элемента) можно кэшировать на основе входных параметров.

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

Memcachedи Redis —  хорошие примеры расположенных в памяти кэшей. В них ключ-значение хранится между приложением и базой данных.

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

Для видео (клипы, фильмы и пр.) хорошим решением является CDN.

  • Обеспечьте масштабирование.

Чтобы справиться с возросшей нагрузкой на микросервис применяют вертикальное (scaling up) и горизонтальное (scaling out) масштабирование.

Вертикальное масштабирование означает увеличение объема памяти одного сервиса. При этом требуется перезапуск микросервиса (приостановка работы). Такое масштабирование сильно зависит от доступности базовой системы хранения.

Горизонтальное масштабирование означает добавление нового узла для обслуживания запросов. Это можно сделать на одном или разных хост/облачных пулах.

Для одного пула распространенным сервисом является Auto-scaler, доступный у большинства облачных провайдеров.

Автоматическое масштабирование можно настроить на основе пропускной способности HTTP, использования памяти и т. д.

На различных хостах используется балансировщик нагрузки для распределения трафика между микросервисами, запущенными на нескольких узлах/облачных пулах. Это может быть Pure Geographic, Round Robin и более настраиваемый балансировщик.

  • Установите ограничители скорости.

Шлюз или ограничитель скорости API собственной разработки защищают API от перегрузки и повышают доступность микросервисов.

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

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

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

  • Читайте нас в Telegram, VK и Дзен
  • Перевод статьи Saurabh Gupta: Developing High-Performance Applications & Microservices

Лучшие практики микросервисов

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

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

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

https://www.youtube.com/watch?v=8ZenCHkZUwg\u0026pp=ygU40JvRg9GH0YjQuNC1INC_0YDQsNC60YLQuNC60Lgg0LzQuNC60YDQvtGB0LXRgNCy0LjRgdC-0LI%3D

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

Каждая услуга инкапсулирует определенную бизнес-возможность или область и может разрабатываться, развертываться и масштабироваться независимо.

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

Еще одним важным аспектом передового опыта микросервисов является использование подхода доменно-ориентированного проектирования (DDD).

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

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

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

Службы с отслеживанием состояния управляют состояниями пользователей и сеансами и, как правило, более ресурсоемки.

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

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

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

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

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

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

Еще одна передовая практика в архитектуре микросервисов — реализация эффективных механизмов обнаружения, регистрации и балансировки нагрузки сервисов.

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

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

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

Поддержание надежных методов обеспечения безопасности жизненно важно в архитектурах микросервисов.

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

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

Использование практик DevOps и конвейеров непрерывной интеграции и непрерывного развертывания (CI/CD) имеет решающее значение для автоматизации и оптимизации разработки, тестирования и развертывания приложений микросервисов. Это способствует развитию культуры сотрудничества, сводит к минимуму ручное вмешательство и обеспечивает быструю обратную связь, что приводит к ускорению доставки программного обеспечения и повышению качества приложений.

AppMaster, мощная платформа no-code для создания серверных, веб- и мобильных приложений, служит примером внедрения лучших практик микросервисов в процесс разработки приложений.

Визуально создавая модели данных, бизнес-логику и endpoints API, а также легко интегрируя их с внешними приложениями, AppMaster позволяет разработчикам с относительной легкостью создавать масштабируемые, надежные и поддерживаемые приложения микросервисов.

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

TypeScript и микросервисы: лучшие практики

TypeScript и микросервисы: лучшие практики

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

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

В этой статье мы рассмотрим лучшие практики использования TypeScript для создания микросервисов.

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

Практика №1 – Оптимизация связей между микросервисами

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

Вы можете использовать TypeScript для создания интерфейсов, определяющих контракты между микросервисами. Эти интерфейсы могут использоваться для описания взаимодействия и управления связями между сервисами.

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

Практика №2 – Использование TypeScript для разработки API

Одной из главных задач микросервисов является предоставление API для взаимодействия с другими сервисами и приложениями. TypeScript может быть использован для создания удобного и понятного API, который будет легко использовать другие сервисы и приложения. Кроме того, TypeScript позволяет создавать документированный код, что упрощает понимание API и сокращает время разработки.

Практика №3 – Использование TypeScript для тестирования микросервисов

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

Это увеличивает количество ошибок, обнаруживаемых на этапе тестирования.

Читайте также:  Инкапсуляция и наследование в Python на примерах: код и задачи

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

Вывод

Использование TypeScript при разработке микросервисов имеет множество преимуществ. Он упрощает управление связями между сервисами, создание API и тестирование.

Также использование TypeScript повышает качество программного кода и уменьшает количество ошибок на этапе разработки.

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

Лучшие практики построения бессерверных микросервисов — Сервер

Микросервис — забавное слово.

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

Даже если вы никогда не слышали эту фразу раньше, контекстные подсказки довольно просты. Это небольшой сервис. Но что значит «маленький»?

Маленький по размеру? Насколько большим должен быть сервис, чтобы его можно было назвать *средним*?

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

Что такое микросервис?

Проще говоря, микросервис — это независимо итерируемая часть программного обеспечения.

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

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

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

Как вы решаете, какой микросервис производит события, а какой их потребляет?

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

В классическом примере с «корзиной» у вас есть несколько микросервисов, каждый из которых несет свою ответственность.

Четыре микросервиса, составляющие приложение для корзины покупок

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

Лучшие практики бессерверного подхода

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

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

Репозитории

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

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

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

С другой стороны, наличие репозитория для каждого микросервиса имеет свои плюсы и минусы.

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

В случае с serverless я выбираю репозиторий для каждого микросервиса. Это позволяет четко определить, за что отвечает микросервис, и сохранить легкость и целенаправленность кода. Один из принципов проектирования AWS serverless — ничего не делить, и разделение микросервисов на отдельные репозитории позволяет легко избежать случайных действий.

Структура папок

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

При использовании бессерверных микросервисов структурируйте папки корневого уровня по типу ресурсов. Возьмите в качестве примера проект эталонной архитектуры Gopher Holes Unlimited.

Компоновка бессерверных микросервисов

Все функции лямбда содержатся в папке functions. Аналогично, рабочие процессы Step Function содержатся в папке workflows. Лямбда-слои содержатся в папке layers и так далее.

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

Возьмем в качестве примера приведенную выше папку для лямбда-функции get-gopher. Она содержит index.js, package.json и package-lock.json. Это означает, что каждая функция может иметь полностью изолированные зависимости, что позволяет вам уменьшить размер пакета Lambda, что в конечном итоге сокращает время холодного запуска.

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

Облачные ресурсы

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

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

Когда я только начинал, я подумал, что было бы неплохо разделить ключи KMS между всеми микросервисами, которые я развернул в аккаунте AWS. Я создал микросервис shared-resources и экспортировал значения из стека, которые я должен был использовать в других микросервисах.

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

Не делайте этого.

Заплатите дополнительные $1/месяц, чтобы иметь уникальный ключ KMS в ваших микросервисах. Безопасность всегда стоит того.

Когда дело доходит до определения ваших ресурсов, все должно быть объявлено как Infrastructure as Code (IaC). Это позволит вам последовательно развернуть один и тот же набор ресурсов в любом регионе в любом аккаунте.

Не существует лучшей практики в отношении типа IaC, который вы используете, будь то SAM, CDK, Terraform, Serverless Framework или Pulumi, если вы определили его каким-либо способом, который имеет смысл для вас, то это лучший способ. В будущем, возможно, нам даже не понадобится IaC!

Заключение

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

Как и все в программном обеспечении, существуют компромиссы в решениях, которые вы принимаете при реализации микросервисов.

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

Соблюдение организованности — один из ключей к долгосрочному успеху любого проекта.

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

Создавайте самодостаточные сервисы. Не создавайте стеки, для развертывания которых требуются ресурсы других сервисов. Однако вы можете (и должны!) создавать микросервисы, которые зависят от других сервисов для удовлетворения бизнес-процессов посредством свободной связи через вызовы API или события.

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

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

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

Счастливого кодинга!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *