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

Tín hiệu gần như theo thời gian thực từ đội xe hoạt động trên mặt đất rất hữu ích cho các doanh nghiệp theo một số cách. Ví dụ: doanh nghiệp có thể sử dụng những thông tin 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 vận đơn và thời gian dự kiến đến chính xác
  • Giảm chi phí bằng cách xác định và giải quyết các vấn đề 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á tuyến đường và lịch trình của tài xế để cải thiện hiệu quả
  • Tuân thủ quy định bằng cách theo dõi vị trí của xe và giờ hoạt động

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

Tài liệu này liên quan đến:

Khi kết thúc tài liệu này, bạn sẽ có kiến thức cơ bản về các thành phần chính và những điều cần cân nhắc của hệ thống truyền trực tuyến, cùng với các khối xây dựng từ Google Maps Platform và Google Cloud tạo nên Giải pháp tham chiếu sự kiện của đội xe.

Tổng quan về giải pháp tham chiếu sự kiện của Nhóm thiết bị

Giải pháp tham chiếu sự kiện của Fleet là một giải pháp nguồn mở cho phép khách hàng và đối tác của Mobility tạo các sự kiện chính dựa trên công cụ Fleet và các thành phần của Google Cloud. Hiện tại, giải pháp tham khảo hỗ trợ khách hàng sử dụng Giải pháp cho đội xe cuối cùng, đồng thời hỗ trợ các dịch vụ Đi xe theo yêu cầu và Giao hàng.

Giải pháp này tự động tạo sự kiện dựa trên các thay đổi đối với dữ liệu cụ thể liên kết với các công việc 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ư sau) 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 của việc cần làm
  • Thay đổi tương đối về thời gian đến dự kiến của việc cần làm
  • 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 của doanh nghiệp.

Khối xây dựng logic

Sơ đồ : Sơ đồ sau đây cho thấy các khối xây dựng cấp cao tạo nên giải pháp tham chiếu Sự kiện của đội xe

Tổng quan về Sự kiện của đội xe và các khối xây dựng logic

Giải pháp tham khảo chứa các thành phần sau:

  • Nguồn sự kiện: Nguồn gốc của luồng sự kiện ban đầu. Cả "Giải pháp xe cuối cùng" hoặc "Giải pháp cho dịch vụ đi xe và giao hàng theo yêu cầu" đều tích hợp với tính năng Ghi nhật ký trên đám mây để giúp chuyển nhật ký lệnh gọi RPC của Công cụ xe thành 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ô đượ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 yêu cầu một kho trạng thái để có thể so sánh các sự kiện mới sắp diễn ra với các sự kiện trước đó nhằm phát hiện sự thay đổi. Sự kiện 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ợ nếu cần.
    • Lưu trữ trạng thái: Một số khung xử lý cung cấp dữ liệu trung gian một cách ổn định. 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 dành riêng cho một loại xe và sự kiện, nên dịch vụ lưu trữ dữ liệu kiểu K-V sẽ phù hợp.
  • Sink (Sự kiện tuỳ chỉnh): Bạn phải cung cấp thay đổi trạng thái đã phát hiện cho mọi ứng dụng hoặc dịch vụ có thể hưởng lợi từ thay đổi đó. Do đó, việc phát hành sự kiện tuỳ chỉnh này cho một hệ thống phân phối sự kiện để sử dụng trong phần phụ trợ 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 đã tạo và thực hiện các thao tác dành riêng cho trường hợp sử dụng của bạn.

Lựa chọn dịch vụ

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

Sơ đồ : Sơ đồ 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 Sự kiện của đội

Bố cục của Dự án trên đám mây

Bạn nên triển khai nhiều dự án theo mặc định. Việc này giúp bạn có thể tách riêng mức sử dụng Nền tảng Google Maps 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 cho đội xe cuối cùng" và "Giải pháp cho dịch vụ gọi xe và giao hàng theo yêu cầu" ghi tải trọng yêu cầu và phản hồi API vào Nhật ký trên đám mây. Cloud Logging phân phối nhật ký đến một hoặc nhiều dịch vụ mà bạn chọn. Chuyển đến Cloud Pub/Sub là lựa chọn hoàn hảo tại đây và cho phép chuyển đổi nhật ký thành luồng sự kiện mà không cần lập trình.

Bồn rửa bát

Trong Google Cloud, Cloud Pub/Sub là hệ thống phân phối tin nhắn gần như theo thời gian thực mà bạn có thể 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 phát hành đến Pub/Sub để sử dụng trong phần phụ trợ.

Đang 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 khối xây dựng 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 cả lên và xuống.

  • Cloud Functions làm nền tảng điện toán cho bản phát hành đầu tiên (*)
    • Không cần máy chủ, mở rộng và thu hẹp quy mô bằng các chế độ kiểm soát mở rộng quy mô để quản lý chi phí
    • Java là ngôn ngữ lập trình do có sẵn thư viện ứng dụng cho các API liên quan đến Động cơ của đội xe, giúp dễ dàng triển khai
  • Cloud Firestore làm kho trạng thái
    • Kho khoá-giá trị không máy chủ
  • Cloud Pub/Sub làm điểm tích hợp với các thành phần thượng nguồn và hạ nguồn
    • Tích hợp gần như theo thời gian thực với mối liên kết lỏng

Bạn có thể sử dụng các hàm như hiện có với chế độ cài đặt mặc định, nhưng cũng có thể định cấu hình lại. Các thông số cấu hình được đặt 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 khảo này dự định phát hành các phương thức triển khai thay thế có thể giúp đáp ứng nhiều yêu cầu.

Triển khai

