Tạo sự kiện gần như theo thời gian thực bằng Fleet Engine và Giải pháp tham chiếu sự kiện của Fleet

Các tín hiệu theo thời gian gần thực từ đội xe đang hoạt động trên mặt đất rất hữu ích cho doanh nghiệp theo nhiều cách. Ví dụ: doanh nghiệp có thể sử dụng các tín hiệu này để:

  • Theo dõi hiệu suất của đội xe và xác định sớm các vấn đề tiềm ẩn
  • Cải thiện dịch vụ khách hàng bằng cách cung cấp thông tin chính xác về thời gian đến dự kiến và thông tin theo dõi
  • Giảm chi phí bằng cách xác định và giải quyết các điểm không hiệu quả
  • Cải thiện độ an toàn bằng cách theo dõi hành vi của tài xế và xác định các mối nguy hiểm tiềm ẩn
  • Tối ưu hoá lộ trình và lịch trình của tài xế để cải thiện hiệu quả
  • Tuân thủ các quy định bằng cách theo dõi vị trí của xe và giờ làm việc

Tài liệu này minh hoạ cách nhà phát triển có thể chuyển các tín hiệu từ Nền tảng Google Maps "Dịch vụ di động" ("Giải pháp đội xe giao hàng chặng cuối (LMFS) hoặc "Giải pháp giao hàng và gọi xe theo yêu cầu (ODRD) thành các sự kiện tuỳ chỉnh có thể thực hiện. Tài liệu này cũng đề cập đến các khái niệm chính và quyết định thiết kế của Giải pháp tham chiếu về sự kiện đội xe có trên GitHub.

Tài liệu này phù hợp với:

Khi đọc xong tài liệu này, bạn sẽ hiểu được các yếu tố và điểm cần cân nhắc cơ bản của hệ thống truyền phát, cùng với các thành phần của Google Maps Platform và Google Cloud tạo nên Giải pháp tham chiếu về sự kiện đội xe.

Tổng quan về Giải pháp tham chiếu về sự kiện đội xe

Giải pháp tham chiếu về sự kiện đội xe là một giải pháp nguồn mở cho phép khách hàng và đối tác của Dịch vụ di động tạo các sự kiện chính trên các thành phần của Fleet Engine và Google Cloud. Hiện tại, giải pháp tham chiếu này hỗ trợ khách hàng sử dụng Giải pháp đội xe giao hàng chặng cuối và sẽ hỗ trợ Giải pháp giao hàng và gọi xe theo yêu cầu trong tương lai.

Giải pháp này tự động tạo các sự kiện dựa trên những thay đổi đối với dữ liệu cụ thể liên quan đến nhiệm vụ hoặc chuyến đi. Bạn có thể sử dụng các sự kiện này để gửi thông báo (chẳng hạn như thông báo sau đây) cho các bên liên quan hoặc kích hoạt các hành động khác cho đội xe của mình.

  • Thay đổi về thời gian đến dự kiến cho nhiệm vụ
  • Thay đổi tương đối về thời gian đến dự kiến cho nhiệm vụ
  • Thời gian còn lại để đến nơi thực hiện nhiệm vụ
  • Khoảng cách còn lại để đến nơi thực hiện nhiệm vụ
  • Thay đổi trạng thái TaskOutcome

Bạn có thể tuỳ chỉnh từng thành phần của giải pháp tham chiếu để phù hợp với nhu cầu kinh doanh của mình.

Thành phần logic

Biểu đồ : Biểu đồ sau đây cho thấy các thành phần cấp cao tạo nên giải pháp tham chiếu về sự kiện đội xe

Tổng quan về Fleet Events và các khối xây dựng logic

Giải pháp tham chiếu này bao gồm các thành phần sau:

  • Nguồn sự kiện: Nơi luồng sự kiện ban đầu xuất phát. Cả "Giải pháp đội xe giao hàng chặng cuối" và "Giải pháp giao hàng và gọi xe theo yêu cầu" đều tích hợp với Cloud Logging để giúp chuyển nhật ký lệnh gọi RPC của Fleet Engine thành các luồng sự kiện mà nhà phát triển có thể sử dụng. Đây là nguồn cốt lõi để sử dụng.
  • Xử lý: Nhật ký lệnh gọi RPC thô sẽ được chuyển đổi thành các sự kiện thay đổi trạng thái trong khối này. Khối này sẽ tính toán trên một luồng sự kiện nhật ký. Để phát hiện sự thay đổi như vậy, thành phần này cần có một kho lưu trữ trạng thái để có thể so sánh các sự kiện mới đến với các sự kiện trước đó nhằm phát hiện sự thay đổi. Các sự kiện có thể không phải lúc nào cũng bao gồm tất cả thông tin mà bạn quan tâm. Trong những trường hợp như vậy, khối này có thể thực hiện các lệnh gọi tìm kiếm đến phần phụ trợ khi cần.
    • Kho lưu trữ trạng thái: Một số khung xử lý cung cấp dữ liệu trung gian được duy trì trên chính khung đó. Tuy nhiên, nếu không, để tự lưu trữ trạng thái, vì các trạng thái này phải là duy nhất đối với một xe và loại sự kiện, nên dịch vụ duy trì dữ liệu loại K-V sẽ phù hợp.
  • Sink (Sự kiện tuỳ chỉnh): Thay đổi trạng thái được phát hiện phải được cung cấp cho mọi ứng dụng hoặc dịch vụ có thể hưởng lợi từ đó. Do đó, bạn nên chọn xuất bản sự kiện tuỳ chỉnh này lên hệ thống phân phối sự kiện để sử dụng ở hạ nguồn.
  • Dịch vụ ở hạ nguồn: Mã sử dụng các sự kiện được tạo và thực hiện các hành động riêng cho trường hợp sử dụng của bạn.

Chọn dịch vụ

Khi triển khai giải pháp tham chiếu cho "Giải pháp đội xe giao hàng chặng cuối" hoặc "Giải pháp giao hàng và gọi xe theo yêu cầu" (ra mắt vào cuối quý 3 năm 2023), việc chọn công nghệ cho "Nguồn" và "Sink '' rất đơn giản. Mặt khác, "Xử lý" có nhiều lựa chọn. Giải pháp tham chiếu này đã chọn các dịch vụ sau đây của Google.

Biểu đồ : Biểu đồ sau đây cho thấy dịch vụ Google Cloud để triển khai giải pháp tham chiếu

Các khối xây dựng giải pháp tham chiếu về Sự kiện của đội xe

Bố cục dự án trên Google Cloud

Bạn nên chọn triển khai nhiều dự án theo mặc định. Điều này giúp tách biệt rõ ràng mức sử dụng của Google Maps Platform và Google Cloud, đồng thời liên kết với phương thức thanh toán mà bạn chọn.

Nguồn sự kiện

"Giải pháp đội xe giao hàng chặng cuối" và "Giải pháp giao hàng và gọi xe theo yêu cầu" ghi yêu cầu API và tải trọng phản hồi vào Cloud Logging. Cloud Logging phân phối nhật ký đến một hoặc nhiều dịch vụ mà bạn chọn. Việc định tuyến đến Cloud Pub/Sub là lựa chọn hoàn hảo ở đây và cho phép chuyển đổi nhật ký thành luồng sự kiện mà không cần viết mã.

Sink

Trong Google Cloud, Cloud Pub/Sub là hệ thống phân phối thông báo theo thời gian gần thực mà bạn nên chọn. Tương tự như cách các sự kiện từ nguồn được phân phối đến Pub/Sub, các sự kiện tuỳ chỉnh cũng được xuất bản lên Pub/Sub để sử dụng ở hạ nguồn.

Xử lý

Các thành phần sau đây đóng vai trò trong quá trình xử lý sự kiện. Giống như các thành phần khác, các thành phần xử lý hoàn toàn không máy chủ và có thể mở rộng lên và xuống.

Bạn có thể sử dụng các hàm này nguyên trạng với chế độ cài đặt mặc định, nhưng cũng có thể định cấu hình lại. Các tham số cấu hình được thiết lập thông qua tập lệnh triển khai và được ghi lại chi tiết trong tệp README của mô-đun terraform tương ứng.

*Lưu ý: Giải pháp tham chiếu này dự định phát hành các cách triển khai thay thế có thể giúp đáp ứng các yêu cầu khác nhau.

Triển khai

Để quá trình triển khai giải pháp tham chiếu có thể lặp lại, tuỳ chỉnh, kiểm soát mã nguồn và bảo mật, Terraform được chọn làm công cụ tự động hoá. Terraform là một công cụ IaC (Cơ sở hạ tầng dưới dạng mã) được sử dụng rộng rãi, hỗ trợ nhiều cho Google Cloud.

Mô-đun Terraform

Thay vì tạo một mô-đun triển khai giải pháp tham chiếu nguyên khối lớn, các khối tự động hoá có thể sử dụng lại được triển khai dưới dạng mô-đun Terraform mà bạn có thể sử dụng độc lập. Các mô-đun cung cấp nhiều biến có thể định cấu hình, hầu hết đều có giá trị mặc định để bạn có thể nhanh chóng bắt đầu nhưng cũng có thể linh hoạt tuỳ chỉnh dựa trên nhu cầu và lựa chọn ưu tiên của mình.

Các mô-đun có trong giải pháp tham chiếu:

  • Cấu hình ghi nhật ký Fleet Engine: Tự động hoá các cấu hình liên quan đến Cloud Logging để sử dụng với Fleet Engine. Trong giải pháp tham chiếu, mô-đun này được dùng để định tuyến các nhật ký liên quan đến Fleet Engine đến một chủ đề Pub/Sub cụ thể.
  • Triển khai hàm trên đám mây cho sự kiện đội xe: Chứa mẫu triển khai mã hàm và cũng xử lý việc tự động hoá các chế độ cài đặt quyền cần thiết để tích hợp an toàn giữa các dự án.
  • Triển khai toàn bộ giải pháp tham chiếu: Gọi 2 mô-đun trước đó và gói toàn bộ giải pháp.

Bảo mật

IAM được áp dụng để tuân thủ các nguyên tắc về quyền tối thiểu cùng với các phương pháp hay nhất về bảo mật của Google Cloud, chẳng hạn như mạo danh Tài khoản dịch vụ. Hãy tham khảo các bài viết sau đây để hiểu rõ hơn về những gì Google Cloud cung cấp để giúp bạn kiểm soát bảo mật tốt hơn.

Các bước tiếp theo

Bây giờ, bạn đã sẵn sàng truy cập và khám phá thêm về Giải pháp tham chiếu về sự kiện đội xe. Hãy truy cập vào GitHub để bắt đầu.

Phụ lục

Thu thập yêu cầu

Bạn nên thu thập yêu cầu sớm hơn trong quá trình này.

Trước tiên, hãy ghi lại thông tin chi tiết về lý do bạn quan tâm hoặc cần sử dụng các sự kiện theo thời gian gần thực. Sau đây là một số câu hỏi giúp bạn xác định rõ nhu cầu của mình.

  • Cần có thông tin gì để luồng sự kiện hữu ích?
    • Bạn có thể chỉ dựa vào dữ liệu được thu thập hoặc tạo trong các dịch vụ của Google để xác định kết quả không? Hay bạn cần làm phong phú dữ liệu bằng các hệ thống bên ngoài được tích hợp? Nếu có, thì đó là những hệ thống nào và chúng cung cấp những giao diện tích hợp nào?
    • Bạn muốn đo lường chỉ số nào với tư cách là doanh nghiệp? Các chỉ số đó được xác định như thế nào?
    • Nếu bạn cần tính toán các chỉ số trên các sự kiện, thì bạn cần loại phương thức tổng hợp nào? Hãy thử trình bày các bước logic. (ví dụ: So sánh thời gian đến dự kiến/thời gian đến thực tế với các mục tiêu cấp dịch vụ trên một nhóm nhỏ đội xe trong giờ cao điểm để tính toán hiệu suất trong điều kiện hạn chế về tài nguyên.)
  • Tại sao bạn quan tâm đến mô hình dựa trên sự kiện thay vì mô hình theo lô? Bạn muốn giảm độ trễ (thời gian thực hiện hành động) hay muốn tích hợp lỏng lẻo (tính linh hoạt)?
    • Nếu muốn giảm độ trễ, hãy xác định "thấp". Phút? Giây? Dưới một giây? Và độ trễ là bao nhiêu?
  • Bạn đã đầu tư vào ngăn xếp công nghệ và các kỹ năng liên quan với tư cách là một nhóm chưa? Nếu có, thì đó là gì và ngăn xếp đó cung cấp những điểm tích hợp nào?
    • Hệ thống hiện tại của bạn có đáp ứng được yêu cầu nào không hoặc có gặp khó khăn khi xử lý các sự kiện đến từ đội xe của bạn không?

Nguyên tắc thiết kế

Bạn nên có một quy trình tư duy để tuân theo. Điều này giúp bạn đưa ra các quyết định thiết kế nhất quán, đặc biệt là khi bạn có nhiều lựa chọn.

  • Chọn các lựa chọn đơn giản hơn theo mặc định.
  • Chọn thời gian tạo giá trị ngắn hơn theo mặc định. Ít mã hơn, đường cong học tập thấp hơn.
  • Đối với độ trễ và hiệu suất, hãy cố gắng đáp ứng ngưỡng mà bạn đã đặt, chứ không phải tối ưu hoá tối đa. Ngoài ra, hãy tránh tối ưu hoá quá mức vì việc này thường dẫn đến việc tăng độ phức tạp.
  • Chi phí cũng tương tự. Hãy giữ chi phí ở mức hợp lý. Bạn có thể chưa ở trạng thái có thể cam kết sử dụng các dịch vụ có giá trị cao nhưng tương đối đắt hơn.
  • Ở giai đoạn thử nghiệm, việc giảm quy mô có thể quan trọng như việc tăng quy mô. Hãy cân nhắc một nền tảng cho phép bạn linh hoạt tăng quy mô có giới hạn và giảm quy mô (tốt nhất là về 0) để bạn không tốn chi phí khi không làm gì. Bạn có thể cân nhắc hiệu suất cao với cơ sở hạ tầng luôn bật sau này trong quá trình này, khi bạn tự tin về nhu cầu của mình.
  • Quan sát và đo lường để sau này bạn có thể xác định nơi cần tiếp tục làm việc.
  • Giữ các dịch vụ được liên kết lỏng lẻo. Điều này giúp bạn dễ dàng thay thế từng phần sau này.
  • Cuối cùng nhưng không kém phần quan trọng, bạn không thể lơ là vấn đề bảo mật. Là một dịch vụ chạy trên môi trường đám mây công cộng, hệ thống không thể có bất kỳ cửa nào không được bảo mật.

Khái niệm về truyền phát

Nếu bạn tương đối mới sử dụng mô hình dựa trên sự kiện hoặc truyền trực tuyến, thì bạn cần biết các khái niệm chính. Một số khái niệm này có thể rất khác so với xử lý hàng loạt.

  • Quy mô : Trái ngược với quá trình xử lý hàng loạt (thường có ý tưởng rõ ràng về lượng dữ liệu cần xử lý), bạn không thể làm như vậy trong quá trình truyền phát. Tình trạng tắc nghẽn giao thông trong một thành phố có thể đột ngột tạo ra nhiều sự kiện từ khu vực cụ thể và bạn vẫn cần có khả năng xử lý tình trạng đó.
  • Chia theo khoảng thời gian : Thay vì xử lý từng sự kiện, bạn thường muốn nhóm các sự kiện theo dòng thời gian thành các "khoảng thời gian" nhỏ hơn làm đơn vị tính toán. Bạn có thể chọn nhiều chiến lược chia theo khoảng thời gian, chẳng hạn như "khoảng thời gian cố định (ví dụ: mỗi ngày dương lịch)", "khoảng thời gian trượt (5 phút qua)", "khoảng thời gian phiên (trong chuyến đi này)". Khoảng thời gian càng dài thì độ trễ trong việc tạo kết quả càng lớn. Hãy chọn mô hình và cấu hình phù hợp với yêu cầu của bạn.
  • Kích hoạt : Trong một số trường hợp, bạn không có lựa chọn nào khác ngoài việc sử dụng các khoảng thời gian tương đối dài hơn. Tuy nhiên, bạn không muốn đợi đến cuối khoảng thời gian để tạo sự kiện mà muốn phát ra kết quả trung gian trong khoảng thời gian đó. Bạn có thể triển khai khái niệm này cho các trường hợp sử dụng mà việc trả về kết quả nhanh trước tiên có giá trị, sau đó sửa kết quả đó sau. Hãy tưởng tượng việc phát ra trạng thái trung gian khi hoàn thành 25%, 50%, 75% quá trình giao hàng.
  • Sắp xếp : Các sự kiện không nhất thiết phải đến hệ thống theo thứ tự được tạo. Đặc biệt là đối với các trường hợp sử dụng liên quan đến việc giao tiếp qua mạng di động, làm tăng độ trễ và các đường định tuyến phức tạp. Bạn cần biết sự khác biệt giữa "thời gian sự kiện" (thời điểm sự kiện thực sự xảy ra) và "thời gian xử lý" (thời điểm sự kiện đến hệ thống) và xử lý các sự kiện cho phù hợp. Nói chung, bạn muốn xử lý các sự kiện dựa trên "thời gian sự kiện".
  • Phân phối thông báo – Ít nhất một lần so với Chính xác một lần: Các nền tảng sự kiện khác nhau có mức hỗ trợ khác nhau đối với các nền tảng này. Tuỳ thuộc vào trường hợp sử dụng, bạn cần cân nhắc các chiến lược thử lại hoặc loại bỏ trùng lặp.
  • Tính đầy đủ : Tương tự như việc thay đổi thứ tự, có khả năng thông báo bị mất. Điều này có thể là do ứng dụng và thiết bị tắt do thời lượng pin của thiết bị, hư hỏng không chủ ý đối với điện thoại, mất kết nối khi ở trong đường hầm hoặc thông báo được nhận nhưng chỉ ở ngoài khoảng thời gian chấp nhận được. Tính không đầy đủ sẽ ảnh hưởng đến kết quả của bạn như thế nào?

Đây không phải là danh sách đầy đủ mà chỉ là phần giới thiệu. Sau đây là một số bài đọc được đề xuất cao có thể giúp bạn hiểu sâu hơn về từng bài đọc.

Người đóng góp

Google duy trì tài liệu này. Những người đóng góp sau đây đã viết tài liệu này.

Tác giả chính: