Sự kiện theo thời gian thực của Fleet Engine

Tín hiệu gần như theo thời gian thực từ đội xe đang 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 các tính năng này để:

  • Theo dõi hiệu suất của đội xe và sớm xác định 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 theo dõi và thời gian đến dự kiến chính xác
  • Giảm chi phí bằng cách xác định và giải quyết các điểm kém hiệu quả
  • Nâng cao mức độ an toàn bằng cách giám sát 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ế để nâng cao hiệu quả
  • Tuân thủ các 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 tín hiệu từ "Dịch vụ di chuyển" của Google Maps Platform ("Giải pháp đội xe 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ể 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 khảo về sự kiện của đội xe có trên GitHub cũng được đề cập.

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

  • Kiến trúc sư quen thuộc với "Dịch vụ di chuyển" của Google Maps Platform và một trong những thành phần cốt lõi của dịch vụ này là "Fleet Engine". Đối với những người mới sử dụng "Dịch vụ di chuyển", bạn nên làm quen với Giải pháp đội xe chặng cuối và/hoặc Giải pháp giao hàng và chuyến đi theo yêu cầu, tuỳ theo nhu cầu của bạn.
  • Kiến trúc sư quen thuộc với Google Cloud. Đối với những người mới sử dụng Google Cloud, bạn nên đọc trước bài viết Xây dựng quy trình truyền dữ liệu trực tuyến trên Google Cloud.
  • Nếu bạn đang nhắm đến các môi trường hoặc ngăn xếp phần mềm khác, hãy tập trung vào việc tìm hiểu các điểm tích hợp và những điểm chính cần xem xét của Fleet Engine, những điểm này vẫn có thể áp dụng được.
  • Những người quan tâm đến việc tìm hiểu cách tạo và sử dụng các sự kiện từ đội xe.

Sau khi đọc xong tài liệu này, bạn sẽ có kiến thức cơ bản về các yếu tố chính và những điều cần cân nhắc đối với một hệ thống truyền trực tuyến, 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 khảo về Sự kiện của đội xe.

Tổng quan về giải pháp tham khảo cho sự kiện của đội xe

Giải pháp tham khảo về sự kiện của độ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 Mobility 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ợ khách hàng sử dụng Giải pháp đội xe chặng cuối, đồng thời hỗ trợ dịch vụ Giao hàng và gọi xe theo yêu cầu.

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 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 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 bạn.

  • Thay đổi thời gian đến dự kiến cho việc cần làm
  • Thay đổi tương đối về thời gian đến dự kiến của nhiệm vụ
  • Thời gian còn lại cho đến khi nhiệm vụ đến
  • Khoảng cách còn lại đến điểm đến của 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 cho phù hợp với nhu cầu kinh doanh của mình.

Thành phần logic

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

Tổng quan về Sự kiện của đội xe và các thành phần logic

Giải pháp tham khảo bao gồm các thành phần sau:

  • Nguồn sự kiện: Nơi bắt nguồn của luồng sự kiện ban đầu. Cả "Last Mile Fleet Solution" và "On-demand Rides and Deliveries Solution" đề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 luồng sự kiện cho nhà phát triển. Đâ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, tính toán trên một luồng sự kiện nhật ký. Để phát hiện thay đổi đó, 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 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 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 liên tục. Nhưng 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 cho một loại xe và loại sự kiện, nên dịch vụ lưu trữ dữ liệu loại K-V là lựa chọn 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ừ thay đổi đó. Do đó, việc xuất bản sự kiện tuỳ chỉnh này lên một 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 biệt 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 giao hàng và chuyến đi theo yêu cầu" (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à "Bồn lưu trữ" rất đơn giản. Mặt khác, "Xử lý" có nhiều lựa chọn. Giải pháp tham khảo đã chọn các dịch vụ sau đây của Google.

Sơ đồ : Sơ đồ sau đây cho thấy dịch vụ Google Cloud để triển khai giải pháp tham khảo

Các thành phần của giải pháp tham khảo về Sự kiện trong đội xe

Bố cục dự án trên đám mây

Bạn nên triển khai nhiều dự án theo mặc định. Nhờ đó, mức sử dụng Google Maps Platform và Google Cloud có thể được tách biệt rõ ràng và gắn 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 chặng cuối" và "Giải pháp gọi xe và giao hàng theo yêu cầu" ghi tải trọng yêu cầu API và phản hồi vào Cloud Logging. Cloud Logging cung cấp nhật ký cho một hoặc nhiều dịch vụ mà bạn chọn. Định tuyến đến Cloud Pub/Sub là một lựa chọn hoàn hảo trong trường hợp nà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 gửi thông báo gần như theo thời gian thực được lựa 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.

Đ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 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ô 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 máy chủ, tăng và giảm quy mô bằng các chế độ kiểm soát việc điều chỉnh quy mô để quản lý chi phí
    • Java là ngôn ngữ lập trình được chọn vì có sẵn các thư viện ứng dụng cho các API liên quan đến Fleet Engine, giúp dễ dàng triển khai
  • Cloud Firestore làm kho lưu trữ trạng thái
    • Kho lưu trữ 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 ngược dòng và xuôi dòng
    • Tích hợp gần như theo thời gian thực, liên kết lỏng lẻo

Bạn có thể sử dụng các hàm này theo 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 đặ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 án 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 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ợ mạnh mẽ 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. Các mô-đun cung cấp nhiều biến có thể định cấu hình, hầu hết trong số đó đề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 Cloud Logging để sử dụng với Fleet Engine. Trong giải pháp tham khảo, bộ lọc này được dùng để định tuyến nhật ký liên quan đến Fleet Engine đến một chủ đề Pub/Sub cụ thể.
  • Triển khai chức năng đám mây Fleet Events: Chứa mã triển khai chức năng 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 để thực thi 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ụ. Tham khảo các bài viết sau để hiểu rõ hơn về những giải pháp của Google Cloud giúp bạn kiểm soát bảo mật hiệu quả hơn.

Hành động tiếp theo

Giờ đây, bạn đã sẵn sàng truy cập và khám phá thêm về Giải pháp tham khảo về 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 của bạn

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

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 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.

  • Cần có thông tin gì để luồng sự kiện trở nên hữu ích?
    • Kết quả có thể được lấy hoàn toàn 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ầ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ó, đó 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 cho doanh nghiệp của mình? Các nhóm này được xác định như thế nào?
    • Nếu cần tính toán các chỉ số trên nhiều sự kiện, bạn sẽ cần loại tổng hợp nào? Cố gắng trình bày các bước một cách hợp lý. (ví dụ: So sánh ETA/ATA với SLO trên một nhóm nhỏ đội tàu 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 hơn là mô hình theo lô? Mục đích là để giảm độ trễ (thời gian thực hiện hành động) hay để tích hợp linh hoạt (nhanh chóng)?
    • Nếu là độ trễ thấp, hãy xác định "thấp". Phút? Giây? Dưới một giây? Còn độ trễ thì sao?
  • Nhóm của bạn đã đầu tư vào một bộ công nghệ và các kỹ năng liên quan chưa? Nếu có, thì đó 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 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.

  • Mặc định là các lựa 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ễ học hơn.
  • Đối với độ trễ và hiệu suất, hãy cố gắng đạt được mức bạn đã đặt ra, chứ không phải mức 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 làm tăng độ phức tạp.
  • Điều tương tự cũng áp dụng cho 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.
  • Trong giai đoạn thử nghiệm, việc thu hẹp quy mô cũng quan trọng như việc mở rộng quy mô. Hãy cân nhắc một nền tảng cho phép linh hoạt tăng quy mô theo giới hạn và cũng có thể giảm quy mô (lý tưởng nhất là về 0) để bạn không phải chi tiêu 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 hoạt động 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 những điểm cần cải thiện thêm.
  • Giữ cho 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, bảo mật là yếu tố không thể lơ là. 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 được có bất kỳ lỗ hổng bảo mật nào.

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

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

  • Quy mô : Trái ngược với xử lý hàng loạt, nơi bạn thường có ý tưởng hay về lượng dữ liệu cần xử lý, trong quá trình truyền trực tuyến, bạn không thể làm như vậy. Tình trạng kẹt xe trong thành phố có thể đột ngột tạo ra nhiều sự kiện từ một khu vực cụ thể và bạn vẫn cần phải xử lý được tình trạng đó.
  • Phân chia cửa sổ : Thay vì xử lý từng sự kiện một, bạn thường 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 dưới dạng một đơn vị để tính toán. Có nhiều chiến lược phân chia 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 gần nhất)", "khoảng thời gian phiên (trong chuyến đi này)" mà bạn nên chọn. Khoảng thời gian càng dài thì thời gian trễ để tạo ra kết quả càng lâu. 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òn lựa chọn nào khác ngoài việ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 cửa sổ để tạo sự kiện, mà thay vào đó, bạn muốn 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 rồi sửa sau là có giá trị. 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% của một lần giao hàng.
  • Thứ tự : 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, 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 diễn ra 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ý các sự kiện cho phù hợp. Nhìn chung, bạn nên xử lý các sự kiện dựa trên "thời gian diễn ra 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 cho những thông báo này. Tuỳ theo trường hợp sử dụng, bạn cần cân nhắ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 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ị, hư hỏng ngoài ý muốn đối với điện thoại, mất kết nối 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 thiếu thông tin 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. Sau đây là một số tài liệu đọc được đề xuất nhiều nhất có thể giúp bạn hiểu sâu hơn về từng loại.

Người đóng góp

Google duy trì tài liệu này. Những người đóng góp sau đây là tác giả ban đầu của nội dung này.

Tác giả chính: