SOA / Microservices: จะจัดการการอนุญาตในการสื่อสารระหว่างบริการได้อย่างไร


19

เบื้องหน้า

เรากำลังเปลี่ยนจากแพลตฟอร์มเสาหินเป็นสถาปัตยกรรมที่เน้นการบริการมากขึ้น เราใช้หลักการ 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 ) บริการการจองจะเข้าใช้บริการบริการเพื่อรับบริการเริ่มต้นของการจองเช่นเที่ยวบินประกันหรือเช่ารถ

เมื่อพูดถึงปัญหานี้ภายในตัวเลือกหลายตัวโผล่ขึ้นมา แต่เราไม่แน่ใจว่าตัวเลือกใดที่ดีที่สุด:

  1. เมื่อการจองสื่อสารกับบริการมันควรส่งต่อโทเค็นดั้งเดิมที่เขาได้รับจาก API เกตเวย์ (ระบุว่าไคลเอ็นต์คือExternalApp )
    • ความหมาย: เราอาจต้องมอบขอบเขตให้กับแอพภายนอกที่ไม่ควรได้รับอนุญาต ตัวอย่าง: ExternalAppอาจต้องมีทั้งขอบเขต "การจอง" และ "บริการ" ในขณะที่ขอบเขตเท่านั้น "การจอง" อาจมีความเหมาะสม
  2. เมื่อการจองสื่อสารกับบริการจะส่งต่อโทเค็นที่ระบุว่าลูกค้าได้กลายเป็นการจอง (แทนที่จะเป็นExternalApp ) + เพิ่มการอ้างสิทธิ์ที่บ่งชี้ว่าการจองเป็นการปลอมตัวเป็นลูกค้าภายนอกแอปเดิม
    • โดยยังรวมทั้งข้อมูลที่ลูกค้าเดิมเป็นExternalApp บริการบริการยังสามารถทำตรรกะเช่นการกรองบริการบางอย่างขึ้นอยู่กับการโทรเดิม (เช่นปพลิเคชันภายในที่เราควรจะกลับมาแข่งขันทั้งหมดสำหรับแอปภายนอกเพียงบางส่วนเท่านั้น)
  3. บริการไม่ควรสื่อสารซึ่งกันและกัน (ดังนั้นเราจึงไม่ควรแม้แต่จะเผชิญกับคำถามนี้)

ขอบคุณล่วงหน้าสำหรับข้อมูลของคุณ


1
คุณแก้ปัญหานี้ได้อย่างไร เราอยู่ในสถานการณ์ที่คล้ายคลึงกัน
Varun Mehta

+1: ฉันสนใจว่าคุณแก้ปัญหาของคุณได้อย่างไร
Dypso

เพื่อที่จะทำจุด 3 - บริการไม่สื่อสารกันคุณต้องมี UI แบบคอมโพสิต ดูโดยเฉพาะอย่างยิ่ง.
net / บล็อก /secret

คำตอบ:


3

ฉันแนะนำให้คุณมีช่องทางการสื่อสารภายในระหว่างไมโครไซต์

ตัวอย่างเช่นการใช้นายหน้าข้อความบางอย่างเช่น RabbitMQ ภายในเพื่อส่ง / รับหรือเผยแพร่ / สมัครสมาชิกข้อความระหว่างไมโครไซต์

จากนั้นผู้ใช้ปลายทางคนแรกที่หันหน้าเข้าหาบริการ "ในตัวอย่างของคุณบริการจองห้องพัก" จะเป็นผู้รับผิดชอบในการตรวจสอบโทเค็นและอนุญาตให้ลูกค้าดำเนินการเฉพาะนี้โดยการสื่อสารกับ IdentityServer

จากนั้นจะสื่อสารกับบริการบริการผ่านนายหน้าข้อความและในกรณีนั้นไม่จำเป็นต้องตรวจสอบโทเค็นอีกครั้ง

ฉันเดาว่ารุ่นนี้จะเรียบง่ายกว่าและให้ประสิทธิภาพที่ดีขึ้นกับคุณ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.