Microservices และขั้นตอนการจัดเก็บ

กระบวนงานที่เก็บไว้ถูกพิจารณาว่าเป็นการปฏิบัติที่ไม่ดีในสถาปัตยกรรม microservice หรือไม่

นี่คือความคิดของฉัน:

• หนังสือส่วนใหญ่ใน microservices แนะนำหนึ่งฐานข้อมูลต่อ microservice ขั้นตอนการจัดเก็บมักจะทำงานบนฐานข้อมูลเสาหิน

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

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

ความคิดใด ๆ เกี่ยวกับเรื่องนี้?

ไม่มีสิ่งใดที่ห้ามหรือโต้แย้งการใช้โพรซีเดอร์ที่เก็บไว้ด้วย microservices อย่างชัดเจน

คำเตือน: ฉันไม่ชอบขั้นตอนการจัดเก็บจากมุมมองของนักพัฒนา แต่ไม่เกี่ยวข้องกับไมโครไซต์ในทางใดทางหนึ่ง

ขั้นตอนการจัดเก็บมักจะทำงานบนฐานข้อมูลขนาดใหญ่

ฉันคิดว่าคุณจำนนต่อการเข้าใจผิดอย่างมีเหตุผล

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

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

หนังสือส่วนใหญ่ใน microservices แนะนำหนึ่งฐานข้อมูลต่อ microservice

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

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

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

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

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

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

นี่เป็นสิ่งที่ฉันเข้าใจเกี่ยวกับ sprocs: ตรรกะทางธุรกิจในฐานข้อมูล แม้ว่าจะไม่ได้ตั้งใจก็ตาม แต่ก็มีแนวโน้มที่จะจบลงด้วยวิธีนั้นเสมอ

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

ในการเขียนซอฟต์แวร์กำหนดให้คุณต้องจับคู่กับเทคโนโลยีอย่างแน่นหนา

อย่างน้อยที่สุดกับสภาวะแวดล้อมรันไทม์ที่จัดเตรียมโดยภาษาการเขียนโปรแกรมที่กำลังถูกพัฒนาภายใน

โดยทั่วไปแม้ว่าคุณจะพบว่าบริการไมโครของคุณเชื่อมโยงกับเทคโนโลยีหลายอย่างแน่นหนา:

• Network Service Framework เพื่อให้การใช้งานโปรโตคอล HTTP / SSL / SOAP ระดับสูง
• Repository / ORM / DAO Framework เพื่อให้มีอยู่
• Data Manipulation Frameworks เป็นเครื่องมือสำหรับการทำงานกับข้อมูล
• Process / Threading / OS Framework เพื่อให้สามารถเข้าถึงทรัพยากรระบบปฏิบัติการเช่นการทำงานแบบมัลติทาสก์, ระบบไฟล์, หน่วยความจำ, การคำนวณ GPU, การ์ดเอ็กซ์แพนชัน, ฯลฯ ...

และนั่นคือการสร้างบริการไมโครกระดูกเปล่า

ขั้นตอนการจัดเก็บ

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

มันคืออะไร:

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

แต่ละค่าใช้จ่ายจริง ในบางกรณีค่าใช้จ่ายนั้นสมเหตุสมผลในกรณีอื่น ๆ ไม่ใช่

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

ตรรกะทางธุรกิจ

การย้ายกฎธุรกิจลงในฐานข้อมูลเป็นการปฏิบัติที่ไม่ดี ไม่ใช่เพราะขั้นตอนการจัดเก็บ

เป็นการปฏิบัติที่ไม่ดีเนื่องจากฐานข้อมูลและตรรกะทางธุรกิจทำงานในระดับการตัดที่แตกต่างกัน

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

• เปรียบเทียบทศวรรษกับกฎเกณฑ์ทางธุรกิจที่เปลี่ยนแปลงอย่างรวดเร็ว จากประสบการณ์ของผมอาจมีกฎเกณฑ์ทางธุรกิจเก่า ๆ อายุไม่กี่ปี แต่ส่วนใหญ่จะเปลี่ยนแปลงอย่างรวดเร็วและคุณไม่สามารถบอกได้ว่าจะเปลี่ยนกฎข้อใดต่อไป ข้อกำหนดใหม่จากหน่วยงานกำกับดูแลผลิตภัณฑ์เก่าที่ถูกปลดประจำการการเปลี่ยนแปลงหัวจดหมายการเปลี่ยนแปลงจำนวนพนักงานที่รายงานถึงเจ้านาย ฯลฯ ฯลฯ ฯลฯ

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

การกระทำที่ระบุสคีมาของตารางนั้นเป็นการย้ายตรรกะทางธุรกิจไปยังฐานข้อมูลเท่านั้น

สถาปัตยกรรม

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

มันไม่ง่ายเลย

แต่ลองคิดว่าสิ่งที่คิดไม่ถึงคุณจะรักษาตรรกะทางธุรกิจไว้ในหลายภาษาได้อย่างไร

• แคตตาล็อก ... เพื่อให้สามารถติดตามและบำรุงรักษากฎการดำเนินธุรกิจแต่ละรายการได้
• การทดสอบ ... ที่สามารถใช้กับกฎทางธุรกิจแต่ละข้อได้ไม่ว่าจะใช้ที่ไหนและอย่างไร
• การดำเนินการอ้างอิง .. เพื่อที่ว่าเมื่อพบความแตกต่างแหล่งที่มาของความจริงจะมีอยู่ (หรืออย่างน้อยก็เป็นแหล่งที่มาของการอภิปราย)

แต่นี่ก็มีค่าใช้จ่ายด้วย

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

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

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

1. คุณกำลังเพิ่มอุปสรรคในการแทนที่เอนจินการเก็บข้อมูล หากคุณลักษณะด้านการดำเนินงานหรือประสิทธิภาพหรือข้อ จำกัด คุณสมบัติบางอย่างทำให้คุณต้องเปลี่ยนเอนจิ้นการจัดเก็บค่าใช้จ่ายจะสูงขึ้นเพราะคุณจะเขียนและทดสอบรหัสใหม่จำนวนมาก การเรียกใช้เอนจินการเก็บข้อมูลมากกว่าหนึ่งรายการ (ไม่ว่าจะเป็นในระหว่างช่วงการย้ายข้อมูลหรือเพื่อแยกกิจกรรมตามความต้องการด้านประสิทธิภาพ) สามารถแนะนำปัญหาที่สอดคล้องกันได้เว้นแต่คุณจะใช้การมอบหมายแบบสองเฟส (2PC) ซึ่งมีปัญหาด้านประสิทธิภาพ
2. คุณมี API อื่นที่จะรักษาซึ่งหมายความว่าการพึ่งพาของคุณอาจแตกหักได้ การเพิ่มการลบหรือการเปลี่ยนชนิดของพารามิเตอร์ในโพรซีเดอร์สามารถทำให้รหัสที่มีอยู่เสียหายได้ สิ่งเดียวกันนี้เกิดขึ้นกับตารางและคิวรี แต่เครื่องมือของคุณอาจมีประโยชน์น้อยลงเมื่อติดตามสิ่งที่อาจเกิดความผิดพลาด ปัญหาเกี่ยวกับขั้นตอนการจัดเก็บมักพบได้ในช่วงรันไทม์ซึ่งช้ามากในกระบวนการพัฒนา / ปรับใช้
3. การอนุญาตฐานข้อมูลของคุณซับซ้อนมากขึ้น โพรซีเดอร์รันในฐานะผู้ใช้ที่ล็อกอินหรือเป็นบทบาทอื่นหรือไม่? คุณต้องคิดเรื่องนี้และจัดการสิ่งนี้ (หวังว่าจะเป็นแบบอัตโนมัติ)
4. คุณต้องสามารถโยกย้ายไปยังเวอร์ชันใหม่ได้อย่างปลอดภัย บ่อยครั้งที่ขั้นตอนจะต้องลดลงและสร้างขึ้นใหม่ สิทธิ์อีกครั้งอาจทำให้เกิดปัญหากับคุณ
5. การย้อนกลับของการโยกย้ายที่ล้มเหลวอาจหมายถึงความพยายามพิเศษ เมื่อสภาพแวดล้อมการผลิตถูกแยกออกจากนักพัฒนาสิ่งต่าง ๆ ก็ยิ่งท้าทายมากขึ้น

นี่คือการใช้โพรซีเดอร์ที่เก็บไว้ซึ่งฉันคิดว่ามักจะคุ้มค่า:

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

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

เนื่องจากคุณควรจัดการทรัพยากรฐานข้อมูลของคุณ (schema, การอนุญาต, ฯลฯ ) ผ่านเครื่องมืออัตโนมัติบางอย่าง, ไม่, ขั้นตอนการจัดเก็บไม่ได้เลวร้ายสำหรับไมโครซอฟท์

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

หนังสือส่วนใหญ่ใน microservices แนะนำหนึ่งฐานข้อมูลต่อ microservice

ตกลงเพื่อให้เราสามารถโค้ดโพรซีเดอร์ที่เก็บในฐานข้อมูลเหล่านี้

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

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

โปรดทราบว่า "แยก" ทำหน้าที่เหมือนตัวแทน decoupling สมมติว่าเรามีสองบริการ A ได้รับการสนับสนุนโดย Oracle และ B โดย MongoDB หากเราไม่ฝ่าฝืนกฎทองของการแยกตัวมันควรจะวาง A + Oracle ด้วยผลข้างเคียงเล็กน้อยบน B

การใช้ขั้นตอนการจัดเก็บที่เขียนไว้บอกเป็นพิเศษใน Oracle จับคู่ microservice กับเทคโนโลยีนั้นอย่างแน่นหนา

อาจทำให้ผู้ขายล็อคอิน หลายครั้งผู้ขายจะถูกกำหนดโดยธุรกิจเนื่องจากเหตุผลทางประวัติศาสตร์หรือสัญญา¹ 1สิ่งสำคัญคือต้องรู้วิธีที่จะไม่ล็อครหัสของเรากับผู้ขาย ตัวอย่างเช่น ORM และกรอบงานบางอย่างใช้ภาษาคิวรีใหม่ที่ซ่อนฟังก์ชันและฟีเจอร์ที่มีอยู่ในฐานข้อมูล

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

หนังสือ MSA ส่วนใหญ่ (ที่ฉันได้อ่าน) แนะนำว่า microservices ควรเป็นเชิงธุรกิจ (ออกแบบโดยใช้ DDD)

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

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

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

ไม่มีอะไรเกี่ยวข้องกับ microservices

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

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

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

ความสัมพันธ์กับ microservices ก็คือ microservices นั้นใหม่และมีอิทธิพลสูง - เราไม่ทำ monoliths อีกต่อไป - และรูปแบบสถาปัตยกรรมใหม่เหล่านี้ก็ยังมีลัคนาอยู่ - เราจะไม่ทำเลเยอร์แบนอีกต่อไป