Topology (โทโพโลยี)

โทโพโลยีพื้นฐานของ microservices แสดงอยู่ใน Figure 18-1 เนื่องจากลักษณะที่ทำหน้าที่เดียว (single-purpose) service ในสถาปัตยกรรมสไตล์นี้จึงมีขนาดเล็กกว่า distributed architecture แบบอื่นมาก ไม่ว่าจะเป็น orchestration-driven SOA ( Chapter 17 ), event-driven architecture ( Chapter 15 ) หรือ service-based architecture ( Chapter 14 ) สถาปนิกคาดหวังให้แต่ละ service มีทุกส่วนที่จำเป็นต่อการทำงานอย่างอิสระ รวมถึงฐานข้อมูลและ component ที่ต้องพึ่งพาอื่น ๆ

Microservices เป็นสถาปัตยกรรมแบบ distributed กล่าวคือ แต่ละ service จะรันอยู่ใน process ของตัวเอง ไม่ว่าจะเป็น virtual machine หรือ container การ decouple service ในระดับนี้ ช่วยแก้ปัญหาที่พบได้บ่อยในสถาปัตยกรรมที่ใช้ multitenant infrastructure สำหรับโฮสต์แอปพลิเคชันได้อย่างง่ายดาย ตัวอย่างเช่น เมื่อระบบใช้ application server จัดการแอปพลิเคชันหลายตัวพร้อมกัน application server จะช่วยให้เกิดการใช้ซ้ำ (reuse) เชิงปฏิบัติการของแบนด์วิดท์เครือข่าย หน่วยความจำ และพื้นที่ดิสก์ อย่างไรก็ตาม หากแอปพลิเคชันที่รองรับทั้งหมดเติบโตขึ้นเรื่อย ๆ ในที่สุดทรัพยากรบางอย่างบน shared infrastructure ก็จะเริ่มตึงตัว

อีกปัญหาหนึ่งคือการแยก (isolation) ที่ไม่เหมาะสมระหว่างแอปพลิเคชันที่ใช้ทรัพยากรร่วมกัน การแยกแต่ละ service ออกเป็น process ของตัวเองช่วยแก้ปัญหาทั้งหมดที่เกิดจากการแชร์ทรัพยากร ก่อนที่ระบบปฏิบัติการโอเพนซอร์สแบบใช้งานฟรีและการจัดสรรเครื่องอัตโนมัติจะพัฒนาขึ้นมา การให้แต่ละโดเมนมี infrastructure ของตัวเองนั้นไม่คุ้มค่าในทางปฏิบัติ แต่ทุกวันนี้ ด้วยทรัพยากรบนคลาวด์และเทคโนโลยี container (ดู "Cloud Considerations" ) ทีมต่าง ๆ จึงสามารถเก็บเกี่ยวประโยชน์ของการ decouple แบบสุดขั้วได้ ทั้งในระดับโดเมนและระดับปฏิบัติการ

Microservices topology

Figure 18-1. โทโพโลยีของสถาปัตยกรรมสไตล์ microservices

ประสิทธิภาพ (performance) มักเป็นข้อเสียของธรรมชาติแบบ distributed ใน microservices การเรียกผ่านเครือข่ายใช้เวลานานกว่าการเรียก method ภายในมาก และการตรวจสอบความปลอดภัยที่ทุก endpoint ก็เพิ่มเวลาประมวลผลเข้าไปอีก ทำให้สถาปนิกต้องคิดให้รอบคอบเกี่ยวกับผลกระทบของ granularity

เนื่องจาก microservices เป็นสถาปัตยกรรมแบบ distributed สถาปนิกที่มีประสบการณ์จึงแนะนำให้หลีกเลี่ยงการทำ transaction ข้ามขอบเขต service การกำหนด granularity ของ service ให้เหมาะสมจึงเป็นกุญแจสำคัญของความสำเร็จในสถาปัตยกรรมนี้