กลยุทธ์การทำธุรกรรมที่ได้รับการยอมรับมากที่สุดสำหรับ microservices คืออะไร

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

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

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

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

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

บริการทางการเงินทำสิ่งนี้ตลอดเวลา - ถ้าฉันต้องการย้ายเงินจากธนาคารของฉันไปยังธนาคารของคุณไม่มีธุรกรรมเดียวเหมือนที่คุณมีในฐานข้อมูล คุณไม่ทราบว่าระบบใดที่ทั้งสองธนาคารกำลังทำงานอยู่ดังนั้นจึงต้องปฏิบัติต่อกันอย่างมีประสิทธิภาพเหมือนกับ microservices ของคุณ ในกรณีนี้ธนาคารของฉันจะย้ายเงินของฉันจากบัญชีของฉันไปยังบัญชีโฮลดิ้งแล้วบอกธนาคารของคุณว่าพวกเขามีเงินถ้าการส่งนั้นล้มเหลวธนาคารของฉันจะคืนเงินในบัญชีของฉันด้วยเงินที่พวกเขาพยายามส่ง

ฉันคิดว่าภูมิปัญญามาตรฐานคือการไม่ทำธุรกรรมข้ามขอบเขตบริการไมโคร หากชุดข้อมูลใด ๆ ที่กำหนดจำเป็นต้องสอดคล้องกับอะตอมด้วยกันจริง ๆ สิ่งทั้งสองนั้นอยู่ด้วยกัน

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

ฉันคิดว่าหากความสอดคล้องเป็นข้อกำหนดที่แข็งแกร่งในใบสมัครของคุณคุณควรถามตัวเองว่าการให้บริการแบบ Microservices เป็นวิธีที่ดีกว่าหรือไม่ เช่นเดียวกับ Martin Fowler พูดว่า :

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

แต่ในกรณีของคุณคุณสามารถเสียสละความสม่ำเสมอใน pos ของความพร้อมใช้งาน

กระบวนการทางธุรกิจมักจะทนต่อความไม่สอดคล้องกันมากกว่าที่คุณคิดเพราะธุรกิจมักจะให้รางวัลมากกว่าความพร้อม

อย่างไรก็ตามฉันยังถามตัวเองว่ามีกลยุทธ์สำหรับการทำธุรกรรมแบบกระจายในไมโครไซต์ แต่อาจมีค่าใช้จ่ายสูงเกินไป ฉันต้องการให้คุณสองเซ็นต์ของฉันกับบทความที่ยอดเยี่ยมเสมอของ Martin Fowler และทฤษฎีบทCAP

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

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

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

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

มีผลิตภัณฑ์ออกมีที่สามารถยึดติดกับระบบของคุณซึ่งดูแลความมั่นคง เอ็นจินกระบวนการทางธุรกิจเป็นตัวอย่างที่ดีและโดยทั่วไปแล้วพวกเขาจะจัดการกับความมั่นคงในที่สุดและโดยใช้การชดเชย ผลิตภัณฑ์อื่น ๆ ทำงานในลักษณะเดียวกัน คุณมักจะจบลงด้วยชั้นของซอฟแวร์ที่อยู่ใกล้ลูกค้า (s) ซึ่งเกี่ยวข้องกับความมั่นคงและการทำธุรกรรมและสาย (ไมโคร) บริการที่จะทำประมวลผลทางธุรกิจที่เกิดขึ้นจริง หนึ่งผลิตภัณฑ์ดังกล่าวคือตัวเชื่อมต่อ JCA ทั่วไปซึ่งสามารถใช้กับโซลูชัน Java EE (เพื่อความโปร่งใส: ฉันเป็นผู้เขียน) ดูhttp://blog.maxant.co.uk/pebble/2015/08/04/1438716480000.htmlสำหรับรายละเอียดเพิ่มเติมและการอภิปรายเชิงลึกของปัญหาที่เกิดขึ้นที่นี่

อีกวิธีหนึ่งในการจัดการธุรกรรมและความสอดคล้องคือการตัดการเรียกไปยัง microservice ในการโทรไปยังรายการที่ทำธุรกรรมเช่นคิวข้อความ ใช้ตัวอย่างบันทึกการขาย / บันทึกคำสั่งซื้อจากด้านบน - คุณสามารถให้พนักงานฝ่ายขายส่งข้อความไปยังระบบการสั่งซื้อซึ่งมีข้อผูกพันในการทำธุรกรรมเดียวกันซึ่งเขียนการขายไปยังฐานข้อมูล ผลลัพธ์คือโซลูชันแบบอะซิงโครนัสซึ่งปรับขนาดได้ดีมาก การใช้เทคโนโลยีเช่นเว็บซ็อกเก็ตคุณสามารถแก้ไขปัญหาการบล็อกซึ่งมักเกี่ยวข้องกับการปรับขนาดโซลูชันแบบอะซิงโครนัส สำหรับแนวคิดเพิ่มเติมเกี่ยวกับรูปแบบเช่นนี้เห็นอีกอย่างหนึ่งของบทความของฉัน: http://blog.maxant.co.uk/pebble/2015/08/11/1439322480000.html

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

