แนวคิดในการทำ Shared data ใน Microservices แบบไม่เหนื่อย (PostgreSQL view + FDW)
ในการออกแบบระบบ โดยส่วนตัวผมคิดว่าปัญหาการ Share data ระหว่าง (Micro)services นี่เป็นปัญหาอันดับ 1 เลย ที่จะทำระบบมีปัญหาได้ง่าย หรือกลายเป็น Technical debt (Private) ไม่ว่าจะ Share data ด้วยวิธีอะไรก็ตาม
แต่ในที่นี้จะพูดถึงการ Share data ด้วยการ Shared Database เป็นหลัก และจะเป็นวิธีที่จะใช้ได้กับ PostgreSQL database เท่านั้น (db อื่นๆก็อาจจะทำได้ แต่ผมไม่รู้ 😆)
อ่านเพิ่ม เกี่ยวกับ Shard Database ที่นี่ >> Microservices Pattern: Shared database
ปัญหาปกติที่จะพบ ถ้าทำ Shared database
เกิด TIGHT coupling ระหว่าง Microservices กัน ซึ่งทำลายประโยชน์ของการที่เราทำ Microservices เพราะ Service ไม่เป็นอิสระต่อกันอีก การเปลี่ยนแปลงแต่ละครั้ง (change) อาจจะส่งผลกระทบให้ Service อื่นพังได้ เช่นการ เพิ่ม/ลบคอลัมน์, DB down for maintenance/upgrade
วิธีที่จะใช้
แนวคิดผมคือ
- database จะเป็นข้อมูลภายใน ไม่อยากให้ใครมาเข้าถึง (Law of Demeter)
- ใช้แนวคิด interface แบบ API Spec (contract) เพื่อจำกัดสิ่งที่เราจะ
- ใช้ Postgres Foreigner Data Wrapper (FDW) (Private) ในการ Share data
ทีนี้สิ่งที่จำต้องทำจริงๆ ก็คือ
-
ออกแบบตารางและข้อมูลที่จะ share ให้ service อื่นใช้ โดยการใช้
View
ซึ่ง view นี้อาจจะ join ข้อมูลมาจากหลายๆ table ให้พร้อมใช้เลยก็ได้ -
Setup Postgres Foreigner Datawrapper (FDW) (Private) เพื่อ import table ไว้ใช้งาน
ข้อดี
- ใช้แรงทำน้อยมาก แค่
CREATE VIEW
แล้วก็ทำFDW Import table
แทบไม่ต้อง dev เลย
ข้อเสีย/ข้อจำกัด
- ใช้ได้กับ PostgreSQL เท่านั้น
- ถ้า Remote PostgreSQL down ก็จะทำให้ Service ทำงานไม่ได้ เพราะเข้าถึงข้อมูลไม่ได้ เหมือนวิธี Shared database แบบปกติ
ทำอะไรต่อได้บ้าง?
แน่นอนว่าวิธีที่ผมบอกไป มันก็จะยังมี coupling กันอยู่ตรงที่ ถ้า database ที่เป็นเจ้าของข้อมูลมีการปิดเพื่อทำอะไรก็ตาม จะทำให้ทุกๆ service ที่ใช้งานข้อมูลนี้ก็จะใช้งานไม่ได้ไปด้วย (แต่ shared database แบบเดิมก็มีปัญหานี้อยู่แล้ว)
ผมคิดอยู่ว่าจะมีวิธีอะไรที่จะ copy ข้อมูลจาก (FDW) Imported tables ไปเก็บไว้ได้แบบง่ายๆได้บ้าง หรือว่าจะมีวิธีไหนที่จะเอา Postgresql Logical Replicaton มาใช้ช่วยตรงนี้ได้มั้ยนะ?
Notes
ผมเลือกที่ใช้จะวิธีการนี้ในการ share data ระหว่าง (Micro)services เพราะคิดว่ามันใช้ต้นทุนต่ำกว่าการทำตัว sync ข้อมูลเอง, การที่จะต้องศึกษา Change data capture tool ที่ไม่ชำนาญมาใช้กับงานนี้
แต่ถ้าระบบนั้นๆ สามารถทำตัว sync ข้อมูลหรือมีระบบนี้อยู่แล้ว หรือว่ามีเครื่องมือ change data capture tool ที่ใช้อยู่แล้ว ก็อาจจะไม่เลือกใช้ Shared database ด้วยวิธีข้างบนที่ผมบอกนี้