2016-12-07 21 views
4

Итак, как вы это называете? Микросервис или услуга Nano?Micro Service vs Nano Service?

Какие у них есть недостатки? Я наткнулся на многие блоги в Интернете, и я мог найти удовлетворительный ответ.

Найдено эту цитату из Марка Литтла на InfoQ:

Первые вещи сначала, что на самом деле это микро-сервис? Ну, на самом деле, это не сложное и быстрое определение, но из разговоров с разными людьми, похоже, консенсус в том, что микросервис - это простое приложение, которое расположено вокруг отметки 10-100 LOC.

еще одно:

NanoService является антипаттерн где услуга слишком мелкозернистый. Наносервис - это сервис, чьи накладные расходы (связь, обслуживание и т. Д.) Перевешивают его полезность. Как и Стив и другие, Арнон приходит к выводу, что Microservices - это еще одно название для SOA

Я ищу точное и объяснимое различие между Micro и Nano Service. Я высоко ценю ваше мнение!

+0

Я предпочитаю Picoservices самостоятельно. –

+0

спасибо @TomRedfern. Я хотел бы знать, на каких основаниях? :-) –

+1

Вы уже указали в своем вопросе. Это анти-образец. В этом вы настраиваете свои службы таким образом, чтобы каждый сервис имел свою конечную точку. Например. В ASP.NET WebAPI, где ваши ресурсы GET/POST имеют одну конечную точку с некоторым базовым URL-адресом, теперь, когда вы сверляете их таким образом, у них должны быть свои конечные точки, здесь вы имеете дело с Nanoservices. Краткий обзор: http://justserverless.com/blog/nanoservices-microservices-monolith-serverless-architectures-by-example/ –

ответ

2

В то время как ответ Джеруэна близок к сути различий между SOA, микросервисами и наносервисами, я думаю, что в конце концов это немного смущает.

SOA нарушает функциональность системы в соответствии с бизнес-возможностями (например, OrderService Jeroen или, возможно, CustomerService). Сервисы часто называют другие сервисы, поэтому они очень вовлекают концепцию сети услуг с зависимостями между собой, а также воплощают концепцию состава услуг, когда некоторые услуги существенно объединяют другие сервисы.

Микросервисы очень похожи и потенциально совместимы и реализуют сервисы SOA, поэтому люди, подобные Mark Little, считают их такими же, как SOA. Тем не менее, они также имеют тенденцию демонстрировать конкретные детали реализации, которые никогда не были четко сформулированы в литературе по SOA. Например, они часто привязаны или делятся на DDD BoundedContexts, они должны использовать свою собственную БД для хранения, и они должны публиковать изменения данных для подписчиков.

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

Так, следуя примеру OrderService:

  • На верхнем уровне мы имеем OrderService, который является бизнес сосредоточены услуги по обработке заказов. Это сервис уровня SOA, но он состоит из 3 отдельных служб.

  • OrderManagementService, ответственный за создание и управление состоянием заказа. Это микросервис и имеет собственное хранилище данных, его также можно рассматривать как службу SOA, но он имеет несколько конечных точек (например, CreateOrder, CloseOrder и т. Д.) И не является нано-сервисом.

  • CustomerManagementService, ответственный за обработку деталей клиента. Это микросервис, имеет собственное хранилище данных и также может считаться сервисом SOA, но он имеет несколько конечных точек (например, RegisterCustomer, DeleteCustomer и т. Д.) И не является нано-сервисом.

  • OrderProcessingService, который отвечает за обработку рабочего процесса заказа, организует вызовы для различных внешних служб, таких как OrderManagementService и CustomerManagementService, а также является службой микросервиса и SOA. Это не нано-сервис.

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

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

+0

спасибо @Ubiguchi, лучшее объяснение, которое у меня было так до сих пор! –

2

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

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

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