Microservices: การจัดการความสอดคล้องในที่สุด

สมมติว่าเรามีฟังก์ชั่นที่อัปเดตรหัสผ่านของผู้ใช้

เมื่อคลิกปุ่ม 'อัปเดตรหัสผ่าน' จะมีการส่ง UpdatePasswordEvent ไปยังหัวข้อที่สมัครใช้บริการอื่น 3 บริการ:

1. บริการที่อัพเดตรหัสผ่านของผู้ใช้จริง
2. บริการที่อัพเดตประวัติรหัสผ่านของผู้ใช้
3. บริการที่ส่งอีเมลแจ้งให้ผู้ใช้ทราบว่ารหัสผ่านของเขาถูกเปลี่ยน

จากสิ่งที่ฉันเข้าใจเกี่ยวกับความสอดคล้องในที่สุดบริการเหล่านี้ (ผู้บริโภค) จะได้รับเหตุการณ์ในเวลาเดียวกันและดำเนินการแยกต่างหากซึ่งในสถานการณ์ที่ดีจะนำไปสู่ข้อมูลที่สอดคล้องกัน

อย่างไรก็ตามจะเกิดอะไรขึ้นถ้าบริการล้มเหลวในการประมวลผลเหตุการณ์ เช่นการตัดการเชื่อมต่ออย่างฉับพลันข้อผิดพลาดของฐานข้อมูล ฯลฯ ... รูปแบบ / การปฏิบัติที่ดีในการจัดการกับความล้มเหลวของธุรกรรมคืออะไร

ฉันกำลังคิดที่จะสร้าง RollbackTopic ซึ่งหากมีเหตุการณ์ใดที่ไม่สามารถประมวลผลได้ RollbackEvent จะถูกสร้างขึ้นในหัวข้อที่ "บริการการย้อนกลับ" จะทำงานและเปลี่ยนกลับเป็นข้อมูล

จากสิ่งที่ฉันเข้าใจเกี่ยวกับความสอดคล้องในที่สุดบริการเหล่านี้ (ผู้บริโภค) จะได้รับเหตุการณ์ในเวลาเดียวกันและดำเนินการแยกต่างหากซึ่งในสถานการณ์ที่ดีจะนำไปสู่ข้อมูลที่สอดคล้องกัน

ไม่ไม่จำเป็น ตามที่ฉันแสดงความคิดเห็นเราไม่สามารถยกเลิกอีเมลที่ส่งดังนั้นเราจึงยังต้องการ "ลำดับ" เรียงลำดับ IPCมากกว่าการจัดการข้อมูลเหตุการณ์ที่ขับเคลื่อนด้วยไม่ได้รับการยกเว้นของ orchestation 1

ตัวอย่างเช่นไม่ควรส่งอีเมลเว้นแต่ว่าการทำธุรกรรมก่อนหน้านี้จะเสร็จสมบูรณ์และบริการอีเมลได้รับการพิสูจน์ ³

อย่างไรก็ตามจะเกิดอะไรขึ้นถ้าบริการล้มเหลวในการประมวลผลเหตุการณ์ เช่นการตัดการเชื่อมต่ออย่างฉับพลันข้อผิดพลาดของฐานข้อมูล ฯลฯ ... รูปแบบ / การปฏิบัติที่ดีในการจัดการกับความล้มเหลวของธุรกรรมคืออะไร

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

ก่อนที่จะเริ่มการเดินทางเพื่อค้นหา Lost Ark เราต้องพิจารณาถามองค์กรก่อน บ่อยครั้งที่การแก้ปัญหาคือในวิธีการที่องค์กรเผชิญกับปัญหาเหล่านี้ในโลกแห่งความจริง

ทุกคน (แผนก) ทำอะไรเมื่อข้อมูลบางอย่างขาดหายไปหรือไม่สมบูรณ์

เราจะได้ตระหนักว่าแผนกต่าง ๆ มีโซลูชั่นที่แตกต่างกันซึ่งรวมกันเป็นโซลูชั่นที่จะดำเนินการ

อย่างไรก็ตามนี่คือแนวทางปฏิบัติบางอย่างที่สามารถช่วยเราในการทำตามกลยุทธ์

ความมั่นคงในที่สุด

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

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

ยกเลิกการดำเนินงานทั้งหมด

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

สำหรับธุรกรรมจำนวนน้อยวิธีการนี้มีความเป็นไปได้เนื่องจากจำนวนธุรกรรมที่มีการชดเชยต่ำเกินไป หากมีธุรกรรมทางธุรกิจหลายอย่างที่เกี่ยวข้องกับ IPC การจัดการธุรกรรมที่ชดเชยหนึ่งรายการสำหรับแต่ละรายการนั้นจะเป็นสิ่งที่ท้าทาย

ถ้าเราไปเพื่อชดเชยการทำธุรกรรมที่เราจะได้พบกับรูปแบบการออกแบบวงจรที่จะเป็นประโยชน์มาก - และบังคับฉันจะกล้าที่จะพูด -

