สัญญาณแบบเกือบเรียลไทม์จากยานพาหนะที่ปฏิบัติงานภาคพื้นดินมีประโยชน์ต่อธุรกิจในหลายๆ ด้าน เช่น ธุรกิจสามารถใช้สัญญาณเหล่านี้เพื่อดำเนินการต่อไปนี้
- ตรวจสอบประสิทธิภาพของยานพาหนะและระบุปัญหาที่อาจเกิดขึ้นตั้งแต่เนิ่นๆ
- ปรับปรุงการบริการลูกค้าด้วยการระบุเวลาถึงโดยประมาณ (ETA) และข้อมูลการติดตามที่ถูกต้อง
- ลดต้นทุนด้วยการระบุและแก้ไขจุดที่ไม่มีประสิทธิภาพ
- ปรับปรุงความปลอดภัยด้วยการตรวจสอบพฤติกรรมของผู้ขับขี่และระบุอันตรายที่อาจเกิดขึ้น
- เพิ่มประสิทธิภาพด้วยการเพิ่มประสิทธิภาพเส้นทางและกำหนดเวลาของผู้ขับขี่
- ปฏิบัติตามกฎระเบียบด้วยการติดตามตำแหน่งยานพาหนะและชั่วโมงการทำงาน
เอกสารนี้แสดงให้เห็นว่านักพัฒนาแอปจะเปลี่ยนสัญญาณจาก Google Maps Platform's "บริการด้านการเดินทาง" ("Last Mile Fleet Solution" (LMFS) หรือ "On-demand Rides and Deliveries Solution" (ODRD)) ให้เป็นเหตุการณ์ที่กำหนดเองที่ดำเนินการได้จริงได้อย่างไร นอกจากนี้ยังครอบคลุมแนวคิดหลักและการตัดสินใจด้านการออกแบบของ โซลูชันอ้างอิงเหตุการณ์ยานพาหนะ ที่พร้อมใช้งานใน GitHub ด้วย
เอกสารนี้เกี่ยวข้องกับบุคคลต่อไปนี้
- สถาปนิกที่คุ้นเคยกับ "บริการด้านการเดินทาง" ของ Google Maps Platform และ "Fleet Engine" ซึ่งเป็นคอมโพเนนต์หลักอย่างหนึ่ง สำหรับผู้ที่เพิ่งเริ่มใช้ "บริการด้านการเดินทาง" เราขอแนะนำให้ทำความคุ้นเคยกับ Last Mile Fleet Solution และ/หรือ On-demand Rides and Deliveries Solution, ทั้งนี้ขึ้นอยู่กับความต้องการของคุณ
- สถาปนิกที่คุ้นเคยกับ Google Cloud สำหรับผู้ที่เพิ่งเริ่มใช้ Google Cloud, เราขอแนะนำให้อ่านบทความ Building streaming data pipelines on Google Cloud ก่อน
- หากคุณกำหนดเป้าหมายเป็นสภาพแวดล้อมหรือซอฟต์แวร์สแต็กอื่นๆ ให้มุ่งเน้นที่การทำความเข้าใจจุดผสานรวมและข้อควรพิจารณาที่สำคัญของ Fleet Engine ซึ่งควรยังคงใช้ได้
- ผู้ที่สนใจทั่วไปในการสำรวจวิธีสร้างและใช้ประโยชน์จากเหตุการณ์จากยานพาหนะ
เมื่ออ่านเอกสารนี้จบแล้ว คุณควรมีความเข้าใจพื้นฐานเกี่ยวกับ องค์ประกอบหลักและข้อควรพิจารณาของระบบสตรีมมิง รวมถึงองค์ประกอบที่ใช้สร้างสรรค์จาก Google Maps Platform และ Google Cloud ซึ่งประกอบกันเป็น โซลูชันอ้างอิง เหตุการณ์ยานพาหนะ
ภาพรวมของโซลูชันอ้างอิงเหตุการณ์ยานพาหนะ
โซลูชันอ้างอิงเหตุการณ์ยานพาหนะเป็นโซลูชันโอเพนซอร์สที่ช่วยให้ลูกค้าและพาร์ทเนอร์ด้านการเดินทางสร้างเหตุการณ์สำคัญบนคอมโพเนนต์ Fleet Engine และ Google Cloud ได้ ปัจจุบันโซลูชันอ้างอิงรองรับลูกค้าที่ใช้ Last Mile Fleet Solution โดยจะรองรับ On-demand Rides and Deliveries ในภายหลัง
โซลูชันจะสร้างเหตุการณ์โดยอัตโนมัติตามการเปลี่ยนแปลงข้อมูลที่เฉพาะเจาะจงซึ่งเชื่อมโยงกับงานหรือการเดินทาง คุณสามารถใช้เหตุการณ์เหล่านี้เพื่อส่งการแจ้งเตือน เช่น การแจ้งเตือนต่อไปนี้ไปยังผู้มีส่วนได้ส่วนเสีย หรือทริกเกอร์การดำเนินการอื่นๆ สำหรับยานพาหนะ
- การเปลี่ยนแปลงเวลาถึงโดยประมาณ (ETA) สำหรับการมาถึงงาน
- การเปลี่ยนแปลงเวลาถึงโดยประมาณ (ETA) สัมพัทธ์สำหรับการมาถึงงาน
- เวลาที่เหลือจนกว่าจะถึงงาน
- ระยะทางที่เหลือจนกว่าจะถึงงาน
- การเปลี่ยนแปลงสถานะ TaskOutcome
คุณสามารถปรับแต่งคอมโพเนนต์แต่ละรายการของโซลูชันอ้างอิงให้เหมาะกับความต้องการทางธุรกิจได้
องค์ประกอบที่ใช้สร้างสรรค์เชิงตรรกะ
แผนภาพ : แผนภาพต่อไปนี้แสดงองค์ประกอบที่ใช้สร้างสรรค์ระดับสูงซึ่งประกอบกันเป็นโซลูชันอ้างอิงเหตุการณ์ยานพาหนะ
โซลูชันอ้างอิงมีคอมโพเนนต์ต่อไปนี้
- แหล่งที่มาของเหตุการณ์: แหล่งที่มาของสตรีมเหตุการณ์เดิม ทั้ง "Last Mile Fleet Solution" หรือ "On-demand Rides and Deliveries Solution" มีการผสานรวมกับ Cloud Logging ซึ่งช่วยเปลี่ยนบันทึกการเรียกใช้ RPC ของ Fleet Engine ให้เป็นสตรีมเหตุการณ์ที่นักพัฒนาแอปใช้ได้ นี่คือแหล่งที่มาหลักในการใช้งาน
- การประมวลผล: ระบบจะแปลงบันทึกการเรียกใช้ RPC ดิบให้เป็นเหตุการณ์การเปลี่ยนแปลงสถานะ
ภายในบล็อกนี้ ซึ่งจะคำนวณเหตุการณ์บันทึกสตรีม คอมโพเนนต์นี้ต้องมีที่เก็บสถานะเพื่อให้สามารถเปรียบเทียบเหตุการณ์ใหม่ที่เข้ามากับเหตุการณ์ก่อนหน้าเพื่อตรวจหาการเปลี่ยนแปลง เหตุการณ์อาจไม่ได้รวมข้อมูลทั้งหมดที่คุณสนใจเสมอไป ในกรณีดังกล่าว บล็อกนี้อาจทำการเรียกดูข้อมูลจากแบ็กเอนด์ตามที่จำเป็น
- ที่เก็บสถานะ: เฟรมเวิร์กการประมวลผลบางรายการจะจัดเก็บข้อมูลกลาง แบบถาวรด้วยตัวเอง แต่หากไม่มี คุณจะต้องจัดเก็บสถานะด้วยตัวเอง เนื่องจากสถานะเหล่านี้ควรเป็นสถานะที่ไม่ซ้ำกันสำหรับยานพาหนะและประเภทเหตุการณ์ ดังนั้นบริการจัดเก็บข้อมูลแบบคีย์-ค่าจึงเหมาะกับกรณีนี้
- ซิงก์ (เหตุการณ์ที่กำหนดเอง): ควรทำให้การเปลี่ยนแปลงสถานะที่ตรวจพบพร้อมใช้งานสำหรับ แอปพลิเคชันหรือบริการใดก็ตามที่ได้รับประโยชน์จากข้อมูลดังกล่าว ดังนั้น การเผยแพร่เหตุการณ์ที่กำหนดเองนี้ไปยังระบบการส่งเหตุการณ์เพื่อการใช้งานปลายทางจึงเป็นตัวเลือกที่เหมาะสม
- บริการปลายทาง: โค้ดที่ใช้เหตุการณ์ที่สร้างขึ้นและดำเนินการ ที่ไม่ซ้ำกันสำหรับกรณีการใช้งานของคุณ
การเลือกบริการ
เมื่อพูดถึงการใช้โซลูชันอ้างอิงสำหรับ "Last Mile Fleet Solution" หรือ "On-demand Rides and Deliveries Solution" (จะเปิดตัวในช่วงปลายไตรมาสที่ 3 ปี 2023) การเลือกเทคโนโลยีสำหรับ "แหล่งที่มา" และ "ซิงก์" นั้น ตรงไปตรงมา ในทางกลับกัน "การประมวลผล" มีตัวเลือกมากมาย โซลูชันอ้างอิงได้เลือกบริการต่อไปนี้ของ Google
แผนภาพ : แผนภาพต่อไปนี้แสดงบริการของ Google Cloud ที่ใช้ในการใช้โซลูชันอ้างอิง
เลย์เอาต์โปรเจ็กต์ Cloud
เราขอแนะนำให้คุณใช้การติดตั้งใช้งานแบบหลายโปรเจ็กต์เป็นค่าเริ่มต้น เพื่อให้การใช้งาน Google Maps Platform และ Google Cloud แยกกันได้อย่างชัดเจนและเชื่อมโยงกับการจัดการการเรียกเก็บเงินที่คุณเลือก
แหล่งที่มาของเหตุการณ์
"Last Mile Fleet Solution" และ "On-demand Rides and Deliveries Solution" จะเขียนเพย์โหลดคำขอและการตอบกลับของ API ไปยัง Cloud Logging Cloud Logging จะส่งบันทึกไปยังบริการที่คุณเลือกอย่างน้อย 1 รายการ การกำหนดเส้นทางไปยัง Cloud Pub/Sub เป็นตัวเลือกที่สมบูรณ์แบบในที่นี้ และช่วยให้คุณแปลงบันทึกให้เป็นสตรีมเหตุการณ์ได้โดยไม่ต้องเขียนโค้ด
- Logging | Fleet Performance (สำหรับผู้ใช้ LMFS)
- Logging | Trip and Order Progress (สำหรับผู้ใช้ ODRD)
- ดูบันทึกที่กำหนดเส้นทางไปยัง Pub/Sub : Logging → Pub/Sub integration overview
ซิงก์
ใน 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 ได้อย่างเต็มที่
- Google Cloud Platform Provider: เอกสารประกอบของทรัพยากรที่ "Google Cloud Platform Provider" รองรับ
- แนวทางปฏิบัติแนะนำสำหรับการใช้ Terraform: คำแนะนำที่ครอบคลุมเกี่ยวกับวิธีนำไปใช้ใน Google Cloud ได้อย่างมีประสิทธิภาพสูงสุด
- Terraform Registry: โมดูลเพิ่มเติมที่ Google และชุมชนรองรับ
โมดูล Terraform
เราได้ติดตั้งใช้งานบล็อกอัตโนมัติที่นำกลับมาใช้ใหม่ได้เป็นโมดูล Terraform ซึ่งสามารถใช้แยกกันได้ แทนที่จะสร้างโมดูลการติดตั้งใช้งานโซลูชันอ้างอิงขนาดใหญ่แบบโมโนลิธ โมดูลมีตัวแปรที่กำหนดค่าได้หลากหลาย ซึ่งส่วนใหญ่มีค่าเริ่มต้นเพื่อให้คุณเริ่มต้นใช้งานได้อย่างรวดเร็ว แต่ก็มีความยืดหยุ่นในการปรับแต่งตามความต้องการและความชอบของคุณ
โมดูลที่รวมอยู่ในโซลูชันอ้างอิงมีดังนี้
- การกำหนดค่าการบันทึก Fleet Engine: ทำให้การกำหนดค่าที่เกี่ยวข้องกับ Cloud Logging เป็นแบบอัตโนมัติเพื่อใช้กับ Fleet Engine ในโซลูชันอ้างอิง โมดูลนี้ใช้เพื่อกำหนดเส้นทางบันทึกที่เกี่ยวข้องกับ Fleet Engine ไปยังหัวข้อ Pub/Sub ที่ระบุ
- การติดตั้งใช้งาน Cloud Function ของ Fleet Events: มีการติดตั้งใช้งานโค้ดฟังก์ชันตัวอย่าง และจัดการการตั้งค่าสิทธิ์แบบอัตโนมัติ ที่จำเป็นสำหรับการผสานรวมข้ามโปรเจ็กต์ที่ปลอดภัย
- การติดตั้งใช้งานโซลูชันอ้างอิงทั้งหมด: เรียกโมดูล 2 รายการก่อนหน้าและ รวมโซลูชันทั้งหมด
ความปลอดภัย
เราใช้ IAM เพื่อใช้หลักการให้สิทธิ์ขั้นต่ำที่สุด รวมถึงแนวทางปฏิบัติแนะนำด้านความปลอดภัยของ Google Cloud เช่น การจำลองตัวตนของบัญชีบริการ โปรดดูบทความต่อไปนี้เพื่อทำความเข้าใจข้อเสนอของ Google Cloud ที่จะช่วยให้คุณควบคุมความปลอดภัยได้มากขึ้น
การดำเนินการถัดไป
ตอนนี้คุณก็พร้อมเข้าถึงและสำรวจ โซลูชันอ้างอิงเหตุการณ์ยานพาหนะ เพิ่มเติมแล้ว ไปที่ GitHub เพื่อเริ่มต้นใช้งาน
ภาคผนวก
รวบรวมข้อกำหนด
เราขอแนะนำให้คุณรวบรวมข้อกำหนดตั้งแต่เนิ่นๆ ในกระบวนการ
ขั้นแรก ให้ระบุรายละเอียดว่าเหตุใดคุณจึงสนใจหรือจำเป็นต้องใช้เหตุการณ์แบบเกือบเรียลไทม์ คำถามต่อไปนี้จะช่วยให้คุณระบุความต้องการได้อย่างชัดเจน
- ข้อมูลใดที่จำเป็นเพื่อให้สตรีมเหตุการณ์มีประโยชน์
- ผลลัพธ์ได้มาจากข้อมูลที่รวบรวมหรือสร้างขึ้นในบริการของ Google เพียงอย่างเดียวหรือไม่ หรือต้องมีการเพิ่มคุณค่าข้อมูลด้วยระบบภายนอกที่ผสานรวม หากเป็นเช่นนั้น ระบบเหล่านั้นคือระบบใดและมีอินเทอร์เฟซการผสานรวมใดบ้าง
- เมตริกใดที่คุณต้องการวัดในฐานะธุรกิจ เมตริกเหล่านั้นกำหนดไว้อย่างไร
- หากคุณต้องคำนวณเมตริกในเหตุการณ์ต่างๆ คุณจะต้องใช้การรวบรวมประเภทใด ลองวางแผนขั้นตอนเชิงตรรกะ (เช่น เปรียบเทียบ ETA/ATA กับ SLO ในยานพาหนะบางส่วนในช่วงเวลาที่มีการใช้พลังงานสูงสุดเพื่อคำนวณประสิทธิภาพภายใต้ข้อจำกัดด้านทรัพยากร)
- เหตุใดคุณจึงสนใจโมเดลที่อิงตามเหตุการณ์แทนที่จะเป็นแบบกลุ่ม เป็นเพราะต้องการเวลาในการตอบสนอง (เวลาในการดำเนินการ) ที่ต่ำลงหรือการผสานรวมที่เชื่อมโยงกันอย่างหลวมๆ (ความคล่องตัว)
- หากเป็นเพราะต้องการเวลาในการตอบสนองต่ำ ให้กำหนดคำว่า "ต่ำ" เป็นนาที เป็นวินาที ต่ำกว่าวินาที และเวลาในการตอบสนองเท่าใด
- คุณได้ลงทุนใน Technology Stack และทักษะที่เกี่ยวข้องในฐานะทีมแล้วหรือยัง หากลงทุนแล้ว เทคโนโลยีสแต็กนั้นคืออะไรและมีจุดผสานรวมใดบ้าง
- ระบบปัจจุบันของคุณมีข้อกำหนดใดบ้างที่ไม่สามารถตอบสนองได้หรืออาจมีปัญหาในการประมวลผลเหตุการณ์ที่มาจากยานพาหนะ
หลักการออกแบบ
การมีกระบวนการคิดที่ต้องทำตามนั้นมีประโยชน์เสมอ ซึ่งจะช่วยให้คุณตัดสินใจด้านการออกแบบได้อย่างสอดคล้องกัน โดยเฉพาะอย่างยิ่งเมื่อมีตัวเลือกมากมายให้เลือก
- เลือกตัวเลือกที่ง่ายกว่าเป็นค่าเริ่มต้น
- เลือกตัวเลือกที่ใช้เวลาในการสร้างคุณค่าสั้นกว่าเป็นค่าเริ่มต้น เขียนโค้ดน้อยลงและมีเส้นโค้งการเรียนรู้ที่ต่ำกว่า
- สำหรับเวลาในการตอบสนองและประสิทธิภาพ ให้ตั้งเป้าหมายที่จะทำให้ได้ตามเกณฑ์ที่คุณกำหนดไว้ ไม่ใช่การเพิ่มประสิทธิภาพสูงสุด นอกจากนี้ ให้หลีกเลี่ยงการเพิ่มประสิทธิภาพมากเกินไป เนื่องจากมักจะทำให้เกิดความซับซ้อน
- ค่าใช้จ่ายก็เช่นกัน กำหนดค่าใช้จ่ายให้สมเหตุสมผล คุณอาจยังไม่พร้อมที่จะใช้บริการที่มีมูลค่าสูงแต่มีค่าใช้จ่ายค่อนข้างสูงกว่า
- ในระยะทดลอง การลดขนาดอาจมีความสำคัญไม่แพ้การเพิ่มขนาด ลองพิจารณาแพลตฟอร์มที่ยืดหยุ่นในการเพิ่มทรัพยากรโดยมีขีดจำกัด และลดทรัพยากรได้ (โดยควรลดขนาดเป็น 0) เพื่อให้คุณไม่ต้องเสียค่าใช้จ่ายเมื่อไม่ได้ใช้งาน คุณสามารถพิจารณาโครงสร้างพื้นฐานที่ทำงานตลอดเวลาและมีประสิทธิภาพสูงได้ในภายหลัง เมื่อมั่นใจแล้วว่าจำเป็นต้องใช้
- สังเกตและวัดผลเพื่อให้คุณระบุจุดที่ต้องปรับปรุงเพิ่มเติมได้ในภายหลัง
- เชื่อมโยงบริการต่างๆ เข้าด้วยกันอย่างหลวมๆ ซึ่งจะช่วยให้คุณเปลี่ยนบริการทีละรายการได้ง่ายขึ้นในภายหลัง
- สิ่งสุดท้ายแต่ไม่ท้ายสุดคือ คุณต้องให้ความสำคัญกับความปลอดภัย เนื่องจากเป็นบริการที่ทำงานในสภาพแวดล้อมระบบคลาวด์สาธารณะ ระบบจึงต้องไม่มีช่องโหว่ที่ไม่ได้รักษาความปลอดภัย
แนวคิดเกี่ยวกับสตรีมมิง
หากคุณเพิ่งเริ่มใช้เหตุการณ์หรือสตรีมมิง มีแนวคิดสำคัญที่คุณควรทราบ ซึ่งบางแนวคิดอาจแตกต่างจากการประมวลผลแบบกลุ่มอย่างมาก
- ขนาด : การประมวลผลแบบกลุ่มมักจะทำให้คุณทราบปริมาณข้อมูลที่จะประมวลผล แต่การประมวลผลแบบสตรีมมิงไม่เป็นเช่นนั้น การจราจรติดขัดในเมืองอาจทำให้เกิดเหตุการณ์จำนวนมากจากพื้นที่หนึ่งๆ ขึ้นมาอย่างกะทันหัน และคุณยังคงต้องประมวลผลเหตุการณ์เหล่านั้นได้
- การแบ่งหน้าต่าง : แทนที่จะประมวลผลเหตุการณ์ทีละรายการ คุณมักจะต้องการจัดกลุ่มเหตุการณ์ตามไทม์ไลน์เป็น "หน้าต่าง" ที่เล็กลงเพื่อใช้เป็นหน่วยสำหรับการคำนวณ คุณควรเลือกกลยุทธ์การแบ่งหน้าต่างต่างๆ เช่น "หน้าต่างคงที่ (เช่น ทุกวันตามปฏิทิน)", "หน้าต่างแบบเลื่อน (5 นาทีล่าสุด)", "หน้าต่างเซสชัน (ระหว่างการเดินทางนี้)" หน้าต่างที่ยาวขึ้นจะทำให้เกิดความล่าช้าในการแสดงผลลัพธ์นานขึ้น เลือกโมเดลและการกำหนดค่าที่เหมาะสมกับข้อกำหนดของคุณ
- การทริกเกอร์ : ในบางกรณี คุณไม่มีทางเลือกอื่นนอกจากต้องใช้หน้าต่างที่ค่อนข้างยาว อย่างไรก็ตาม คุณไม่ต้องการรอจนกว่าจะสิ้นสุดหน้าต่างเพื่อสร้างเหตุการณ์ แต่ต้องการแสดงผลลัพธ์ระดับกลางแทน คุณสามารถใช้แนวคิดนี้กับกรณีการใช้งานที่การแสดงผลลัพธ์อย่างรวดเร็วเป็นสิ่งสำคัญก่อน แล้วจึงแก้ไขผลลัพธ์ในภายหลัง ลองนึกภาพการแสดงสถานะระดับกลางเมื่อการจัดส่งเสร็จสมบูรณ์ 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