Технология

Микросервизна комуникация: Пролетен урок за интеграция с Redis

Архитектурата на Microservice е много популярен подход при проектирането и внедряването на силно мащабируеми уеб приложения. Комуникацията в рамките на монолитно приложение между компонентите обикновено се основава на извиквания на метод или функция в рамките на същия процес. Приложението, базирано на микроуслуги, от друга страна е разпределена система, работеща на множество машини.

Комуникацията между тези микроуслуги е важна, за да има стабилна и мащабируема система. Има няколко начина да направите това. Комуникацията, базирана на съобщения, е един от начините да направите това надеждно.

Когато използват съобщения, компонентите взаимодействат помежду си чрез асинхронен обмен на съобщения. Съобщенията се обменят по канали.

графично представяне на система за съобщения, улесняваща комуникацията между услуга A и услуга B

прототипите са особено важни в процеса на:

Когато услуга A иска да комуникира със услуга B, вместо да я изпраща директно, A я изпраща до определен канал. Когато услуга B иска да прочете съобщението, тя взема съобщението от определен канал за съобщения.

В този урок за пролетната интеграция ще научите как да внедрите съобщения в пролетно приложение, използвайки Redis. Ще бъдете преведени през примерно приложение, при което една услуга изтласква събития в опашката, а друга услуга обработва тези събития едно по едно.

Пролетна интеграция

Проектът Spring Integration разширява рамката Spring, за да осигури поддръжка за съобщения между или в рамките на приложения, базирани на Spring. Компонентите са свързани помежду си чрез парадигмата за съобщения. Отделните компоненти може да не са наясно с други компоненти в приложението.

Spring Integration предоставя богат избор от механизми за комуникация с външни системи. Каналните адаптери са един такъв механизъм, използван за еднопосочна интеграция (изпращане или получаване). И шлюзовете се използват за сценарии за заявка / отговор (входящи или изходящи).

Apache Camel е алтернатива, която се използва широко. Пролетната интеграция обикновено се предпочита в съществуващите пролетни услуги, тъй като е част от пролетната екосистема.

Редис

Redis е изключително бързо съхранение на данни в паметта. По желание може да се запази и на диск. Той поддържа различни структури от данни като прости двойки ключ-стойност, набори, опашки и т.н.

Използването на Redis като опашка прави споделянето на данни между компонентите и хоризонталното мащабиране много по-лесно. Производител или множество производители могат да изпратят данни към опашката, а потребител или множество потребители могат да изтеглят данните и да обработват събитието.

Множество потребители не могат да консумират едно и също събитие - това гарантира, че едно събитие се обработва веднъж.

диаграма, показваща архитектура производител / потребител

Предимства от използването на Redis като опашка за съобщения:

Паралелно изпълнение на дискретни задачи по неблокиращ начин
Голяма производителност
Стабилност
Лесно наблюдение и отстраняване на грешки
Лесно изпълнение и използване

Правила:

Добавянето на задача към опашката трябва да бъде по-бързо от обработката на самата задача.
Потреблението на задачи трябва да бъде по-бързо от тяхното производство (и ако не, добавете повече потребители).

Пролетна интеграция с Redis

По-долу се разглежда създаването на примерно приложение, за да се обясни как да се използва Spring Integration с Redis.

Да предположим, че имате приложение, което позволява на потребителите да публикуват публикации. И вие искате да изградите функция за следване. Друго изискване е всеки път, когато някой публикува публикация, всички последователи трябва да бъдат уведомявани чрез някакъв комуникационен канал (например имейл или push известие).

Един от начините да се приложи това е изпращането на имейл до всеки последовател, след като потребителят публикува нещо. Но какво се случва, когато потребителят има 1000 последователи? И когато 1000 потребители публикуват нещо за 10 секунди, всеки от които има 1000 последователи? Освен това, публикацията на издателя ще изчака ли, докато бъдат изпратени всички имейли?

Разпределените системи разрешават този проблем.

