การสร้างเกตเวย์ API ของเราเองช่วยประหยัดค่าใช้จ่ายในการเรียกใช้บริการจากผู้ให้บริการภายนอกได้ถึง 38% แต่เราก็พบปัญหาเกี่ยวกับการปรับแต่งให้เหมาะสมกับการใช้งานในพื้นที่ต่างๆ
เมื่อสัปดาห์ที่แล้วทีมเครื่องมืออีคอมเมิร์ซในเอเชียตะวันออกเฉียงใต้ของเราเพิ่งเสร็จสิ้นการซื้อขายใหม่Q1การเรียกเก็บเงินค่าใช้จ่ายทางเทคนิคของเพื่อนร่วมงานที่รับผิดชอบต่ออินเทอร์เฟซการชําระเงินเกือบจะกระโดดขึ้น: หลังจากเปลี่ยนเกตเวย์ของบุคคลที่สามที่ใช้ก่อนหน้านี้ด้วยการวิจัยด้วยตนเองค่าใช้จ่ายในการเรียก API ต่อเดือนลดลงโดยตรง 38% แต่ในการทดสอบระดับสีเทาก่อนการส่งเสริมการขายอัตราความสําเร็จในการชําระเงินของผู้ใช้ของโหนดสิงคโปร์ก็ลดลง 6% หลังจากตรวจสอบครึ่งวันพบว่ากฎการเชื่อมต่อข้ามภูมิภาคของเกตเวย์ไม่ได้ปรับตัว
ก่อนอื่นเราต้องเข้าใจกันว่า “เกตเวย์ที่สร้างขึ้นเอง” (self-built gateway) คืออะไร
พูดง่ายๆคือคุณเขียนชุดของโปรแกรมพอร์ตเวย์การจราจรของคุณเองซึ่งจะนําคําขอ API ภายนอกทั้งหมดการโทรกลับของบุคคลที่สามและการโทรข้ามบริการทั้งหมดผ่านชั้นนี้แทนที่บริการเกตเวย์ของบุคคลที่สามที่คุณซื้อก่อนหน้านี้รุ่นที่เราใช้ในปัจจุบันทํางานบนเซิร์ฟเวอร์โหนดต่างประเทศ 4G แบบ 2 คอร์ เครื่องเดียวสามารถรับการร้องขอ 1200 ครั้งต่อวินาทีครอบคลุมความต้องการในการชําระเงินและการโทรแบบซิงโครนัสสินค้าโภคภัณฑ์เฉลี่ยต่อวัน 1.8 ล้านครั้ง
สามข้อดีที่คุณจะได้รับอย่างแท้จริง
- ประการแรกคือค่าใช้จ่ายสามารถลดลงได้จริงๆเกตเวย์ของบุคคลที่สามที่เราเคยใช้คิดค่าใช้จ่ายตามปริมาณการโทรซึ่งมีค่าใช้จ่าย $ 2,100 ต่อเดือนตอนนี้ค่าใช้จ่ายในการสร้างเซิร์ฟเวอร์ + การตรวจสอบของเราเองน้อยกว่า $ 1,300 ต่อเดือนและไม่มีข้อ จํากัด ของการเพิ่มขึ้นของราคาบันได
- ประการที่สอง กฎระเบียบเป็นตัวแทนของตัวเองก่อนหน้านี้การ จํากัด ปัจจุบันของเกตเวย์บุคคลที่สามเป็นแบบครบวงจร ในช่วงโปรโมชั่นใหญ่เราควรเพิ่มโควต้าการ จํากัด ปัจจุบันให้กับอินเตอร์เฟซการชําระเงินชั่วคราวและใช้เวลา 3 วันทําการในการสั่งงานทุกครั้ง ตอนนี้การเปลี่ยนการกําหนดค่าในพื้นหลังสามารถมีผลบังคับใช้ได้ใน 10 วินาที
- สุดท้ายคือข้อมูลที่ไม่ได้ใช้บุคคลที่สามเราทําเครื่องมืออีคอมเมิร์ซเพื่อรับการโทรกลับการชําระเงินจากผู้ใช้จํานวนมาก ก่อนหน้านี้คําขอทั้งหมดต้องไปยังโหนดของผู้ให้บริการบุคคลที่สาม ตอนนี้ข้อมูลที่ละเอียดอ่อนทั้งหมดไหลเวียนในเซิร์ฟเวอร์ของตัวเองและค่าใช้จ่ายในการปฏิบัติตามกฎระเบียบลดลงอย่างมาก
อย่าเร่งรีบสร้างมันเลย ลองดูข้อผิดพลาดที่เราเคยเจอกันก่อน
หลุมแรกคือปัญหาการปรับตัวของเครือข่ายในภูมิภาคในตอนแรกเราวางโหนดหลักของเกตเวย์ไว้ในสิงคโปร์ ต่อมาเราตัดการจราจรโดยตรงเมื่อเราเปิดเว็บไซต์มาเลเซีย เป็นผลให้คําขอของผู้ใช้ในท้องถิ่นหลีกเลี่ยงไปยังสิงคโปร์ก่อนและกลับความล่าช้าของเครือข่ายแสงเป็น 200 ms ผู้ใช้จํานวนมากไม่สามารถรอที่จะปิดหน้าการชําระเงินเราใช้เวลาหนึ่งสัปดาห์ในการสร้างโหนดขอบของมาเลเซีย
หลุมที่สองคือการหลุดออกจากกฎความปลอดภัยก่อนหน้านี้เกตเวย์ของบุคคลที่สามมาพร้อมกับการป้องกัน DDoS และการสกัดกั้นคําขอที่เป็นอันตรายโดยค่าเริ่มต้น เราลืมเพิ่มส่วนนี้เมื่อเราตั้งตัวเอง ในวันที่สามของการออนไลน์มีการร้องขอที่ไม่ถูกต้อง 200,000 ครั้งโดย และเกือบจะแขวนอินเทอร์เฟซสินค้าคงคลัง
หลุมที่สามคือค่าใช้จ่ายในการดําเนินงานและการบํารุงรักษาสูงกว่าที่คาดไว้ก่อนหน้านี้เกตเวย์ของบุคคลที่สามมีปัญหาการบริการลูกค้าโดยตรง ตอนนี้เราสามหลังการทํางานจะเปลี่ยนกันในการตรวจสอบเกตเวย์ การแก้ไขปัญหาของเกตเวย์แสงเมื่อเดือนที่แล้วคิดเป็น 15% ของเวลาทํางานของทุกคน
ทีมแบบไหนที่เหมาะสมสำหรับการร่วมงานด้วย และทีมแบบไหนควรถูกมองข้ามไปเลย เพื่อไม่เสียเวลา
หากทีมของคุณมีจำนวนการเรียกใช้ API ต่อวันมากกว่า 1 ล้านครั้ง หรือมีข้อมูลสำคัญจำนวนมากที่ต้องจัดการ หรือคุณเบื่อกับข้อจำกัดด้านการรองรับการใช้งาน (throttling) และขั้นตอนการส่งคำขอจากเกตเวย์ของบุคคลที่สาม การสร้างเกตเวย์ของตัวเองก็คุ้มค่าอย่างแน่นอนที่จะลงทุน
แต่ถ้าทีมงานของคุณมีแบ็คเอนด์เพียงไม่ถึง 2 หรือธุรกิจยังอยู่ในขั้นตอนการทดลองและข้อผิดพลาดอย่างรวดเร็ว กฎของอินเทอร์เฟซจะเปลี่ยนไปทุกสัปดาห์จริงๆ ไม่จําเป็นต้องใช้เวลาทํา เพียงแค่ใช้เกตเวย์ของบุคคลที่สามเพื่อแบกมันไว้ก่อน รอให้ธุรกิจมีเสถียรภาพก่อนเปลี่ยน
3 ข้อแนะนำปฏิบัติสำหรับผู้ที่ต้องการสร้างสิ่งนี้เป็นครั้งแรก
- ตัดจากฉากเดียวก่อน อย่าขึ้นมาแทนที่ทั้งหมดในตอนแรกเราตัดการจราจรของอินเทอร์เฟซการชําระเงินไปยังเกตเวย์ที่สร้างขึ้นเองและใช้เวลาสองสัปดาห์โดยไม่มีปัญหาก่อนที่จะค่อยๆย้ายอินเทอร์เฟซอื่น ๆ แม้ว่าปัญหาจะส่งผลกระทบต่อสถานการณ์การชําระเงินเท่านั้นจะไม่ปิดสถานีทั้งหมด
- ให้แน่ใจว่าคุณได้ทําการทดสอบความเครียดข้ามพื้นที่โดยเฉพาะอย่างยิ่งสําหรับธุรกิจในต่างประเทศอย่าเพิ่งออนไลน์หลังจากการทดสอบในท้องถิ่นค้นหาโหนดทดสอบในตลาดเป้าหมายของคุณเพื่อวิ่งการทดสอบความดัน 24 ชั่วโมงเพื่อดูว่ามีความล่าช้าและอัตราการสูญเสียแพคเกจมีปัญหาหรือไม่
- อย่าละเลยแผงควบคุมการตรวจสอบเลย คุณควรจับตาดูตัวชี้วัดหลักสามตัว ได้แก่ จำนวนคำขอ (request volume), อัตราความสำเร็จ (success rate), และความล่าช้า (delay) อย่างใกล้ชิด ตั้งค่าเกณฑ์การแจ้งเตือนให้เหมาะสม เพื่อที่คุณจะได้รับทราบทันทีเมื่อเกิดปัญหากับเว็บเกตเวย์ ไม่ต้องรอให้มีผู้ใช้งานร้องเรียนก่อน
ปัญหาเล็กๆ ที่พบบ่อย
คำถาม: จำเป็นต้องเขียนด้วยภาษา Go หรือ Rust เท่านั้นหรือไม่?
ไม่ต้องครับ เวอร์ชันแรกของเราเขียนด้วย Node.js และก็สามารถรองรับภาระงานในช่วงเวลาที่มีการใช้งานสูงสุดได้เช่นกัน คุณสามารถเลือกใช้ภาษาโปรแกรมที่ทีมของคุณคุ้นเคยได้เลย หากมีปัญหาด้านประสิทธิภาพในภายหลัง ค่อยเปลี่ยนไปใช้ภาษาอื่นก็ยังไม่สายครับ
คำถาม: เมื่อเทียบกับเกตเวย์ของผู้ให้บริการคลาวด์ ตัวไหนดีกว่ากัน?
ผู้ให้บริการคลาวด์มีเกตเวย์ที่มีความยืดหยุ่นมากกว่าผู้ให้บริการภายนอก แต่ก็ยังไม่เท่ากับความเสรีที่ได้จากการสร้างเอง หากคุณไม่ต้องการถูกผูกมัดกับผู้ให้บริการคลาวด์รายใดรายหนึ่ง การสร้างระบบเองจะเป็นทางเลือกที่คุ้มค่ากว่า
มีประโยชน์หรือไม่?