架构师陈
？
แพลตฟอร์มใหม่ของเราควรใช้สถาปัตยกรรมไมโครเซอร์วิสตั้งแต่ต้นเลยไหม?
高级工程师周
，，。
ไม่จำเป็นเสมอไป ไมโครเซอร์วิสแก้ปัญหาเรื่องการขยายขนาดและการทำงานร่วมกันในทีม โปรเจกต์ระยะแรกใช้สถาปัตยกรรมแบบ monolith กลับเรียบง่ายและมีประสิทธิภาพกว่า
架构师陈
，？
คอขวดหลักของ monolith คืออะไรที่ทำให้เราต้องย้ายในภายหลัง?
高级工程师周
，，。
หลักๆ คือการ deploy ที่ผูกติดกันและความละเอียดในการขยายที่หยาบ การเปลี่ยนแปลงโมดูลเดียวต้องทำการ deploy ทั้งระบบ และไม่สามารถขยายโมดูลแต่ละตัวได้อิสระ
架构师陈
？
Distributed transaction ในไมโครเซอร์วิสจัดการอย่างไร?
高级工程师周
，，。
นี่คือปัญหาที่ยุ่งยากที่สุดอย่างหนึ่ง โดยทั่วไปใช้รูปแบบ Saga แยก distributed transaction ออกเป็นชุดของ local transaction แล้วใช้ event compensation เมื่อล้มเหลว
架构师陈
？
การสื่อสารระหว่างเซอร์วิสควรใช้แบบ synchronous หรือ asynchronous?
高级工程师周
，，。
คำขอที่ sensitive ต่อ latency ใช้ gRPC แบบ synchronous คำขอที่ไม่ต้องการ eventual consistency สูงใช้ message queue แบบ asynchronous การใช้ทั้งสองอย่างผสมกันยืดหยุ่นกว่า
架构师陈
？
ด้าน observability มีอะไรสำคัญที่ต้องทำบ้าง?
高级工程师周
，，，。
Distributed tracing เป็นสิ่งจำเป็น ทุก request ต้องมี global trace ID รวมกับ centralized logging และ metric aggregation จึงจะสามารถระบุปัญหาข้ามเซอร์วิสได้อย่างรวดเร็ว
架构师陈
，，？
งั้นการตัดสินใจของเราคือ ทำ monolith ที่มีการแบ่งโมดูลอย่างดีก่อน แล้วรอให้ทีมและ traffic เติบโตถึงระดับหนึ่งค่อยแยก?
高级工程师周
，“”，，，。
ถูกต้อง นั่นเรียกว่ากลยุทธ์ "monolith ก่อน" ถ้าขอบเขตชัดเจนแล้วการแยกในภายหลังก็เป็นธรรมชาติมากขึ้น หลีกเลี่ยงการนำความซับซ้อนของระบบกระจายมาใช้เร็วเกินไป