ลองนึกภาพสถานการณ์ของ microservices สองแบบ หนึ่งในการจัดการรับรองความถูกต้องภายในบริการอื่น ๆ จะดูแลการจัดการผู้ใช้ พวกเขาทั้งสองมีแนวคิดของผู้ใช้และจะพูดคุยเกี่ยวกับผู้ใช้ผ่านการโทรหากัน
รูปแบบโดเมนของ "ผู้ใช้" จะอยู่ที่ไหน พวกเขาทั้งสองจะมีการแสดงที่แตกต่างกันของสิ่งที่ผู้ใช้อยู่ในระดับของฐานข้อมูลหรือไม่ เมื่อเรามี UserDTO ที่จะใช้ในการโทร API พวกเขาทั้งสองจะมีหนึ่งอันสำหรับ API ที่เกี่ยวข้องหรือไม่
อะไรคือทางออกที่ยอมรับกันโดยทั่วไปสำหรับปัญหาสถาปัตยกรรมประเภทนี้?
คำตอบ:
ในสถาปัตยกรรม Microservices แต่ละรายการนั้นไม่ขึ้นอยู่กับผู้อื่นและจะต้องซ่อนรายละเอียดของการใช้งานภายใน
หากคุณแบ่งปันโมเดลคุณกำลังมีส่วนร่วมกับ microservices และสูญเสียหนึ่งในข้อได้เปรียบที่ยิ่งใหญ่ที่สุดซึ่งแต่ละทีมสามารถพัฒนาบริการไมโครสโคปได้โดยไม่มีข้อ จำกัด และจำเป็นต้องรู้ว่าจะต้องพัฒนาไมโครเซลเวอร์อื่น ๆ อย่างไร โปรดจำไว้ว่าคุณสามารถใช้ภาษาที่แตกต่างกันในแต่ละภาษาได้ซึ่งอาจเป็นเรื่องยากหากคุณเริ่มให้บริการไมโครซิส
หากพวกเขาเกี่ยวข้องกันมากเกินไปพวกเขาอาจจะเป็นคนที่เหมือน @soru พูด
คำถามที่เกี่ยวข้อง:
หากบริการสองอย่างเชื่อมโยงกันอย่างพอเพียงว่าเป็นความเจ็บปวดในการใช้งานโดยไม่ต้องแบ่งปัน DTO และวัตถุรูปแบบอื่น ๆ นั่นเป็นสัญญาณที่ดีที่คุณไม่ควรมีบริการสองบริการ
ตัวอย่างที่เห็นได้ชัดก็คือบริการสองอย่าง มันยากที่จะจินตนาการถึงสเปคของ 'การจัดการผู้ใช้' ที่ซับซ้อนดังนั้นมันจะทำให้ทั้งทีมยุ่งมากพวกเขาไม่มีเวลาทำการพิสูจน์ตัวตน
หากมีเหตุผลบางอย่างที่พวกเขาแล้วพวกเขาจะติดต่อสื่อสารโดยใช้สิ่งที่เป็นสตริงโดยพลการโดยทั่วไปในขณะที่OAuth 2.0
คุณสามารถคิดว่าพวกเขาเป็นบริบทที่ถูก จำกัด สองแยก (ในสำนวนการออกแบบที่ขับเคลื่อนด้วยโดเมน) พวกเขาไม่ควรเปิดเผยข้อมูลใด ๆ ระหว่างพวกเขานอกเหนือจาก ID ที่ใช้สำหรับเชื่อมโยง "ผู้ใช้" ของบริบทการรับรองความถูกต้องกับ "ผู้ใช้" ของบริบทอื่น พวกเขาแต่ละคนสามารถมีการเป็นตัวแทนของพวกเขาในสิ่งที่ "ผู้ใช้" คือและรูปแบบโดเมนของตัวเองซึ่งเป็นเพียงข้อมูลที่จำเป็นในการดำเนินธุรกิจของพวกเขา
โปรดจำไว้ว่ารูปแบบโดเมนไม่ได้พยายามจำลอง "สิ่ง" ในโลกแห่งความเป็นจริง แต่สิ่งที่อยู่ในบริบทเฉพาะ (เช่นการจัดการข้อมูลผู้ใช้ / การอนุญาตหรือทรัพยากรมนุษย์ ฯลฯ )
พวกเขาทั้งสองมีแนวคิดของผู้ใช้และจะพูดคุยเกี่ยวกับผู้ใช้ผ่านการโทรหากัน
ฉันเห็นด้วยกับสิ่งที่ @soru พูด หากบริการหนึ่งต้องการข้อมูลของบริการอื่นกว่าขอบเขตของบริการนั้นผิด
ทางออกที่ดีคือสิ่งที่ @pnschofield เกิดขึ้นกับ - ปฏิบัติต่อบริการของคุณตามบริบทที่ถูก จำกัด
พูดคุยเกี่ยวกับเรื่องนี้ในไม่ช้า: โมเดลโดเมนที่ใช้ร่วมกันจะทำลายความเป็นอิสระของบริการเปลี่ยนระบบ microservice ของคุณให้เป็น monolith แบบกระจาย ซึ่งเห็นได้ชัดยิ่งกว่าหินใหญ่ก้อนเดียว
ดังนั้นยังมีคำถามทั่วไปที่ยังไม่แก้ - วิธีการกำหนดขอบเขตการบริการหรือบริบทเพื่อให้พวกเขาเจริญเติบโตในการติดต่อกันสูงและดีงามคับ
ฉันคิดวิธีแก้ปัญหาเพื่อรักษาสภาพแวดล้อมทางธุรกิจ มันเป็นความรับผิดชอบทางธุรกิจในระดับสูงกว่าฟังก์ชั่นทางธุรกิจที่เอื้อต่อเป้าหมายทางธุรกิจโดยรวม คุณสามารถนึกถึงขั้นตอนที่องค์กรของคุณจำเป็นต้องดำเนินการเพื่อให้ได้มาซึ่งคุณค่าทางธุรกิจ
ลำดับขั้นตอนโดยทั่วไปของฉันที่ฉันทำเมื่อระบุขอบเขตบริการมีดังต่อไปนี้:
อาจเป็นตัวอย่างของเทคนิคนี้อาจเป็นที่สนใจของคุณ อย่าลังเลที่จะแจ้งให้เราทราบว่าคุณคิดอย่างไรเนื่องจากฉันพบว่าวิธีการนี้ทำกำไรได้จริง แน่นอนว่ามันสามารถช่วยคุณได้เช่นกัน
Microservice ไม่ได้เกี่ยวกับ "แชร์อะไรเลย" แต่ "แบ่งปันให้น้อยที่สุด" ในกรณีส่วนใหญ่ "ผู้ใช้" เป็นเอนทิตี้ทั่วไปจริง ๆ (เพียงเพราะผู้ใช้ถูกระบุโดยตัวบ่งชี้ที่ใช้ร่วมกันบางอย่าง - userId / อีเมล / โทรศัพท์) เอนทิตีชนิดดังกล่าวที่ใช้ร่วมกันโดยคำจำกัดความ โมเดลผู้ใช้อยู่นอกขอบเขตหนึ่งไมโครเซอร์วิส ดังนั้นคุณต้องมีสคีมาระดับโลกที่ควรกำหนดตำแหน่งผู้ใช้ (เฉพาะฟิลด์ที่พบบ่อยที่สุด) ในกรณีที่เข้มงวดคือ id เท่านั้น