Вам бонус- начислено 1 монета за дневную активность. Сейчас у вас 1 монета

МИКРОСЕРВИС- реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

Лекция



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

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

Если в традиционных вариантах сервис-ориентированной архитектуры модули могут быть сами по себе достаточно сложными программными системами, а взаимодействие между ними зачастую полагается на стандартизованные тяжеловесные протоколы (такие, как SOAP, XML-RPC), в микросервисной архитектуре системы выстраиваются из компонентов, выполняющих относительно элементарные функции, и взаимодействующие с использованием экономичных сетевых коммуникационных протоколов (в стиле REST с использованием, например, JSON, Protocol Buffers, Thrift). За счет повышения гранулярности модулей архитектура нацелена на уменьшение степени зацепления и увеличение связности, что позволяет проще добавлять и изменять функции в системе в любое время.

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

Монолитный сервер систем, в которой Вся логика обработки запроса выполняется в одном процессе

1 Микросервисы общая теория и микросервисы на бекэнде

Рассмотрим, что вкладывается в понятие «микросервис», в чем состоят преимущества микросервисов в разных сферах деятельности.

Микросервисы и Business и Project Management

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

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

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

Для бизнеса корректно реализованная архитектура микросервиса подразумевает лучшие варианты для продукта:

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

Микросервис в Computer Science

Микросервис - это state machine. Его состояние представляет собой транзакционную границу.

Представьте себе светофор:

Цвет, который должен появиться, зависит от цвета, который светофор показывает на данный момент. Если «currentColor=green», тогда команда «Switch to next color» может работать правильно только в том случае, если никто другой не переключает свет на следующий цвет, пока обрабатывается ваша команда «Switch to next color».

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

Микросервис в Software Engineering

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

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

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

Известный Bezos memo расшифровывает это как для целых команд, так и для «микросервисов» любого размера. По каким причинам – смотрите выше в “Business и Project Management”.

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

Микросервис в Networking & Infrastructure

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

Хорошим показателем качества внедрения микросервиса и проектирования его инфраструктуры является возможность контроля, оповещения и масштабирования на основе запросов бизнеса, а не технических критериев. Например, «Обработка платежей не работает (... но выполнение заказа продолжает работать нормально)».

Что означает «работа в нормальном режиме»?

Если обработка платежей не работает, то как все может «работать в нормальном режиме»?

Работа в нормальном режиме означает отсутствие ошибок и отсутствие ошибочного принятия решения из-за неправильных данных. Это может быть достигнуто посредством конечной согласованности. Например, выполнение заказа инициируется событием PaymentProcessed. Ни одно из них не может произойти, если обработка платежей не работает, поэтому выполнение будет завершать заказы, обработка платежей которых происходила до отключения, но не последующие. Когда обработка платежей вернется в оперативный режим, служба выполнения начнет получать события PaymentProcessed для пропущенных заказов и будет постепенно догонять. С точки зрения UX, это означает, что у предприятия есть варианты для разработки отказоустойчивых приложений. То есть вместо полного сбоя в работе, функции, которые обрабатываются незатронутыми микросервисами, могут оставаться доступными для пользователей.

Подводные камни

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

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

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

Можно сказать, это — не монолит. На практике это означает, что микросервис работает лишь с небольшой, максимально ограниченной областью задач. Он выполняет минимум функций для достижения определенной цели в вашем стеке. Вот более конкретный пример: допустим, в банке есть "Login Service", и вы, конечно, не хотите, чтобы у этого сервиса был доступ к финансовым транзакциям ваших клиентов. Эту область вы вынесете в какой-нибудь “Transaction Service” (имейте ввиду — давать названия очень сложно).

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

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

Пока все кажется достаточно простым — нужно просто обернуть небольшие куски системы в какой-нибудь REST API, и пусть все общаются друг с другом по сети. По моему опыту, есть 5 "истин", в которые верят люди, и которые не всегда бывают истинными:

  1. Код будет чище
  2. Писать модули, решающие одну задачу — легче
  3. Это работает быстрее, чем монолит
  4. Инженерам проще, если не нужно работать с единой кодовой базой
  5. Это самый простой способ обеспечить автоматическое масштабирование, и тут где-то замешан Докер

Заблуждение #1: Более чистый код

«Не нужно добавлять сетевое ограничение чтобы оправдать написание лучшего кода».

Правда жизни в том, что ни микросервисы, ни любой другой подход при моделировании технического стека не являются требованием для написания более чистого и поддерживаемого кода. Об этом говорит сайт https://intellect.icu . Конечно, раз движимых частей меньше, то снижается возможность писать ленивый и непродуманный код. Но это как говорить, что кражи можно победить убрав товары с витрин магазинов. Вы не решили проблему, вы просто удалили много возможностей.

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

Еще одно преимущество этого подхода в том, что оно напоминает сервис-ориентированную архитектуру (Service Oriented Architecture), построенную на базе микросервисов: если вы решите перейти к микросервисам, то большая часть работы уже выполнена, и у вас скорее всего уже есть неплохое понимание предметной области для правильного разделения ее частей. Настоящий SOA начинается с кода, и с течением времени продолжается на уровне физической топологии стека.

Заблуждение #2: Это легче

«Распределенные транзакции никогда не легче»

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

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

Заблуждение #3: Приложение и использванием микросервиса работает быстрее

«Можно сильно улучшить производительность монолита если добавить немного дисциплины»

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

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

К тому же, многие истории об увеличении производительности на самом деле связаны с преимуществами нового языка или целого технологического стека, а не просто архитектурой микросервисов. Если переписать старое Ruby on Rails, Django или NodeJS приложение на новом языке вроде Scala и Go (два популярных выбора для микросервисной архитектуры), то производительность улучшится хотя бы из-за улучшений производительности новых технологий в целом. Но этим языкам вообще-то без разницы, если вы будете называть их процессы "микро". Они работают быстрее ввиду простых факторов вроде компиляции.

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

Заблуждение #4: Микросервисы Лучше для инженеров

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

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

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

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

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

Заблуждение #5: Лучше масштабируется

«Микросервис можно масштабировать вширь также, как и монолит»

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

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

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

Когда использовать микросервисы а когда монолиты?

«Когда вы, как инженерная организация, будете готовы»

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

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

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

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

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

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

Достоинства и недостатаки использования микросервисов на бекэнде

Достоинства микросервисов

  • Протокол
  • Простота модуля
  • Скорость разработки
  • Независимость комманд
  • Независимость технологий

Недостатки микросервисов

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

Пример реализации и детали микросервисной архитектуры

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

2 Микросервисный фронтенд — подход к разделению фронта

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд



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

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

Сегодня я расскажу вам, как мы делали микросервисный фронт в нашем SaaS-решении и с какими проблемами столкнулись.

Проблематика разработки и проектирования приложения для фронтэнда


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

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

  • Все модули разнородные, со своей спецификой. Для каждого модуля лучше подходят свои технологии. При этом выбор технологий — трудновыполнимая задача в условиях SPA.
  • Так как приложение SPA (а в современном мире это означает компиляцию в единый бандл или как минимум сборку), то одновременно могут делаться только выдачи всего приложения. Риск каждой выдачи растет.
  • Все сложнее заниматься управлением зависимостями. Разным модулям нужны разные (возможно, специфичные) версии зависимостей. Кто-то не готов перейти на обновленный API зависимости, а кто-то не может сделать фичу из-за баги в старой ветке зависимости.
  • Из-за второго пункта релизный цикл у всех модулей должен быть синхронизирован. Все ждут отстающих.

Анализ , разделение и фрагментирование фронтенда


Наступил момент накопления критической массы, и фронтенд решили разделить на… фронтендные микросервисы. Давайте определим, что такое фронтендный микросервис:

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


Но мы пошли дальше и ввели еще один уровень деления.

Понятие фрагмента


Фрагментом мы называем некий бандл, состоящий из js + css + дескриптора развертывания. По сути, это независимая часть UI, которая должна выполнять набор правил разработки, для того чтобы его можно было использовать в общем SPA. Например, все стили должны быть максимально специфичны для фрагмента. Никаких попыток прямого взаимодействия с другими фрагментами быть не должно. Необходимо иметь специальный метод, которому можно передать DOM-элемент, где фрагмент должен отрисоваться.

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

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

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

Все, что нужно сделать разработчику, желающему использовать существующий фрагмент на странице, — это:

  1. Подключить скрипт микросервисной платформы на страницу.
    
     
  2. Вызвать метод добавления фрагмента на страницу.
    window.MUI.createFragment(
        // fragment name
        "hello-label",
    
        // fragment model
        {
            text: "HelloLabelFragment text from run time"
        },
    
        // fragment position
        {
            selector: ".hello-label-placeholder",
            position: "afterend"
        })
        .then(callback);
    


Также для общения фрагментов между собой есть шина, построенная на Observable и rxjs. Написана она на NativeJS. Кроме того, в SDK поставляются обертки для разных фреймворков, которые помогают использовать эту шину нативно. Пример для Angular 6 — утилитный метод, возвращающий rxjs/Observable:

import {fromEvent} from "@vendorname/mui-platform/angular3-factory/modules/shared/utils/event-utils"

fromEvent("");
fromEvent(EventClassType);


Кроме того, платформа предоставляет набор сервисов, которые часто используются разными фрагментами и являются базовыми в нашей инфраструктуре. Это такие сервисы, как локализация/интернационализация, авторизационный сервис, работа с кросс-доменными куками, local storage и многое другое. Для их использования в SDK также поставляются обертки для разных фреймворков.

Синтез (объединение) фрагментов фронтенда


Для примера можем рассмотреть такой подход в SPA админки (она объединяет разные возможные настройки с разных микросервисов). Содержимое каждой закладки мы можем сделать отдельным фрагментом, поставлять и разрабатывать который будет каждый микросервис по отдельности. Благодаря этому мы можем сделать простую «шапку», которая будет показывать соответствующий микросервис при клике на закладку.

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

Более глубокое примернения методики фрагментирования фронтэнда


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

И тут нам тоже помогают фрагменты! Так как все, что нужно фрагменту, — это DOM-элемент для отрисовки, мы выдаем любому микросервису глобальный API, через который он может разместить любой фрагмент внутри своего DOM-дерева. Для этого достаточно передать ID фрагмента и контейнер, в котором ему надо отрисоваться. Остальное сделается само!
Теперь мы можем строить «матрешку» любого уровня вложенности и переиспользовать целые куски UI без необходимости поддержки в нескольких местах.

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

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

Общие сервисы


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

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

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

Достонства применения микросервисов на фронтэнде


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

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

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

Решение с микросерисным фронтендом выглядит неплохо. Ведь теперь каждый фрагмент (микросервис) может сам решать, как деплоиться: нужен ли просто nginx для раздачи статики, полноценный middleware для агрегации запросов к бэкам или поддержки websockets либо еще какая-нибудь специфика в виде бинарного протокола передачи данных внутри http. Кроме того, фрагменты могут сами выбирать способы сборки, методы оптимизации и прочее.

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

  • Взаимодействие между фрагментами невозможно обеспечить стандартными ламповыми методами (DI, например).
  • Как быть с общими зависимостями? Ведь размер приложения будет расти как на дрожжах, если их не выносить из фрагментов.
  • За роутинг в конечном приложении все равно должен отвечать кто-то один.
  • Что делать, если один из фрагментов недоступен / не может отрисоваться.
  • Неясно, что делать с тем, что разные микросервисы могут находиться на разных доменах.

Выводы об использовании микросервисной архитектуре на бекэнде и фронтэнде

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

Если спрашивать моего совета, то я бы смотрел в сторону "внутренних" сервисов на основе чистых, хорошо определенных модулей в коде. Их уже можно будет вынести в настоящие сервисы в будущем, если появится такая необходимость. Этот подход — не единственный возможный, и уж точно не панацея от плохого кода. Но он поможет вам продвигаться вперед быстрее, чем если вы закопаетесь в микросервисы раньше нужного.

«Микросервис» ничем не отличается от многих компонентов, которые составляют сложную технику, окружающую нас каждый день:

  • Минимальная зависимость от других механизмов («Требуется 12В от аккумулятора автомобиля и подключение к антенне»)

  • Четко определенный API как единственный способ взаимодействия с микросервисом («Единственный способ отрегулировать громкость – с помощью этой ручки»).

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

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

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

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

МИКРОСЕРВИС-  реализации, и разработки. пример архитектуры микросервиса,Микросервисный фронтенд

Вау!! 😲 Ты еще не читал? Это зря!

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

создано: 2018-09-27
обновлено: 2021-11-18
132265



Рейтиг 9 of 10. count vote: 2
Вы довольны ?:


Найди готовое или заработай

С нашими удобными сервисами без комиссии*

Как это работает? | Узнать цену?

Найти исполнителя
$0 / весь год.
  • У вас есть задание, но нет времени его делать
  • Вы хотите найти профессионала для выплнения задания
  • Возможно примерение функции гаранта на сделку
  • Приорететная поддержка
  • идеально подходит для студентов, у которых нет времени для решения заданий
Готовое решение
$0 / весь год.
  • Вы можите продать(исполнителем) или купить(заказчиком) готовое решение
  • Вам предоставят готовое решение
  • Будет предоставлено в минимальные сроки т.к. задание уже готовое
  • Вы получите базовую гарантию 8 дней
  • Вы можете заработать на материалах
  • подходит как для студентов так и для преподавателей
Я исполнитель
$0 / весь год.
  • Вы профессионал своего дела
  • У вас есть опыт и желание зарабатывать
  • Вы хотите помочь в решении задач или написании работ
  • Возможно примерение функции гаранта на сделку
  • подходит для опытных студентов так и для преподавателей



Комментарии


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

Проектирование веб сайта или программного обеспечения

Термины: Проектирование веб сайта или программного обеспечения