Published on

Microservices

Authors
  • avatar
    Name
    PatharaNor
    Twitter

เป็น 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 นั้น

Internal services
call-v1
call-v2
v1
v2
Service B
Service A
Service D
Service C
iOS
API Gateway
Android

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

Internal services
New Service B
New Service A
New Service C
Client
Proxy/API Gateway
Legacy monolith

Authentication

service เกือบทุก service ในองค์กรส่วนใหญ่เป็น sensitive data เกือบทั้งหมด นั่นถือเป็น risk หากคนนอกสามารถเข้าถึงได้โดยง่าย ดังนั้นเราต้องให้ user ทำการ login เข้าสู่ระบบ เพื่อพิสูจน์ตัวตนก่อน เพื่อให้ทราบว่าเป็นสมาชิกของเรารึเปล่า

แต่การที่เราเอา logic ในการพิสูจน์ตัวตนไปใส่ในทุกๆ services ที่เราทำขึ้นมานั้นเป็นท่าที่ไม่เหมาะหนัก เพราะ code หน้าตาเหมือนกันทำงานเหมือนกัน เราควรรวบไปอยู่ในที่ที่เดียว ในที่นี้คือ API gateway ที่ทุกๆ transaction วิ่งผ่าน shared layer นี้หมด และยังทำให้ service เราเล็กลงด้วย

Internal services
Service B
Service A
Service D
Service C
Client
API Gateway + Auth

Data aggregation

ในบางเหตุการณ์ client side ต้องการข้อมูลที่แตกต่างกัน ซึ่งอยู่คนละ microservice

ตัว API gateway สามารถเข้ามาช่วยในการแปลงชุดข้อมูล ให้อยู่ในโครงสร้างที่นำไปใช้ได้(denormalizing data)ง่ายๆ และรวบข้อมูลเข้าด้วยกันก่อนตอบไปยัง client

Internal services
response
uid
credit
Service A
Service B
Service C
Service D
API Gateway
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 ได้เช่นกัน

XML
JSON
JSON
Client
API Gateway
Service A
Service C

Protocol transformation

ปัจจุบัน technology ใหม่ๆเกิดขึ้นมากมาย เพื่อตอบโจทย์ข้อดีทางด้าน technical แตกต่างกันไป

API gateway เป็นตัวช่วยนึงที่เข้ามาช่วยให้เราคุยกับ client ได้แม้จะมีการปรับใช้ technology ใหม่ๆหลังบ้านก็ตาม

RESTful
gRPC
GraphQL
Client
API Gateway
Service A
Service C

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 เข้าใจ และหาวิธีที่เหมาะสมต่อไป...

avatar
PatharaNor
Tech Writer