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 gần sát thời gian thực từ đội xe đang hoạt động trên mặt đất có í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 (ETA) 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 người lái xe 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 người lái xe để cải thiện hiệu quả
  • Tuân thủ các quy định bằng cách theo dõi vị trí 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 chặng cuối (LMFS) hoặc "Giải pháp gọi xe và giao hàng theo yêu cầu (ODRD) thành các sự kiện tuỳ chỉnh có thể thực hiện. Các khái niệm chính và quyết định thiết kế của Giải pháp tham khảo về sự kiện đội xe có trên GitHub cũng được đề cập.

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 trực tuyến, cùng với các thành phần từ Google Maps Platform và Google Cloud tạo nên Giải pháp tham khảo về sự kiện đội xe.

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

Giải pháp tham khảo 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 dựa trên Fleet Engine và các thành phần của Google Cloud. Hiện tại, giải pháp tham khảo này hỗ trợ những khách hàng sử dụng Giải pháp đội xe chặng cuối, đồng thời hỗ trợ Giải pháp gọi xe và giao hàng theo yêu cầu.

Giải pháp này tự động tạo sự kiện dựa trên những thay đổi đối với dữ liệu cụ thể được liên kết với các 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.

  • Thay đổi giờ đến dự kiến (ETA) cho việc đến nơi thực hiện nhiệm vụ
  • Thay đổi thời gian đến dự kiến (ETA) tương đối cho việc đến nơi thực hiện 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 khảo để 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 khảo 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 khảo này chứa các thành phần sau:

  • Nguồn sự kiện: Nơi bắt nguồn luồng sự kiện ban đầu. Cả "Giải pháp đội xe chặng cuối" và "Giải pháp gọi xe và giao hàng 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.
  • Đang 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, 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 yêu cầu 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 tra cứu đế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, để lưu trữ trạng thái trên chính bạn, vì các trạng thái này phải là duy nhất đối với một loại xe và sự kiện, thì dịch vụ duy trì dữ liệu loại K-V sẽ phù hợp.
  • Bồn lưu trữ dữ liệu (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 đó, việc 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 là một lựa chọn tự nhiê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 khảo cho "Giải pháp đội xe chặng cuối" hoặc "Giải pháp gọi xe và giao hàng 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à "bồn lưu trữ dữ liệu '' rất đơn giản. Mặt khác, "Đang xử lý" có nhiều lựa chọn. Giải pháp tham khảo 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 khảo

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 chế độ triển khai nhiều dự án theo mặc định. Điều này là để việc sử dụng Google Maps Platform và Google Cloud có thể được tách biệt rõ ràng và được liên kết với thoả thuận thanh toán mà bạn chọn.

Nguồn sự kiện

"Giải pháp đội xe chặng cuối" và "Giải pháp gọi xe và giao hàng theo yêu cầu" ghi các tải trọng yêu cầu API và 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à một 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ã.

Bồn lưu trữ dữ liệu

Trong Google Cloud, Cloud Pub/Sub là hệ thống phân phối thông báo gần sát thời gian thực mà bạn chọn. Giống 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.

Đang xử lý

Các thành phần sau đây đóng vai trò trong việc 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 có máy chủ và có thể mở rộng quy mô tốt cả lên và xuống.

Bạn có thể sử dụng các hàm này ở dạng 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 các tệp README của mô-đun terraform tương ứng.

*Lưu ý: Giải pháp tham khảo 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 khảo 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 khảo 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 các mô-đun Terraform có thể được 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ể bắt đầu nhanh chóng 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 khảo:

  • 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 khảo, cấu hình 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 chỉ định.
  • Triển khai hàm đám mây Fleet Events: Chứa quá trình triển khai mã hàm mẫu 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 khảo: Gọi hai mô-đun trước đó và gói toàn bộ giải pháp.

Bảo mật

IAM được áp dụng để áp dụng 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ụ. 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 nhằm giúp bạn kiểm soát tốt hơn tính bảo mật.

Hành động tiếp theo

Bây giờ, bạn đã sẵn sàng truy cập và khám phá thêm Giải pháp tham khảo 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 gần sát thời gian 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?
    • Có thể chỉ dựa trên 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? Hoặc có 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 không? 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 những chỉ số nào với tư cách là một 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ì loại phương thức tổng hợp nào sẽ cần? Hãy thử trình bày các bước logic. (ví dụ: So sánh ETA/ATA với SLO trên một nhóm nhỏ của độ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ô? Đây là để giảm độ trễ (thời gian thực hiện hành động) hay để tích hợp lỏng lẻo (tính linh hoạt)?
    • Nếu là để 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à nó cung cấp những điểm tích hợp nào?
    • Có yêu cầu nào mà hệ thống hiện tại của bạn không đáp ứng được hoặc có thể 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 luôn có một quy trình tư duy để làm theo. Điều này giúp đư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.

  • 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, không phải tối ưu hoá tối đa. Cũng tránh tối ưu hoá quá mức vì điều này thường dẫn đến việc tăng độ phức tạp.
  • Điều này cũng đúng đối với chi phí. 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 có khả năng linh hoạt để tăng quy mô với giới hạn và cũng giảm quy mô (lý tưởng 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 hành trình, 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 hoán đổi từng phần sau này.
  • Cuối cùng nhưng không kém phần quan trọng, tính bảo mật không thể lỏng lẻo. Là một dịch vụ chạy trên môi trường đám mây công cộng, không thể có bất kỳ cửa nào không được bảo mật vào hệ thống.

Khái niệm về truyền trực tuyến

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ì có những khái niệm chính mà bạn cần biết, một số khái niệm có thể rất khác so với xử lý hàng loạt.

  • Quy mô : Ngược lại với xử lý hàng loạt, nơi bạn thường có ý tưởng rõ ràng về lượng dữ liệu cần xử lý, trong truyền trực tuyến thì bạn không thể. Tình trạng tắc nghẽn giao thông trong một thành phố có thể tạo ra nhiều sự kiện đột ngột từ khu vực cụ thể và bạn vẫn cần có khả năng xử lý tình trạng đó.
  • Chia cửa sổ : Thay vì xử lý các sự kiện từng sự kiện một, thường thì bạn muốn nhóm các sự kiện theo dòng thời gian thành các "cửa sổ" nhỏ hơn làm đơn vị tính toán. Có nhiều chiến lược chia cửa sổ như "cửa sổ cố định (ví dụ: mỗi ngày dương lịch)", "cửa sổ trượt (5 phút qua)", "cửa sổ phiên (trong chuyến đi này)", bạn nên chọn một trong số đó. Cửa sổ càng dài thì độ trễ trong việc tạo kết quả càng lâu. Chọn mô hình và cấu hình phù hợp đáp ứng yêu cầu của bạn.
  • Kích hoạt : Có những trường hợp bạn không có lựa chọn nào khác ngoài việc có các cửa sổ tương đối dài hơn. Tuy nhiên, bạn không muốn đợi đến cuối cửa sổ để tạo sự kiện, mà thay vào đó, hãy phát ra kết quả trung gian ở giữa. 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 có liên quan đến việc giao tiếp qua mạng di động, điều này làm tăng độ trễ và các đường dẫn đị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 đủ : Giống 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 đã nhận nhưng chỉ ở ngoài cửa sổ 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: