Сервис и микросервис в чем отличие
Сервисы, микросервисы и пакетно-ориентированное программирование
Многие программисты слышали о том, что иногда код следует выделять в отдельные библиотеки для дальнейшего повторного использования. Однако, вопрос, какой же все-таки код следует выделять в отдельную сущность, ставит многих разработчиков в тупик. При прочтении статей/разговоре на данную тему обычно вспоминается проблема преждевременного обобщения.
Опытные программисты обычно имеют свои правила, соблюдая которые, понимают, следует ли выделять код в повторно используемый. Например, если такой(или сильно похожий) код используется в трех местах или более. Тем не менее, все, с кем мне довелось говорить на этот счет, соглашаются с тем, что такой повторно используемый код должен существовать, его создание является благом, и на это стоит тратить свое время.
Хочу поднять тему повторного использования кода в контексте создания сервис-ориентированной и микросервисной архитектуры.
Что есть повторно используемый код
Повторно используемый код — это код, выделенный в отдельную сущность, называемую в разных языках по разному — библиотека, пакет, зависимость и т.д. Обычно такой код хранится в отдельном репозитории, и имеется документация по подключению и использованию этого кода(README.md). Дополнительно, код может быть покрыт тестами, может иметься инструкция по внесению изменений(CONTRIBUTING.md) и может быть настроен CI. Различные бейджи, прикрепленные к описанию, только улучшают визуальное представление зрелости данной сущности, а количество поставленных звезд скажет о популярности данного решения. За примерами далеко ходить не надо — достаточно открыть страницу github любого из популярных фреймворков на любимом вами языке, например vue.js. В общем, способов качественного оформления библиотек вагон и маленькая тележка.
Сервисы и микросервисы
В данной статье под сервисом понимается законченная сущность, которая выполняет определенный набор определенных задач в своем домене ответственности и предоставляет интерфейс для взаимодействия. Сервис или микросервис в данной статье с архитектурной точки зрения могут быть идентичными понятиями, вопрос лишь в масштабе. Сервис может состоять из набора микросервисов, реализующих свой участок бизнес-логики, либо быть одним гордым микросервисом.
Сервис-ориентированная архитектура предполагает, что каждый сервис минимально связан с другими. Тем не менее, межсервисное взаимодействие не исключено, а только предполагается, что оно должно быть сведено к минимуму. Для приема запросов в сервисе обычно реализуется какое-либо стандартизированное API. Это может быть что угодно — REST, SOAP, JSONRPC или новомодный GraphQL.
Условно, сервисы можно разделить на инфраструктурные и продуктовые. Продуктовые сервисы — это те, которые реализуют логику какого-либо клиентского продукта. Например, работают с заявками на его подключение, или организуют сопровождение этого продукта на всем жизненном цикле работы с ним клиента. Инфраструктурные сервисы — это больше про базовый функционал компании(или проекта), например сервис, содержащий клиентскую информацию, или сервис, хранящий информацию о тех или иных заказах. Также к инфраструктурным можно отнести сервисы, реализующие вспомогательный функционал, например сервис информирования клиентов (отправка push-сообщений или СМСок) или сервис взаимодействия с dadata.
Чуточку пофантазируем
Допустим, существует гипотетический интернет-магазин, построенный по сервис-ориентированной архитектуре. Разработчики этого чуда инженерной мысли смогли договориться между собой и пришли к выводу, что в качестве API все их сервисы будут работать, например, по jsonrpc-протоколу. Однако, поскольку интернет-магазин большой, он не стоит на месте и активно развивается, то групп разработки там несколько, пусть будет больше двух — две проектные, одна по сопровождению уже написанного. Также, для пущего эффекта, все команды пишут на одном стеке.
Архитектура гипотетического интернет-магазина:
В интернет торчит только сервис API, предоставляющий доступ для всех фронтальных систем — веб-интерфейса интернет-магазина, а также мобильных приложений.
Сервис клиентской информации хранит информацию о клиентах, умеет их заводить, авторизовывать, выдавать о них необходимую информацию.
Сервис информации о товарах хранит информацию о товарах, об их остатках и доступности для заказа, также предоставляет методы для удобного получения необходимой информации.
Сервис заказов оперирует заказами. Тут находится логика формирования заказа, его подтверждения, выбора типа оплаты и адреса доставки и т.д.
Сервис информирования клиентов умеет отправлять PUSH/SMS/email-сообщения. Тип коммуникации, допустим, зависит от настроек конкретного клиента, также клиент может настроить желаемое время получения уведомлений.
Данные сервисы условно являются инфраструктурными, поскольку без них не может функционировать интернет-магазин как таковой.
Сервисы акций и предложений и рассылки дайджеста предполагается разработать в ближайшее время проектным командам. Эти сервисы условно являются продуктовыми.
Очевидно, любой новый продуктовый сервис в большинстве случаев не сможет существовать без взаимодействия с инфраструктурными сервисами — ему скорее всего придется получать информацию по клиентам или понадобится необходимость отправлять уведомления.
В описанном выше примере намеренно сокрыты детали реализации каждого из сервисов. Так, например, сервис информирования клиентов, вероятно, имеет механизм отложенного выполнения кода, типа очереди выполнения, а сервис информации о товарах может иметь собственную админку для удобного управления товарами, а api для фронтальных систем, вероятно, имеет несколько реплик. Более того, описанная архитектура может быть не оптимальной, она просто взята из головы.
В контексте предложенной архитектуры сразу становится ясно, что для быстрой продуктовой разработки крайне необходимы готовые библиотеки. Так, важно иметь готовую реализацию jsonrpc-сервера, а также клиента к нему, поскольку это основной протокол организации межсервисного взаимодействия. Также в данном примере во весь рост встает вопрос документирования API. Очевидно, для формирования документации у команд также должен быть готовый инструмент. Если предположить, что еще есть готовый инструмент и для генерирования smd-схем для jsonrpc-серверов, то скорость разработки новых сервисов может еще больше вырасти. В итоге, внутри компании, в идеале, должен быть набор готовых библиотек, которыми пользуются все команды для выполнения типовых задач. Эти библиотеки могут быть как собственные, так и open-source’ные, главное, чтобы хорошо выполняли свои задачи. Очевидно, что команда, которая находится в общем стеке и пишет сервисы используя готовые библиотеки, будет более эффективная, нежели команда, которая постоянно велосипедит. Наличие единого фреймворка и единой базы библиотек, которые используются во всех проектных командах, я называю единой экосистемой.
А как обстоят дела в крупных компаниях?
В больших компаниях инфраструктурных сервисов куда больше, равно как и используемых протоколов взаимодействия. Количество готовых библиотек может идти на десятки или даже сотни. Выделение в повторно используемого кода здесь еще более актуально.
Так уж вышло, что у меня есть опыт работы в компании, в которой трудятся около 200 разработчиков, пишущих на различных языках — java, c#, php, python, go, js и др. Удивительно, но общую экосистему, в контексте единого стека, имеют и используют далеко не все команды разработчиков. Казалось бы, очевидная вещь — готовить повторно используемый код, оформлять его должным образом и использовать — далеко не очевидная. Конечно, команды разработчиков решают свои задачи. Кто-то использует шаблон сервиса — набор кода, составляющее ядро их каждого нового сервиса, из которого выкидывается все ненужное и дописывается нужное.
Другие команды разработчиков используют собственные велосипеды, копипастят их из проекта в проект и не заботятся о их документировании и тестировании. В общем, ощущается большая разобщенность в используемых инструментах и подходах внутри одного стека в одной компании. При этом, территориально расположенных в одном городе.
Преимущества единой экосистемы
Формирование единой экосистемы позволяет решить множество сложностей, и имеет огромный потенциал повышения производительности для большой компании. Фактически, эта практика взята из Open Source сообщества — выживают и наиболее популярны лучшие решения в своей области. Сейчас достаточно открыть любой менеджер зависимостей и только удивиться обилию предлагаемых решений. А ведь именно такой подход можно реализовать и внутри компании. Преимущества же такого подхода при реализации нового сервиса следующие:
Ложка дёгтя
Понятно, что для достижения такого подхода следует соблюдать некоторые практики, а именно вести разработку библиотек, используя семантическое версионирование, заботиться о документации и тестах, иметь настроенный ci. Это, своего рода, показатель зрелости не только команды разработки, но и разработчиков в компании в целом.
— Коллега: ты превращаешься в кассира в пятерочке
— я: всмысле?)
— Коллега: скоро будешь спрашивать «пакет надо?»
— я: раскрой пожалуйста мысль. я не понимаю
— Коллега: ну уже в который раз у тебя есть готовый пакет для решения моей задачи
Отличие SOA от микросервисной архитектуры
В его основе лежат несколько основных идей – переиспользование сервисов и корпоративная шина. Разработчики стремятся разбить систему на сервисы таким образом, чтобы их можно было использовать повторно. Взаимодействие и маршрутизация осуществляется через корпоративную шину ESB. Типичная SOA архитектура показана на рисунке ниже.
Давайте посмотрим из каких частей она состоит, и какова их роль.
Шина(ESB): в случае взаимодействия сложных событий действует как посредник и управляет различными рутинными операциями, такими как передача сообщений и координация вызовов.
Инфраструктурные сервисы (infrastructure services): группа легко переиспользуемых сервисов, таких как аутентификация/авторизация, отправка смс и прочее.
Прикладные сервисы (application services): не могут быть переиспользованны под разные задачи, так как ограничены определенным прикладным контекстом, но их можно встраивать в более высокоуровневые сервисы.
Сервисы предприятия (Enterprise services): эти сервисы отвечают за реализацию крупных частей бизнес процессов компании, они потребляют более низкоуровневые сервисы.
API: по сути это бэкенды, предоставляющие API, доступное в интернет, для сайтов и мобильных приложений компании. Они взаимодействуют с ESB и раскрывают функциональность для конечных потребителей.
Как вы могли заметить, проектируя архитектуру в данном стиле, мы имеем очень большое количество слоев и как следствие команд, которые ими владеют. Любой запрос пронизывает все слои системы, в большей степени напоминая монолитную архитектуру. Но данный тип архитектуры намного сложнее, потому что является распределенной архитектурой.
Как и зачем переходить от сервис-ориентированной архитектуры к микросервисам
Здравствуйте, меня зовут Алексей, я главный IT-архитектор банка «Ренессанс Кредит». Лет десять назад мы, как и многие компании, ускорили свое развитие благодаря сервис-ориентированной архитектуре (SOA). Но со временем требования к архитектуре менялись, и к данной парадигме стали возникать серьезные вопросы. В конце концов мы решили перейти от интеграционной шины ESB к микросервисам. На нашем примере я расскажу, почему стоит задуматься об эффективности SOA и что можно предпринять, если эта модель вас тоже не устраивает.
Новые проблемы ESB
Все началось с того, что мы оценили структуру нашей интеграционной шины. На схеме представлена типовая ситуация с интеграционными потоками для ESB.
Таких блоков может насчитываться нескольких десятков (вплоть до сотни!), и они тесно переплетены между собой. Если потребуется сделать новый продукт и внести какие-то изменения, то на переработку этого здоровенного монолита не хватит никаких ресурсов. И это только общий взгляд. Мы изучили SOA со всех сторон и всего выделили семь основных проблем:
Новые потребности заказчиков
Традиционная сервисная шина, ориентированная на waterfall, со своими сложными и медленными процессами никак не вписывается в условия рынка. Сегодня заказчики знают о гибких методологиях разработки. Они могут не знать различий между agile и waterfall, но хотят получать первые результаты — от появления идеи до прототипа в эксплуатации — не через 6-8, а через 2-3 месяца, а лучше вообще через один. Пусть это будет MVP, но заказчику важно как можно быстрее проверить бизнес-идею, понять, что решение «взлетит».
В таких условиях традиционные, горизонтально ориентированные команды уступают вертикально ориентированным, которые работают со всеми составляющими продукта — от канала взаимодействия до бэк-энда. Ребром встает вопрос: как поступить с интеграционной шиной, превратившейся из-за повторного использования сервисов в монолит? Нужен новый технологический подход.
Фундамент нового подхода
Мы начали прорабатывать альтернативу SOA с формулировки основных требований:
Пирамида технологий
В соответствии с требованиями мы сформировали пирамиду технологий:
Теперь о составляющих каждого уровня в отдельности:
1. Уровень методологии
4. Уровень модели данных
Изменения в архитектуре
Исходя из нового сочетания технологий, мы представили то, к чему хотим прийти. На рисунке ниже — схема нашей нынешней инфраструктуры с интеграционной шиной. Рядом — та схема, к которой мы стремимся.
Что меняется? Изначально на уровне бэк-офиса любая АБС имеет бизнес-логику и источник данных. Мы стремимся к тому, чтобы бэк-офисные системы свелись исключительно к хранению и «ядерному» функционалу, где изменения были бы редкими. А продуктовая логика ушла на уровень микросервисов, позволяющих гибко менять и создавать продукты, разделенные по доменам.
В масштабах канала мы планируем на основе микросервисов сформировать и управлять логикой, «размазанной» по слою фронт-энда. В итоге сами фронтальные приложения будут содержать только канальную логику, то есть нативные приложения для автоматизации нужных каналов обслуживания запросов.
Все управление доступом будет осуществляться через портал API Management, где будут описаны и опубликованы все API. Здесь любой разработчик сможет получить о них всю информацию и включиться в фабрику разработки. В ней с помощью технологий GitLab организован непрерывный цикл работы — планирование, разработка, тестирование, выпуск и эксплуатация.
Схема API Management и Open API
В чем разница между микросервисами и веб-сервисами
главное отличие между микросервисами и веб-сервисами является то, что Под микросервисами понимается подход к разработке приложений, при котором большое приложение создается как набор модульных компон
Содержание:
главное отличие между микросервисами и веб-сервисами является то, что Под микросервисами понимается подход к разработке приложений, при котором большое приложение создается как набор модульных компонентов или сервисов, в то время как веб-сервисы относятся к набору стандартов или протоколов, которые позволяют различным приложениям взаимодействовать друг с другом через World Wide Web (WWW). ).
Ключевые области покрыты
1. Что такое микросервисы
— определение, функциональность
2. Что такое веб-сервисы
— определение, функциональность
3. В чем разница между микросервисами и веб-сервисами
— Сравнение основных различий
Основные условия
Что такое микросервисы
Рисунок 1: Архитектура микросервиса
Например, предположим, что веб-приложение для электронной коммерции. Каждый компонент разделен на отдельные модули. Каждый запрос и ответ на микросервис является независимой транзакцией. Это приложение может иметь микросервисы для продукта, корзины, клиента и т. Д. У каждого есть свои модели данных. Детали реализации одного сервиса скрыты от других сервисов. Когда запрос приходит от клиента, он сначала отправляется на шлюз API. Затем шлюз API отправит запрос в соответствующий микросервис. Если клиент запрашивает несколько сервисов, шлюз API будет предоставлять агрегированные сервисы.
Есть несколько преимуществ микросервисов. Каждый сервис может быть разработан и развернут независимо. Также легче идентифицировать неисправности, а также проводить тестирование и развертывание изменений. Кроме того, микросервисы поддерживают гранулированное масштабирование. Другими словами, услуги могут масштабироваться независимо.
Что такое веб-сервисы
Рисунок 2: Веб-сервисы
REST расшифровывается как представительский государственный трансферт. Веб-сервис, который подтверждает архитектурный стиль REST, является веб-сервисом RESTful. Он не зависит от платформы, более гибок и потребляет меньше пропускной способности и ресурсов.
В чем разница между микросервисами и веб-сервисами
Определение
функциональность
В микросервисах приложение делится на сервисы. Каждый сервис запускает уникальный процесс и управляет своей собственной базой данных. Принимая во внимание, что веб-сервис работает как общая платформа для взаимодействия различных приложений. Это одно из основных различий между микросервисами и веб-сервисами.
заявка
Другим основным отличием между микросервисами и веб-сервисами является их применение. Микросервисы позволяют разделить приложение на несколько модулей или служб в слабосвязанной форме, чтобы они не зависели друг от друга. Это облегчает разработку приложения. С другой стороны, веб-службы предоставляют стандарт или протоколы для обмена информацией между различными устройствами или приложениями.
Заключение
Разница между микросервисами и веб-сервисами заключается в том, что микросервисы относятся к подходу к разработке приложений, при котором большое приложение создается как набор модульных компонентов или сервисов, а веб-сервисы ссылаются на набор стандартов или протоколов, которые позволяют различным приложениям взаимодействовать друг друга через всемирную паутину (WWW).
Ссылка:
В чем разница между микросервисами и веб-сервисами?
Но я не понимал, что заставит меня выбрать одно из них, и могут ли микросервисы также использовать REST API и общаться через http.
Я в основном не понимал, что такое микросервис и может ли он прийти вместо веб-сервиса, кроме цели
разбивка больших программных приложений на слабосвязанные модули
5 ответов
Архитектура микросервисов экономит день, когда большие приложения выходят из строя или не работают Если какой-либо службе не удается установить связь, отказ одного модуля не может повлиять на общее приложение. Возможно сочетание микросервисов на языках разработки Java, C #, Python и мобильных приложений. Он может быть независимо развернут в моделях обслуживания для бизнес-домена.
Он определяет механизмы взаимодействия между API и основным кодом с использованием стандартного протокола HTTP и универсальных форматов представления данных, таких как XML, JSON и т. Д. Это позволяет программным приложениям, разработанным с использованием различных технологий, взаимодействовать друг с другом.
Веб-сервисы не участвуют в разработке внешнего интерфейса. Они не связаны с какими-либо языками разработки или программными платформами пользовательских устройств. Также возможно объединение разных веб-сервисов в один, если они написаны на разных языках и для разных операционных систем, как в микросервисах.
Принимая во внимание, что микросервис не подчиняется контексту WWW. По своей сути микросервис должен предоставлять одну конкретную услугу, но, к примеру, нет никаких ограничений для протокола http.
Кроме того, микросервисы часто подразумеваются как модель счетчика для огромного монолитного приложения, которое обслуживает множество различных типов запросов.