Microservices อัตโนมัติคิวเหตุการณ์และการค้นหาบริการ

ฉันได้อ่านเกี่ยวกับบริการไมโครเมื่อไม่นานมานี้และนี่คือข้อสรุปบางอย่างที่ฉันได้รับ (โปรดแก้ไขฉันหากฉันผิดที่จุดใด)

1. สถาปัตยกรรมบริการไมโครเป็นไปด้วยดีกับการออกแบบที่ขับเคลื่อนด้วยโดเมน โดยทั่วไปแล้วหนึ่ง MS หมายถึงบริบทที่มีขอบเขตหนึ่ง
2. ถ้า micro-service Aต้องการฟังก์ชันที่อยู่ใน micro-service BโมเดลของฉันอาจผิดและAและB ควรเป็น micro-service / BC หนึ่งอัน
3. การสื่อสารแบบซิงโครนัสระหว่างบริการไมโคร (คำขอ HTTP โดยตรง) ไม่ดีทำให้ขัดต่อวัตถุประสงค์ของบริการไมโครและแนะนำการมีเพศสัมพันธ์ระหว่างส่วนประกอบ
4. การสื่อสารแบบอะซิงโครนัสระหว่างบริการเป็นที่ต้องการ บริการควรเผยแพร่กิจกรรมไปยังคิวข้อความเพื่อให้บริการอื่น ๆ สามารถสมัครและประมวลผลส่วนหนึ่งของเหตุการณ์หรือใช้เพื่อทำซ้ำส่วนของข้อมูลที่จำเป็นสำหรับบริบทของพวกเขา วิธีนี้บริการสามารถดำเนินการตามคำขอแม้บริการอื่น ๆ จะหยุดทำงานซึ่งไม่ได้เกิดขึ้นในการสื่อสารแบบซิงโครนัส
5. ถ้า micro-service Aเผยแพร่เหตุการณ์, micro-service Bสมัครสมาชิกกับเหตุการณ์นั้นและสร้างเหตุการณ์ใหม่เป็นผลลัพธ์, micro-service Aไม่ควรเป็นการประมวลผลเหตุการณ์ที่สร้างขึ้นใหม่, ซึ่งจะเป็นการอ้างอิงแบบวงกลม ในกรณีนี้เราควรแนะนำบริการไมโครที่สามหรือรวมAและBเข้ากับบริการไมโครAB
6. บริการไมโครเป็นจริงคำที่ทำให้เข้าใจผิด เราควรพยายามเพื่อบริบทขนาดเล็ก แต่ไม่จำเป็นต้องเป็นกรณี คำไม่ควรเป็น "บริการไมโคร" แต่ " ใหญ่พอที่จะทำงานบริการ "
7. บริการไมโครช่วยให้เราสามารถแนะนำฟังก์ชั่นใหม่ได้อย่างง่ายดายและไม่ต้องกลัวว่าเราจะทำลายทั้งระบบ มันสามารถทำได้โดยการแนะนำบริการใหม่หรือ refactoring หนึ่งในที่มีอยู่
8. แต่ละบริการไมโครควรมีการจัดเก็บข้อมูลของตัวเอง การจำลองแบบ / การทำสำเนาข้อมูลเป็นพฤติกรรมที่พึงประสงค์ในสถาปัตยกรรมนี้

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

บริการไม่ควรมีความรู้เกี่ยวกับบริการอื่น ๆ ในระบบ พวกเขาตระหนักถึงบริบทและเหตุการณ์ที่ควรเผยแพร่หรือสมัครสมาชิกเท่านั้น?

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

ฉันจะไม่สนับสนุนอย่างเต็มที่ 2, 5 และ 8:

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

  ดังนั้นหาก microservice A ต้องการฟังก์ชั่นใน microservice B บ่อยมากและ microservice B นั้นไม่ค่อยจำเป็นสำหรับ microservices อื่น ๆ คุณควรท้าทายโครงสร้างที่มองเห็นและถามว่ามันจะไม่เหมาะสมกว่าในการจัดกลุ่ม microservices ทั้งสอง

• 5) แน่นอนคุณต้องหลีกเลี่ยงการขี่จักรยานอย่างไม่มีที่สิ้นสุดในการจัดการข้อความ

  แต่การเพิ่มคนกลางจะไม่ป้องกัน: A สามารถเปิดข้อความที่จัดการโดย C ซึ่งเปิดตัวข้อความที่จัดการโดย B ซึ่งจะเปิดข้อความที่จัดการโดย A และที่นี่คุณติดอยู่ในลูป

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

• 8) ใช่แต่ละไมโครไซต์จะต้องมีพื้นที่จัดเก็บ / ฐานข้อมูลเฉพาะ

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

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

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

