Предисловие
Теперь все больше и больше компаний используют Spring Cloud. Spring Boot - это следующее поколение веб -фреймворков, а Spring Cloud является лидером последних и самых популярных микросервисов. По какой причине вы должны отказаться? Многие студенты в Java также начали активно изучать весеннее облако. На самом деле, здесь есть еще одна проблема: хотя все узнали, что Эврика, лента, Хистрикс, Зул, Файн и т. Д., По -прежнему трудно применить его к реальным проектам.
Сложность микросервисов заключается в разделении услуг. Framework - это всего лишь инструмент, и многие люди будут использовать его. Расщепление услуг и отношения между услугами - это вещи, которые необходимо учитывать во время разделения.
Сегодня одноклассник прислал мне электронное письмо, чтобы спросить меня о следующих двух вопросах:
Вот несколько ответов, основанных на моем собственном опыте, только для справки:
Относительно API в первом вопросе контроллер под каждым микросервисом?
То, что мы называем API, на самом деле является интерфейсом, и большинство из них разработаны с использованием Spring MVC, который является аннотированным методом в контроллере. Аннотации - это те, которые мы часто используем:
Что касается первого вопроса, требуется ли унифицированный проект для инкапсуляции контроллера других микросервисов?
На самом деле нет фиксированного шаблона. Большая часть этого прямо направляется на ваши бизнес -услуги через Gateway API
Возьмите бизнес -категорию веб -сайтов блогов, таких как Yuantiandi в качестве примера:
Есть бизнес -функция. Когда я просматриваю конкретные сообщения в блоге, информация, которую мне нужно вернуть, заключается в следующем:
В настоящее время наш интерфейс для просмотра статьи фактически включает в себя три части данных, информацию самой статьи, информацию о комментариях и информацию автора.
Есть 3 услуги, услуги пользователей, услуги блога и услуги комментариев
Таким образом, вопрос заключается в том, что он включает взаимодействие между несколькими службами ранее. На самом деле, тот же вопрос, что и одноклассник, заданный выше. Нужно ли мне иметь унифицированный проект и собирать другие услуги? Могут ли их называть друг другу?
Я рекомендую два способа реализации этого:
1. Ворота API направляется прямо в службу блога
Наш API является интерфейсом для получения информации о сообщении в блоге. Основным органом должен быть сервис блога. В службе блога есть интерфейс для информации о блоге. В интерфейсе мы называем интерфейс информации пользователя, предоставленный Службой пользователя, и также называем информацию о комментарии в блоге в службе комментариев. Давайте посмотрим на псевдод:
@Getmapping ("/blog/detail/{id}") public bloginfo bloginfo (@pathvariable ("id") long id) {// Получить информацию в блоге блог блог = blogservice.getbyid (id); // Получить информацию пользователя userInfo userInfo = userfeignClient.getUserInfo (blog.getUserid ()); // Получить информацию о комментариях комментарий CommentInfo = commentFeignClient.getCommentInfo (id); вернуть собрать всю информацию и вернуть. }2. Добавьте уровень обслуживания агрегации
Уровень сервиса сбора - одноклассник выше, необходимо ли иметь унифицированный проект для предоставления услуг сборки? Это означает, что наш сервис блога по -прежнему предоставляет базовую информацию в блоге, а для сборки этой информации добавляется отдельная служба агрегации бизнеса и единого возврата к абоненту. Псевдокод выглядит следующим образом:
@Getmapping ("/blog/detail/{id}") public bloginfo bloginfo (@pathvariable ("id") long id) {// Получить информацию блога блог = blogfeignclient.getbyid (id); // Получить информацию пользователя userInfo userInfo = userfeignClient.getUserInfo (blog.getUserid ()); // Получить информацию о комментариях комментарий CommentInfo = commentFeignClient.getCommentInfo (id); вернуть собрать всю информацию и вернуть. }Данные называются удаленно, конечно, вы можете назвать их параллельно здесь. Другим способом является выполнение операции агрегации в шлюзе API. Это решение также осуществимо. Я предлагаю не делать это в воротах. API -шлюз как можно прост и только вперед. Добавление уровня обслуживания агрегации является хорошим выбором.
Если ваше управление услугами построено с Dubbo, уровень обслуживания агрегации также является лучшим методом. Dubbo Service Aggregation предоставляет интерфейс HTTP для внешних вызовов.
3. звонящий получает различные данные самостоятельно
Другой способ - позвонить в интерфейс блога, интерфейс комментариев и пользовательский интерфейс. Таким образом, интерфейс должен только обратить внимание на свои собственные данные и передать задачу сборки пользователю. Это обычно используется меньше. Лучше всего возвращать данные в абонент одновременно и называть их неоднократно, особенно на мобильном терминале, который требует слишком большого количества запросов и тратит трафик.
Суммировать
Что касается сборки данных, вы должны решить это самостоятельно. Вы можете разместить сборку в соответствующие бизнес -службы или добавить услугу агрегации, чтобы собрать ее отдельно или позволить клиенту собирать ее само по себе.
Услуги определенно могут быть названы друг другу. Если их нельзя вызвать, то какой смысл разбить их на части? Используйте Feign, чтобы позвонить в интерфейс службы, и вы просто относитесь к нему как к вызову между службами.
Хорошо, вышеупомянутое содержимое этой статьи. Я надеюсь, что содержание этой статьи имеет определенную справочную ценность для каждого обучения или работы. Если у вас есть какие -либо вопросы, вы можете оставить сообщение для общения. Спасибо за поддержку Wulin.com.