เบื้องหน้า
เรากำลังเปลี่ยนจากแพลตฟอร์มเสาหินเป็นสถาปัตยกรรมที่เน้นการบริการมากขึ้น เราใช้หลักการ DDD ขั้นพื้นฐานมากและแยกโดเมนของเรากับบริบทที่แตกต่างกัน แต่ละโดเมนมีการกระจายและเปิดเผยบริการผ่านเว็บ API (REST)
เนื่องจากลักษณะของธุรกิจของเราเรามีบริการเช่นการจอง , บริการ , ลูกค้า , ผลิตภัณฑ์ฯลฯ
เรายังได้ติดตั้งเซิร์ฟเวอร์ข้อมูลประจำตัว (ขึ้นอยู่กับเซิร์ฟเวอร์ข้อมูลประจำตัวของ Thinktecture 3) ซึ่งมีบทบาทหลักคือ:
- การพิสูจน์ตัวตนจากศูนย์กลาง (ให้ข้อมูลรับรองว่ามันเป็นปัญหาโทเค็น)
- เพิ่มการอ้างสิทธิ์ในโทเค็นเช่น: ขอบเขตของลูกค้า (ตามลูกค้าฉันหมายถึงแอปพลิเคชันที่ทำการร้องขอ), ตัวระบุลูกค้า (ตามลูกค้าฉันหมายถึงบุคคลที่ใช้แอปพลิเคชัน)
นอกจากนี้เรายังแนะนำบทบาทของAPI เกตเวย์ซึ่งเป็นศูนย์กลางการเข้าถึงจากภายนอกสู่บริการของเรา API Gateway มีฟังก์ชันที่ไม่ต้องการความรู้อย่างลึกซึ้งเกี่ยวกับโดเมนภายในเช่น:
- Reverse proxy: กำหนดเส้นทางคำขอที่เข้ามาในบริการภายในที่เหมาะสม
- การกำหนดเวอร์ชัน: เวอร์ชันของ API เกตเวย์จับคู่กับเวอร์ชันต่างๆของบริการภายใน
- การตรวจสอบความถูกต้อง: คำขอของลูกค้ารวมถึงโทเค็นที่ออกโดยเซิร์ฟเวอร์ประจำตัวและ API เกตเวย์ตรวจสอบโทเค็น (ตรวจสอบให้แน่ใจว่าผู้ใช้คือใครบอกว่าเธอเป็น)
- การควบคุมปริมาณ: จำกัด จำนวนการร้องขอต่อลูกค้า
การอนุญาต
สิ่งที่เกี่ยวข้องกับการอนุญาตนี้ไม่ได้รับการจัดการใน API เกตเวย์ แต่ในบริการภายในตัวเอง ขณะนี้เรากำลังทำการอนุญาต 2 ประเภทหลัก:
- การอนุญาตตามขอบเขตของไคลเอ็นต์ ตัวอย่าง: ลูกค้า (แอปพลิเคชันภายนอกที่ใช้ API ของเรา) ต้องใช้ขอบเขต "การจอง" เพื่อเข้าถึงจุดสิ้นสุดบริการ API ของBookings
- การอนุญาตขึ้นอยู่กับลูกค้า ตัวอย่าง: เฉพาะเมื่อลูกค้า (บุคคลที่ใช้แอพพลิเคชั่น) เป็นผู้เข้าร่วมการจองสามารถเข้าถึงจุดสิ้นสุด GET / การจองจากบริการการจอง
เพื่อให้สามารถจัดการการอนุญาตในบริการภายใน API เกตเวย์จะส่งต่อโทเค็น (เมื่อกำหนดเส้นทางการร้องขอไปยังบริการภายใน) ซึ่งรวมถึงข้อมูลเกี่ยวกับลูกค้า (แอปพลิเคชันที่ทำการร้องขอ) และลูกค้าเป็นข้อเรียกร้อง (ใน กรณีที่บุคคลถูกบันทึกไว้ในแอปพลิเคชันไคลเอนต์)
คำอธิบายปัญหา
ดีมากจนกระทั่งเราแนะนำการสื่อสารระหว่างบริการ (บริการบางอย่างสามารถสื่อสารกับบริการอื่น ๆ เพื่อรับข้อมูลบางอย่าง)
คำถาม
เราควรเข้าหาการอนุญาตในการสื่อสารระหว่างบริการอย่างไร
พิจารณาตัวเลือก
เพื่อหารือเกี่ยวกับตัวเลือกต่าง ๆ ฉันจะใช้สถานการณ์ตัวอย่างต่อไปนี้:
- เรามีแอปพลิเคชันภายนอกที่ชื่อว่าExternalAppที่เข้าถึง API ของเรา ( สามารถมองเห็นExternalAppเป็นไคลเอนต์ ) เพื่อสร้างขั้นตอนการจอง
- ExternalAppต้องการการเข้าถึงบริการการจองดังนั้นเราจึงอนุญาตให้ขอบเขต "การจอง" ExternalApp
- ภายใน (นี่เป็นสิ่งที่โปร่งใสอย่างสมบูรณ์สำหรับExternalApp ) บริการการจองจะเข้าใช้บริการบริการเพื่อรับบริการเริ่มต้นของการจองเช่นเที่ยวบินประกันหรือเช่ารถ
เมื่อพูดถึงปัญหานี้ภายในตัวเลือกหลายตัวโผล่ขึ้นมา แต่เราไม่แน่ใจว่าตัวเลือกใดที่ดีที่สุด:
- เมื่อการจองสื่อสารกับบริการมันควรส่งต่อโทเค็นดั้งเดิมที่เขาได้รับจาก API เกตเวย์ (ระบุว่าไคลเอ็นต์คือExternalApp )
- ความหมาย: เราอาจต้องมอบขอบเขตให้กับแอพภายนอกที่ไม่ควรได้รับอนุญาต ตัวอย่าง: ExternalAppอาจต้องมีทั้งขอบเขต "การจอง" และ "บริการ" ในขณะที่ขอบเขตเท่านั้น "การจอง" อาจมีความเหมาะสม
- เมื่อการจองสื่อสารกับบริการจะส่งต่อโทเค็นที่ระบุว่าลูกค้าได้กลายเป็นการจอง (แทนที่จะเป็นExternalApp ) + เพิ่มการอ้างสิทธิ์ที่บ่งชี้ว่าการจองเป็นการปลอมตัวเป็นลูกค้าภายนอกแอปเดิม
- โดยยังรวมทั้งข้อมูลที่ลูกค้าเดิมเป็นExternalApp บริการบริการยังสามารถทำตรรกะเช่นการกรองบริการบางอย่างขึ้นอยู่กับการโทรเดิม (เช่นปพลิเคชันภายในที่เราควรจะกลับมาแข่งขันทั้งหมดสำหรับแอปภายนอกเพียงบางส่วนเท่านั้น)
- บริการไม่ควรสื่อสารซึ่งกันและกัน (ดังนั้นเราจึงไม่ควรแม้แต่จะเผชิญกับคำถามนี้)
ขอบคุณล่วงหน้าสำหรับข้อมูลของคุณ