Този специфичен проблем може да бъде разрешен с помощта на опашка. Служба A (продуцентът), която отговаря за публикуването на публикации, просто ще направи това. Той ще публикува публикация и ще изпрати събитие със списъка на потребителите, които трябва да получат имейл и самата публикация. Списъкът с потребители може да бъде извлечен в услуга Б, но за улеснение на този пример ще го изпратим от услуга А.

Това е асинхронна операция. Това означава, че услугата, която публикува, няма да трябва да чака да изпраща имейли.

Услуга Б (потребителят) ще изтегли събитието от опашката и ще го обработи. По този начин лесно бихме могли да мащабираме услугите си и бихме могли n потребители, изпращащи имейли (обработка на събития).

Така че нека започнем с внедряване в услугата на производителя. Необходимите зависимости са:

 redis.clients jedis org.springframework.data spring-data-redis org.springframework.integration spring-integration-redis

Тези три зависимости на Maven са необходими:

Jedis е клиент на Redis.
Зависимостта Spring Spring Redis улеснява използването на Redis в Java. Той предоставя познати концепции на Spring, като клас на шаблон за основно използване на API и лек достъп до данни в стил хранилище.
Spring Integration Redis предоставя разширение на програмния модел Spring, за да поддържа добре познатото Модели за интеграция на предприятието .

След това трябва да конфигурираме клиента Jedis:

@Configuration public class RedisConfig { @Value('${redis.host}') private String redisHost; @Value('${redis.port:6379}') private int redisPort; @Bean public JedisPoolConfig poolConfig() { JedisPoolConfig poolConfig = new JedisPoolConfig(); poolConfig.setMaxTotal(128); return poolConfig; } @Bean public RedisConnectionFactory redisConnectionFactory(JedisPoolConfig poolConfig) { final JedisConnectionFactory connectionFactory = new JedisConnectionFactory(); connectionFactory.setHostName(redisHost); connectionFactory.setPort(redisPort); connectionFactory.setPoolConfig(poolConfig); connectionFactory.setUsePool(true); return connectionFactory; } }

Анотацията @Value означава, че Spring ще инжектира стойността, дефинирана в свойствата на приложението в полето. Това означава redis.host и redis.port стойностите трябва да бъдат дефинирани в свойствата на приложението.

Сега трябва да дефинираме съобщението, което искаме да изпратим на опашката. Един прост пример за съобщение може да изглежда така:

калкулатор на общата цена на служителите

@Getter @Setter @Builder public class PostPublishedEvent { private String postUrl; private String postTitle; private List emails; }

