Microservices & Canonical model

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

รูปแบบสถาปัตยกรรม Microservices ปฏิเสธส่วนอื่น ๆ ของ SOA เช่นแนวคิดของ schema แบบบัญญัติ

— นักพนัน Vicky
แหล่งที่มา

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

— แจ็ค

ชัวร์แจ็คอยู่ที่นี่ - nginx.com/blog/introduction-to-microservices/…

— Punter Vicky

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

— Arseni Mourzenko

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

— Punter Vicky

แบบจำลองข้อมูลบางอย่างใช่ แต่ดูเหมือนว่าสำหรับฉันแล้วบทความนี้อ้างถึงแบบจำลองข้อมูล "ที่ใช้ร่วมกัน" หรือ "ทั่วไป" ระหว่าง 2 บริการขึ้นไป Canonical schema เป็นรูปแบบที่มีไว้เพื่อบันทึกบริการจากในการแปลงข้อมูลแบบรันไทม์ "ภาษา" ทั่วไประหว่างบริการ ดังนั้นดูเหมือนว่าบทความนี้จะเน้นไปที่ความเป็นอิสระทั้งหมดของ MS จาก "ระบบนิเวศ" ที่มันอาศัยอยู่ ยกตัวอย่างเช่นการกล่าวถึง ESB ESB มักจะต้องการรูปแบบข้อมูลองค์กร (ข้อความ) ซึ่งจะเป็นเรื่องธรรมดาสำหรับทุกคนในรถบัส MS ปฏิเสธที่จะเชื่อมต่อกับการหดตัวของระบบภายนอก

— Laiv

คำตอบ:

ขออภัยล่วงหน้าสำหรับการพึ่งพาความคิดเห็น @ArseniMourzenko แต่เมื่อฉันเริ่มอ่าน Wikipedia ฉันเข้าใจทันทีว่าCanonical Schemaหมายถึงอะไร

นี่คือความคิดเห็นของ OP ที่มุ่งเน้นไปที่ข้อสงสัยที่แท้จริง

ฉันเชื่อว่าแม้ในสถาปัตยกรรมไมโครบริการคำขอและการตอบสนองต้องเป็นไปตามรูปแบบข้อมูลบางอย่าง

แบบจำลองข้อมูลบางตัวใช่ แต่ดูเหมือนว่าบทความนี้อ้างถึงแบบจำลองข้อมูล "ที่ใช้ร่วมกัน" หรือ "ทั่วไป" ระหว่าง 2 บริการขึ้นไป

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

เป็น "ภาษา" ทั่วไประหว่างบริการ

ดังนั้นดูเหมือนว่าบทความนี้จะเน้นไปที่ความเป็นอิสระทั้งหมดของ MS จาก "ระบบนิเวศ" ที่มันอาศัยอยู่

ยกตัวอย่างเช่นการกล่าวถึง ESB

พวกเขายังหลีกเลี่ยงการใช้ ESB เป็นอย่างมากและใช้ฟังก์ชั่นคล้าย ESB แทนในไมโครไซต์ด้วยตนเอง

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

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

— LAIV
แหล่งที่มา

ขอบคุณ @Laiv ฉันจะมอบรางวัลใน 9 ชั่วโมง - ดังนั้นจะ จำกัด ฉัน :)

— Punter Vicky

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

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

— pnschofield
แหล่งที่มา

If you find that you have microservices making synchronous calls. ไม่จำเป็นต้องมีการเรียกแบบอะซิงโครนัส มันอาจเกิดขึ้นได้ด้วยข้อความแบบอะซิงโครนัส ESB ฉันคิดว่ามันมุ่งเน้นไปที่ความจริงที่จะควบคู่ไปกับ Schemas ที่ใช้ร่วมกันหรือสัญญาข้อมูล ฉันคิดว่าในสถาปัตยกรรม MS ควรหลีกเลี่ยงการสื่อสาร p2p ใด ๆ ระหว่าง servicies การสื่อสารควรจะเกิดขึ้นผ่านแอปพลิเคชันแทนเลเยอร์ภายใน (เซอร์วิสภายใน) หรือเลเยอร์ภายนอก (ESB, คิว ฯลฯ ) เลเยอร์

— Laiv