ใน microservices มีสามวิธีในการบรรลุความสอดคล้องระหว่าง diff บริการ:

1. Orchestration - กระบวนการหนึ่งที่จัดการธุรกรรมและย้อนกลับข้ามบริการ

2. ออกแบบท่าเต้น - บริการส่งข้อความระหว่างกันและในที่สุดก็ถึงสถานะที่สอดคล้องกัน

3. ไฮบริด - ผสมสองรายการข้างต้น

สำหรับการอ่านที่สมบูรณ์ไปที่ลิงค์: https://medium.com/capital-one-developers/microservices-when-to-react-vs-orchestrate-c6b18308a14c

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

ตัวเลือกที่ 1: หลีกเลี่ยงความจำเป็นในการทำธุรกรรมหากเป็นไปได้ทั้งหมด

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

ตัวเลือก 2: ใช้คิว

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

ตัวอย่างเช่นสมมติว่าเราต้องการแทรกเอนทิตีและส่งอีเมลเป็นธุรกรรมเดียว แทนที่จะเรียกเมลเซิร์ฟเวอร์เราจัดคิวอีเมลในตาราง

Begin transaction
Insert entity
Insert e-mail
Commit transaction

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

ตัวเลือกที่ 3: ทำงานภายนอกให้เสร็จก่อนที่จะทำธุรกรรม

วิธีนี้ขึ้นอยู่กับสมมติฐานที่ว่าการทำธุรกรรมนั้นไม่น่าจะล้มเหลว

Begin transaction
Insert entity
Insert another entity
Make external call
Commit transaction

หากการสอบถามล้มเหลวการโทรภายนอกยังไม่เกิดขึ้น หากการโทรภายนอกล้มเหลวการทำธุรกรรมจะไม่เกิดขึ้น

วิธีการนี้มาพร้อมกับข้อ จำกัด ที่เราสามารถทำการโทรภายนอกได้เพียงครั้งเดียวและต้องทำการโทรครั้งสุดท้าย (เช่นเราไม่สามารถใช้ผลลัพธ์ในแบบสอบถามของเราได้)

ตัวเลือก 4: สร้างสิ่งต่าง ๆ ในสถานะรอดำเนินการ

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

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

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

ตัวเลือกที่ 5: ให้ microservice แชร์คิวรีของมัน

ไม่มีตัวเลือกอื่นให้คุณ จากนั้นให้ของได้รับนอกรีต

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

มีวิธีเปลี่ยนแบบสอบถามจาก microservices หลายรายการเป็นธุรกรรมฐานข้อมูลเดียวที่เรียบง่าย

ส่งคืนเคียวรีแทนที่จะเรียกใช้งาน

Begin transaction
Execute our own query
Make external call, receiving a query
Execute received query
Commit transaction

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

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

เราได้รับแบบสอบถามรวมถึงประเภทการเชื่อมต่อพารามิเตอร์และสตริงการเชื่อมต่อ เราสามารถสรุปมันได้ในคลาส Commandable executable ที่ทำให้ flow อ่านได้: การเรียก microservice ใน Command ซึ่งเราดำเนินการซึ่งเป็นส่วนหนึ่งของการทำธุรกรรมของเรา

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

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

ฉันจะเริ่มต้นด้วยการแยกพื้นที่ปัญหา - ระบุขอบเขตบริการของคุณ เมื่อทำอย่างถูกต้องคุณไม่จำเป็นต้องมีธุรกรรมระหว่างบริการ

บริการต่าง ๆ มีข้อมูลพฤติกรรมแรงจูงใจรัฐบาลกฎเกณฑ์ทางธุรกิจและอื่น ๆ การเริ่มต้นที่ดีคือการแสดงความสามารถระดับสูงขององค์กรของคุณ ตัวอย่างเช่นการตลาดการขายการบัญชีการสนับสนุน อีกจุดเริ่มต้นคือโครงสร้างองค์กร แต่โปรดทราบว่ามีข้อแม้ - ด้วยเหตุผลบางอย่าง (เช่นการเมือง) อาจไม่ใช่รูปแบบการสลายตัวทางธุรกิจที่ดีที่สุด ที่เข้มงวดมากขึ้นวิธีการคือการวิเคราะห์ห่วงโซ่มูลค่า โปรดจำไว้ว่าบริการของคุณอาจรวมถึงผู้คนด้วยไม่ใช่ซอฟต์แวร์อย่างเคร่งครัด บริการควรสื่อสารซึ่งกันและกันผ่านกิจกรรมต่างๆ

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

หากคุณคิดว่าโดเมนของคุณต้องการความมั่นคงก่อนอื่นให้คิดอีกครั้ง ไม่มีระบบขนาดใหญ่และภารกิจที่สำคัญใด ๆ ที่สร้างขึ้นโดยคำนึงถึงสิ่งนี้ พวกเขาทั้งหมดมีการกระจายและสอดคล้องกันในที่สุด ตรวจสอบ Pat Helland ของกระดาษคลาสสิก

ต่อไปนี้เป็นเคล็ดลับที่เป็นประโยชน์เกี่ยวกับวิธีการสร้างระบบแบบกระจาย