การสื่อสารไมโครเซอร์วิส: บทช่วยสอนการบูรณาการในฤดูใบไม้ผลิกับ Redis

เผยแพร่แล้ว: 2022-03-11

สถาปัตยกรรมไมโครเซอร์วิสเป็นวิธีที่ได้รับความนิยมอย่างมากในการออกแบบและใช้งานเว็บแอปพลิเคชันที่ปรับขนาดได้สูง การสื่อสารภายในแอปพลิเคชันแบบเสาหินระหว่างส่วนประกอบมักจะใช้เมธอดหรือการเรียกใช้ฟังก์ชันภายในกระบวนการเดียวกัน ในทางกลับกัน แอปพลิเคชันที่ใช้ไมโครเซอร์วิสเป็นระบบแบบกระจายที่ทำงานบนหลายเครื่อง

การสื่อสารระหว่างไมโครเซอร์วิสเหล่านี้มีความสำคัญเพื่อให้ระบบมีเสถียรภาพและสามารถปรับขนาดได้ มีหลายวิธีในการทำเช่นนี้ การสื่อสารด้วยข้อความเป็นวิธีหนึ่งในการดำเนินการนี้อย่างน่าเชื่อถือ

เมื่อใช้การส่งข้อความ ส่วนประกอบจะโต้ตอบกันโดยการแลกเปลี่ยนข้อความแบบอะซิงโครนัส ข้อความจะถูกแลกเปลี่ยนผ่านช่องทาง

การแสดงภาพกราฟิกของระบบข้อความที่อำนวยความสะดวกในการสื่อสารระหว่างบริการ A และบริการ B

เมื่อบริการ A ต้องการสื่อสารกับบริการ B แทนที่จะส่งโดยตรง A จะส่งไปยังช่องทางเฉพาะ เมื่อ Service B ต้องการอ่านข้อความ จะรับข้อความจากช่องทางข้อความเฉพาะ

ในบทช่วยสอน Spring Integration นี้ คุณจะได้เรียนรู้วิธีปรับใช้การส่งข้อความในแอปพลิเคชัน Spring โดยใช้ Redis คุณจะได้รับการแนะนำผ่านแอปพลิเคชันตัวอย่างที่บริการหนึ่งกำลังผลักดันกิจกรรมในคิว และบริการอื่นกำลังประมวลผลกิจกรรมเหล่านี้ทีละรายการ

การรวมสปริง

โปรเจ็กต์ Spring Integration ขยายเฟรมเวิร์กของ Spring เพื่อรองรับการส่งข้อความระหว่างหรือภายในแอปพลิเคชันที่ใช้ Spring ส่วนประกอบต่างๆ ถูกเชื่อมต่อเข้าด้วยกันผ่านกระบวนทัศน์การส่งข้อความ ส่วนประกอบแต่ละรายการอาจไม่ทราบส่วนประกอบอื่นๆ ในแอปพลิเคชัน

Spring Integration มีกลไกให้เลือกมากมายในการสื่อสารกับระบบภายนอก ตัวแปลงช่องสัญญาณเป็นกลไกหนึ่งที่ใช้สำหรับการรวมทางเดียว (ส่งหรือรับ) และเกตเวย์จะใช้สำหรับสถานการณ์การขอ/ตอบกลับ (ขาเข้าหรือขาออก)

Apache Camel เป็นอีกทางเลือกหนึ่งที่ใช้กันอย่างแพร่หลาย การรวม Spring มักจะเป็นที่นิยมในบริการที่ใช้ Spring ที่มีอยู่ เนื่องจากเป็นส่วนหนึ่งของระบบนิเวศของ Spring

Redis

Redis เป็นที่เก็บข้อมูลในหน่วยความจำที่รวดเร็วมาก สามารถเลือกเก็บไว้ในดิสก์ได้เช่นกัน รองรับโครงสร้างข้อมูลที่แตกต่างกัน เช่น คู่คีย์-ค่าอย่างง่าย ชุด คิว ฯลฯ

การใช้ Redis เป็นคิวทำให้การแชร์ข้อมูลระหว่างส่วนประกอบและการปรับขนาดในแนวนอนทำได้ง่ายขึ้นมาก ผู้ผลิตหรือผู้ผลิตหลายรายสามารถส่งข้อมูลไปยังคิว และผู้บริโภคหรือผู้บริโภคหลายรายสามารถดึงข้อมูลและประมวลผลเหตุการณ์ได้

