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 doanh nghiệp theo nhiều 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à 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 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 đ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á tuyến đường và lịch trình của người lái xe để nâng cao hiệu quả
- Tuân thủ các quy định bằng cách theo dõi vị trí xe và giờ phục vụ
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ừ "Dịch vụ di động" của Nền tảng Google Maps ("Giải pháp cho đội xe chặng cuối (LMFS) hoặc "Giải pháp cho dịch vụ 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ể 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 độ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 động" của Nền tảng Google Maps và một trong những thành phần cốt lõi của nền tảng này là "Fleet Engine". Nếu 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 cho chặng cuối và/hoặc Giải pháp gọi xe và giao hàng theo yêu cầu, tuỳ thuộc vào nhu cầu của bạn.
- Kiến trúc sư có kinh nghiệm sử dụng 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 Tạo quy trình truyền trực tuyến dữ liệu 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 cần cân nhắc chính của Fleet Engine. Những điểm này vẫn sẽ áp dụng được.
- Những người có mối quan tâm chung đến việc khám phá cách tạo và sử dụng các sự kiện từ đội xe.
Đến cuối tài liệu này, bạn sẽ hiểu rõ những yếu tố và điểm cần cân nhắc chính của một hệ thống truyền phát trực tiếp, 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 cho sự kiện của nhóm xe
Giải pháp tham chiếu 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 trong ngành 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 chiếu này hỗ trợ những khách hàng sử dụng Last Mile Fleet Solution, đồng thời hỗ trợ tính năng Chuyến đi 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ể liên quan đến các nhiệm vụ hoặc chuyến đi. Bạn có thể sử dụng những 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 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 cho việc đến nơi thực hiện việc cần làm
- Thời gian còn lại cho đến khi đến nơi thực hiện nhiệm vụ
- Khoảng cách còn lại cho đến khi đế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 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 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
Giải pháp tham chiếu 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 cho đội xe chặng cuối" hoặc "Giải pháp cho dịch vụ chở khách 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 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, tính toán trên một luồng các sự kiện nhật ký. Để phát hiện thay đổi như vậy, thành phần này cần một kho 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 có thể không phải lúc nào cũng bao gồm tất cả thông tin cần thiết. 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 các phần phụ trợ khi cần.
- Lưu trữ trạng thái: Một số khung xử lý cung cấp dữ liệu trung gian duy trì theo cách riêng. 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 đối với một loại xe và 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): Mọi ứng dụng hoặc dịch vụ có thể hưởng lợi từ thay đổi trạng thái được phát hiện đều phải có sẵn. Do đó, việc xuất bản sự kiện tuỳ chỉnh này sang 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 đã 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 cho đội xe chặng cuối" hoặc "Giải pháp cho dịch vụ chở khách và giao hàng 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à "Đích" sẽ 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 đã chọn các dịch vụ sau đây của Google.
Sơ đồ : Sơ đồ sau đây cho thấy dịch vụ của Google Cloud để triển khai giải pháp tham chiếu
Bố cục Dự án trên đám mây
Bạn nên mặc định sử dụng chế độ triển khai nhiều dự án. Điều này là để mức sử dụng Nền tảng Google Maps và Google Cloud có thể được tách biệt rõ ràng và gắn với thoả thuận thanh toán mà bạn chọn.
Nguồn sự kiện
"Last Mile Fleet Solution" (Giải pháp đội xe chặng cuối) và "On-demand Rides and Deliveries Solution" (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 và phản hồi API 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à 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 lập trình.
- Ghi nhật ký | Hiệu suất của đội xe (đối với người dùng LMFS)
- Ghi nhật ký | Tiến trình chuyến đi và đơn đặt hàng (đối với người dùng ODRD)
- Xem nhật ký được định tuyến đến Pub/Sub : Ghi nhật ký → Tổng quan về việc tích hợp Pub/Sub
Bồn rửa bát
Trong Google Cloud, Cloud Pub/Sub là hệ thống gửi tin nhắn gần theo thời gian thực được lựa chọn. Giống như cách các sự kiện từ nguồn được gửi đến Pub/Sub, các sự kiện tuỳ chỉnh cũng được xuất bản đế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 khối xây dựng khác, các thành phần xử lý hoàn toàn không cần máy chủ và có thể mở rộng quy mô tốt 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 ban đầu (*)
- Không cần máy chủ, có thể tăng và giảm quy mô bằng các chế độ kiểm soát quy mô để quản lý chi phí
- Java là ngôn ngữ lập trình được cung cấp khả năng sử dụng 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 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 nguồn và đích
- Tích hợp gần như theo thời gian thực với mức độ liên kết lỏng lẻo
Bạn có thể sử dụng các hàm này ngay lập tứ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 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ự kiến sẽ 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
Để có thể lặp lại, tuỳ chỉnh, kiểm soát mã nguồn và bảo mật quy trình triển khai giải pháp tham chiếu, 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 và có khả năng hỗ trợ phong phú cho Google Cloud.
- Nhà cung cấp Google Cloud Platform: Tài liệu về tài nguyên do "Nhà cung cấp Google Cloud Platform" hỗ trợ
- Các phương pháp hay nhất để sử dụng Terraform: Hướng dẫn chi tiết về cách áp dụng hiệu quả nhất trong Google Cloud
- Terraform Registry: các mô-đun bổ sung được Google và cộng đồng hỗ trợ
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ể dùng lại được triển khai dưới dạng các mô-đun Terraform có thể được 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ể tuỳ chỉnh linh hoạt 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, tham số 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 đá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 trên nhiều dự án.
- Triển khai toàn bộ giải pháp tham chiếu: Gọi 2 mô-đun trước và bao bọc toàn bộ giải pháp.
Bảo mật
IAM được áp dụng để triển khai 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ư tính năng 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 gì Google Cloud cung cấp nhằm giúp bạn kiểm soát bảo mật tốt hơn.
Các hành động tiếp theo
Giờ đây, bạn đã sẵn sàng truy cập và khám phá thêm Giải pháp tham chiếu về sự kiện của đội xe. Truy cập vào GitHub để bắt đầu.
Phụ lục
Thu thập các yêu cầu của bạn
Bạn nên thu thập các yêu cầu của mình 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 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ỉ dựa trên dữ liệu được thu thập hoặc tạo ra trong các dịch vụ của Google 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ó, đó 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 chỉ số 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 hoạt động tổng hợp nào? Cố gắng 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ỏ trong đội xe vào 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 phản hồi) hay để tích hợp lỏng lẻo (tính linh hoạt)?
- Nếu độ trễ thấp, hãy xác định là "thấp". Phút? Giây? Dưới một giây? Độ trễ là bao nhiêu?
- Bạn đã đầu tư vào một bộ 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 có một quy trình tư duy để làm theo. Điều này giúp bạn đưa ra các quyết định nhất quán về thiết kế, đặc biệt là khi bạn có nhiều lựa chọn để chọn.
- Đặt 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, đườ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 mức bạn đã đặt, 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ì điều này thường dẫn đến việc tăng độ phức tạp.
- Điều này cũng áp dụng cho chi phí. Giữ chi phí ở mức hợp lý. Có thể bạn 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 tiền hơn.
- Trong giai đoạn thử nghiệm, việc giảm quy mô có thể quan trọng không kém việc tă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à giảm quy mô (lý tưởng là về 0) để bạn không tốn tiền 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, 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.
- Duy trì các dịch vụ được liên kết lỏng lẻo. Nhờ đó, bạn có thể 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 thể lơ là việc 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, không thể có bất kỳ cửa nào không được bảo mật cho hệ thống.
Các khái niệm về truyền trực tuyến
Nếu bạn mới làm quen với việc xử lý dựa trên sự kiện hoặc xử lý trực tuyến, thì bạn nên biết một số khái niệm chính. Một số khái niệm trong số đó có thể rất khác so với xử lý hàng loạt.
- Quy mô : Khác với 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ể xử lý dữ liệu truyền trực tuyến. Tình trạng tắc nghẽn giao thông trong thành phố có thể đột ngột tạo ra rất nhiều sự kiện từ một khu vực cụ thể và bạn vẫn cần có khả năng xử lý sự kiện đó.
- Phân cửa sổ : 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 "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 cửa sổ, chẳng hạn 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ì thời gian trễ để tạo 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ó 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 khung thời gian để tạo sự kiện, mà thay vào đó, bạn muốn phát ra các kết quả trung 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 chúng sau. Hãy tưởng tượng việc phát trạng thái trung gian khi hoàn thành 25%, 50%, 75% của một lượt phân phối.
- 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 đố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 biết sự khác biệt giữa "thời gian diễn ra sự kiện" (thời điểm sự kiện thực sự diễn 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. Nhìn chung, bạn muốn xử lý các sự kiện dựa trên "thời gian sự kiện".
- Gử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 sẽ có mức độ 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ỏ dữ liệu trùng lặp.
- Tính đầy đủ : Tương tự như việc thay đổi thứ tự, có thể các 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 do vô tình, mất kết nối khi ở trong đường hầm hoặc tin nhắn đã nhận được nhưng chỉ ở 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 chưa phải là danh sách đầy đủ mà chỉ là thông tin giới thiệu. Sau đây là một số tài liệu rất nên đọc 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 bài viết này.
Tác giả chính:
- Mary Pishny | Giám đốc 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