การสื่อสารไมโครเซอร์วิส: บทช่วยสอนการบูรณาการในฤดูใบไม้ผลิกับ Redis
เผยแพร่แล้ว: 2022-03-11สถาปัตยกรรมไมโครเซอร์วิสเป็นวิธีที่ได้รับความนิยมอย่างมากในการออกแบบและใช้งานเว็บแอปพลิเคชันที่ปรับขนาดได้สูง การสื่อสารภายในแอปพลิเคชันแบบเสาหินระหว่างส่วนประกอบมักจะใช้เมธอดหรือการเรียกใช้ฟังก์ชันภายในกระบวนการเดียวกัน ในทางกลับกัน แอปพลิเคชันที่ใช้ไมโครเซอร์วิสเป็นระบบแบบกระจายที่ทำงานบนหลายเครื่อง
การสื่อสารระหว่างไมโครเซอร์วิสเหล่านี้มีความสำคัญเพื่อให้ระบบมีเสถียรภาพและสามารถปรับขนาดได้ มีหลายวิธีในการทำเช่นนี้ การสื่อสารด้วยข้อความเป็นวิธีหนึ่งในการดำเนินการนี้อย่างน่าเชื่อถือ
เมื่อใช้การส่งข้อความ ส่วนประกอบจะโต้ตอบกันโดยการแลกเปลี่ยนข้อความแบบอะซิงโครนัส ข้อความจะถูกแลกเปลี่ยนผ่านช่องทาง
เมื่อบริการ 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 การปรับปรุงประสิทธิภาพอย่างมากด้วยคิวก็ทำได้ง่ายมาก