ทำไมคุณถึงต้องการเกตเวย์?
เรารู้ว่าเราต้องการป้อนบริการเองและเห็นได้ชัดว่าเราไม่มีวิธีที่ดีเป็นพิเศษ เราป้อนหมายเลขที่อยู่ IP + พอร์ตโดยตรง เรารู้ว่าวิธีนี้แย่มาก มีปัญหาใหญ่กับวิธีการนี้ ก่อนอื่นจะเปิดเผยที่อยู่ IP ของเครื่องทางกายภาพของเรา เมื่อคนอื่นดูที่ที่อยู่ IP ของคุณพวกเขารู้ว่าบริการถูกปรับใช้ที่ไหนช่วยให้ผู้อื่นดำเนินการโจมตีได้อย่างสะดวกสบายมาก
ประการที่สองเรามีบริการมากมายเราต้องโทรหาพวกเขาทีละคนหรือไม่? สมมติว่าเราได้ทำการรับรองความถูกต้องแล้วและลูกค้าแต่ละรายของเราเข้าถึงโปรแกรมบริการบน JVM ที่แตกต่างกันที่ทำงานบนเครื่องจักรที่แตกต่างกัน บริการแต่ละแห่งของเราต้องการการรับรองความถูกต้องของบริการ มันน่ารำคาญ? เห็นได้ชัดว่ามันน่ารำคาญมาก
จากนั้นเรากำลังเผชิญกับปัญหาสองอย่างนี้และปัญหาทั่วไปของพวกเขาในเวลานี้และเราต้องการวิธีแก้ปัญหา ก่อนอื่นมาดูการเปิดรับที่อยู่ IP และปัญหาจุดเดียวที่เกิดจากการเขียนที่อยู่ IP หลังความตาย ฉันจำเป็นต้องรักษารายการบริการสำหรับบริการดังกล่าวด้วยตัวเองหรือไม่? ฉันต้องเรียกบริการนี้ด้วยตัวเองฉันต้องการสิ่งที่สมดุลโหลดหรือไม่?
นอกจากนี้ยังมีสิ่งต่าง ๆ เกี่ยวกับการเปิดรับที่อยู่ IP ฉันจำเป็นต้องเป็นพร็อกซีเช่นพร็อกซีย้อนกลับของ Nginx และยังมีสิ่งต่าง ๆ ที่ปรับใช้โมดูลสาธารณะในสิ่งนี้เช่นการตรวจสอบการอนุญาตสำหรับพอร์ทัลทั้งหมด ดังนั้นตอนนี้เราต้องการเกตเวย์ Zuul API มันแก้ปัญหาข้างต้น หากคุณต้องการโทรหาบริการบางอย่างมันจะแมปคุณและแมปที่อยู่ IP ของบริการของคุณ
หากคุณเข้าสู่เส้นทางมันจะตรงกับมันและมันจะเข้าถึงบริการให้คุณ มันจะมีกระบวนการส่งต่อคำขอ เช่นเดียวกับ Nginx ความแข็งแกร่งเฉพาะของอินสแตนซ์ของเครื่องบริการมันจะไม่เข้าถึง IP โดยตรงมันจะไปที่ศูนย์ลงทะเบียนยูเรก้าเพื่อรับ ID อินสแตนซ์บริการนั่นคือชื่อบริการ ฉันใช้ริบบิ้นโหลดบาลานซ์ของลูกค้าเพื่อเข้าถึงหนึ่งในอินสแตนซ์บริการอีกครั้ง
เกตเวย์ API ส่วนใหญ่ใช้เพื่อแก้ปัญหาการโทรภายนอกโดยบริการเองและเพื่อแก้ปัญหาการตรวจสอบการอนุญาต คุณสามารถรวมและเรียกชุดของตัวกรองที่นี่เช่นการรวมชิโร่สปริงส์ความปลอดภัยและสิ่งอื่น ๆ
Zuul สามารถโหลดกลไกการกรองแบบไดนามิกเพื่อให้ได้ฟังก์ชั่นต่อไปนี้:
1. การตรวจสอบและความปลอดภัย: ระบุข้อกำหนดการตรวจสอบสำหรับทรัพยากรต่าง ๆ และปฏิเสธคำขอที่ไม่ตรงกับข้อกำหนด
2. การตรวจสอบและการตรวจสอบ: ติดตามข้อมูลที่มีความหมายและผลลัพธ์ทางสถิติที่สถานที่ขอบจึงนำข้อสรุปที่ถูกต้องของเราเกี่ยวกับสถานะการผลิต
3. การกำหนดเส้นทางแบบไดนามิก: คำขอเส้นทางไปยังกลุ่มแบ็กเอนด์ที่แตกต่างกันแบบไดนามิกตามต้องการ
4. การทดสอบความเครียด: ค่อยๆเพิ่มการไหลของโหลดไปยังคลัสเตอร์เพื่อคำนวณระดับประสิทธิภาพ
5. การจัดสรรโหลด: กำหนดความสามารถที่สอดคล้องกันให้กับแต่ละประเภทโหลดและคำขอเสียเปรียบที่เกินค่าขีด จำกัด
6. การประมวลผลการตอบสนองแบบคงที่: สร้างการตอบสนองบางส่วนโดยตรงที่ตำแหน่งขอบเพื่อป้องกันไม่ให้ไหลเข้าสู่คลัสเตอร์ภายใน
7. ความยืดหยุ่นหลายภูมิภาค: ขอการกำหนดเส้นทางข้ามภูมิภาค AWS ได้รับการออกแบบมาเพื่อให้ได้การใช้ ELB ที่หลากหลายและตรวจสอบให้แน่ใจว่าสถานที่ขอบใกล้เคียงที่สุดสำหรับผู้ใช้
ถัดไปไปที่การสาธิตเล็ก ๆ
ขั้นตอนแรกคือ การสร้างโมดูล Zuul ใหม่ภายใต้โครงการดั้งเดิมและแนะนำการอ้างอิง รหัสมีดังนี้:
<การพึ่งพา> <roupId> org.springframework.cloud </groupId> <ratifactid> Spring-Cloud-Starter-eureka </artifactid> <sersion> 1.3.5.Release </เวอร์ชัน> </การพึ่งพา> <Sersion> 1.3.5.Release </เวอร์ชัน> </derctency>
จากนั้นพิมพ์คำอธิบายประกอบ @enablezuulproxy บนคลาสเริ่มต้นและรหัสมีดังนี้:
เซิร์ฟเวอร์: พอร์ต: 5000spring: แอปพลิเคชัน: ชื่อ: API-GETEWAYZUUL: เส้นทาง: #Identify ชื่อบริการของคุณซึ่งสามารถกำหนดได้ด้วยตัวเองที่นี่ โดยทั่วไปการพูดความสะดวกสบายและข้อกำหนดจะเหมือนกับชื่อบริการของคุณ Hello-Service:#เส้นทางของการทำแผนที่บริการผ่านเส้นทางนี้คุณสามารถเข้าถึงบริการของคุณจากภายนอก วัตถุประสงค์คือเพื่อหลีกเลี่ยงการเปิดเผย IP ของเครื่องและเส้นทางที่มุ่งเน้นบริการและเลือกเส้นทางที่มีให้สำหรับคุณ #here, Zuul โดยอัตโนมัติขึ้นอยู่กับ Hystrix และ Ribbon ไม่ใช่สำหรับเส้นทางแบบสแตนด์อโลน: /Hello-Service /**# นี่จะต้องเป็นชื่อของบริการในศูนย์ลงทะเบียนยูเรก้าของคุณ ดังนั้น ServiceID จึงถูกกำหนดค่าที่นี่เพราะรวมกับยูเรก้า หากคุณใช้ Zuul เพียงอย่างเดียวคุณต้องเขียน IP ของเครื่องของคุณเอง #SUCH AS URL: http: // localhost: 8080/นี่ไม่ดีพอที่จะเขียน IP ตาย หาก IP นี้ล้มเหลวและนี่คือความพร้อมใช้งานสูงชุดการลงทะเบียนบริการจะไม่ถูกใช้ ServiceId: Hello-ServiceEureka: #Client: #Registration Center ที่อยู่ Service-URL: DefaultZone: http: // localhost: 8888/eureka/, http: // localhost: 8889/eureka/
จากนั้นเริ่มศูนย์รีจิสทรีและผู้ให้บริการ Hello-Service สองรายในบทความก่อนหน้า จากนั้นเราก็เรียกใช้และดูฟังก์ชั่นการส่งต่อคำขอเพื่อดูว่ามีการสำรวจความคิดเห็นเป็นสองบริการหรือไม่
ป้อน LocalHost: 5000/Hello-Service/Hello ดังต่อไปนี้:
จากนั้นรีเฟรชอีกครั้ง:
คุณจะเห็นว่า Zuul ได้ทำการร้องขอเพื่อแจกจ่าย มันถูกแมปกับเครื่องเฉพาะตามชื่อบริการของคุณ Hello-Servie นี่ไม่ใช่ฟังก์ชั่นของพร็อกซีย้อนกลับหรือไม่?
Zuul ยังสามารถดำเนินการกรองคำขอได้ดังนั้นลองทำการตรวจสอบโทเค็นเพื่อแสดงให้เห็น ก่อนอื่นเราต้องสร้างคลาสโทเค็นฟิลเตอร์ใหม่เพื่อสืบทอดคลาส Zuulfilter และใช้อินเทอร์เฟซสี่แบบ รหัสมีดังนี้:
แพ็คเกจ hjc.zuul; นำเข้า com.netflix.zuul.zuulfilter; นำเข้า com.netflix.zuul.context.requestcontext; นำเข้า Javax.servlet.http.httpservletrequest; */คลาสสาธารณะ TokenFilter ขยาย Zuulfilter {// สี่ประเภท: ก่อนการกำหนดเส้นทางข้อผิดพลาดโพสต์ // ก่อน: มันส่วนใหญ่จะใช้ในขั้นตอนการแมปการกำหนดเส้นทางเพื่อค้นหาตารางการแมปการกำหนดเส้นทาง // การกำหนดเส้นทาง: ตัวกรองการส่งต่อเส้นทางที่เฉพาะเจาะจงอยู่บนเราเตอร์ เมื่อส่งต่อคำขอเฉพาะจะมีการเรียก // ข้อผิดพลาด: เมื่อเกิดข้อผิดพลาดตัวกรองก่อนหน้านี้จะเรียกตัวกรองข้อผิดพลาด // โพสต์: ตัวกรองนี้จะไม่ถูกเรียกหลังจากการกำหนดเส้นทางและข้อผิดพลาดเสร็จสมบูรณ์ มันคือ @Override Public String FilterType () {return "pre"; } // ปรับแต่งลำดับการดำเนินการของตัวกรอง ค่าที่ใหญ่ขึ้นในภายหลังการดำเนินการ ยิ่งค่ามีขนาดเล็กลงเท่าไหร่ก็ยิ่งดำเนินการมากขึ้นเท่านั้น @Override public int filterOrder () {return 0; } // ควบคุมตัวกรองให้มีผลหรือไม่ คุณสามารถเขียนสตริงของตรรกะในนั้นเพื่อควบคุม @Override บูลีนสาธารณะควร filter () {return true; } // ดำเนินการตัวกรองลอจิก @Override วัตถุสาธารณะรัน () {requestcontext context = requestcontext.getCurrentContext (); httpservletRequest Request = context.getRequest (); สตริงโทเค็น = request.getParameter ("โทเค็น"); if (token == null) {context.setSendzuulResponse (เท็จ); Context.SetResponSestatusCode (401); Context.setResponseBody ("unauthrized"); คืนค่า null; } return null; -FilterType: ส่งคืนสตริงที่แสดงถึงประเภทของตัวกรอง สี่ประเภทตัวกรองที่มีวงจรชีวิตที่แตกต่างกันถูกกำหนดใน Zuul ดังนี้:
1. pre : สามารถเรียกได้ก่อนที่คำขอจะถูกกำหนดเส้นทาง มันถูกใช้เพื่อค้นหาตารางการทำแผนที่การกำหนดเส้นทางระหว่างขั้นตอนการทำแผนที่การกำหนดเส้นทาง
2.route : ถูกเรียกในระหว่างการร้องขอการกำหนดเส้นทาง ตัวกรองการส่งต่อการกำหนดเส้นทางที่เฉพาะเจาะจงจะถูกเรียกเมื่อกำหนดเส้นทางการส่งต่อคำขอเฉพาะของเราเตอร์
3. error : เรียกเมื่อเกิดข้อผิดพลาดขณะประมวลผลคำขอ
4. post : ตัวกรองจะไม่ถูกเรียกหลังจากการกำหนดเส้นทางและข้อผิดพลาดเสร็จสมบูรณ์ซึ่งอยู่ในขั้นตอนสุดท้าย
ที่นี่เราประกาศข้อยกเว้นที่เกิดขึ้นเมื่อตัวกรอง Zuul ดำเนินการคำขอเครือข่าย ข้อยกเว้นที่จับโดยการจับไม่สามารถโยนลงไปที่หน้าในตัวกรองได้โดยตรง ข้อยกเว้นที่แอปพลิเคชันสามารถส่งกลับไปยังหน้าโดยใช้เมธอด context.set () ในการจับ ดังนี้:
ลอง {Business Logic ... } catch (Exception e) {requestcontext context = requestcontext.getCurrentContext (); context.set ("error.status_code", 401); context.set ("error.exception", e); context.set ("error.message", "sfdfsdf");}ถัดไปคุณจะต้องเพิ่มตัวกรองนี้ลงในสปริงและปล่อยให้สปริงจัดการได้ รหัสมีดังนี้:
แพ็คเกจ HJC; นำเข้า hjc.zuul.tokenfilter; นำเข้า org.springframework.boot.springapplication; นำเข้า org.springframework.boot.autoconfigure.springbootapplication; org.springframework.context.annotation.bean;@springbootapplication@enablezuulproxypublic zuulapplication {โมฆะคงที่สาธารณะหลัก (สตริง [] args) {springapplication.run (zuulapplication.class, args); } // ปล่อยให้ตัวกรองไปยังสปริงการจัดการ @bean สาธารณะ Tokenfilter tokenfilter () {ส่งคืน tokenfilter ใหม่ (); -ถัดไปเริ่มคลาสเริ่มต้นและการเข้าถึงครั้งแรกโดยไม่ต้องโทเค็นดังนี้:
คุณจะเห็นว่าข้อความโดยไม่ได้รับอนุญาตจะถูกส่งคืน ที่นี่ฉันอยากจะบอกว่าโทเค็นมักจะอยู่ในส่วนหัวคำขอ ที่นี่เราไม่ได้ทำเพื่อจุดประสงค์ในการสาธิต
จากนั้นนำโทเค็นและเยี่ยมชมดังนี้:
คุณจะเห็นว่าคำขอของเราถูกส่งไปแล้ว
ที่นี่ฉันจะพูดคุยเกี่ยวกับเส้นทางเริ่มต้นและลบการกำหนดค่า Zuul ดังต่อไปนี้:
เซิร์ฟเวอร์: พอร์ต: 5000spring: แอปพลิเคชัน: ชื่อ: API-GETEWAYEUREKA: #Client Client: #REGISTER CENTER SERVICE-URL: DefaultZone: http: // localhost: 8888/EUREKA/, http: // localhost: 8889/Eureka/
จากนั้นรีสตาร์ทและเข้าถึงต่อไปดังนี้:
-
คุณจะเห็นว่าเรายังสามารถเข้าถึงต่อไปได้ เราไม่มีอะไรทำ แต่เรายังสามารถเข้าถึงได้ นั่นเป็นเพราะโดยค่าเริ่มต้นคุณจะได้รับการประกาศโดยอัตโนมัติด้วยชื่อบริการของคุณ Hello-Service
ดังนั้นถ้าฉันไม่ต้องการให้มันประกาศโดยอัตโนมัติสำหรับฉันและฉันต้องการกำหนดด้วยตัวเองฉันสามารถใช้ zuu.ignored-services ในไฟล์กำหนดค่า YML เพื่อกรองเช่นการกรองดังนี้: "
Zuul:#หากไม่ได้รับบริการ:* หมายความว่าเส้นทางเริ่มต้นทั้งหมดหมดอายุแล้ว คุณต้องจับคู่พวกเขาทีละคน จะไม่มีใครระยำเว้นแต่คุณจะพบธุรกิจแปลก ๆ เพิกเฉยต่อบริการ:
มาพูดถึงกฎการแมปกันเถอะ
Zuul: เส้นทาง: #Identify ชื่อบริการของคุณคุณสามารถกำหนดเองได้ที่นี่ โดยทั่วไปการพูดความสะดวกสบายและข้อกำหนดจะเหมือนกับชื่อบริการของคุณ Hello-Service: #Service Mapped Path ผ่านเส้นทางนี้คุณสามารถเข้าถึงบริการของคุณจากภายนอก วัตถุประสงค์คือเพื่อหลีกเลี่ยงการเปิดเผย IP ของเครื่องของคุณและเส้นทางที่มุ่งเน้นบริการนั้นเหมาะสำหรับคุณ #Here Zuul ขึ้นอยู่กับ Hystrix และ Ribbon โดยอัตโนมัติไม่ใช่สำหรับเส้นทางแบบสแตนด์อโลน: /Hello-Service /**#นี่จะต้องเป็นชื่อของบริการศูนย์การลงทะเบียนยูเรก้าของคุณดังนั้น ServiceId จึงถูกกำหนดค่าที่นี่ หากคุณใช้ zuul เพียงอย่างเดียวคุณต้องเขียน IP ของเครื่องของคุณ #SUCH เป็น URL: http: // localhost: 8080/สิ่งนี้ไม่ดีนั่นหมายถึงการเขียน IP ตาย หาก IP นี้ล้มเหลวและมีความพร้อมใช้งานสูงชุดลงทะเบียนบริการจะไม่ถูกใช้ ServiceId: Hello-ServiceZuul: เส้นทาง: Hello-Service: Path:/Hello-Service/Ext/** บริการ: Hello-Service
เส้นทางการแมปการกำหนดค่า Zuul สองเส้นทางที่นี่มี /hello-service / คุณจะเห็นว่า/hello-service/** รวม/hello-service/ext/** มีความขัดแย้งใด ๆ เมื่อจับคู่เส้นทางทั้งสองนี้หรือไม่? จะจัดการกับมันได้อย่างไร? ใครจะจับคู่ก่อน?
นี่คือคำสั่งที่กำหนดไว้ใน YML เพื่อให้ตรงกับ หากเป็นไฟล์การกำหนดค่าในรูปแบบแอปพลิเคชัน properties คำสั่งนี้ไม่สามารถรับประกันได้ ไฟล์การกำหนดค่าในรูปแบบ YML นั้นอยู่ในลำดับซึ่งสามารถรับประกันได้ โปรดทราบที่นี่
ถ้าเราต้องการกำหนดกฎการจับคู่ จากนั้นเราต้องกำหนดถั่วในคลาสเริ่มต้นซึ่งกำหนดเส้นทางของคุณดังนี้:
ฉันจะไม่แสดงที่นี่ เมื่อคุณต้องการให้ไปค้นหาข้อมูลอย่างช้าๆ
นอกจากนี้ยังมีการละเว้นรูปแบบ: ดังนี้:
Zuul: เส้นทาง: #Identify ชื่อบริการของคุณคุณสามารถกำหนดเองได้ที่นี่ โดยทั่วไปการพูดความสะดวกสบายและข้อกำหนดจะเหมือนกับชื่อบริการของคุณ Hello-Service: #Service Mapped Path ผ่านเส้นทางนี้คุณสามารถเข้าถึงบริการของคุณจากภายนอก วัตถุประสงค์คือเพื่อหลีกเลี่ยงการเปิดเผย IP ของเครื่องของคุณและเส้นทางที่มุ่งเน้นบริการนั้นเหมาะสำหรับคุณ #Here Zuul ขึ้นอยู่กับ Hystrix และ Ribbon โดยอัตโนมัติไม่ใช่สำหรับเส้นทางแบบสแตนด์อโลน: /Hello-Service /**#นี่จะต้องเป็นชื่อของบริการศูนย์การลงทะเบียนยูเรก้าของคุณดังนั้น ServiceId จึงถูกกำหนดค่าที่นี่ หากคุณใช้ Zuul เพียงอย่างเดียวคุณต้องเขียน IP ของเครื่องของคุณ #SUCH เป็น URL: http: // localhost: 8080/นี่เป็นสิ่งที่ไม่ดีนั่นหมายถึงการเขียน IP ที่ตายแล้ว หาก IP นี้ล้มเหลวและมีความพร้อมใช้งานสูงชุดลงทะเบียนบริการจะไม่ถูกใช้ ServiceId: Hello-Service ถูกละเว้นรูปแบบ: /Hello /**
ละเว้นรูปแบบ: ระบุว่าเส้นทางของ /hello /** ถูกบล็อก แม้ว่าคุณ/Hello-Service/Hello/** เป็นไปไม่ได้คุณก็ยังบล็อกอยู่ เราสามารถปรับแต่งการกำหนดค่านี้เพิ่มเติมได้ ตัวอย่างเช่นหากฉันไม่ต้องการกำหนดเส้นทาง /Hello Interface เราสามารถกำหนดค่าได้ตามด้านบน
ถ้าเราต้องการกำหนดค่าคำนำหน้าของบริการด้วย รหัสมีดังนี้:
Zuul: เส้นทาง: #Identify ชื่อบริการของคุณคุณสามารถกำหนดเองได้ที่นี่ โดยทั่วไปการพูดความสะดวกสบายและข้อกำหนดจะเหมือนกับชื่อบริการของคุณ Hello-Service: #Service Mapped Path ผ่านเส้นทางนี้คุณสามารถเข้าถึงบริการของคุณจากภายนอก วัตถุประสงค์คือเพื่อหลีกเลี่ยงการเปิดเผย IP ของเครื่องของคุณและเส้นทางที่มุ่งเน้นบริการนั้นเหมาะสำหรับคุณ #Here Zuul ขึ้นอยู่กับ Hystrix และ Ribbon โดยอัตโนมัติไม่ใช่สำหรับเส้นทางแบบสแตนด์อโลน: /Hello-Service /**#นี่จะต้องเป็นชื่อของบริการศูนย์การลงทะเบียนยูเรก้าของคุณดังนั้น ServiceId จึงถูกกำหนดค่าที่นี่ หากคุณใช้ Zuul เพียงอย่างเดียวคุณต้องเขียน IP ของเครื่องของคุณ #SUCH เป็น URL: http: // localhost: 8080/นี่ไม่ดีพอที่จะเขียน IP ที่ตายแล้ว หาก IP นี้ล้มเหลวจะมีอยู่อย่างสูงและชุดการลงทะเบียนบริการจะไม่ถูกใช้ ServiceId: คำนำหน้าบริการสวัสดี: /API /**
คุณจะเห็นว่าบริการที่คุณเยี่ยมชมจะต้องนำหน้าด้วย/api/เช่น/api/hello-service/**
เราควรทำอย่างไรถ้าเราต้องการข้ามไปยังพื้นที่ท้องถิ่นของฉันหากเราต้องการเข้าถึงเส้นทาง?
ฉันหวังว่าผู้ใช้จะสามารถข้ามไปยังวิธีนี้โดยอัตโนมัติเมื่อเข้าถึง /ท้องถิ่น ดังนั้นในเวลานี้เราจำเป็นต้องใช้การกระโดดในท้องถิ่นของ Zuul และวิธีการกำหนดค่ามีดังนี้:
zuul: คำนำหน้า:/api ที่ถูกเพิกเฉยต่อรูปแบบ:/**/hello/** เส้นทาง: local: path:/hello-service/** url: ส่งต่อ:/local
บางส่วนที่ใช้กันทั่วไปซึ่งเชื่อมต่อกับสปริงส์ความปลอดภัยหรือส่วนประกอบของบุคคลที่สามบางส่วนจะได้รับข้อมูลคุกกี้ของคุณ ดังนั้น Zuul Gateway จึงฆ่าข้อมูลคุกกี้ทั้งหมดของคุณด้วยเหตุผลด้านความปลอดภัยและไม่มีวิธีทำคุกกี้ มันถูกฆ่าโดยค่าเริ่มต้น
ที่นี่ Zuul จัดหา zuul.sensitive-headers เพื่อสร้างคุกกี้และส่วนหัวเหล่านี้ให้คุณและอย่ากรองข้อมูลเหล่านี้ ควบคุมข้อมูลที่ละเอียดอ่อนของคุณ
โดยค่าเริ่มต้นข้อมูลส่วนหัวที่ละเอียดอ่อนไม่สามารถส่งผ่านเกตเวย์ API เราสามารถทำให้ผ่านการกำหนดค่าต่อไปนี้:
Zuul: เส้นทาง: Hello-Service: Path: /Hello-Service /** ServiceId: Hello-Service Sensitive-Headers: Cookie, Header และสิ่งอื่น ๆ
นอกจากนี้ยังสามารถใช้กับการกำหนดค่าโดยละเอียดของ Hystrix ดังที่ได้กล่าวไว้ก่อนหน้านี้ ฉันจะไม่พูดถึงเรื่องนี้ที่นี่
ข้างต้นเป็นเนื้อหาทั้งหมดของบทความนี้ ฉันหวังว่ามันจะเป็นประโยชน์ต่อการเรียนรู้ของทุกคนและฉันหวังว่าทุกคนจะสนับสนุน wulin.com มากขึ้น