เหตุการณ์แบบเรียลไทม์ของ Fleet Engine

สัญญาณแบบเกือบเรียลไทม์จากกลุ่มยานพาหนะที่ทำงานในพื้นที่นั้นมีประโยชน์ต่อธุรกิจในหลายๆ ด้าน ตัวอย่างเช่น ธุรกิจสามารถใช้ข้อมูลเหล่านี้เพื่อดำเนินการต่อไปนี้

  • ตรวจสอบประสิทธิภาพของกลุ่มยานพาหนะและระบุปัญหาที่อาจเกิดขึ้นตั้งแต่เนิ่นๆ
  • ปรับปรุงการบริการลูกค้าด้วยการระบุเวลาถึงโดยประมาณและข้อมูลการติดตามที่ถูกต้อง
  • ลดค่าใช้จ่ายด้วยการระบุและแก้ไขความไม่มีประสิทธิภาพ
  • เพิ่มความปลอดภัยด้วยการตรวจสอบพฤติกรรมคนขับและระบุอันตรายที่อาจเกิดขึ้น
  • เพิ่มประสิทธิภาพเส้นทางและตารางเวลาของคนขับเพื่อปรับปรุงประสิทธิภาพ
  • ปฏิบัติตามกฎระเบียบโดยการติดตามตำแหน่งของยานพาหนะและชั่วโมงการให้บริการ

