รูปแบบสถาปัตยกรรมและรูปแบบการสื่อสาร

การพัฒนาแอปพลิเคชันบน AWS

Ricardo Sueiras

Principal Technologist

ผู้สอน

รูปแบบสถาปัตยกรรมคืออะไร?

 

 

 

• แนวทางแก้ปัญหาที่ใช้ซ้ำได้สำหรับปัญหาที่พบบ่อย
• รูปแบบช่วยให้รู้ว่าควรใช้ AWS services ร่วมกันอย่างไร
• สถาปัตยกรรมกำหนดว่าแอปรับภาระงานได้ดีแค่ไหน
• มีรูปแบบสถาปัตยกรรมหลายแบบที่ควรรู้จัก

Monoliths

 

 

 

 

• หน่วยเดียวที่เชื่อมโยงกันแน่น
• โค้ดเบสเดียว ดีพลอยครั้งเดียว
• พัฒนาได้ง่ายในช่วงแรก
• ปรับขนาดลำบาก: ต้องขยายทุกส่วนพร้อมกัน

Microservices

 

 

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

Serverless

• ไม่ต้องจัดการ infrastructure เพียงแค่โค้ดและ configuration
• สร้างโดยใช้ AWS managed services ประกอบกัน
• AWS จัดการ provisioning การขยายขนาด และการบำรุงรักษา
• ข้อแลกเปลี่ยน: ขีดจำกัดเวลาประมวลผล cold starts และการผูกติดกับ vendor
• ค่าใช้จ่ายในการดำเนินงานแทบเป็นศูนย์ และขยายขนาดได้อัตโนมัติ

 

สถาปัตยกรรมขับเคลื่อนด้วย event (EDA)

• คอมโพเนนต์สื่อสารกันผ่านการผลิตและรับ event ไม่ใช่การเรียกตรง
• event คือบันทึกของสิ่งที่เกิดขึ้น (สั่งซื้อสินค้า รับชำระเงิน จัดส่งสินค้า)
• Producer ส่ง event ออกไป
• Consumer ลงทะเบียนรับ event ที่ต้องการ

 

ระบบแบบ tightly coupled และ loosely coupled

• แอปคลาวด์สมัยใหม่ประกอบด้วยหลายเซอร์วิส
• เซอร์วิสต้องสื่อสารและประสานงานกันเพื่อทำงานให้สำเร็จ
• การสื่อสารแบบ synchronous เชื่อมโยงกันแน่น
• การสื่อสารแบบ asynchronous เชื่อมโยงกันหลวม

การสื่อสารแบบ Synchronous

 

• เซอร์วิสส่งคำขอและรอการตอบกลับ
• ผู้เรียกถูกบล็อกจนกว่าจะได้รับการตอบกลับหรือ timeout
• นำไปใช้และทำความเข้าใจได้ง่าย
• เชื่อมโยงแน่น: ความช้าหรือล้มเหลวของ downstream อาจกระจายออกไป
• บรรเทาได้ด้วย timeout การ retry และ circuit breaker

รูปแบบ: request/response

• เป็นรากฐานของอินเทอร์เฟซแอปพลิเคชันส่วนใหญ่
• พฤติกรรมคาดเดาได้
• ผู้ใช้ได้รับ feedback ทันที

การสื่อสารแบบ Asynchronous

 

• ผู้ส่งไม่รอการตอบกลับ
• ส่งข้อความหรือ event แล้วประมวลผลต่อไป
• ผู้รับประมวลผลข้อความอย่างอิสระ
• เชื่อมโยงหลวม: ขยายขนาดและรับมือกับความล้มเหลวได้ดีกว่า
• รับมือกับ traffic spike และการขัดข้องบางส่วนได้อย่างราบรื่น
• ความท้าทาย: ข้อความซ้ำ ลำดับข้อความ และ eventual consistency

รูปแบบ: การแยกส่วนด้วย queue

• Producer ส่งข้อความไปยัง queue
• Consumer ดึงและประมวลผลข้อความอย่างอิสระ
• ป้องกันความล้มเหลวไม่ให้กระจายออกไป
• Producer และ consumer ขยายขนาดได้อิสระจากกัน

 

รูปแบบ: worker queue

• worker หลายตัวดึงข้อความจาก queue เดียวกัน
• ประมวลผลข้อความแบบขนาน
• รองรับการขยายขนาดแนวนอนและ throughput สูงขึ้น
• ไม่รับประกันลำดับข้อความ

รูปแบบ: publish/subscribe

• Publisher ส่งข้อความไปยัง SNS topic
• subscriber หลายรายได้รับข้อความเดียวกัน
• กระจายข้อมูลแบบ real-time ไปยัง consumer จำนวนมาก

 

รูปแบบ: fan-out

• ส่งข้อความหนึ่งชิ้นไปยัง consumer หลายรายพร้อมกัน
• ใช้กันอย่างแพร่หลายในสถาปัตยกรรมขับเคลื่อนด้วย event
• มีประโยชน์เมื่อหลายเซอร์วิสต้องตอบสนองต่อ event เดียวกัน

การเรียงลำดับข้อความ

• งานบางประเภทต้องประมวลผลข้อความตามลำดับที่ถูกต้อง
• Amazon SQS FIFO และ Kinesis รองรับการประมวลผลตามลำดับ
• การเรียงลำดับที่เข้มงวดลด throughput
• สมดุลระหว่างความถูกต้องและความสามารถในการขยายขนาด

มาฝึกกันเถอะ!

การพัฒนาแอปพลิเคชันบน AWS