Summary (สรุป)

เราครอบคลุมเนื้อหามากมายในบทนี้—มาแยกส่วนบางส่วนของมันกัน:

  • เริ่มต้นก่อนอื่นเลย ให้แน่ใจว่าปัญหาที่คุณกำลังพยายามแก้เป็นตัวนำทางการเลือกเทคโนโลยีของคุณ จากบริบทของคุณและสไตล์การสื่อสารที่ คุณต้องการ เลือกเทคโนโลยีที่เหมาะสมที่สุดสำหรับคุณ—อย่าตกหลุมพรางของการเลือกเทคโนโลยีก่อน สรุปสไตล์ของการสื่อสารระหว่างไมโครเซอร์วิส ที่แนะนำครั้งแรกใน Chapter 4 และแสดงอีกครั้งใน Figure 5-10 สามารถช่วยชี้นำการตัดสินใจของคุณได้ แต่การทำตามโมเดลนี้เพียงอย่างเดียวไม่ได้แทนที่การนั่งลงและคิดเกี่ยวกับสถานการณ์ของคุณเอง

Different styles of inter-microservice communication along with example implementing technologies

Figure 5-10. Different styles of inter-microservice communication, along with example implementing technologies (สไตล์ที่แตกต่างกันของการสื่อสารระหว่างไมโครเซอร์วิส พร้อมกับตัวอย่างเทคโนโลยีที่ใช้ implement)

  • ไม่ว่าคุณจะเลือกอะไร ให้พิจารณาการใช้ schema ส่วนหนึ่งเพื่อช่วยทำให้ contract ของคุณชัดเจนขึ้น แต่ก็เพื่อช่วยจับ breaking change ที่เกิดโดยไม่ตั้งใจด้วย

  • เมื่อทำได้ ให้พยายามทำการเปลี่ยนแปลงที่ backward compatible เพื่อให้แน่ใจว่า independent deployability ยังคงเป็นไปได้

  • ถ้าคุณจำเป็นต้องทำ backward-incompatible change หาวิธีให้เวลาผู้เรียกใช้ในการ upgrade เพื่อหลีกเลี่ยง lockstep deployment

  • คิดเกี่ยวกับสิ่งที่คุณสามารถทำได้เพื่อช่วยแสดงข้อมูลเกี่ยวกับ endpoint ของคุณให้กับมนุษย์—พิจารณาการใช้ humane registry และสิ่งที่คล้ายกันเพื่อช่วยทำความเข้าใจความโกลาหล

เราได้ดูว่าเราสามารถ implement การเรียกระหว่างไมโครเซอร์วิสสองตัวได้อย่างไร แต่จะเกิดอะไรขึ้นเมื่อเราต้องประสาน operation ระหว่าง ไมโครเซอร์วิสหลายตัว? นั่นจะเป็นจุดเน้นของบทถัดไปของเรา

1 Martin Fowler สำรวจเรื่องนี้ในรายละเอียดมากขึ้นในบริบทของ schemaless data storage

2 ควรสังเกตว่าจริงๆ แล้วมีเครื่องมือที่แตกต่างกันสามตัวในพื้นที่นี้ที่มีชื่อเดียวกัน! เครื่องมือ openapi-diff ที่ https://github.com/Azure/openapi-diff ดูเหมือน จะใกล้เคียงที่สุดกับเครื่องมือที่ pass หรือ fail compatibility ได้จริง