ในสถาปัตยกรรม microservices ที่เชื่อมโยงกันอย่างหลวม ๆ คุณจะติดตามการพึ่งพาของคุณได้อย่างไร

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

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

รูปแบบหรือเครื่องมือใดที่สามารถนำมาใช้เพื่อลดความเสี่ยงนี้และให้ทัศนวิสัยที่ดีขึ้นในการพึ่งพาของสถาปัตยกรรมคู่ที่หลวม

— เดวิดพูดว่า Reinstate Monica
แหล่งที่มา

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

— Frank Hileman

@ FrankHileman การทดสอบเห็นได้ชัดว่าช่วย แต่ฉันพบว่ามันยากที่จะเชื่อว่านี่เป็นทางออกเดียวที่มี นอกจากนี้ยังมีหลายภาษาที่ไม่มีการตรวจสอบเวลาคอมไพล์ (เช่น JS หรือ Python) ดังนั้นแม้จะมีการเชื่อมต่ออย่างแน่นหนาคุณก็จะยังมีปัญหาอยู่

— David พูดว่า Reinstate Monica

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

— Frank Hileman

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

— Laiv

@Laiv ฉันอยากรู้อยากเห็นเกี่ยวกับบริการ RESTful โดยเฉพาะดังนั้นจึงไม่ใช่ตัวเลือกเพราะใคร ๆ ก็สามารถส่งคำขอ HTTP ได้ไม่มากก็น้อย

— David พูดว่า Reinstate Monica

คำตอบ:

รูปแบบหรือเครื่องมือใดที่สามารถใช้เพื่อลดความเสี่ยงนี้

การรักษา API ของคุณและความสามารถทางธุรกิจของคุณสามารถใช้งานได้ย้อนหลัง

ให้การมองเห็นที่ชัดเจนขึ้นเกี่ยวกับสิ่งที่การพึ่งพาของสถาปัตยกรรมคู่ที่หลวม

ตรวจสุขภาพ

บริการของฉันคือไคลเอนต์สำหรับความสามารถของ API รายเดือนของคุณ แต่บริการของฉันคือลูกค้าของ API ทุกครั้งที่บริการของฉันทำงานอยู่ ดังนั้นบริการของฉันจะตื่นขึ้นทุกๆ 10 นาทีหรืออะไรก็ตามที่เชื่อมต่อกับ API รายเดือนของคุณและเรียกใช้โปรโตคอลเพื่อให้แน่ใจว่าความสามารถในการบริการที่ฉันต้องการยังคงมีอยู่

ดังนั้นบันทึกของคุณจะแสดงให้คุณเห็นว่าบริการอื่น ๆ ตรวจสอบบ่อยแค่ไหนเพื่อดูว่าบริการเฉพาะที่คุณเสนอยังคงมีอยู่เหมือนเดิมซึ่งจะแสดงให้คุณเห็นว่าบริการที่คุณเสนอนั้นใช้บริการบ่อยแค่ไหน

— VoiceOfUnreason
แหล่งที่มา

มีอย่างน้อยสองตำแหน่งที่คุณสามารถค้นหาการอ้างอิง:

องค์ประกอบ การเข้าถึง API ภายนอกต้องทราบข้อมูลมากมายเกี่ยวกับ API เหล่านั้นแต่ละรายการ ID การเข้าถึงคีย์ลับจุดสิ้นสุด ทั้งหมดนี้ไม่สามารถอยู่ในรหัสได้เนื่องจากข้อมูลดังกล่าวจะเปลี่ยนแปลง ตัวอย่างฉันเพิ่งเริ่มโยกย้าย microservices ทั้งหมดของฉันไปยัง SSL ซึ่งหมายความว่าการให้บริการซึ่งอาศัยที่หนึ่งที่มีการอพยพควรจะยกเครื่องไปยังจุดที่จะทุกรุ่นแทนhttps:// http://ฉันดีใจที่จุดสิ้นสุดอยู่ในการกำหนดค่าแทนที่จะเป็นฮาร์ดโค้ด
อินเตอร์เฟซ คุณไม่สามารถเข้าถึงบริการได้โดยตรงจากรหัสของคุณเนื่องจากเวอร์ชัน API จะเปลี่ยนแปลงและคุณอาจตัดสินใจเปลี่ยนไปใช้ API อื่น คุณสร้างเลเยอร์ที่เป็นนามธรรมแทนและใช้การพึ่งพาผ่านอินเตอร์เฟส โดยทำตามตรรกะทั่วไปเมื่อสร้างอินเทอร์เฟซเหล่านั้นคุณสามารถทำให้ชีวิตของคุณง่ายขึ้นในภายหลังเมื่อค้นหาการอ้างอิง

เมื่อถึงเวลาต้องปรับโครงสร้างการโทรรายไตรมาสมีความเสี่ยงสูงที่จะแตกหัก

นี่คือการทดสอบการถดถอยสำหรับ

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

— Arseni Mourzenko
แหล่งที่มา

-2

REST APIs มีการระบุไว้อย่างหลวม ๆ ดังนั้นในบางจุดอาจมีประโยชน์ในการย้ายไปที่ gRPC, google protobufs หรือ Thrift เพื่อกำหนดอินเตอร์เฟส RPC จากนั้นให้ทำการอัพเกรด

— แพทริค
แหล่งที่มา

นี่อาจจะดีกว่าเป็นความคิดเห็น ... แต่ความซื่อสัตย์นี้ไม่ได้อธิบายมาก

— David พูดว่า Reinstate Monica

ยุติธรรมพอสมควร API ส่วนที่เหลือไม่มีการพึ่งพาเวลารวบรวมเฉพาะกับบริการอื่นเนื่องจากการเชื่อมโยงระหว่างทั้งสองเป็นเพียงแค่การโทรส่วนที่เหลือ HTTP บางอย่างเช่นโฮสต์และเส้นทาง ด้วย gRPC หรือ Protobuf หรือ Thrift อินเตอร์เฟซที่กำหนดซึ่งจะใช้ในการสร้างรหัส รหัสที่สร้างขึ้นได้รับการคอมไพล์และกำหนดเวอร์ชันแล้วบริการของคุณจะถูกสร้างขึ้นสำหรับส่วนต่อประสานเหล่านั้น ผลที่ได้คือบริการแต่ละบริการจะขึ้นอยู่กับส่วนต่อประสานบริการอื่นของคุณอย่างน้อยหนึ่งรายการ หวังว่าจะได้คำตอบที่ชัดเจน!

— Patrick