- Published on
Microservices
- Authors
- Name
- PatharaNor
เป็น service ที่มีโครงสร้างที่มุ่งเน้นไปในเรื่องของการ design, develop และส่งต่อข้อมูลอย่างอิสระต่อกัน บนความหลากหลายในแง่ของระบบ ทั้งในเรื่องของ programing language, database, protocol รวมถึงระดับ network ที่เป็น transportation layer.
แต่ด้วยความที่มันอิสระจากกันการ implement logic เดียวกันในทุกๆ service นั้น (ยกตัวอย่าง เช่น authentication) ซึ่งไม่เหมาะ เพราะถ้า logic มีการเปลี่ยนแปลง เราต้องกลับมาปรับ logic นั้นในทุกๆ service ซึ่งมีโอกาสผิดพลาด และเกิดการทำงานซับซ้อนเกิดขึ้นได้
โดยมากแล้วจะมี service อีก layer นึงมาครอบ microservices เหล่านั้น เรามักเรียกว่า API Gateway
API Gateway
เป็น shared layer ที่คุยกับทั้ง client side และ internal services ซึ่งมีได้มากกว่า 1 API gateway ขึ้นอยู่กับการใช้งานหรือ objective ของ platform นั้นๆ โดยมากแล้วมีรูปแบบที่มักใช้กัน ดังนี้ :
- Routing and versioning
- Evolutionary design
- Authentication
- Data aggregation
- Transformation
- Serialization format transformation
- Protocol transformation
- Rate-limiting and caching
- Overambitious API gateways
Routing and versioning
เอาไว้สำหรับ support การใช้งาน service ใน version ต่างๆ ทั้ง version ใหม่และเก่าผ่าน API gateway นั้น
Evolutionary design
API gateway สามารถช่วยเราทำ transition จาก legacy system(หรือ monolith application) ที่เป็น as is
system ไปยัง new system ได้ smooth ขึ้น
แม้ microservices จะดีแต่เราก็ไม่ควรเริ่มจากการรื้อทำใหม่ในทันที แต่เราควรใช้ข้อดีของ microservice ร่วมกับ API gateway มาทะยอยย้ายของไปยังระบบใหม่ โดยทะยอยหยิบบาง service/module มา implement เป็น microservice(อย่าลืม design กันก่อนนะ) แล้วค่อยๆปลดของเก่าออก ซึ่งระหว่างนี้ก็ยังสามารถใช้ legacy service ได้อยู่ผ่าน proxy gateway
Authentication
service เกือบทุก service ในองค์กรส่วนใหญ่เป็น sensitive data เกือบทั้งหมด นั่นถือเป็น risk หากคนนอกสามารถเข้าถึงได้โดยง่าย ดังนั้นเราต้องให้ user ทำการ login เข้าสู่ระบบ เพื่อพิสูจน์ตัวตนก่อน เพื่อให้ทราบว่าเป็นสมาชิกของเรารึเปล่า
แต่การที่เราเอา logic ในการพิสูจน์ตัวตนไปใส่ในทุกๆ services ที่เราทำขึ้นมานั้นเป็นท่าที่ไม่เหมาะหนัก เพราะ code หน้าตาเหมือนกันทำงานเหมือนกัน เราควรรวบไปอยู่ในที่ที่เดียว ในที่นี้คือ API gateway ที่ทุกๆ transaction วิ่งผ่าน shared layer นี้หมด และยังทำให้ service เราเล็กลงด้วย
Data aggregation
ในบางเหตุการณ์ client side ต้องการข้อมูลที่แตกต่างกัน ซึ่งอยู่คนละ microservice
ตัว API gateway สามารถเข้ามาช่วยในการแปลงชุดข้อมูล ให้อยู่ในโครงสร้างที่นำไปใช้ได้(denormalizing data)ง่ายๆ และรวบข้อมูลเข้าด้วยกันก่อนตอบไปยัง client
note:
response
is
{
"uid": "tester",
"credit": 1000
}
uid
is
{
"uid": "tester"
}
credit
is
{
"credit": 1000
}
Serialization format transformation
นอกจากนี้ยังนำมาใช้ในการแปลงโครงสร้างของข้อมูล(data schema) จาก microservice ที่หลากหลาย ให้อยู่ในรูป standard กลางที่เราใช้คุยกัน ระหว่าง platform ของเราและ client ได้เช่นกัน
Protocol transformation
ปัจจุบัน technology ใหม่ๆเกิดขึ้นมากมาย เพื่อตอบโจทย์ข้อดีทางด้าน technical แตกต่างกันไป
API gateway เป็นตัวช่วยนึงที่เข้ามาช่วยให้เราคุยกับ client ได้แม้จะมีการปรับใช้ technology ใหม่ๆหลังบ้านก็ตาม
Rate-limiting and caching
คล้ายกับการทำ authentication logic ที่มีการใช้งานคล้ายๆกัน เราสามารถรวบ logic เหล่านั้นมาจัดการที่ API gateway ได้
โดยอะไรที่มีการใช้งานบ่อยๆ แล้วไม่มีการเปลี่ยน เราสามารถทำ caching ที่ gateway เพื่อช่วยลด load ที่ไม่จำเป็น ที่อาจส่งผลกับระบบได้
Overambitious API gateways
การ implement API gateway เราควรหลีกเลี่ยงการใส่ logic ที่จำเพาะเจาะจงลงไป จนเกินหน้าที่ๆมันเป็น
หากเราดันทุรังไม่ว่าสาเหตุใดก็ตาม โดยทำการใส่ logic ลงไปให้มันเรื่อยๆ ยกตัวอย่างเช่น
business: แก้ด่วน...ขอเที่ยงนี้ !!!
developer: -.-"แม้การแก้ที่ gateway มีความง่าย และเร็วกว่าก็ตาม การทำแบบนี้ มันอาจได้กลายร่างจาก API gateway เป็น service เข้าสักวัน
ต้องแข็งเข้าไว้ ชี้แจงให้ business เข้าใจ และหาวิธีที่เหมาะสมต่อไป...