เอกสารนี้แสดงวิธีที่นักพัฒนาแอปสามารถเปลี่ยนสัญญาณจาก "บริการด้านการเดินทาง" ของ Google Maps Platform ("โซลูชัน Last Mile Fleet (LMFS) หรือ "โซลูชันการเดินทางและการจัดส่งแบบออนดีมานด์ (ODRD) ให้เป็นเหตุการณ์ที่กำหนดเองที่นำไปใช้ได้จริง นอกจากนี้ยังครอบคลุมแนวคิดหลักและการตัดสินใจด้านการออกแบบของโซลูชันอ้างอิงเหตุการณ์ของ Fleet ที่มีอยู่ใน GitHub ด้วย

เอกสารนี้เกี่ยวข้องกับบุคคลต่อไปนี้

  • สถาปนิกที่คุ้นเคยกับ "บริการด้านการเดินทาง" ของ Google Maps Platform และ "Fleet Engine" ซึ่งเป็นหนึ่งในองค์ประกอบหลัก สำหรับผู้ที่เพิ่งเริ่มใช้ "บริการด้านการเดินทาง" เราขอแนะนำให้ทำความคุ้นเคยกับโซลูชัน Last Mile Fleet และ/หรือโซลูชันการเดินทางและการจัดส่งแบบออนดีมานด์ ทั้งนี้ขึ้นอยู่กับความต้องการของคุณ
  • สถาปนิกที่คุ้นเคยกับ Google Cloud สำหรับผู้ที่เพิ่งเริ่มใช้ Google Cloud เราขอแนะนำให้อ่านการสร้าง Data Pipeline สตรีมมิงใน Google Cloud ก่อน
  • หากคุณกำหนดเป้าหมายเป็นสภาพแวดล้อมหรือสแต็กซอฟต์แวร์อื่นๆ ให้มุ่งเน้นที่การทำความเข้าใจจุดผสานรวมและข้อควรพิจารณาที่สำคัญของ Fleet Engine ซึ่งยังคงใช้ได้
  • ผู้ที่มีความสนใจทั่วไปในการสำรวจวิธีสร้างและใช้ประโยชน์จากเหตุการณ์จากกลุ่มยานพาหนะ

เมื่ออ่านเอกสารนี้จบ คุณควรมีความเข้าใจพื้นฐานเกี่ยวกับองค์ประกอบหลักและข้อควรพิจารณาของระบบสตรีมมิง รวมถึงองค์ประกอบต่างๆ จาก Google Maps Platform และ Google Cloud ที่ประกอบกันเป็นโซลูชันอ้างอิงสำหรับเหตุการณ์ใน Fleet

ภาพรวมโซลูชันอ้างอิงสำหรับเหตุการณ์ของ Fleet

โซลูชันอ้างอิงเหตุการณ์ของ Fleet เป็นโซลูชันโอเพนซอร์สที่ช่วยให้ลูกค้าและพาร์ทเนอร์ด้านการเดินทางสามารถสร้างเหตุการณ์สำคัญบน Fleet Engine และคอมโพเนนต์ของ Google Cloud ปัจจุบันโซลูชันอ้างอิงรองรับลูกค้าที่ใช้ Last Mile Fleet Solution โดยจะรองรับการเรียกรถและการจัดส่งแบบออนดีมานด์ในอนาคต

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

  • การเปลี่ยนแปลง ETA สำหรับการมาถึงของงาน
  • การเปลี่ยนแปลง ETA แบบสัมพัทธ์สำหรับการมาถึงของงาน
  • เวลาที่เหลือก่อนถึงงาน
  • ระยะทางที่เหลือจนกว่าจะถึงสถานที่ทำงาน
  • การเปลี่ยนแปลงสถานะ TaskOutcome

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

องค์ประกอบที่ใช้สร้างสรรค์เชิงตรรกะ

แผนภาพ : แผนภาพต่อไปนี้แสดงองค์ประกอบที่ใช้สร้างสรรค์ระดับสูงซึ่งประกอบขึ้นเป็นโซลูชันอ้างอิงของเหตุการณ์ใน Fleet

ภาพรวมของ Fleet Events และองค์ประกอบเชิงตรรกะ

โซลูชันอ้างอิงประกอบด้วยคอมโพเนนต์ต่อไปนี้

  • แหล่งที่มาของเหตุการณ์: แหล่งที่มาของสตรีมเหตุการณ์เดิม ทั้ง "โซลูชัน Last Mile Fleet" หรือ "โซลูชันการเดินทางและการจัดส่งแบบออนดีมานด์" มีการผสานรวมกับ Cloud Logging ที่ช่วยเปลี่ยนบันทึกการเรียก RPC ของ Fleet Engine ให้เป็นสตรีมเหตุการณ์ที่นักพัฒนาแอปเข้าถึงได้ ซึ่งเป็นแหล่งข้อมูลหลักที่ใช้ในการบริโภค
  • การประมวลผล: บันทึกการโทร RPC ดิบจะได้รับการแปลงเป็นเหตุการณ์การเปลี่ยนแปลงสถานะภายในบล็อกนี้ซึ่งจะคำนวณผ่านสตรีมของเหตุการณ์ในบันทึก หากต้องการตรวจจับการเปลี่ยนแปลงดังกล่าว คอมโพเนนต์นี้ต้องมีที่เก็บสถานะเพื่อให้สามารถเปรียบเทียบเหตุการณ์ขาเข้าใหม่กับเหตุการณ์ก่อนหน้าเพื่อตรวจจับการเปลี่ยนแปลงได้ กิจกรรมอาจไม่ได้รวมข้อมูลทั้งหมดที่น่าสนใจเสมอไป ในกรณีดังกล่าว บล็อกนี้อาจทำการค้นหาการเรียกใช้แบ็กเอนด์ตามที่จำเป็น
    • State store: เฟรมเวิร์กการประมวลผลบางอย่างจะจัดเก็บข้อมูลระดับกลางไว้ในตัวเฟรมเวิร์กเอง แต่หากไม่เป็นเช่นนั้น คุณควรใช้บริการการคงอยู่ของข้อมูลประเภท K-V เพื่อจัดเก็บสถานะด้วยตนเอง เนื่องจากข้อมูลเหล่านี้ควรไม่ซ้ำกันสำหรับยานพาหนะและประเภทเหตุการณ์
  • ซิงก์ (เหตุการณ์ที่กำหนดเอง): การเปลี่ยนแปลงสถานะที่ตรวจพบควรพร้อมใช้งานสำหรับแอปพลิเคชันหรือบริการที่อาจได้รับประโยชน์จากการเปลี่ยนแปลงดังกล่าว ดังนั้นจึงเป็นตัวเลือกที่เหมาะสมในการเผยแพร่เหตุการณ์ที่กำหนดเองนี้ไปยังระบบการนำส่งเหตุการณ์สำหรับการใช้งานปลายทาง
  • บริการดาวน์สตรีม: โค้ดที่ใช้เหตุการณ์ที่สร้างขึ้นและดำเนินการตามกรณีการใช้งานของคุณ

การเลือกบริการ

เมื่อต้องใช้โซลูชันอ้างอิงสำหรับ "Last Mile Fleet Solution" หรือ "On-demand Rides and Deliveries Solution" (จะพร้อมให้บริการในช่วงปลายไตรมาสที่ 3 ปี 2023) การเลือกเทคโนโลยีสำหรับ "แหล่งที่มา" และ "ซิงก์" จะตรงไปตรงมา ในทางกลับกัน "การประมวลผล" มีตัวเลือกที่หลากหลาย โซลูชันอ้างอิงได้เลือกบริการของ Google ต่อไปนี้

แผนภาพ : แผนภาพต่อไปนี้แสดงบริการ Google Cloud เพื่อใช้โซลูชันอ้างอิง

องค์ประกอบพื้นฐานของโซลูชันอ้างอิงสำหรับเหตุการณ์ใน Fleet

เลย์เอาต์โปรเจ็กต์ที่อยู่ในระบบคลาวด์

เราขอแนะนำให้คุณใช้การติดตั้งใช้งานแบบหลายโปรเจ็กต์เป็นค่าเริ่มต้น ทั้งนี้เพื่อให้สามารถแยกการใช้งาน Google Maps Platform และ Google Cloud ออกจากกันอย่างชัดเจน และเชื่อมโยงกับการจัดการการเรียกเก็บเงินที่คุณเลือก

แหล่งที่มาของเหตุการณ์

"Last Mile Fleet Solution" และ "On-demand Rides and Deliveries Solution" เขียนเพย์โหลดคำขอและการตอบกลับ API ไปยัง Cloud Logging Cloud Logging จะส่งบันทึกไปยังบริการที่เลือกอย่างน้อย 1 รายการ การกำหนดเส้นทางไปยัง Cloud Pub/Sub เป็นตัวเลือกที่เหมาะสมที่สุดในกรณีนี้ และช่วยให้คุณแปลงบันทึกเป็นสตรีมเหตุการณ์ได้โดยไม่ต้องเขียนโค้ด

อ่างล้างจาน

ใน Google Cloud นั้น Cloud Pub/Sub เป็นระบบการส่งข้อความแบบเกือบเรียลไทม์ที่ได้รับความนิยม เหตุการณ์ที่กำหนดเองจะได้รับการเผยแพร่ไปยัง Pub/Sub เพื่อการใช้งานปลายทางเช่นเดียวกับวิธีที่เหตุการณ์จากแหล่งที่มาได้รับการส่งไปยัง Pub/Sub

กำลังดำเนินการ

คอมโพเนนต์ต่อไปนี้มีบทบาทในการประมวลผลเหตุการณ์ เช่นเดียวกับองค์ประกอบอื่นๆ คอมโพเนนต์การประมวลผลเป็นแบบ Serverless โดยสมบูรณ์และปรับขนาดได้ดีทั้งขึ้นและลง

  • Cloud Functions เป็นแพลตฟอร์มการประมวลผลสำหรับรุ่นแรก (*)
    • Serverless ปรับขนาดขึ้นและลงได้ด้วยการควบคุมการปรับขนาดเพื่อจัดการค่าใช้จ่าย
    • Java เป็นภาษาโปรแกรมที่ใช้เนื่องจากมีไลบรารีของไคลเอ็นต์สำหรับ API ที่เกี่ยวข้องกับ Fleet Engine ซึ่งช่วยให้ติดตั้งใช้งานได้ง่าย
  • Cloud Firestore เป็นพื้นที่เก็บข้อมูลสถานะ
    • ที่เก็บคีย์-ค่าแบบ Serverless
  • Cloud Pub/Sub เป็นจุดผสานรวมกับคอมโพเนนต์อัปสตรีมและดาวน์สตรีม
    • การผสานรวมแบบเกือบเรียลไทม์ที่เชื่อมต่อแบบหลวม

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

*หมายเหตุ: โซลูชันอ้างอิงนี้มีแผนที่จะเปิดตัวการติดตั้งใช้งานทางเลือกที่ช่วยให้เป็นไปตามข้อกำหนดต่างๆ ได้

การทำให้ใช้งานได้

เราเลือก Terraform เป็นเครื่องมืออัตโนมัติเพื่อให้กระบวนการติดตั้งใช้งานโซลูชันอ้างอิงทำซ้ำได้ ปรับแต่งได้ ควบคุมซอร์สโค้ดได้ และปลอดภัย Terraform เป็นเครื่องมือ IaC (Infrastructure as Code) ที่มีการนำไปใช้อย่างแพร่หลายและรองรับ Google Cloud อย่างเต็มรูปแบบ

โมดูล Terraform

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

โมดูลที่รวมอยู่ในโซลูชันอ้างอิงมีดังนี้

  • การกำหนดค่าการบันทึก Fleet Engine: กำหนดค่าที่เกี่ยวข้องกับ Cloud Logging โดยอัตโนมัติเพื่อใช้กับ Fleet Engine ในโซลูชันอ้างอิง ระบบจะใช้เพื่อกำหนดเส้นทางบันทึกที่เกี่ยวข้องกับ Fleet Engine ไปยังหัวข้อ Pub/Sub ที่ระบุ
  • การทำให้ใช้งานได้ของ Cloud Function ของ Fleet Events: มีการทำให้ใช้งานได้ของโค้ดฟังก์ชันตัวอย่าง และยังจัดการการตั้งค่ากลุ่มสิทธิ์อัตโนมัติที่จำเป็นสำหรับการผสานรวมข้ามโปรเจ็กต์อย่างปลอดภัยด้วย
  • การติดตั้งใช้งานโซลูชันอ้างอิงทั้งหมด: เรียกใช้โมดูล 2 รายการก่อนหน้าและรวมโซลูชันทั้งหมดไว้ด้วยกัน

ความปลอดภัย

เราใช้ IAM เพื่อใช้หลักการสิทธิ์ขั้นต่ำที่สุดร่วมกับแนวทางปฏิบัติแนะนำด้านความปลอดภัยของ Google Cloud เช่น การแอบอ้างเป็นบัญชีบริการ โปรดอ่านบทความต่อไปนี้เพื่อทำความเข้าใจสิ่งที่ Google Cloud นำเสนอเพื่อช่วยให้คุณควบคุมความปลอดภัยได้มากขึ้น

การดำเนินการถัดไป

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

ภาคผนวก

รวบรวมข้อกำหนด

เราขอแนะนำให้คุณรวบรวมข้อกำหนดตั้งแต่เนิ่นๆ ในกระบวนการ

ก่อนอื่น ให้ระบุรายละเอียดว่าเหตุใดคุณจึงสนใจหรือจำเป็นต้องใช้เหตุการณ์ที่ใกล้เคียงเรียลไทม์ ต่อไปนี้คือคำถามบางส่วนที่จะช่วยให้คุณเข้าใจความต้องการของตนเองได้ชัดเจนขึ้น

  • สตรีมเหตุการณ์ต้องมีข้อมูลใดบ้างจึงจะเป็นประโยชน์
    • ผลลัพธ์ที่ได้มาจากข้อมูลที่บันทึกหรือสร้างขึ้นในบริการของ Google เพียงอย่างเดียวได้ไหม หรือจำเป็นต้องเพิ่มประสิทธิภาพข้อมูลด้วยระบบภายนอกที่ผสานรวมหรือไม่ หากมี ระบบเหล่านั้นคืออะไรและมีอินเทอร์เฟซการผสานรวมใดบ้าง
    • เมตริกที่คุณต้องการวัดในฐานะธุรกิจคืออะไร และมีการกำหนดอย่างไร
    • หากต้องการคํานวณเมตริกในเหตุการณ์ต่างๆ คุณจะต้องใช้การรวมประเภทใด พยายามวางขั้นตอนอย่างสมเหตุสมผล (เช่น เปรียบเทียบ ETA/ATA กับ SLO ในชุดย่อยของกลุ่มยานพาหนะในช่วงเวลาที่มีการใช้พลังงานสูงสุดเพื่อคำนวณประสิทธิภาพภายใต้ข้อจำกัดด้านทรัพยากร)
  • ทำไมคุณจึงสนใจโมเดลที่อิงตามเหตุการณ์มากกว่าแบบกลุ่ม เพื่อลดเวลาในการตอบสนอง (เวลาในการดำเนินการ) หรือเพื่อการผสานรวมแบบเชื่อมต่อแบบหลวม (ความคล่องตัว)
    • หากต้องการเวลาในการตอบสนองต่ำ ให้กำหนดเป็น "low" นาที? วินาที น้อยกว่า 1 วินาที และเวลาในการตอบสนอง เป็นอย่างไร
  • คุณได้ลงทุนใน Technology Stack และทักษะที่เกี่ยวข้องในฐานะทีมแล้วหรือยัง หากมี ระบบดังกล่าวคืออะไรและมีจุดผสานรวมใดบ้าง
    • มีข้อกำหนดใดบ้างที่ระบบปัจจุบันของคุณไม่สามารถตอบสนองได้หรืออาจประสบปัญหาเมื่อประมวลผลเหตุการณ์ที่มาจากกลุ่มยานพาหนะของคุณ

หลักการออกแบบ

การมีกระบวนการคิดที่ควรปฏิบัติตามนั้นมีประโยชน์เสมอ ซึ่งจะช่วยให้ตัดสินใจด้านการออกแบบได้อย่างสอดคล้องกัน โดยเฉพาะอย่างยิ่งเมื่อคุณมีตัวเลือกมากมายให้เลือก

  • ใช้ตัวเลือกที่ง่ายกว่าโดยค่าเริ่มต้น
  • ค่าเริ่มต้นคือระยะเวลาที่สั้นลงในการสร้างคุณค่า โค้ดน้อยลง เส้นโค้งการเรียนรู้ต่ำลง
  • สำหรับเวลาในการตอบสนองและประสิทธิภาพ ให้ตั้งเป้าหมายให้เป็นไปตามเกณฑ์ที่คุณตั้งไว้ ไม่ใช่การเพิ่มประสิทธิภาพสูงสุด นอกจากนี้ ให้หลีกเลี่ยงการเพิ่มประสิทธิภาพมากเกินไปเนื่องจากมักจะทำให้เกิดความซับซ้อนมากขึ้น
  • ค่าใช้จ่ายก็เช่นกัน รักษาต้นทุนให้อยู่ในระดับที่สมเหตุสมผล คุณอาจยังไม่อยู่ในสถานะที่สามารถใช้บริการที่มีมูลค่าสูงแต่มีราคาค่อนข้างแพงได้
  • ในระยะทดลอง การลดทรัพยากรอาจมีความสำคัญพอๆ กับการเพิ่มทรัพยากร พิจารณาแพลตฟอร์มที่ให้ความยืดหยุ่นในการเพิ่มทรัพยากรโดยมีขีดจำกัด และลดทรัพยากร (โดยหลักการแล้วคือลดเป็นศูนย์) เพื่อให้คุณไม่ต้องเสียค่าใช้จ่ายเมื่อไม่ได้ดำเนินการใดๆ คุณสามารถพิจารณาประสิทธิภาพสูงด้วยโครงสร้างพื้นฐานที่เปิดตลอดเวลาได้ในภายหลังเมื่อคุณมั่นใจในความต้องการของโครงสร้างพื้นฐานดังกล่าว
  • สังเกตและวัดผลเพื่อให้คุณระบุได้ในภายหลังว่าต้องดำเนินการต่อในส่วนใด
  • เชื่อมต่อบริการแบบหลวมๆ ซึ่งจะช่วยให้เปลี่ยนชิ้นส่วนทีละชิ้นได้ง่ายขึ้นในภายหลัง
  • สุดท้ายแต่ไม่ท้ายสุด ความปลอดภัยต้องรัดกุม ในฐานะบริการที่ทำงานในสภาพแวดล้อมระบบคลาวด์สาธารณะ ระบบจะต้องไม่มีช่องโหว่ที่ไม่ปลอดภัย

แนวคิดเกี่ยวกับสตรีมมิง

หากคุณค่อนข้างใหม่สำหรับการประมวลผลตามเหตุการณ์หรือการสตรีม มีแนวคิดสำคัญที่ควรทราบ ซึ่งบางแนวคิดอาจแตกต่างจากการประมวลผลแบบกลุ่มอย่างมาก

  • ขนาด : ในทางตรงกันข้ามกับการประมวลผลแบบกลุ่ม ซึ่งโดยปกติแล้วคุณจะทราบปริมาณข้อมูลที่จะประมวลผล แต่ในการสตรีมคุณจะไม่ทราบ การจราจรที่ติดขัดในเมืองอาจทำให้เกิดเหตุการณ์จำนวนมากจากพื้นที่หนึ่งๆ อย่างกะทันหัน และคุณยังคงต้องประมวลผลเหตุการณ์ดังกล่าวได้
  • การแบ่งกรอบเวลา : แทนที่จะประมวลผลเหตุการณ์ทีละรายการ คุณมักจะต้องการจัดกลุ่มเหตุการณ์ตามไทม์ไลน์เป็น "กรอบเวลา" ที่เล็กลงเพื่อใช้เป็นหน่วยในการคำนวณ มีกลยุทธ์การกำหนดกรอบเวลาที่หลากหลาย เช่น "กรอบเวลาคงที่ (เช่น ทุกวันตามปฏิทิน)" "กรอบเวลาแบบเลื่อน (5 นาทีที่ผ่านมา)" "กรอบเวลาเซสชัน (ระหว่างการเดินทางนี้)" ซึ่งคุณควรเลือกจากกลยุทธ์เหล่านี้ ยิ่งกรอบเวลานานเท่าใด ความล่าช้าในการสร้างผลลัพธ์ก็จะยิ่งนานขึ้นเท่านั้น เลือกรุ่นและการกำหนดค่าที่เหมาะสมซึ่งตรงกับความต้องการของคุณ
  • การทริกเกอร์ : มีบางกรณีที่คุณไม่มีทางเลือกอื่นนอกจากต้องใช้กรอบเวลาที่ค่อนข้างยาวนาน อย่างไรก็ตาม คุณไม่ควรปล่อยให้เวลาผ่านไปจนถึงช่วงท้ายของกรอบเวลาเพื่อสร้างเหตุการณ์ แต่ควรปล่อยผลลัพธ์ระดับกลางออกมาเป็นระยะๆ แนวคิดนี้สามารถนำไปใช้กับ Use Case ที่มีคุณค่าในการแสดงผลลัพธ์ที่รวดเร็วก่อน แล้วค่อยแก้ไขในภายหลัง ลองนึกภาพการแสดงสถานะกลางที่ 25%, 50%, 75% ของการนำส่งที่เสร็จสมบูรณ์
  • การจัดลำดับ : เหตุการณ์ไม่จำเป็นต้องเข้าถึงระบบตามลำดับที่สร้างขึ้น โดยเฉพาะอย่างยิ่งสำหรับกรณีการใช้งานที่เกี่ยวข้องกับการสื่อสารผ่านเครือข่ายมือถือซึ่งเพิ่มความล่าช้าและเส้นทางการกำหนดเส้นทางที่ซับซ้อน คุณต้องตระหนักถึงความแตกต่างระหว่าง "เวลาของเหตุการณ์" (เมื่อเหตุการณ์เกิดขึ้นจริง) และ "เวลาประมวลผล" (เมื่อเหตุการณ์เข้าถึงระบบ) และจัดการเหตุการณ์ตามนั้น โดยทั่วไป คุณควรประมวลผลเหตุการณ์ตาม "เวลาที่เกิดเหตุการณ์"
  • การส่งข้อความ - อย่างน้อย 1 ครั้งเทียบกับ 1 ครั้งพอดี: แพลตฟอร์มเหตุการณ์ที่แตกต่างกันจะมีการรองรับที่แตกต่างกันสำหรับสิ่งเหล่านี้ คุณต้องพิจารณากลยุทธ์การลองใหม่หรือการกรองข้อมูลที่ซ้ำกันออก ทั้งนี้ขึ้นอยู่กับกรณีการใช้งานของคุณ
  • ความสมบูรณ์ : เช่นเดียวกับการเปลี่ยนแปลงลำดับ มีโอกาสที่ข้อความจะสูญหาย ซึ่งอาจเกิดจากการปิดแอปพลิเคชันและอุปกรณ์เนื่องจากอายุการใช้งานแบตเตอรี่ของอุปกรณ์ ความเสียหายต่อโทรศัพท์โดยไม่ตั้งใจ การเชื่อมต่อขาดหายขณะอยู่ในอุโมงค์ หรือข้อความที่ได้รับแต่เฉพาะนอกกรอบเวลาที่ยอมรับได้ ความไม่สมบูรณ์จะส่งผลต่อผลลัพธ์ของคุณอย่างไร

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

ผู้ร่วมให้ข้อมูล

Google เป็นผู้ดูแลเอกสารนี้ ผู้เขียนต้นฉบับมีรายชื่อดังต่อไปนี้

ผู้เขียนหลัก:

  • Mary Pishny | ผู้จัดการผลิตภัณฑ์ Google Maps Platform
  • Ethel Bao| วิศวกรซอฟต์แวร์, Google Maps Platform
  • Mohanad Almiski | วิศวกรซอฟต์แวร์, Google Maps Platform
  • Naoya Moritani | วิศวกรโซลูชัน Google Maps Platform