บริการไมโครเกี่ยวกับการแยกโดเมนฟังก์ชันการทำงานที่แตกต่างกัน แต่ละบริการสามารถพัฒนาได้ในระดับที่แตกต่างกันโดยทีมงานที่แตกต่างกันโดยใช้เทคโนโลยีที่แตกต่างกัน สิ่งนี้สร้างความยืดหยุ่นขององค์กร ข้อเสียคือความซับซ้อนในการปฏิบัติงานซึ่งบริการเสริมแต่ละอย่างจะสร้างอีกหนึ่งสิ่งที่ต้องจัดการในสภาพแวดล้อมการปฏิบัติงาน ดังนั้นการแลกเปลี่ยนพื้นฐานของ monolith vs micro-service ไม่ได้เกี่ยวกับการหลีกเลี่ยงการพึ่งพามันเป็นเรื่องเกี่ยวกับการหลีกเลี่ยงการพัฒนาขั้นตอนล็อคและการใช้งานที่ทุกอย่างจะต้องจัดส่งทั้งหมดในครั้งเดียว แต่ค่าใช้จ่ายในการจัดส่งบ่อยขึ้น ชิ้นส่วนที่เคลื่อนไหวได้มากขึ้น

บริการไม่ควรมีความรู้เกี่ยวกับบริการอื่น ๆ ในระบบ พวกเขาตระหนักถึงบริบทและเหตุการณ์ที่ควรเผยแพร่หรือสมัครสมาชิกเท่านั้น?

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

ถ้าบริการกำลังสื่อสารแบบอะซิงโครนัสและใช้คิวเหตุการณ์กลางเช่น amazon SQS หมายความว่าการค้นพบบริการไม่มีตำแหน่งในสถาปัตยกรรมเช่นนั้นหรือไม่

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

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

1. สถาปัตยกรรมบริการไมโครเป็นไปด้วยดีกับการออกแบบที่ขับเคลื่อนด้วยโดเมน โดยทั่วไปแล้วหนึ่ง MS หมายถึงบริบทที่มีขอบเขตหนึ่ง

ไม่เห็นด้วย DDD มีแนวโน้มที่จะ OO มาก ส่งคำสั่งซื้อแล้วหรือยัง Order.Deliver () ในขณะที่ Micro-services จะมี DeliveryService.Deliver (order)

2. ถ้า micro-service A ต้องการฟังก์ชันที่อยู่ใน micro-service B โมเดลของฉันอาจผิดและ A และ B ควรเป็น micro-service / BC หนึ่งอัน

ไม่เห็นด้วยคุณควรลองใช้บริการไมโคร แยกพวกมันให้เล็กลง!

3. การสื่อสารแบบซิงโครนัสระหว่างบริการไมโคร (คำขอ HTTP โดยตรง) ไม่ดีทำให้ขัดต่อวัตถุประสงค์ของบริการไมโครและแนะนำการมีเพศสัมพันธ์ระหว่างส่วนประกอบ

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

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

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

5. ถ้า micro-service A เผยแพร่เหตุการณ์, micro-service B สมัครสมาชิกกับเหตุการณ์นั้นและสร้างเหตุการณ์ใหม่เป็นผลลัพธ์, micro-service A ไม่ควรเป็นการประมวลผลเหตุการณ์ที่สร้างขึ้นใหม่, ซึ่งจะเป็นการอ้างอิงแบบวงกลม ในกรณีนี้เราควรแนะนำบริการไมโครที่สามหรือรวม A และ B เข้ากับบริการไมโคร AB

ไม่เห็นด้วย มันไม่ได้ขึ้นอยู่กับการเวียนเพราะบริการไมโครของคุณไม่ได้อยู่คู่กัน นอกจากนี้คุณต้องการที่จะตอบสนองความต้องการส่ง Senarios, SendEmail, EmailFailed, SendAgain ไม่จำเป็นต้อง 3 บริการไมโคร

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

ไม่เห็นด้วย ลองใช้บริการนาโน

7. บริการไมโครช่วยให้เราสามารถแนะนำฟังก์ชั่นใหม่ได้อย่างง่ายดายและไม่ต้องกลัวว่าเราจะทำลายทั้งระบบ มันสามารถทำได้โดยการแนะนำบริการใหม่หรือ refactoring หนึ่งในที่มีอยู่

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

8. แต่ละบริการไมโครควรมีการจัดเก็บข้อมูลของตัวเอง การจำลองแบบ / การทำสำเนาข้อมูลเป็นพฤติกรรมที่พึงประสงค์ในสถาปัตยกรรมนี้

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

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

และสำหรับคำถามอื่นของคุณการค้นหาบริการไม่จำเป็นสำหรับการสื่อสารแบบอิงคิว

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

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

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

ตัวอย่างเช่นทุกอย่างที่กล่าวในคำตอบอื่น ๆ เป็นข้อความเกี่ยวกับ OOP

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

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

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

นี่คือตัวอย่างของการระบุขอบเขตบริการโดยใช้วิธีนี้