{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

Микросервисная архитектура

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

Преимущества микросервисной архитектуры

Границы ответственности

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

Технологическая неоднородность

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

Надёжность

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

Масштабирование

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

Простота развертывания

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

Согласованность рабочих процессов в организации

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

Повторное использование

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

Недостатки микросервисной архитектуры

Технологическая перегрузка

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

Стоимость

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

Отчётность

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

Безопасность

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

Тестирование

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

Время ожидания

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

Согласованность данных

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

Выводы

Чтобы стать высококвалифицированным специалистом нужно:

  • Постоянно расти над собой;
  • Делать выводы чего ты добился;
  • Каким образом ты растёшь;
  • Понимать как ты растёшь.

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

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

В свободное время нужно писать свои пет-проекты, и писать всё с нуля в образовательных целях.

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

0
2 комментария
Иванов Иван

Начали про микросервисы и закончили про саморазвитие. Статья то о чем?

Где предыдущие две части про микросервисы, если это "часть третья"?

Ответить
Развернуть ветку
ПиццаФабрика IT
Автор

Мы опубликовали 3 части одной большой статьи нашего разработчика Владимира. Микросервисной архитектурой заканчиваем трилогию.

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда