สถาปัตยกรรมไมโครเซอร์วิสแบบ Domain-Oriented ของ Uber

DOMA คือแนวทางที่ Uber ซึ่งมีไมโครเซอร์วิส 2,200 ตัว เลือกใช้เพื่อลดความซับซ้อน ขณะยังคงความยืดหยุ่นของ MSA ไว้

• ออกแบบโดยหยิบแนวคิดจาก DDD, SOA, OO, CA เป็นต้น แล้วปรับให้เหมาะกับระบบกระจายขนาดใหญ่ขององค์กรขนาดใหญ่

• เป็นบทความที่สรุปประสบการณ์ยาวนานของ Uber จากการดำเนินงาน MSA มาค่อนข้างนาน

หลักการพื้นฐานของ DOMA

1. รวมไมโครเซอร์วิสเป็นคอลเล็กชันตามหน่วยของโดเมน

2. สร้างคอลเล็กชันของโดเมนที่เรียกว่า Layer เพื่อให้ภายในแต่ละเลเยอร์สามารถมีการพึ่งพากันได้ → Layer Design

3. สร้าง Gateway ที่ให้อินเทอร์เฟซที่สะอาดในฐานะจุดเข้าใช้งานเดียวของแต่ละคอลเล็กชัน

4. แต่ละโดเมนควรเป็นอิสระจากโดเมนอื่น แต่ในหลายกรณีก็จำเป็นต้องรวมตรรกะของโดเมนอื่นด้วย จึงมีสถาปัตยกรรม Extension มารองรับเรื่องนี้อย่างเหมาะสม

** การนำไปใช้ของ Uber

• Domains

→ กลุ่มของไมโครเซอร์วิสอย่างน้อยหนึ่งตัวที่ถูกจัดกลุ่มกันในเชิงตรรกะ

→ ในแต่ละโดเมนอาจมีบริการมากกว่า 10 ตัว หรืออาจมีเพียงตัวเดียวก็ได้

→ ตัวอย่าง) การค้นหาแผนที่ ค่าโดยสาร แพลตฟอร์มการจับคู่ (ผู้โดยสารและคนขับ) ล้วนเป็นหนึ่งโดเมน

→ ไม่ได้ยึดตามโครงสร้างองค์กรของบริษัท ดังนั้นทีมด้านแผนที่ของ Uber จึงประกอบด้วย 3 โดเมน, 80 ไมโครเซอร์วิส และ 3 เกตเวย์

• Layer Design

→ เป็นคำตอบของคำถามว่า "บริการใดสามารถเรียกใช้บริการอื่นได้บ้าง?"

→ คือ "separation of concerns at scale" หรือ "dependency management at scale"

→ Uber แบ่งออกเป็น 5 Layer

1. Infrastructure : ความสามารถที่ทุกองค์กรใช้ได้ เช่น สตอเรจ/เน็ตเวิร์ก เป็นต้น

2. Business : ความสามารถที่ใช้ได้ในระดับธุรกิจ โดยไม่จำกัดอยู่แค่หมวดผลิตภัณฑ์เฉพาะหรือ LOB (Line Of Business) อย่าง Rides, Eats, Freight เป็นต้น

3. Product : ความสามารถที่เกี่ยวข้องกับหมวดผลิตภัณฑ์หรือ LOB เฉพาะ แต่ก็อาจเป็นสิ่งที่หลายแอปใช้ร่วมกัน เช่น "Request a ride"

4. Presentation : ความสามารถที่เกี่ยวข้องกับแอปพลิเคชันสำหรับผู้ใช้ (มือถือ / เว็บ)

5. Edge : การเปิดเผยบริการของ Uber ออกสู่ภายนอกอย่างปลอดภัย และเชื่อมโยงกับแอปมือถือด้วย

• Gateways

→ ไม่ได้ต่างจาก API Gateway ของไมโครเซอร์วิสมากนัก แต่ให้มองว่าเป็นจุดเข้าใช้งานเดียว (Single Entry-point) ที่เชื่อมกับ Domain

→ เพราะภายในจะมี dependency กับภายนอกเพียงจุดเดียว จึงช่วยลดภาระเรื่อง migration, discovery และความซับซ้อนของระบบโดยรวม

• Extensions

→ กลไกสำหรับขยายโดเมนโดยไม่ต้องเปลี่ยน implementation ของบริการหรือกระทบต่อเสถียรภาพ

1. การขยาย Logic : ขยายตรรกะของบริการด้วย Provider หรือ Plugin pattern

2. การขยาย Data : กลไกสำหรับแนบข้อมูลตามต้องการเพื่อป้องกันไม่ให้ core data พองตัว โดยใช้ Any type ของ Protobuf

3. การขยาย Custom : แต่ละทีมขยายตามรูปแบบที่เหมาะกับโดเมนของตน

ช่วยลดเวลา onboarding ลงได้ 25~50%

แยกไมโครเซอร์วิส 2,200 ตัวออกเป็น 70 โดเมน

Uber คำนวณอายุครึ่งชีวิตของไมโครเซอร์วิสไว้ที่ 1.5 ปี กล่าวคือทุก ๆ 1.5 ปี ไมโครเซอร์วิส 50% จะหายไป

หากไม่มีเกตเวย์ ทุกครั้งที่มันหายไปก็จะเกิด migration hell ขึ้น

ที่ Uber ได้พิสูจน์แล้วว่าแพลตฟอร์มที่ออกแบบด้วย DOMA นั้นขยายได้ง่ายกว่าและดูแลรักษาง่ายกว่าอย่างมาก

คำแนะนำเชิงปฏิบัติสำหรับบริษัทอื่น ๆ

• สตาร์ตอัป :

→ คำถามสำคัญคือ "ควรเริ่มใช้ MSA เมื่อไร?" และ "เหมาะกับองค์กรของเราหรือไม่?"

→ MSA มีข้อดีด้านการปฏิบัติการสำหรับองค์กรที่มีวิศวกรมาก แต่ก็เพิ่มความซับซ้อนและอาจทำให้การพัฒนาฟีเจอร์ยากขึ้น

→ สำหรับองค์กรขนาดเล็ก อาจได้เพียงความซับซ้อนทางสถาปัตยกรรมที่เพิ่มขึ้นโดยแทบไม่ได้ประโยชน์ด้านการปฏิบัติการ และอาจมีต้นทุนสูงขึ้นด้วย

→ ค่อย ๆ นำมาใช้ก็ได้ไม่มีปัญหา และถ้าตัดสินใจไปทาง MSA ก็ควรมองมันเป็น "โปรแกรมแบบกระจายขนาดใหญ่" และแยกไมโครเซอร์วิสออกจากกันอย่างเหมาะสม

→ ไมโครเซอร์วิสชุดแรกจะมีความสำคัญในการอธิบายฟังก์ชันหลักของธุรกิจ และมีแนวโน้มจะคงอยู่นาน

• บริษัทขนาดกลาง :

→ เมื่อบริษัทเริ่มแบ่งเป็นหลายทีม และความสนใจของแต่ละแพลตฟอร์มเริ่มแยกออกจากกัน MSA จะมีประโยชน์มากขึ้น

→ ในขั้นนี้สามารถเริ่มพิจารณาโครงสร้างแบบลำดับชั้นระหว่างไมโครเซอร์วิสได้ และเมื่อมีบริการถูกใช้งานมากขึ้น การจัดการ dependency ก็จะสำคัญมากขึ้น

→ แม้จำนวนไมโครเซอร์วิสจะยังไม่มากจนการทำคลัสเตอร์อาจยังไม่ค่อยมีความหมาย แต่การคิดแบบ domain-oriented ก็ยังมีประโยชน์

• บริษัทขนาดใหญ่ :

→ สำหรับองค์กรวิศวกรรมขนาดใหญ่ที่มีวิศวกรจำนวนหลายร้อยคน รวมถึงไมโครเซอร์วิสและ dependency จำนวนมาก DOMA มีประโยชน์อย่างเต็มที่

→ สามารถจัดกลุ่มเป็นโดเมนที่มีเกตเวย์ได้ง่าย และเมื่อรีแฟกเตอร์หรือเขียนระบบ legacy ใหม่ เกตเวย์ก็มีประโยชน์เช่นกัน

ที่ Uber เองก็มีทีมจำนวนมากขึ้นเรื่อย ๆ ที่กำลังนำ DOMA ไปใช้ (ว่ากันว่ามีคนราว 60 คนจากทุกองค์กรของ Uber ร่วมกันพัฒนาสิ่งนี้ตลอด 2 ปี)

[algedian]

https://eng.uber.com/microservice-architecture/

ตอนนี้เหมือนจะมองเห็นได้ตามปกติแล้ว.. แต่ดูเหมือนว่ารูปในเวอร์ชันบน Wayback Machine จะต่างออกไปนิดหน่อย

[xguru]

อ๊ะ กลับมาใช้ได้อีกแล้วนะ 555 เลยเปลี่ยนกลับไว้เหมือนเดิมแล้วครับ

ดูเหมือนว่ารูปที่เห็นชื่อบริการแบบละเอียดจะเป็นปัญหานะครับ

[jaeyeonling]

สงสัยว่าบทความน่าจะถูกลบไปแล้วนะ T.T

[xguru]

อ๋อ จริงด้วยครับ อย่างน้อยก็ยังดูได้ใน Wayback Machine

https://web.archive.org/web/20200803012939/…

[jaeyeonling]

ขอบคุณค่ะ :)