ผู้บริโภคหลายรายไม่สามารถใช้เหตุการณ์เดียวกันได้ ซึ่งจะทำให้แน่ใจได้ว่าเหตุการณ์หนึ่งจะได้รับการประมวลผลเพียงครั้งเดียว

แผนภาพแสดงสถาปัตยกรรมของผู้ผลิต/ผู้บริโภค

ประโยชน์ของการใช้ Redis เป็นคิวข้อความ:

  • การทำงานที่ไม่ต่อเนื่องแบบคู่ขนานกันในลักษณะที่ไม่ปิดกั้น
  • ประสิทธิภาพดีเยี่ยม
  • ความเสถียร
  • ง่ายต่อการตรวจสอบและแก้ไขจุดบกพร่อง
  • ใช้งานง่ายและใช้งานง่าย

กฎ:

  • การเพิ่มงานไปยังคิวควรเร็วกว่าการประมวลผลงานเอง
  • การบริโภคงานควรเร็วกว่าการผลิต (และถ้าไม่ใช่ ให้เพิ่มผู้บริโภคมากขึ้น)

การรวมสปริงกับ Redis

ข้อมูลต่อไปนี้จะอธิบายเกี่ยวกับการสร้างแอปพลิเคชันตัวอย่างเพื่ออธิบายวิธีใช้ Spring Integration กับ Redis

สมมติว่าคุณมีแอปพลิเคชันที่อนุญาตให้ผู้ใช้เผยแพร่โพสต์ และคุณต้องการสร้างคุณลักษณะติดตาม ข้อกำหนดอีกประการหนึ่งคือทุกครั้งที่มีคนเผยแพร่โพสต์ ผู้ติดตามทุกคนควรได้รับแจ้งผ่านช่องทางการสื่อสารบางช่องทาง (เช่น อีเมลหรือการแจ้งเตือนแบบพุช)

วิธีหนึ่งในการดำเนินการนี้คือส่งอีเมลไปยังผู้ติดตามแต่ละคนเมื่อผู้ใช้เผยแพร่บางสิ่ง แต่จะเกิดอะไรขึ้นเมื่อผู้ใช้มีผู้ติดตาม 1,000 คน? และเมื่อผู้ใช้ 1,000 คนเผยแพร่บางสิ่งใน 10 วินาที แต่ละคนมีผู้ติดตาม 1,000 คน? นอกจากนี้ โพสต์ของผู้จัดพิมพ์จะรอจนกว่าจะมีการส่งอีเมลทั้งหมดหรือไม่

ระบบแบบกระจายสามารถแก้ไขปัญหานี้ได้

ปัญหาเฉพาะนี้สามารถแก้ไขได้โดยใช้คิว บริการ A (ผู้ผลิต) ซึ่งรับผิดชอบในการเผยแพร่โพสต์ก็จะทำเช่นนั้น จะเผยแพร่โพสต์และผลักดันกิจกรรมด้วยรายชื่อผู้ใช้ที่ต้องการรับอีเมลและโพสต์เอง สามารถดึงรายชื่อผู้ใช้ในบริการ B ได้ แต่เพื่อความง่ายของตัวอย่างนี้ เราจะส่งจากบริการ A

นี่คือการดำเนินการแบบอะซิงโครนัส ซึ่งหมายความว่าบริการที่เผยแพร่จะไม่ต้องรอส่งอีเมล

บริการ B (ผู้ใช้บริการ) จะดึงเหตุการณ์ออกจากคิวและดำเนินการ ด้วยวิธีนี้ เราจึงสามารถปรับขนาดบริการของเราได้อย่างง่ายดาย และเราอาจมีผู้บริโภค n คนส่งอีเมล (ประมวลผลกิจกรรม)

เริ่มจากการใช้งานในบริการของผู้ผลิต การพึ่งพาที่จำเป็นคือ:

 <dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> </dependency> <dependency> <groupId>org.springframework.data</groupId> <artifactId>spring-data-redis</artifactId> </dependency> <dependency> <groupId>org.springframework.integration</groupId> <artifactId>spring-integration-redis</artifactId> </dependency>

การพึ่งพา Maven ทั้งสามนี้มีความจำเป็น:

  • เจดิสเป็นลูกค้า Redis
  • การพึ่งพา Spring Data 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<String> emails; }

