Есть три microservices на месте:Если один microservice быть как государственным, так и внутренним одновременно
Авторы
, который имеет возможность выбрать и CRUD объект «автор»
Книга
который имеет возможность SELECT и CRUD «книга»
Мобильный оператор
создан специально для того, чтобы мобильный клиент ответил на полную запрошенную модель данных, чтобы мобильное приложение не «обогатило» данные на своем конце.
Пример: API «MobileHost.getAllBooksOfGivenAuthor» будет реагировать как с именем автора и книги имен, называя «Authors.getAuthorData (AuthorID)» и слияние его данные с «Books.getBooksByAuthorIds (AuthorID)», в результате структуры как это:
{
"author" : {
"name" : "Winner",
"id" : 1
},
"books" : [
{
"name" : "Book A",
"id" : "13231231"
}
]
}
Мой вопрос является:
Если мобильный клиент считывает данные через «мобильное приложение хоста» должен это сделать «добавить автора» через «мобильное приложение хоста» также, или это нормально обратитесь непосредственно к службе «Авторы»? Должен ли CRUD быть проксированным в таком случае или нет?
Спасибо за подробный ответ. Еще один вопрос для вас: Помимо услуг «хоста», вы создаете API, которые являются внутренними и внешними? Если да, можете ли вы назвать причину того, почему вы сделали это таким образом? Спасибо. – user3765648
У нас смешанная политика в отношении сервисов API из-за кэширования. API кэширует некоторые очень частые данные и возвращает данные из кешей по запросу. Также он обрабатывает разбиение на страницы и выбор из сервисов только определенных «страниц» данных. Если есть служба, которая не требует какой-либо системы кеша, мы вызываем ее напрямую, потому что она уменьшает количество межсервисных сообщений, которые могут быть довольно дорогими при высоких нагрузках. Но наши сервисы API предназначены для разделения в любой момент, они следуют шаблону проектирования фасадов. Если мы заметим, что на небольшой части сервиса API будет огромная нагрузка, мы его вытащим. – cassandrad
Спасибо, теперь у меня четкое видение. – user3765648