การทำธุรกรรมแบบกระจาย

มีแนวคิดที่จะขยายการทำธุรกรรมหลายรายการภายในรายการเดียวผ่านกระบวนการปกครองโดยรวมที่รู้จักในฐานะผู้จัดการของธุรกรรม อัลกอริทึมที่พบบ่อยสำหรับการจัดการการทำธุรกรรมการกระจายสองเฟสกระทำ

ข้อกังวลหลักของการทำธุรกรรมแบบกระจายคือพวกเขาต้องอาศัยการล็อคทรัพยากรในช่วงเวลาชีวิตของมันและอย่างที่เรารู้ว่าสิ่งต่าง ๆ อาจผิดพลาดสำหรับผู้จัดการธุรกรรมด้วยเช่นกัน

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

การสลายตัวของการดำเนินงาน ทำไม?

หากคุณกำลังสลายระบบที่มีอยู่และค้นหาชุดของแนวคิดที่ต้องการให้อยู่ภายในขอบเขตการทำธุรกรรมเพียงครั้งเดียว

แซมนิวแมน

ตามข้อโต้แย้งข้างต้นแซมในหนังสือMicroservices Buildingของเขาระบุว่าถ้าเราจริง ๆ แล้วไม่สามารถมีความสอดคล้องในที่สุดเราควรหลีกเลี่ยงการแยกการดำเนินการตอนนี้

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

ยกตัวอย่างเช่นในกรณีของเราเรามาตระหนักถึงการทำธุรกรรมที่ # 1 และ # 2 มีความสัมพันธ์แน่นอีกคนหนึ่งและอาจทั้งอาจจะจัดอยู่เหมือนกัน bounded บริบทบัญชี , ผู้ใช้ , สมัครสมาชิก , สิ่งที่ ...

พิจารณาวางการดำเนินการทั้งสองไว้ภายในขอบเขตของธุรกรรมเดียวกัน มันจะทำให้การดำเนินการทั้งหมดง่ายขึ้นในการจัดการ นอกจากนี้เรายังยกระดับความสำคัญของแต่ละธุรกรรม อาจเป็นไปได้หากธุรกรรม # 2 ล้มเหลวก็ไม่ควรประนีประนอมการดำเนินงานทั้งหมด ในกรณีที่มีข้อสงสัยถามไปยังองค์กร

^{1: ไม่ใช่การประสานเสียงแบบที่คุณคิด ฉันไม่ได้พูดถึงการดัดแปลงของ ESB ฉันกำลังพูดถึงการทำให้การบริการตอบสนองต่อเหตุการณ์ที่เหมาะสม}

^{2: คุณอาจพบความคิดเห็นที่น่าสนใจของSam Newmanเกี่ยวกับการทำธุรกรรมแบบกระจาย}