หมายเหตุ: Project Lombok (https://projectlombok.org/) มี @Getter , @Setter , @Builder และคำอธิบายประกอบอื่นๆ อีกมากมาย เพื่อหลีกเลี่ยงไม่ให้โค้ดรกกับ getters, setters และเรื่องไม่สำคัญอื่นๆ คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับเรื่องนี้ได้จากบทความ Toptal นี้

ข้อความนั้นจะถูกบันทึกในรูปแบบ JSON ในคิว ทุกครั้งที่เผยแพร่กิจกรรมไปยังคิว ข้อความจะถูกจัดลำดับเป็น JSON และเมื่อบริโภคจากคิว ข้อความจะถูกดีซีเรียลไลซ์

ด้วยข้อความที่กำหนดไว้ เราจำเป็นต้องกำหนดคิวเอง ใน Spring Integration สามารถทำได้ง่าย ๆ ผ่านการกำหนดค่า .xml การกำหนดค่าควรอยู่ในไดเร็กทอรี resources/WEB-INF

 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:int="http://www.springframework.org/schema/integration" xmlns:int-redis="http://www.springframework.org/schema/integration/redis" xsi:schemaLocation="http://www.springframework.org/schema/integration/redis http://www.springframework.org/schema/integration/redis/spring-integration-redis.xsd http://www.springframework.org/schema/integration http://www.springframework.org/schema/integration/spring-integration.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> <int-redis:queue-outbound-channel-adapter channel="eventChannelJson" serializer="serializer" auto-startup="true" connection-factory="redisConnectionFactory" queue="my-event-queue" /> <int:gateway service-interface="org.toptal.queue.RedisChannelGateway" error-channel="errorChannel" default-request-channel="eventChannel"> <int:default-header name="topic" value="queue"/> </int:gateway> <int:channel/> <int:channel/> <bean class="org.springframework.data.redis.serializer.StringRedisSerializer"/> <int:object-to-json-transformer input-channel="eventChannel" output-channel="eventChannelJson"/> </beans>

ในการกำหนดค่า คุณสามารถดูส่วน "int-redis:queue-outbound-channel-adapter" คุณสมบัติของมันคือ:

  • id: ชื่อ bean ของส่วนประกอบ
  • ช่อง: MessageChannel ที่ปลายทางนี้รับข้อความ
  • connection-factory: การอ้างอิงถึง RedisConnectionFactory bean
  • คิว: ชื่อของรายการ Redis ที่มีการดำเนินการพุชตามคิวเพื่อส่งข้อความ Redis คุณลักษณะนี้ไม่เกิดร่วมกันกับการแสดงคิว
  • นิพจน์คิว: นิพจน์ SpEL เพื่อกำหนดชื่อของรายการ Redis โดยใช้ข้อความขาเข้าที่รันไทม์เป็นตัวแปร #root แอ็ตทริบิวต์นี้ไม่เกิดร่วมกันกับคิว
  • serializer: การอ้างอิง RedisSerializer bean โดยค่าเริ่มต้น มันคือ JdkSerializationRedisSerializer อย่างไรก็ตาม สำหรับเพย์โหลด String จะมีการใช้ StringRedisSerializer หากไม่มีการอ้างอิงซีเรียลไลเซอร์
  • extract-payload: ระบุว่าปลายทางนี้ควรส่งเฉพาะเพย์โหลดไปยังคิว Redis หรือข้อความทั้งหมด ค่าเริ่มต้นของมันคือ true
  • กดซ้าย: ระบุว่าปลายทางนี้ควรใช้การกดซ้าย (เมื่อ true ) หรือกดขวา (เมื่อ false ) เพื่อเขียนข้อความไปยังรายการ Redis ถ้าเป็นจริง รายการ Redis จะทำหน้าที่เป็นคิว FIFO เมื่อใช้กับอะแด็ปเตอร์ช่องทางขาเข้าของคิว Redis ที่เป็นค่าเริ่มต้น ตั้งค่า false เพื่อใช้กับซอฟต์แวร์ที่อ่านจากรายการที่มีป๊อปอัปด้านซ้ายหรือเพื่อให้ได้ลำดับข้อความที่เหมือนสแต็ก ค่าเริ่มต้นของมันคือ true

ขั้นตอนต่อไปคือการกำหนดเกตเวย์ ซึ่งระบุไว้ในการกำหนดค่า .xml สำหรับเกตเวย์ เราใช้คลาส RedisChannelGateway จากแพ็คเกจ org.toptal.queue

StringRedisSerializer ใช้เพื่อจัดลำดับข้อความก่อนบันทึกใน Redis นอกจากนี้ ในการกำหนดค่า .xml เราได้กำหนดเกตเวย์และตั้งค่า RedisChannelGateway เป็นบริการเกตเวย์ ซึ่งหมายความว่า RedisChannelGateway bean สามารถฉีดเข้าไปใน bean อื่นได้ เรากำหนดคุณสมบัติ 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 ใช้เพื่อนำเข้าไฟล์การกำหนดค่า Spring .xml ไปที่ @Configuration และคำอธิบายประกอบ @AutoConfigureAfter ใช้เพื่อบอกใบ้ว่าควรใช้การกำหนดค่าอัตโนมัติหลังจากคลาสการกำหนดค่าอัตโนมัติอื่นๆ ที่ระบุ

ตอนนี้เราจะสร้างบริการและนำวิธีการที่จะจัด enqueue เหตุการณ์ไปยังคิว Redis

 public interface QueueService { void enqueue(PostPublishedEvent event); }
 @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

คิว Redis เป็นเพียงรายการที่มีผู้ผลิตและผู้บริโภคอย่างน้อยหนึ่งราย ในการเผยแพร่ข้อความไปยังคิว โปรดิวเซอร์ใช้คำสั่ง LPUSH Redis และถ้าคุณมอนิเตอร์ Redis (คำใบ้: พิมพ์ redis-cli monitor ) คุณจะเห็นว่าข้อความถูกเพิ่มในคิว:

 "LPUSH" "my-event-queue" "{\"postUrl\":\"test\",\"postTitle\":\"test\",\"emails\":[\"test\"]}"

ตอนนี้ เราต้องสร้างแอปพลิเคชันสำหรับผู้บริโภคซึ่งจะดึงเหตุการณ์เหล่านี้ออกจากคิวและประมวลผล บริการผู้บริโภคต้องการการพึ่งพาเดียวกันกับบริการของผู้ผลิต

ตอนนี้เราสามารถนำคลาส PostPublishedEvent กลับมาใช้ใหม่เพื่อยกเลิกการซีเรียลไลซ์ข้อความได้

เราจำเป็นต้องสร้างการกำหนดค่าคิวและต้องวางไว้ในไดเร็กทอรี resources/WEB-INF อีกครั้ง เนื้อหาของการกำหนดค่าคิวคือ:

 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:int="http://www.springframework.org/schema/integration" xmlns:int-redis="http://www.springframework.org/schema/integration/redis" xsi:schemaLocation="http://www.springframework.org/schema/integration/redis http://www.springframework.org/schema/integration/redis/spring-integration-redis.xsd http://www.springframework.org/schema/integration http://www.springframework.org/schema/integration/spring-integration.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> <int-redis:queue-inbound-channel-adapter channel="eventChannelJson" queue="my-event-queue" serializer="serializer" auto-startup="true" connection-factory="redisConnectionFactory"/> <int:channel/> <int:channel> <int:queue/> </int:channel> <bean class="org.springframework.data.redis.serializer.StringRedisSerializer"/> <int:json-to-object-transformer input-channel="eventChannelJson" output-channel="eventChannel" type="com.toptal.integration.spring.model.PostPublishedEvent"/> <int:service-activator input-channel="eventChannel" ref="RedisEventProcessingService" method="process"> <int:poller fixed-delay="10" time-unit="SECONDS" max-messages-per-poll="500"/> </int:service-activator> </beans>

ในการกำหนดค่า .xml int-redis:queue-inbound-channel-adapter สามารถมีคุณสมบัติต่อไปนี้:

  • id: ชื่อ bean ของส่วนประกอบ
  • channel: MessageChannel ที่เราส่งข้อความจากปลายทางนี้
  • การเริ่มต้นอัตโนมัติ: แอตทริบิวต์ SmartLifecycle เพื่อระบุว่าปลายทางนี้ควรเริ่มต้นโดยอัตโนมัติหลังจากบริบทของแอปพลิเคชันเริ่มต้นหรือไม่ ค่าเริ่มต้นของมันคือ true
  • เฟส: แอ็ตทริบิวต์ SmartLifecycle เพื่อระบุเฟสที่ปลายทางนี้จะเริ่มต้น ค่าเริ่มต้นของมันคือ 0
  • connection-factory: การอ้างอิงถึง RedisConnectionFactory bean
  • คิว: ชื่อของรายการ Redis ซึ่งดำเนินการป๊อปอัพตามคิวเพื่อรับข้อความ Redis
  • error-channel: MessageChannel ที่เราจะส่ง ErrorMessages พร้อม Exceptions จากงานฟังของ Endpoint โดยค่าเริ่มต้น MessagePublishingErrorHandler พื้นฐานจะใช้ errorChannel เริ่มต้นจากบริบทของแอปพลิเคชัน
  • serializer: การอ้างอิง RedisSerializer bean อาจเป็นสตริงว่าง ซึ่งหมายความว่าไม่มีซีเรียลไลเซอร์ ในกรณีนี้ byte[] จากข้อความ Redis ขาเข้าจะถูกส่งไปยังแชนเนลเป็นเพย์โหลดของ Message โดยค่าเริ่มต้น มันคือ JdkSerializationRedisSerializer
  • รับ-หมดเวลา: หมดเวลาในหน่วยมิลลิวินาทีสำหรับการดำเนินการป๊อปเพื่อรอข้อความ Redis จากคิว ค่าเริ่มต้นคือ 1 วินาที
  • ช่วงเวลาการกู้คืน: เวลาในหน่วยมิลลิวินาทีที่งาน Listener ควรสลีปหลังจากเกิดข้อยกเว้นในการดำเนินการป๊อปก่อนที่จะเริ่มงาน Listener ใหม่
  • ข้อความคาดหวัง: ระบุว่าปลายทางนี้คาดว่าข้อมูลจากคิว Redis จะมีข้อความทั้งหมดหรือไม่ หากแอตทริบิวต์นี้ถูกตั้งค่า true ตัวทำให้ซีเรียลไลเซอร์ไม่สามารถเป็นสตริงว่างได้ เนื่องจากข้อความต้องมีรูปแบบการดีซีเรียลไลซ์เซชันบางรูปแบบ (การทำให้เป็นอนุกรม JDK โดยค่าเริ่มต้น) ค่าเริ่มต้นของมันคือ false
  • task-executor: การอ้างอิงถึง Spring TaskExecutor (หรือ JDK 1.5+ Executor มาตรฐาน) ใช้สำหรับงานฟังพื้นฐาน ตามค่าเริ่มต้น SimpleAsyncTaskExecutor จะถูกใช้
  • right-pop: ระบุว่าปลายทางนี้ควรใช้ right pop (เมื่อ true ) หรือ left pop (เมื่อ false ) เพื่ออ่านข้อความจากรายการ Redis หาก true รายการ Redis จะทำหน้าที่เป็นคิว FIFO เมื่อใช้กับอะแด็ปเตอร์ช่องสัญญาณขาออกของคิว Redis ที่เป็นค่าเริ่มต้น ตั้งค่า false เพื่อใช้กับซอฟต์แวร์ที่เขียนไปยังรายการด้วยการกดขวาหรือเพื่อให้ได้ลำดับข้อความที่เหมือนสแต็ก ค่าเริ่มต้นของมันคือ true

ส่วนที่สำคัญคือ "ตัวเปิดใช้งานบริการ" ซึ่งกำหนดว่าบริการและวิธีใดควรใช้ในการประมวลผลเหตุการณ์

นอกจากนี้ json-to-object-transformer ยังต้องการแอตทริบิวต์ type เพื่อแปลง JSON เป็นอ็อบเจ็กต์ โดยตั้งค่าด้านบนเป็น type="com.toptal.integration.spring.model.PostPublishedEvent"

อีกครั้ง เพื่อเชื่อมต่อการกำหนดค่านี้ เราจำเป็นต้องมีคลาส SpringIntegrationConfig ซึ่งสามารถเป็นแบบเดิมได้ และสุดท้าย เราต้องการบริการที่จะประมวลผลเหตุการณ์ได้จริง

 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 :) } }

เมื่อคุณเรียกใช้แอปพลิเคชัน คุณจะเห็นใน Redis:

 "BRPOP" "my-event-queue" "1"

บทสรุป

ด้วย Spring Integration และ Redis การสร้างแอปพลิเคชัน Spring microservices ไม่ได้น่ากลัวอย่างที่ควรจะเป็น ด้วยการกำหนดค่าเพียงเล็กน้อยและโค้ดสำเร็จรูปจำนวนเล็กน้อย คุณสามารถสร้างรากฐานของสถาปัตยกรรมไมโครเซอร์วิสของคุณในเวลาไม่นาน

แม้ว่าคุณจะไม่ได้วางแผนที่จะขีดข่วนโปรเจ็กต์ Spring ปัจจุบันของคุณทั้งหมดและเปลี่ยนไปใช้สถาปัตยกรรมใหม่ ด้วยความช่วยเหลือของ Redis การปรับปรุงประสิทธิภาพอย่างมากด้วยคิวก็ทำได้ง่ายมาก