การออกแบบแอปพลิเคชันใน Azure Service Fabric

ฉันต้องการความช่วยเหลือในการคิดเกี่ยวกับการออกแบบแอปพลิเคชันของเราให้เข้ากับเทมเพลต Azure Service Fabric ใหม่

วันนี้เรามีแอปพลิเคชันที่สร้างบน Azure Cloud Services แอปพลิเคชันนี้สร้างขึ้นโดยใช้ DDD และเรามีบริบทที่มีขอบเขตแยกต่างหากสำหรับส่วนระบบย่อยต่างๆ ของแอปพลิเคชัน ปัจจุบันบริบทที่มีขอบเขตถูกโฮสต์ในบทบาทผู้ปฏิบัติงานเพียงคนเดียว ซึ่งเปิดเผยระบบย่อยเหล่านี้โดยใช้ WebAPI เดียว

นอกจากนี้ เรายังมีบทบาทเว็บหนึ่งรายการที่โฮสต์ส่วนหน้าของเว็บ และบทบาทผู้ปฏิบัติงานอีกหนึ่งบทบาทที่ประมวลผลคิวเบื้องหลัง

เรามุ่งมั่นที่จะย้ายไปสู่สถาปัตยกรรมไมโครเซอร์วิส สิ่งแรกที่ฉันวางแผนจะทำคือแยกบริบทที่มีขอบเขตทั้งหมดลงในโฮสต์ API ของตัวเอง ซึ่งจะส่งผลให้มีบริการ WebAPI ใหม่ 5-10 บริการที่รองรับระบบย่อยของเรา

สำหรับคำถามของฉัน ระบบย่อย/บริบทที่มีขอบเขต/โฮสต์ API ทั้งหมดควรเป็น Service Fabric Application ของตัวเองหรือบริการภายใน Service Fabric Application เดียว

ฉันได้อ่านเอกสารประกอบแล้ว ซึ่งพบได้ที่นี่ โมเดลแอปพลิเคชัน Service Fabric ซ้ำแล้วซ้ำอีก และฉันก็ไม่รู้ว่าบริการของฉันเหมาะกับจุดไหน

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

โปรดมีคนแนะนำฉันในสิ่งที่เหมาะสมกับความต้องการของฉัน


comment
หากคุณต้องการอัปเกรดส่วนต่างๆ แยกกัน แต่ละส่วนควรเป็นแอปพลิเคชัน สำหรับวิธีออกแบบสถาปัตยกรรมแอปพลิเคชันของคุณนั้นขึ้นอยู่กับความต้องการส่วนบุคคลของคุณจริงๆ ตรวจสอบให้แน่ใจว่าคุณได้ตั้งค่าแผนการแบ่งพาร์ติชันเพื่อรองรับการเติบโตในอนาคต ด้วย SF คุณจะวางพาร์ติชั่นทั้งหมดของคุณไว้ในเครื่องจำนวนเล็กน้อย จากนั้นจึงกระจายพาร์ติชั่นออกไปในภายหลังเมื่อคุณเติบโตเทียบกับการเพิ่มพาร์ติชั่นเพิ่มเติมในอนาคต   -  person Dan Harms    schedule 01.06.2016


คำตอบ (1)


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

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

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

ในการใช้งานจริง แอปพลิเคชันแสดงถึงขอบเขตกระบวนการ กลุ่มการอัพเกรด และกลุ่มเวอร์ชัน:

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

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

person Vaclav Turecek    schedule 01.06.2016
comment
ขอบคุณสำหรับคำตอบโดยละเอียดของคุณ! ช่วยฉันได้มาก :-) - person honk; 02.06.2016
comment
หากเราใช้แอปพลิเคชันแยกกัน แต่แต่ละบริการจำเป็นต้องสื่อสารกับบริการในแอปพลิเคชันอื่น วิธีที่ดีที่สุดคืออะไร (บริบท: การพัฒนาและการทดสอบ) ? Kuberenetes มอบตัวเลือก Azure Dev Space พร้อม AKS เพื่อสร้างสถานการณ์จำลองของการพัฒนาบริการขนาดเล็กด้วยการวนซ้ำภายใน คำแนะนำเกี่ยวกับโครงสร้างการบริการจะเป็นประโยชน์มาก - person Sowmyan Soman; 09.11.2018