^{3: ตรวจสอบคำตอบของ David Parker's เกี่ยวกับเรื่องนี้}

ในกรณีของคุณคุณไม่สามารถดำเนินการทั้งสามอย่างพร้อมกันได้ สิ่งที่คุณต้องการคือกระบวนการ นี่คือตัวอย่างที่ง่ายมาก:

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

ระบบของคุณควรรับประกันว่าก่อนที่จะมีเหตุการณ์ใด ๆ เกิดขึ้นในการเปลี่ยนแปลงระบบของคุณต้องยืนยันด้วยความปลอดภัยในการทำธุรกรรมก่อน นี่คือเพื่อให้แน่ใจว่าเหตุการณ์ที่เกิดขึ้นจริงเป็นการยืนยันสิ่งที่เกิดขึ้นจริง

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

• การจัดการข้อความซ้ำซ้อน
• การจัดการการส่งอีเมล

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

เมื่อ PO อยู่ในNewสถานะและกระบวนการUserPasswordHasBeenUpdatedมันจะเปลี่ยนสถานะเป็นUserPasswordHasBeenUpdated(หรือชื่อใดก็ได้ที่เหมาะกับคุณ) หากใบสั่งซื้อยังคงอยู่ในUserPasswordHasBeenUpdatedและอีกUserPasswordHasBeenUpdatedจะมาถึง PO จะไม่สนใจข้อความอย่างสมบูรณ์รู้ว่ามันซ้ำซ้อน กลไกที่คล้ายกันจะถูกนำมาใช้สำหรับรัฐอื่นเช่นกัน

การจัดการการส่งอีเมลที่แท้จริงนั้นเป็นเรื่องที่ยุ่งยากเล็กน้อย ที่นี่คุณมีสองตัวเลือก:

1. ส่งได้มากสุดครั้งเดียว
2. ส่งอย่างน้อยหนึ่งครั้ง

ส่งได้ไม่เกินครั้งเดียว

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

ส่งอย่างน้อยหนึ่งครั้ง

_{นี่คือสิ่งที่ฉันจะไป}

แทนที่จะบันทึกUserPasswordHistoryHasBeenSavedและส่งอีเมลเป็นปฏิกิริยาคุณลองส่งอีเมลก่อน หากการดำเนินการส่งล้มเหลวสถานะของ PO จะไม่เปลี่ยนเป็นUserPasswordHistoryHasBeenSavedและข้อความอื่นที่เป็นประเภทเดียวกันจะยังคงถูกประมวลผล ควรส่งอีเมลสำเร็จจริง แต่ระบบของคุณจะล้มเหลวในระหว่างการคงสถานะ PO ด้วยUserPasswordHistoryHasBeenSavedสถานะใหม่ข้อความอื่น ๆ ของข้อความUserPasswordHistoryHasBeenSavedจะเรียกคำสั่งอีกครั้งเพื่อส่งอีเมลและผู้ใช้จะได้รับหลายครั้ง .

ในกรณีของคุณคุณต้องการให้แน่ใจว่าผู้ใช้รับอีเมลจริง นั่นเป็นเหตุผลที่ฉันจะเลือกตัวเลือกที่สองในช่วงแรก

ระบบการจัดคิวนั้นค่อนข้างบอบบางเหมือนที่คุณคิด

หากเรากำลังเขียนกระบวนการทั้งสามไปยังฐานข้อมูลเชิงสัมพันธ์เราอาจใช้ทรานแซคชันเพื่อจัดการกับความล้มเหลวของกระบวนการกลาง

หากไม่มีการกระทำขั้นสุดท้ายงานบางส่วนก็จะถูกยกเลิก

ในระบบฐานคิวคุณจะมีตัวเลือกที่คล้ายกันเมื่อคุณอ่านข้อความจากคิวเพื่อจัดการกับความล้มเหลวของกระบวนการกลาง

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

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

อาจเป็นไปได้ว่าคุณสามารถสร้าง 'บริการย้อนกลับ' ซึ่งตรวจสอบข้อความผิดพลาดเหล่านี้รู้เกี่ยวกับข้อความที่เกี่ยวข้องและสถานะที่ผ่านมาและดำเนินการย้อนกลับ

แต่! โดยปกติแล้วจะเป็นการดีกว่าเพียงแค่ส่งข้อความผิดพลาดอีกครั้ง หลังจากสิ่งเหล่านี้มักจะเป็นกรณีขอบ อาจเป็นเซิร์ฟเวอร์ที่ล้มเหลวอย่างรุนแรงหรือมีข้อผิดพลาดในการจัดการประเภทข้อความเฉพาะ

เมื่อได้รับการแจ้งเตือนถึงข้อผิดพลาดบริการสามารถซ่อมแซมและข้อความที่ประมวลผลสำเร็จ นำระบบโดยรวมกลับสู่สภาวะที่สอดคล้องกัน

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

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

เพื่อแก้ปัญหาของคุณจริง ๆ ฉันจะไม่พิจารณาธุรกรรมแบบกระจาย แต่ให้มองไปในทิศทางของการส่งข้อความอย่างน้อยหนึ่งครั้งและการประมวลผล idempotent

• อย่างน้อยหนึ่งครั้ง

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

• idempotence

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

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

ฉันไม่เห็นด้วยกับคำตอบมากมาย

1. ส่งอีเมลทันที“ มีคนเปลี่ยนรหัสผ่านของคุณ ถ้าเป็นคุณคุณไม่ต้องทำอะไรเลย หากไม่ตื่นตระหนก” สิ่งนี้จะมาถึงเมื่อมันมาถึง
2. เปลี่ยนรหัสผ่าน แม้ว่าคุณจะมีความมั่นคงในที่สุด คุณต้องการให้แน่ใจว่าเซสชั่นนี้เห็นการเปลี่ยนแปลงที่ทำโดยผู้ใช้

มีสัญญาความมั่นคงอื่น ๆ ที่คุณสามารถเพิ่มได้

• ตรวจสอบให้แน่ใจว่าการเปลี่ยนแปลงเกิดขึ้นตามลำดับเวลา
• ตรวจสอบให้แน่ใจว่าผู้ใช้ไม่เคยเห็นการย้อนกลับ แต่ผู้ใช้รายอื่นอาจยังไม่เห็นการเปลี่ยนแปลง
• มีคนอื่น ๆ

ความสอดคล้องเพิ่มเติมเหล่านี้จะต้องดำเนินการตามการกระทำของแอปพลิเคชัน

ฉันไม่รู้ว่าคุณหมายถึงอะไรโดย "อัพเดทประวัติ" แต่โปรดอย่าเปลี่ยนประวัติ หากคุณเพิ่งขยาย DAG ไปแล้วสิ่งนี้จะทำให้เกิดการเปลี่ยนแปลงในสถานะปัจจุบัน พวกเขาไม่ได้เป็นอิสระ หากพวกเขาเป็นแล้วคุณไม่สามารถพึ่งพาประวัติศาสตร์สะท้อนสิ่งที่เกิดขึ้น (และสุดท้าย แต่ไม่ท้ายสุดอย่าเก็บรหัสผ่านดูว่าจะเก็บรหัสผ่านอย่างไร )