Забележка: Проект Ломбок ( https://projectlombok.org/ ) предоставя @Getter, @Setter, @Builder и много други пояснения, за да се избегне претрупването на код с гетери, сетери и други тривиални неща. Можете да научите повече за това от тази статия от ApeeScape .

Самото съобщение ще бъде запазено във формата JSON на опашката. Всеки път, когато събитие бъде публикувано в опашката, съобщението ще бъде сериализирано в JSON. И когато консумирате от опашката, съобщението ще бъде десериализирано.

С дефинираното съобщение трябва да дефинираме самата опашка. При пролетната интеграция това може лесно да се направи чрез .xml конфигурация. Конфигурацията трябва да бъде поставена в resources/WEB-INF директория.

MessageChannel

В конфигурацията можете да видите частта „int-redis: queue-outbound-channel-adapter.“ Неговите свойства са:

документ за самоличност: Името на боб на компонента.
канал: RedisConnectionFactory от която тази крайна точка получава съобщения.
фабрика за връзка: Препратка към #root боб.
опашка: Името на списъка Redis, върху който се извършва операцията за тласък на опашка за изпращане на съобщения Redis. Този атрибут се изключва взаимно с израз на опашка.
израз на опашка: Израз SpEL за определяне на името на списъка Redis, използвайки входящото съобщение по време на изпълнение като RedisSerializer променлива. Този атрибут се изключва взаимно с опашката.
сериализатор: A JdkSerializationRedisSerializer справка за боб. По подразбиране е String. Въпреки това, за StringRedisSerializer полезни натоварвания, a true се използва, ако не е предоставена справка за сериализатор.
екстракт-полезен товар: Посочете дали тази крайна точка трябва да изпраща само полезния товар към опашката Redis или цялото съобщение. Стойността му по подразбиране е true.
натискане наляво: Посочете дали тази крайна точка трябва да използва ляв бутон (когато false) или десен бутон (когато false), за да пише съобщения в списъка Redis. Ако е вярно, списъкът Redis действа като опашка FIFO, когато се използва с адаптер за входящ канал по подразбиране на Redis. Зададено на true да се използва със софтуер, който чете от списъка с ляво изскачане или да се постигне ред на съобщения, подобен на стека. Стойността му по подразбиране е .xml.

Следващата стъпка е да дефинираме шлюза, който е споменат в RedisChannelGateway конфигурация. За шлюз използваме org.toptal.queue клас от StringRedisSerializer пакет.

.xml се използва за сериализиране на съобщение преди запазване в Redis. Също така в RedisChannelGateway конфигурация, дефинирахме шлюза и зададохме RedisChannelGateway като шлюзова услуга. Това означава, че default-request-channel боб може да се инжектира в други зърна. Дефинирахме свойството @Gateway защото също така е възможно да се предоставят препратки към канали по метод, като се използва public interface RedisChannelGateway { void enqueue(PostPublishedEvent event); } анотация. Определение на класа:

SpringIntegrationConfig

За да свържем тази конфигурация с нашето приложение, трябва да я импортираме. Това е реализирано в @ImportResource('classpath:WEB-INF/event-queue-config.xml') @AutoConfigureAfter(RedisConfig.class) @Configuration public class SpringIntegrationConfig { } клас.

@ImportResource

.xml анотацията се използва за импортиране на Spring @Configuration конфигурационни файлове в @AutoConfigureAfter. И enqueue анотацията се използва за намек, че трябва да се приложи автоматична конфигурация след други посочени класове за автоматична конфигурация.

Сега ще създадем услуга и ще приложим метода, който ще public interface QueueService { void enqueue(PostPublishedEvent event); } събития в опашката Redis.

@Service public class RedisQueueService implements QueueService { private RedisChannelGateway channelGateway; @Autowired public RedisQueueService(RedisChannelGateway channelGateway) { this.channelGateway = channelGateway; } @Override public void enqueue(PostPublishedEvent event) { channelGateway.enqueue(event); } }

enqueue

И сега можете лесно да изпратите съобщение до опашката, използвайки QueueService метод от LPUSH.

Опашките за Redis са просто списъци с един или повече производител и потребител. За да публикуват съобщение на опашка, производителите използват redis-cli monitor Команда Redis. И ако наблюдавате Redis (подсказка: тип 'LPUSH' 'my-event-queue' '{'postUrl':'test','postTitle':'test','emails':['test']}' ), можете да видите, че съобщението е добавено към опашката:

PostPublishedEvent

Сега трябва да създадем потребителско приложение, което да изтегли тези събития от опашката и да ги обработи. Потребителската услуга се нуждае от същите зависимости като услугата производител.

Сега можем да използваме повторно resources/WEB-INF клас за десериализиране на съобщения.

Трябва да създадем конфигурацията на опашката и отново трябва да бъде поставена в .xml директория. Съдържанието на конфигурацията на опашката е:

int-redis:queue-inbound-channel-adapter

В MessageChannel конфигурация, SmartLifecycle може да има следните свойства:

документ за самоличност: Името на боб на компонента.
канал: true до които изпращаме съобщения от тази крайна точка.
автоматично стартиране: A SmartLifecycle атрибут, за да укажете дали тази крайна точка трябва да стартира автоматично след стартиране на контекста на приложението или не. Стойността му по подразбиране е 0.
фаза: A RedisConnectionFactory атрибут, за да се определи фазата, в която тази крайна точка ще бъде стартирана. Стойността му по подразбиране е MessageChannel.
фабрика за връзка: Препратка към ErrorMessages боб.
опашка: Името на списъка Redis, върху който се извършва изскачаща операция, базирана на опашка, за да се получат съобщения Redis.
канал за грешка: Exceptions на които ще изпратим Endpoint с MessagePublishingErrorHandler от задачата за слушане на errorChannel. По подразбиране основният RedisSerializer използва по подразбиране byte[] от контекста на приложението.
сериализатор: Message справка за боб. Това може да е празен низ, което означава, че няма сериализатор. В този случай суровият JdkSerializationRedisSerializer от входящото съобщение Redis се изпраща до канала като true полезен товар. По подразбиране е false.
изчакване за получаване: Времето за изчакване в милисекунди за поп операцията да изчака съобщение Redis от опашката. Стойността му по подразбиране е 1 секунда.
интервал на възстановяване: Времето в милисекунди, за което задачата на слушателя трябва да спи след изключения в операцията pop, преди да рестартирате задачата на слушателя.
очаквайте съобщение: Посочете дали тази крайна точка очаква данните от опашката Redis да съдържат цели съобщения. Ако този атрибут е зададен на TaskExecutor, сериализаторът не може да бъде празен низ, тъй като съобщенията изискват някаква форма на десериализация (JDK сериализация по подразбиране). Стойността му по подразбиране е SimpleAsyncTaskExecutor.
изпълнител на задача: Препратка към извор true (или стандартен JDK 1.5+ Изпълнител) боб. Използва се за основната задача за слушане. По подразбиране a false се използва.
десен поп: Посочете дали тази крайна точка трябва да използва дясно изскачане (когато true) или ляво изскачане (когато false) за четене на съобщения от списъка Redis. Ако true, списъкът Redis действа като FIFO опашка, когато се използва с адаптер за изходящ канал по подразбиране на Redis опашка. Зададено на json-to-object-transformer да се използва със софтуер, който пише в списъка с десен бутон или да се постигне ред на съобщения, подобен на стека. Стойността му по подразбиране е type='com.toptal.integration.spring.model.PostPublishedEvent'.

Важната част е „активаторът на услугата“, който определя коя услуга и метод трябва да се използват за обработка на събитието. “

Също така, SpringIntegrationConfig се нуждае от атрибут тип, за да трансформира JSON в обекти, зададени по-горе на public interface EventProcessingService { void process(PostPublishedEvent event); } @Service('RedisEventProcessingService') public class RedisEventProcessingService implements EventProcessingService { @Override public void process(PostPublishedEvent event) { // TODO: Send emails here, retry strategy, etc :) } } .

Отново, за да свържем тази конфигурация, ще ни трябва 'BRPOP' 'my-event-queue' '1' клас, който може да бъде същият като преди. И накрая, имаме нужда от услуга, която всъщност ще обработи събитието.

|_+_|

След като стартирате приложението, можете да видите в Redis:

защо един архитект може да избере прост, повтарящ се ритъм за своята сграда?

|_+_|

Заключение

С Spring Integration и Redis изграждането на приложението Spring microservices не е толкова обезсърчително, колкото обикновено. С малко конфигурация и малко количество шаблонни кодове можете за нула време да изградите основите на вашата микросервисна архитектура.

Дори и да не планирате да надраскате изцяло текущия си проект Spring и да преминете към нова архитектура, с помощта на Redis е много лесно да постигнете огромни подобрения в производителността с опашки.

Разбиране на основите

Какво представлява архитектурата на микроуслугите?

Приложението, базирано на микроуслуги, е разпределена система, работеща на множество машини. Всяка услуга в системата комуникира, като предава съобщения на останалите.

Какво е монолитна архитектура в софтуера?

В монолитно приложение всички компоненти се намират в един и същ процес и комуникацията обикновено се основава на извиквания на метод или функция в рамките на един и същ процес.