สัญญาณแบบเกือบเรียลไทม์จากยานพาหนะที่ปฏิบัติงานภาคพื้นดินมีประโยชน์ต่อธุรกิจในหลายๆ ด้าน เช่น ธุรกิจสามารถใช้สัญญาณเหล่านี้เพื่อดำเนินการต่อไปนี้
- ตรวจสอบประสิทธิภาพของยานพาหนะและระบุปัญหาที่อาจเกิดขึ้นตั้งแต่เนิ่นๆ
- ปรับปรุงการบริการลูกค้าด้วยการระบุเวลาที่คาดว่าจะถึง (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 ซึ่งควรยังคงใช้ได้
- ผู้ที่สนใจทั่วไปในการสำรวจวิธีสร้างและใช้ประโยชน์จากเหตุการณ์จากยานพาหนะ
ภาพรวมโซลูชันอ้างอิงเหตุการณ์ยานพาหนะ
โซลูชันอ้างอิงเหตุการณ์ยานพาหนะเป็นโซลูชันโอเพนซอร์สที่ช่วยให้ลูกค้าและพาร์ทเนอร์ด้านการเดินทางสร้างเหตุการณ์สำคัญบนคอมโพเนนต์ 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 ดิบให้เป็นเหตุการณ์การเปลี่ยนแปลงสถานะ
ภายในบล็อกนี้ ซึ่งจะคำนวณเหตุการณ์บันทึกแบบสตรีม คอมโพเนนต์นี้ต้องมีที่เก็บสถานะเพื่อให้สามารถเปรียบเทียบเหตุการณ์ใหม่ที่เข้ามากับเหตุการณ์ก่อนหน้าเพื่อตรวจหาการเปลี่ยนแปลง เหตุการณ์อาจไม่ได้รวมข้อมูลทั้งหมดที่น่าสนใจเสมอไป ในกรณีดังกล่าว บล็อกนี้อาจทำการเรียกดูข้อมูลจากแบ็กเอนด์ตามความจำเป็น
- ที่เก็บสถานะ: เฟรมเวิร์กการประมวลผลบางรายการจะให้ข้อมูลระดับกลาง ที่คงอยู่ด้วยตัวเอง แต่หากไม่เป็นเช่นนั้น คุณจะต้องจัดเก็บสถานะด้วยตัวเอง เนื่องจากสถานะเหล่านี้ควรเป็นสถานะที่ไม่ซ้ำกันสำหรับยานพาหนะและประเภทเหตุการณ์ ดังนั้นบริการการคงอยู่ของข้อมูลประเภท K-V จึงเหมาะสม
- ซิงก์ (เหตุการณ์ที่กำหนดเอง): ควรทำให้การเปลี่ยนแปลงสถานะที่ตรวจพบพร้อมใช้งานสำหรับ แอปพลิเคชันหรือบริการใดก็ตามที่ได้รับประโยชน์จากการเปลี่ยนแปลงดังกล่าว ดังนั้น การเผยแพร่เหตุการณ์ที่กำหนดเองนี้ไปยังระบบการนำส่งเหตุการณ์เพื่อการใช้งานปลายทางจึงเป็นตัวเลือกที่เหมาะสม
- บริการปลายทาง: โค้ดที่ใช้เหตุการณ์ที่สร้างขึ้นและดำเนินการที่ไม่ซ้ำกันสำหรับกรณีการใช้งานของคุณ
การเลือกบริการ
เมื่อพูดถึงการใช้โซลูชันอ้างอิงสำหรับ "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 ครั้งเท่านั้น: แพลตฟอร์มเหตุการณ์ต่างๆ มีการรองรับที่แตกต่างกันสำหรับตัวเลือกเหล่านี้ คุณต้องพิจารณากลยุทธ์การลองใหม่หรือการกรองข้อมูลที่ซ้ำกันออก ทั้งนี้ขึ้นอยู่กับ Use Case ของคุณ
- ความสมบูรณ์ : เช่นเดียวกับการเปลี่ยนแปลงการจัดลำดับ ข้อความอาจสูญหายได้ ซึ่งอาจเกิดจากการปิดแอปพลิเคชันและอุปกรณ์เนื่องจากแบตเตอรี่ของอุปกรณ์หมด ความเสียหายโดยไม่ตั้งใจต่อโทรศัพท์ การเชื่อมต่อขาดหายขณะอยู่ในอุโมงค์ หรือข้อความที่ได้รับแต่ได้รับนอกหน้าต่างที่ยอมรับได้ ความไม่สมบูรณ์จะส่งผลต่อผลลัพธ์ของคุณอย่างไร
นี่เป็นเพียงรายการเบื้องต้น เราขอแนะนำให้อ่านเอกสารต่อไปนี้ที่จะช่วยให้คุณเข้าใจแต่ละหัวข้อได้ลึกซึ้งยิ่งขึ้น
ผู้ร่วมให้ข้อมูล
Google เป็นผู้ดูแลเอกสารนี้ ผู้ร่วมให้ข้อมูลต่อไปนี้เป็นผู้เขียนเอกสารนี้ในตอนแรก
ผู้เขียนหลัก
- Mary Pishny | ผู้จัดการผลิตภัณฑ์, Google Maps Platform
- Ethel Bao| วิศวกรซอฟต์แวร์, Google Maps Platform
- Mohanad Almiski | วิศวกรซอฟต์แวร์, Google Maps Platform
- Naoya Moritani | วิศวกรโซลูชัน, Google Maps Platform