Để quy trình triển khai giải pháp tham chiếu có thể lặp lại, có thể tuỳ chỉnh, kiểm soát được mã nguồn và an toàn, 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, có nhiều tính năng hỗ trợ 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 có thể được sử dụng độc lập. Mô-đun cung cấp nhiều biến có thể định cấu hình, hầu hết các biến này đề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ý của Fleet Engine: Tự động hoá các cấu hình liên quan đến tính năng Ghi nhật ký trên đám mây để sử dụng với Fleet Engine. Trong giải pháp tham chiếu, lớp này được dùng để định tuyến nhật ký liên quan đến Công cụ của đội xe đến một chủ đề Pub/Sub được chỉ định.
  • Triển khai hàm trên đám mây của Sự kiện của đội xe: 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 chiếu: 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ề đặc 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 để 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 vấn đề bảo mật.

Hành động tiếp theo

Giờ đây, bạn đã có thể truy cập và khám phá thêm về Giải pháp tham chiếu sự kiện của độ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 các yêu cầu của mình 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 sự kiện gần như theo 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.

  • Luồng sự kiện cần có những thông tin gì để hữu ích?
    • Kết quả có thể chỉ xuất phát từ dữ liệu được thu thập hoặc tạo ra trong các dịch vụ của Google không? Hay bạn có cần làm phong phú dữ liệu bằng các hệ thống bên ngoài tích hợp không? Nếu có, đó là những hệ thống nào và chúng cung cấp giao diện tích hợp nào?
    • Là một doanh nghiệp, bạn muốn đo lường những chỉ số nào? Các giá trị này đượ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 dữ liệu tổng hợp nào? Hãy cố gắng sắp xếp các bước hợp lý. (ví dụ: So sánh thời gian dự kiến đến/thời gian dự kiến khởi hành với SLO trên một nhóm nhỏ trong độ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ô? Điều này là để giảm độ trễ (thời gian thực hiện hành động) hay để tích hợp một cách lỏng lẻo (nhanh nhẹn)?
    • Nếu muốn có độ trễ thấp, hãy xác định là "thấp". Phút? Giây? Dưới một giây? Và độ trễ là bao nhiêu?
  • Bạn đã đầu tư vào một 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ó, đó là gì và 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 thể đáp ứng 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 luôn nê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.

  • Đặt mặc định là các tuỳ chọn đơn giản hơn.
  • Mặc định là thời gian tạo ra giá trị ngắn hơn. Ít mã hơn, độ dốc học tập thấp hơn.
  • Đối với độ trễ và hiệu suất, hãy đặt mục tiêu đạt được mức 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ì đ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 đỏ.
  • Ở giai đoạn thử nghiệm, việc thu hẹp quy mô có thể quan trọng như việc mở rộng quy mô. Hãy cân nhắc một nền tảng có thể linh hoạt mở rộng quy mô với giới hạn và cũng giảm quy mô (tốt nhất là về 0) để bạn không chi tiêu khi không làm gì cả. 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 cơ sở hạ tầng đó.
  • Hãy quan sát và đo lường để sau này bạn có thể xác định những điểm cần cải thiện thêm.
  • Giữ cho các dịch vụ được ghép nối lỏng lẻo. Việc 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, bạn không được 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 khai, không được có bất kỳ cửa nào không an toàn đối với hệ thống.

Các khái niệm về nội dung phát trực tuyến

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

  • Điều chỉnh theo quy mô : Trái ngược với quy trình xử lý hàng loạt, trong đó bạn thường có khái niệm rõ ràng về lượng dữ liệu cần xử lý, thì trong quy trình truyền trực tuyến, bạn không thể làm được điều này. 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ừ một khu vực cụ thể và bạn vẫn cần xử lý được tình trạng này.
  • Phân đoạn : Thay vì xử lý từng sự kiện một, thường thì bạn muốn nhóm các sự kiện trên một dòng thời gian thành các "khung" nhỏ hơn làm đơn vị tính toán. Bạn nên chọn trong số nhiều chiến lược tạo khoảng thời gian như "khoảng thời gian cố định (ví dụ: mỗi ngày theo 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. 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 : Có những trường hợp bạn không có lựa chọn nào khác ngoài việc sử dụng khoảng thời gian tương đối dài hơn. Tuy nhiên, bạn không nê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 trong đó giá trị này là giá trị trả về kết quả nhanh trước, sau đó sửa lại sau. Hãy tưởng tượng việc phát trạng thái trung gian ở mức 25%, 50%, 75% hoàn thành một lượt phân phối.
  • Thứ tự : 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, đ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 lưu ý sự khác biệt giữa "thời gian sự kiện" (khi sự kiện thực sự xảy ra) và "thời gian xử lý" (khi sự kiện đến hệ thống) và xử lý sự kiện cho phù hợp. Nhìn 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: Mỗi nền tảng sự kiện có cách hỗ trợ khác nhau đối với các thông báo 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.
  • Độ đầy đủ : Tương tự như việc thay đổi thứ tự, có khả năng thông báo sẽ 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ị, điện thoại bị hư hỏng ngoài ý muốn, mất kết nối trong khi ở trong đường hầm hoặc tin nhắn đã nhận được nhưng chỉ nằm ngoài khoảng thời gian chấp nhận được. Việc không hoàn thành sẽ ảnh hưởng như thế nào đến kết quả của bạn?

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

Người đóng góp

Google duy trì tài liệu này. Các cộng tác viên sau đây là tác giả ban đầu của bài viết này.

Tác giả chính:

  • Mary Pishny | Nhà quản lý sản phẩm, Nền tảng Google Maps
  • Ethel Bao| Kỹ sư phần mềm, Nền tảng Google Maps
  • Mohanad Almiski | Kỹ sư phần mềm, Nền tảng Google Maps
  • Naoya Moritani | Kỹ sư giải pháp, Nền tảng Google Maps