Почему микросервисная архитектура?
В настоящее время с развитием социальных сетей, быстрого интернета и т. Д. Тенденция к использованию приложений становится все больше и больше. В результате этих изменений поведения монолитным приложениям приходится иметь дело с огромным большинством изменений.
большинство предприятий сталкиваются с новой функцией, которую следует добавить в их приложения, с другой стороны, объем данных, которые должны быть обработаны, становится намного больше, и во многих случаях приложения становятся монолитными из-за их недостатков, таких как низкая скорость разработки, более медленное развертывание, поскольку едва ли поддерживает гибкую методологию, которая является основной идеей для борьбы с быстрыми изменениями в индустрии программного обеспечения.
Если вы хотите создать программный проект для большого или сложного бизнеса (это неверно о стартап-проектах или тех проектах, которые находятся на стадии финансирования, потому что они должны подчиняться ограничениям рынка), лучше начать с микросервисной архитектуры.
Таким образом, одним из решений для повышения гибкости, масштабируемости и многих других проблем приложения является использование гибкой архитектуры, такой как архитектура на основе микросервисов.
Зачем вам дорожная карта?
Насколько я понимаю, многие разработчики хотят знать, как им начать этот путь, очевидно, что есть тысячи ресурсов, которые можно использовать, но проблема в их рассредоточении. Я решил сделать это путешествие более понятным, составив дорожную карту для этой кривой обучения.
Как работает эта дорожная карта?
Архитектура на основе микросервисов состоит из нескольких отдельных модулей, которые работают вместе, чтобы получать и обрабатывать запросы из различных источников. Некоторые части этого комплекса могут быть сменными модулями, что означает, что в случае необходимости вы можете либо подключить новый модуль, либо отключить модуль, что не должно мешать общей работе приложения.
Например, если вы решили реализовать микросервисную архитектуру, вы должны быть знакомы с различными проблемами жизненного цикла приложения, такими как постоянство, ведение журнала, мониторинг, балансировка нагрузки, кеширование и т. Д., Кроме того, вы должны знать, какие инструменты или какие stack больше подходят для ваших приложений.
Что ж, это основной подход в моей статье, я объясню проблему, а затем представлю некоторые из лучших инструментов для удовлетворения потребностей.
Я объясняю каждую тему, чтобы получить ответы на эти вопросы:
1. Что это?
2. Зачем мне его использовать?
3. Какие инструменты лучше?
Обратите внимание, что я упомянул только два или три инструмента для части инструментов. Конечно, у нас так много других инструментов, что критерием выбора этих инструментов является популярность, производительность, наличие открытого исходного кода, а также частота обновлений.
Обратите внимание, что у нас также есть облачные сервисы, которые не рассматриваются в этой статье.
Я использовал приведенную выше диаграмму в качестве образца диаграммы архитектуры, потому что эта диаграмма включает в себя большинство компонентов архитектуры микросервисов, а также была признана стандартной моделью, конечно, я знаю, что эта диаграмма не очень исчерпывающая диаграмма, но я пробовал Чтобы сделать эту статью как можно более простой, возможно, в будущем я исправлю ее и напишу новую версию. Я думаю, что лучший способ объяснения каждой концепции всегда должен следовать образцу KISS.
В этой статье были объяснены следующие концепции:
- Докер
- Контейнерная оркестровка
- Управление контейнером Docker
- API-шлюз
- Балансировка нагрузки
- Обнаружение службы
- Автобус событий
- логирование
- Мониторинг и оповещение
- Распределенная трассировка
- Сохранение данных
- Кеширование
- Облачный провайдер
.: Докер:.
Какие
Docker - это платформа с открытым исходным кодом для контейнеризации ваших приложений с библиотеками и зависимостями, которые необходимы вашему приложению для работы в различных средах. С помощью Docker группы разработчиков могут упаковывать приложения в контейнеры.
Почему
Фактически, Docker - это один из инструментов для создания контейнеров приложений. Это означает, что вы также можете создавать контейнеры без использования Docker. Реальные преимущества Docker заключаются в том, чтобы сделать этот процесс проще, безопаснее и намного проще.
Инструменты
Docker Inc
.: Контейнерная оркестровка:.
Какие
После того, как вы поместите свое приложение в контейнер, вам потребуются некоторые инструменты для управления контейнерными приложениями для выполнения некоторых ручных и автоматических операций, таких как горизонтальное масштабирование.
Почему
Эти инструменты предоставляют некоторые услуги для управления вашим приложением, такие как автоматическая балансировка нагрузки, гарантируя высокую доступность услуг. Этот вид службы выполняется путем определения нескольких узлов-диспетчеров, и в случае сбоя в одном диспетчере узлов другие диспетчеры могут поддерживать доступность служб приложений.
Инструменты
Kubernetes или K8s, Docker Swarm
.: Управление контейнерами Docker:.
Какие
Управление средой Docker, управление конфигурацией, обеспечение безопасности среды и т. д. Эти проблемы можно централизовать и автоматизировать с помощью инструмента управления контейнером Docker.
Почему
Инструмент управления контейнером Docker предоставляет пользователям инструмент на основе графического интерфейса пользователя, и им не нужно иметь дело с интерфейсом командной строки, что неудобно для всех пользователей. Эти инструменты предоставляют разработчикам богатый пользовательский интерфейс для создания и публикации своих изображений, а также значительно упрощают выполнение некоторых рабочих задач, таких как горизонтальное масштабирование сервисов, за счет упрощенного пользовательского интерфейса.
Инструменты
Portainer, DockStation, Kitematic, Rancher
.: API-шлюз:.
Какие
Шлюз API можно рассматривать как инструмент управления API, который работает как промежуточное программное обеспечение между службами вашего приложения и различными клиентами. Шлюз API может управлять многими вещами, такими как:
Маршрутизация: шлюз получает все запросы API и перенаправляет их в целевые службы.
Ведение журнала: вы сможете регистрировать все запросы в одном месте.
Авторизация: проверьте, имеете ли вы как пользователь право на доступ к сервису, в противном случае запрос может быть прерван
Профилирование производительности: вы можете оценить время выполнения каждого запроса и проверить узкие места в вашем приложении.
Кеширование: управление кешированием на уровне шлюза позволит устранить такой объем трафика на своих сервисах.
Фактически, он работает как обратный прокси-сервер, и клиентам просто нужно знать о вашем шлюзе, а службы приложений могут быть скрыты извне.
Почему
Без шлюза API вам может потребоваться выполнить некоторые сквозные задачи для каждой службы, например, если вы хотите регистрировать запрос и ответ для служб. Кроме того, если ваше приложение состоит из нескольких служб, ваш клиент должен знать адрес каждой службы, а в случае изменения адреса службы необходимо обновить несколько мест.
Инструменты
Конг, Оцелот
.: Балансировка нагрузки :.
Какие
Одной из наиболее важных причин, по которой мы выбрали архитектуру микросервисов, является масштабируемость. Это означает, что мы сможем обрабатывать больше запросов, запустив больше экземпляров наших сервисов, но вопрос в том, какой экземпляр должен получать запросы или как это сделать. клиенты знают, какой экземпляр службы должен обрабатывать запросы?
Ответ на эти вопросы - балансировка нагрузки. Балансировка нагрузки означает разделение трафика дохода между экземплярами службы.
Почему
Чтобы масштабировать ваши независимые сервисы, вам нужно запустить несколько экземпляров сервисов. При использовании балансировщика нагрузки клиентам не нужно знать, какие экземпляры обслуживают.
Инструменты
Traefik, NGINX, Seesaw
.: Обнаружение службы:.
Какие
По мере того, как количество сервисов вашего приложения становится все больше и больше, сервисы должны знать адреса экземпляров сервисов друг друга, но в больших приложениях с большим количеством сервисов это невозможно. Итак, нам нужно обнаружение служб, которое отвечает за предоставление адресов всех компонентов в вашем приложении, они могут легко отправить запрос в службу обнаружения служб и получить адрес доступного экземпляра служб.
Почему
Когда в вашем приложении может быть несколько сервисов, обнаружение сервисов является обязательным для вашего приложения. Вашим службам приложений не нужно знать адрес каждого экземпляра службы, это означает, что обнаружение службы прокладывает этот путь для вас.
Инструменты
Consul, Zookeeper, Eureka, etcd и Keepalived
.: Шина событий:.
Какие
В шаблоне микросервисной архитектуры вы должны использовать два разных типа взаимодействия: синхронное и асинхронное.
Синхронизация связи означает, что службы обращаются друг к другу через HTTP-вызов или вызов GRPC. Асинхронная связь означает, что службы взаимодействуют друг с другом через шину сообщений или шину событий. Это означает, что между службами нет прямого соединения.
Хотя ваша архитектура может использовать оба стиля связи одновременно, например, в примере интернет-магазина вы можете отправлять сообщение всякий раз, когда заказ зарегистрирован, и те службы, которые подписались на определенный канал, получат сообщение. Но иногда вам может потребоваться запрос в реальном времени, например, вам нужно знать количество элемента, вы можете использовать GRPC или HTTP-вызов между службами для получения ответа.
Почему
Если вы хотите иметь масштабируемое приложение с несколькими службами, одним из принципов, которым вы должны следовать, является создание слабосвязанных служб, которые взаимодействуют друг с другом через шину событий. Кроме того, если вам нужно создать приложение, которое может подключать новую службу для получения серии определенных сообщений, вам необходимо использовать шину событий.
Инструменты
RabbitMQ, Kafka
.: Логирование :.
Какие
При использовании модели микросервисной архитектуры лучше централизовать журналы сервисов. Эти журналы будут использоваться при отладке проблемы или агрегировании журналов в соответствии с их типами для аналитического использования.
Почему
В случае необходимости отладки запроса вы можете столкнуться с трудностями, если не соберете журналы служб в одном месте. Вы также можете сопоставить журналы, относящиеся к конкретному запросу, с уникальным идентификатором корреляции. Это означает, что все журналы в различных службах, связанные с запросом, будут доступны по этому идентификатору корреляции.
Инструменты
Эластичный Logstash
.: Мониторинг и оповещение:.
Какие
В микросервисной архитектуре, если вы хотите иметь надежное приложение или службу, вы должны отслеживать функциональность, производительность, обмен данными и любые другие аспекты вашего приложения, чтобы создать ответственное приложение.
Почему
Вам необходимо отслеживать общую функциональность и работоспособность служб, а также отслеживать узкие места в производительности и составлять план их устранения. Оптимизируйте взаимодействие с пользователем, сократив время простоя вашего сервиса, определив ранние предупреждения для ваших сервисов в критических точках. Отслеживайте общее потребление ресурсов сервисами, когда они находятся под большой нагрузкой и т. Д.
Инструменты
Прометей, Кибана, Графана
.: Распределенная трассировка:.
Какие
Отладка всегда является одной из задач разработчиков. У всех вас есть опыт трассировки или отладки монолитного объекта. Это очень просто и легко, но когда дело доходит до архитектуры микросервисов, потому что запрос может передаваться через разные службы, что затрудняет отладку и трассировку, поскольку кодовая база находится не в одном месте, поэтому здесь может быть полезен инструмент распределенной трассировки.
Почему
Без распределенного инструмента отслеживания сложно или, возможно, невозможно отследить ваш запрос через различные службы. С помощью этих инструментов вы можете легко отслеживать запросы и события с помощью богатого пользовательского интерфейса для демонстрации потока запроса.
Инструменты
OpenTelemetry, Jeager, Zipkin
.: Сохранение данных:.
Какие
В большинстве систем нам необходимо сохранять данные, потому что нам потребуются данные для дальнейших процессов или отчетов и т. д., чтобы сохранять данные, нам нужен какой-то инструмент для записи данных наших приложений в физический файл с другой структурой.
Почему
В монолитных приложениях мы использовали один или два разных типа персистентности, и большинство монолитных приложений используют реляционные базы данных, такие как SQL Server, Oracel, MySQL. Но в микросервисной архитектуре мы должны следовать шаблону «База данных для каждой службы», это означает, что постоянные данные каждой микросервиса должны быть приватными для этой службы и доступны только через ее API.
Что ж, у вас будут разные базы данных для разных целей и сценариев. Например, служба отчетов может использовать базы данных NoSQL, такие как ElasticSearch или MongoDB, потому что они используют базовую структуру документа. Это означает, что структура для хранения данных в этих базах данных отличается от реляционные базы данных, которые подходят для сервисов с высокой скоростью чтения или выборки данных.
С другой стороны, вам могут потребоваться реляционные базы данных, такие как Oracle или SQL SERVER, в некоторых микросервисах, или вам также могут потребоваться некоторые базы данных, которые поддерживают структуру графа или структуру ключ-значение.
Итак, в микросервисной архитектуре в соответствии с миссией обслуживания вам потребуются разные типы баз данных.
Инструменты
Реляционные базы данных или СУБД: PostgreSQL, MySQL, SQL SERVRE, Oracle
База данных NoSQL: MongoDB, Cassandra, Elasticsearch
.: Кеширование:.
Какие
Кэширование сокращает задержку при обмене данными между сервисами микросервисных архитектур. Кэш - это высокоскоростной уровень хранения данных, на котором хранится подмножество данных. Когда данные запрашиваются из кеша, они доставляются быстрее, чем если бы вы обращались к основному месту хранения данных.
Почему
В микросервисной архитектуре существует множество стратегий, которые можно реализовать таким образом кэширования. Например,
1- Встроенный кэш (распределенный и нераспределенный)
2- клиент-серверный кэш (распределенный)
3- Кэш обратного прокси-сервера (сопроводительный документ)
Чтобы уменьшить задержку, кеширование может быть реализовано на разных уровнях. Это означает, что у вас будет более высокое время отклика. кроме того, вы также можете реализовать распределенное кеширование, которое доступно для нескольких микросервисов и иногда рассматривается как заполнитель для общих ресурсов, которые используются по-разному, например
Ограничение скорости. Наиболее частой причиной ограничения скорости является повышение доступности служб на основе API за счет предотвращения нехватки ресурсов.
Инструменты
Redis (сервер REmote DIctionary), Apache Ignite, Hazelcast IMDG
.: Облачный провайдер :.
Какие
Поставщик облачных услуг - это сторонняя компания, предлагающая облачную платформу, инфраструктуру, приложение или услуги хранения. Подобно тому, как домовладелец платит за коммунальные услуги, такие как электричество или газ, компании обычно должны платить только за тот объем облачных услуг, который они используют, в соответствии с требованиями бизнеса. [Microsoft]
Самые важные категории для поставщиков облачных услуг
1- Программное обеспечение как услуга (SaaS).
2-платформа как услуга (PaaS).
3- Инфраструктура как услуга (IaaS).
Почему
Одно из преимуществ использования услуг облачных вычислений заключается в том, что фирмы могут избежать первоначальных затрат и сложностей, связанных с владением и обслуживанием собственной ИТ-инфраструктуры, и вместо этого просто платят за то, что они используют, когда они ее используют. Сегодня, вместо того, чтобы владеть собственной вычислительной инфраструктурой или центрами обработки данных, компании могут арендовать доступ ко всему, от приложений до хранилища.
Инструменты
Amazon Web Services (AWS), Microsoft Azure, Google Cloud, Alibaba Cloud
Заключение
В этой статье я попытался продемонстрировать план действий, связанный с шаблоном архитектуры микросервисов. Если вы хотите реализовать микросервисную архитектуру с нуля или перенести свою монолитную на микросервисную архитектуру, вам необходимо знать эти концепции.
Помимо этих концепций, у нас есть другие концепции, такие как сервисная сетка, кеширование, постоянство, которые могут быть частью этой дорожной карты, но я намеренно не упомянул их для простоты и в целях краткости.
Не стесняйтесь присылать мне свои комментарии и предлагать другие концепции этой дорожной карты.
Статьи по Теме:
