Разделение хранилища данных, каналов связи и т. Д.
Если вы не разрабатывали программное обеспечение в пещере, вы наверняка слышали, как люди восхваляют микросервисы. Они гибкие, простые и в целом улучшились по сравнению с временами монолитной и сервис-ориентированной архитектуры. Но, конечно же, со всеми преимуществами микросервисов возникает новый набор проблем.
В этой статье мы рассмотрим некоторые передовые методы работы с микросервисами. Кроме того, мы предложим несколько проверенных способов помочь вам разработать, организовать и защитить архитектуру микросервисов. Поняв эти методы, вы получите фору для успешного проекта.
Преимущества и проблемы микросервисов
Однако прежде чем мы углубимся в передовые практики микросервисов, мы должны сначала поговорить о некоторых преимуществах и проблемах микросервисов и о том, почему вы хотели бы их использовать в первую очередь.
Вкратце, микросервисы - это улучшенная программная архитектура, которая позволяет:
- Развертывайте и масштабируйте быстрее. Меньшая ответственность за домен приложения позволяет автоматизировать, что приводит к более быстрому развертыванию и более быстрому масштабированию.
- Сократите время простоя. Ограничьте влияние одной недоступной службы на вашу основную бизнес-функцию, улучшив общее время безотказной работы вашего бизнеса.
- Обеспечьте доступность. Сохраняйте функциональность между микросервисами дискретными, ограничивая влияние при выходе из строя экземпляра.
Конечно, с этими преимуществами у нас есть новый набор проблем, включая межсервисную связь, безопасность и масштабируемость.
- Связь между службами. В монолитном приложении все модули могут взаимодействовать друг с другом. У вас есть один сертификат для управления, и после проверки подлинности и авторизации запроса он может без проблем проходить пути кода. Когда вы извлекаете функцию из монолитной архитектуры в приложение микросервисов, то, что когда-то было внутренним вызовом функции, становится внешним вызовом API, требующим аутентификации и авторизации для этого внешнего микросервиса.
- Уровень безопасности. Аутентификация и авторизация в монолитном приложении могут выполняться один раз в точке входа. С переходом на микросервисы каждый микросервис должен выполнить некоторую аутентификацию и авторизацию для обеспечения контроля доступа. Нереально просить пользователей входить в систему каждый раз, когда они используют другой микросервис, поэтому необходимо разработать комплексную стратегию аутентификации.
- Масштабируемость. Хотя микросервисы позволяют быстро масштабировать независимую функциональность, для этого требуется хорошее управление приложениями и даже лучшие инструменты. Эффективность вашей масштабируемости зависит от вашей микросервисной платформы оркестровки, о которой мы поговорим более подробно ниже.
Сделав краткий обзор преимуществ и проблем микросервисов, давайте теперь рассмотрим некоторые передовые практики. Эти передовые методы помогут вам создать надежную, простую в управлении, масштабируемую и безопасную систему взаимосвязанных микросервисов.
1. Малый домен приложения
Принятие стратегии микросервисов требует принятия принципа единой ответственности. Ограничивая объем ответственности для любой отдельной услуги, мы ограничиваем негативное влияние сбоя этой услуги. Если один микросервис отвечает за слишком многое, его отказ или недоступность окажут эффект домино на остальную систему.
Служба micro должна быть именно такой: micro. Сохраняйте небольшой размер домена приложения ваших микросервисов, предназначенный для одной логической функции. Это снизит влияние данного микросервиса в случае возникновения каких-либо проблем. Кроме того, небольшие сервисы проще обслуживать. Результат - более легкое обновление и более быстрая разработка.
Как это выглядит на практике? Например, предположим, что наш микросервис - это сервер API, который принимает запросы на выборку данных, и токен авторизации должен сопровождать эти запросы. Когда вы только начинаете, это единственный микросервис, для которого требуется токен авторизации. Почему бы просто не сделать аутентификацию и генерацию токенов частью микросервиса? На первый взгляд преимущество - меньше движущихся частей, меньше нужно управлять.
Конечно, наступит день, когда у вас появятся другие службы, требующие токена авторизации. Скоро вы обнаружите, что исходный микросервис работает как сервер API и сервер аутентификации. Если ваш сервер API выходит из строя, то и ваш сервер аутентификации выходит из строя. При этом то же самое относится и к любой другой службе, для которой требуется токен авторизации.
Будьте внимательны к своему будущему: держите микросервисы небольшими.
2. Разделение хранилища данных
Несколько микросервисов, подключенных к одной базе данных, по сути, по-прежнему представляют собой монолитную архитектуру. Монолит находится на уровне базы данных, а не на уровне приложения, что делает его столь же хрупким. Каждый микросервис должен иметь, насколько это возможно, свой собственный уровень сохранения данных. Это не только обеспечивает изоляцию от других микросервисов, но также минимизирует радиус взрыва, если этот конкретный набор данных станет недоступным.
Иногда может показаться, что для разных микросервисов имеет смысл обращаться к данным в одной и той же базе данных. Однако более глубокое изучение может выявить, что один микросервис работает только с подмножеством таблиц базы данных, а другой микросервис работает только с совершенно другим подмножеством таблиц. Если два подмножества данных полностью ортогональны, это будет хорошим случаем для разделения базы данных на отдельные службы. Таким образом, отдельная служба зависит от ее выделенного хранилища данных, и отказ этого хранилища данных не повлияет на работу какой-либо другой службы, кроме этой.
Мы могли бы сделать аналогичный аргумент в отношении файловых хранилищ. При внедрении архитектуры микросервисов не требуется, чтобы отдельные микросервисы использовали одну и ту же службу хранения файлов. Если нет фактического перекрытия файлов, отдельные микросервисы должны иметь отдельные хранилища файлов.
Благодаря такому разделению данных увеличивается гибкость. Например, предположим, что у нас есть два микросервиса, оба используют одну и ту же службу хранения файлов с поставщиком облачных услуг. Один микросервис регулярно затрагивает множество ресурсов, но имеет небольшой размер файла. Другой микросервис имеет лишь несколько файлов, к которым он периодически обращается, но эти файлы имеют размер в сотни гигабайт.
Использование общей службы хранилища файлов для обоих микросервисов снижает гибкость в оптимизации затрат, поскольку у вас есть как большие, так и маленькие файлы, а также регулярный и периодический доступ. Если бы у каждого микросервиса был свой собственный уровень сохранения данных - и это, конечно, мог бы быть отдельный микросервис - тогда у вас было бы больше гибкости, чтобы найти поставщика или услугу, которая наилучшим образом соответствует потребностям этого отдельного микросервиса.
Оптимизация затрат, гибкость опций и меньшая зависимость от одного решения, которое может выйти из строя - все это причины для разделения данных разных микросервисов.
3. Каналы связи
То, как микросервисы взаимодействуют друг с другом, в частности, в отношении интересующих событий, требует вдумчивого рассмотрения. В противном случае одна недоступная служба может привести к сбою связи, что приведет к разрушению всего приложения.
Представьте себе систему микросервисов для интернет-магазина. Один микросервис принимает заказы, размещенные на сайте. Другой микросервис отправляет клиенту текстовое уведомление о том, что он получил свой заказ. Другой микросервис уведомляет склад об отправке товара. Наконец, другой микросервис обновляет счетчики инвентаря.
Между микросервисами существует два типа связи: синхронный и асинхронный. Если мы подойдем к приведенному выше примеру с использованием синхронной связи, веб-сервер может обработать новый заказ, сначала отправив запрос в службу уведомления клиентов. После того, как служба уведомления клиентов отвечает, веб-сервер отправляет запрос в службу уведомлений склада и снова ожидает ответа. Наконец, веб-сервер отправляет запрос средству обновления инвентаризации. Наш синхронный подход будет выглядеть так:
Конечно, предположим, что служба уведомления клиентов не работает. В этом случае запрос на уведомление клиента может истечь по таймауту, вернуть ошибку или, возможно, оставить веб-сервер в ожидании ответа на неопределенное время. Служба складских уведомлений может никогда не получить запрос на выполнение отгрузки. Синхронная связь между микросервисами может создать цепочку зависимостей, которая разрывается, если разрывается какое-либо звено в цепочке.
При асинхронной связи служба отправляет запрос и продолжает свою жизнь, не дожидаясь ответа. В одном из возможных асинхронных подходов веб-сервер может отправить запрос «уведомить клиента», а затем выполнить свою задачу. Служба уведомления клиентов отвечает за уведомление клиента и отправку асинхронного запроса в службу уведомления склада, которая отвечает за отправку запроса в службу обновления инвентаризации. Это могло бы выглядеть так:
В этой модели, конечно, мы видим, что асинхронная связь по-прежнему может приводить к цепной зависимости, и отказ одной службы все равно нарушит работу приложения.
Простой, но эффективный подход к асинхронному обмену данными - использовать шаблон публикации / подписки. Когда происходит интересующее событие, производитель - в данном случае микросервис - публикует запись об этом событии в службе очереди сообщений. Любые другие микросервисы, заинтересованные в этом типе события, подписываются на службу очереди сообщений как потребители этого события. Микросервисы разговаривают и слушают только службу очереди сообщений, но не друг друга.
В нашем примере это может выглядеть так:
Очередь сообщений - это отдельная служба, не связанная со всеми микросервисами. Он отвечает за получение опубликованных событий и уведомление подписчиков об этих событиях. Это гарантирует, что отказ одного микросервиса, который может означать задержку доставки сообщения, окажет минимальное влияние на другие связанные, но не связанные с ним службы.
Существует множество инструментов для выполнения такого рода асинхронной связи (например, Kafka или RabbitMQ). Ищите способы интеграции подобных инструментов в качестве магистральных асинхронных коммуникаций для ваших микросервисов.
Бывают случаи, когда необходима синхронная связь между микросервисами. Большинство взаимодействий между запросами и ответами по необходимости являются синхронными. Например, сервер API, запрашивающий базу данных, должен дождаться ответа на запрос; веб-сервер, получающий кэшированные данные, должен дождаться ответа хранилища "ключ-значение".
Когда требуется синхронная связь, вы захотите использовать Kong Gateway с открытым исходным кодом, чтобы обеспечить быструю и надежную маршрутизацию вашей коммуникации к нужным микросервисам.
4. Совместимость
В максимально возможной степени поддерживайте обратную совместимость, чтобы ваши потребители не столкнулись с неисправными API. Популярный способ сделать это - следовать гарантиям совместимости на уровне пути, например /api/v1 или /api/v2. Любые обратно несовместимые изменения попадают в новый путь, например /api/v3.
Однако, несмотря на все наши усилия как инженеров-программистов, иногда нам нужно отказаться от API-интерфейсов, чтобы мы не застревали в их использовании навсегда. С помощью плагина Преобразование запросов шлюза API ваши микросервисы могут предупреждать потребителей API, легко вводя уведомления об устаревании вместе с исходным ответом API или прикрепляя заголовок устаревания, аналогичный Kubernetes.
5. Управление микросервисами
Оркестровка ваших микросервисов - ключевой фактор успеха как в процессах, так и в инструментах. Технически вы можете использовать что-то вроде systemd и Docker или podman для запуска контейнеров на виртуальной машине, но это не обеспечивает такого же уровня отказоустойчивости, как платформа оркестровки контейнеров. Это отрицательно сказывается на преимуществах времени безотказной работы и доступности, связанных с внедрением архитектуры микросервисов. Для эффективной оркестровки микросервисов вам понадобится проверенная в боевых условиях платформа оркестровки контейнеров; и явным лидером в этой области является Kubernetes.
Kubernetes управляет подготовкой и развертыванием всех ваших контейнеров, решая вопросы балансировки нагрузки, масштабирования, наборов реплик для обеспечения высокой доступности и сетевого взаимодействия.
Вы можете развернуть чистый Kubernetes локально или использовать облачный дистрибутив, такой как Azure Kubernetes Service, Red Hat OpenShift или Amazon Elastic Kubernetes Service. Встроенные в Kubernetes возможности планирования, репликации и работы в сети делают оркестровку микросервисов намного проще, чем в традиционной операционной системе.
Соедините Kubernetes с сервисной сеткой Kuma и Kong Ingress Controller, и вы получите микросервисы, которые обнаруживаются, отслеживаются и устойчивы - как по волшебству.
6. Безопасность микросервисов
Поскольку ваше приложение включает в себя все больше и больше микросервисов, обеспечение надлежащей безопасности может стать сложной задачей. Централизованная система для обеспечения соблюдения политик безопасности жизненно важна для защиты вашего приложения от злонамеренных пользователей, инвазивных ботов и ошибочного кода. Kong должен стать началом вашей истории безопасности с помощью микросервисов, независимо от того, работаете ли вы на виртуальных машинах или в Kubernetes. Обилие поддерживаемых Kong плагинов безопасности позволяет легко удовлетворить некоторые из наиболее распространенных потребностей микросервисов, включая аутентификацию, авторизацию, управление трафиком и ограничение скорости.
Пример: ограничение скорости с помощью Kong Ingress Controller
Чтобы продемонстрировать пример работы плагина безопасности, мы развернем плагин Kong Ограничение скорости, чтобы показать, как Kong может предотвратить чрезмерные входящие запросы к вашим приложениям. Мы создадим локальный кластер Kubernetes с kind, а затем развернем Kong Ingress Controller, следуя этим инструкциям.
После создания кластера и развертывания Kong Ingress Controller нашим первым шагом является установка плагина ограничения скорости. Есть разные области, для которых вы можете настроить плагин. Мы будем использовать проект по умолчанию в нашем кластере Kubernetes для нашего варианта использования и ограничить плагин этим пространством имен по умолчанию.
$ echo ‘apiVersion: configuration.konghq.com/v1 kind: KongPlugin metadata: name: rate-limiting-example namespace: default config: second: 5 hour: 10000 policy: local plugin: rate-limiting’ | kubectl apply -f - kongplugin.configuration.konghq.com/rate-limiting-example created
Теперь мы создадим эхо-сервис и вход для сервиса. В данном случае мы заимствуем пример из документации Kong Начало работы с Kubernetes Ingress Controller:
$ kubectl apply -f https://bit.ly/echo-service service/echo created deployment.apps/echo created $ echo “ apiVersion: extensions/v1beta1 kind: Ingress metadata: name: demo annotations: kubernetes.io/ingress.class: kong konghq.com/plugins: rate-limiting-example spec: rules: — http: paths: — path: /foo backend: serviceName: echo servicePort: 80 “ | kubectl apply -f -
Последнее, что нам нужно сделать, это протестировать! Мы возьмем shell-demo из документации Kubernetes для тестирования в кластере:
$ kubectl apply -f https://k8s.io/examples/application/shell-demo.yaml -n default
Прежде чем перейти к нашему модулю оболочки, нам понадобится кластерный IP-адрес kong-proxy:
$ kubectl get svc/kong-proxy -n kong -o jsonpath=’{.spec.clusterIP}’
10.96.74.69
Теперь мы можем получить доступ к оболочке нашего модуля и протестировать ограничение скорости:
$ kubectl exec — stdin — tty shell-demo — /bin/bash # curl -I 10.96.74.69/foo HTTP/1.1 200 OK Content-Type: text/plain; charset=UTF-8 Connection: keep-alive X-RateLimit-Limit-Second: 5 X-RateLimit-Remaining-Hour: 9998 X-RateLimit-Limit-Hour: 10000 RateLimit-Reset: 1 RateLimit-Remaining: 4 RateLimit-Limit: 5 X-RateLimit-Remaining-Second: 4 Date: Sat, 24 Jul 2021 20:01:35 GMT Server: echoserver X-Kong-Upstream-Latency: 0 X-Kong-Proxy-Latency: 0 Via: kong/2.4.1
Дополнительный этап использования промежуточного модуля для тестирования ограничения скорости не потребуется для большинства облачных провайдеров, что дает вам балансировщик нагрузки «из коробки». В этом случае, поскольку мы используем вид, балансировщик нагрузки не подготовлен, поэтому наш тест проводится внутри кластера. Этот же тест работал бы внешне, если бы был доступен балансировщик нагрузки.
Ограничение скорости - лишь один из примеров того, как Kong вписывается в проблемы безопасности вашей общей стратегии и передовых методов работы с микросервисами, но может легко предоставить полностью комплексное решение. Kong поддерживает несколько подключаемых модулей и продуктов, которые обеспечивают надежную защиту ваших каналов связи, минимизируют влияние изменений API и позволяют управлять доменами приложений. Кроме того, он совместим с большинством языков программирования и опциями поставщиков.
7. Метрики и мониторинг
Архитектура, построенная на микросервисах, может привести к массовому масштабированию сотен или тысяч небольших модульных сервисов. Хотя это дает огромный потенциал для увеличения скорости, доступности и охвата, разрастающаяся система микросервисов требует стратегического и систематического подхода к мониторингу. Следя за всеми своими микросервисами, вы убедитесь, что они работают должным образом, доступны для ваших пользователей и используют ресурсы надлежащим образом. Если какое-либо из этих ожиданий не оправдывается, вы можете отреагировать, приняв соответствующие меры.
К счастью, вам не нужно изобретать велосипед, когда дело касается мониторинга. Существует несколько широко распространенных решений для мониторинга, которые можно легко интегрировать в вашу инфраструктуру. В некоторых решениях используются SDK экспортера метрик, которые можно интегрировать, добавив одну или две строки кода в микросервис. Другие могут быть интегрированы с вашим API-шлюзом или сервисной сеткой в качестве плагина для мониторинга сетевых проблем и использования ресурсов.
Когда ваши инструменты мониторинга собирают метрики, эти метрики могут использоваться инструментами визуализации - красивыми панелями мониторинга, которые помогут вам увидеть цифры, стоящие за вашими микросервисами. Сколько пользователей были онлайн в прошлый четверг в 20:00? Насколько увеличилась загрузка процессора с тех пор, как мы выпустили эту новую функцию? Какова задержка между API доставки нашего продукта и API выставления счетов?
Наблюдая за своими микросервисами и четко представляя свои точные цифры, вы можете принимать обоснованные решения о том, как поддерживать работоспособность и доступность своих микросервисов. Поступая так, вы сделаете своих пользователей счастливыми.
Не забывай свой гриф на коленях
Микросервисы - это дикая поездка! Вы начинаете с невероятных преимуществ более быстрого развертывания и масштабируемости, сокращения времени простоя и общего повышения доступности вашего бизнеса. Затем вы добавляете свою платформу оркестровки вместе с некоторыми передовыми практиками, основанными на Kong и его плагинах, и бум!
У вас есть симфония пакетов, передаваемых туда и сюда между вашими микросервисами, которые являются безопасными, надежными и пуленепробиваемыми. Мы рассмотрели лишь небольшую часть того, что может делать Kong, поэтому я настоятельно рекомендую заглянуть в Kong Hub, чтобы увидеть все доступные функции, облегчающие ваше путешествие в нирвану микросервисов!
