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 theo dõi và thời gian dự kiến đến (ETA) chính xác
  • Giảm chi phí bằng cách xác định và giải quyết những đ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 tài xế để cải thiện hiệu quả
  • Tuân thủ quy định bằng cách theo dõi vị trí 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 nhóm có trên GitHub cũng sẽ đượ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 khảo cho sự kiện nhóm

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 các đối tác và khách hàng 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ả dịch vụ Giao hàng và Đ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 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 cho 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.

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

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 hạng mục cuối cùng của đội ngũ di động" hoặc "Giải pháp gọ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 để chuyển nhật ký lệnh gọi RPC của Fleet Engine thành những 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ý cuộc 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 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. Không phải lúc nào các sự kiện cũng bao gồm tất cả thông tin 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 nên 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 cho các hoạt động tiếp theo là một lựa chọn hợp lý.
  • 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 cho Fleet Events

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. Điều 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 tuyến đường cuối cùng" và "Giải pháp gọi xe và giao hàng theo yêu cầu" ghi yêu cầu API và tải trọng phản hồi vào tính năng Ghi 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. Việc định tuyến sang 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 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 máy chủ và điều chỉnh được quy mô hoạt động 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 đầ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 một cách linh hoạt

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 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 với khả năng hỗ trợ đa dạng dành 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ể tái sử dụng sẽ được triển khai dưới dạng các mô-đun Terraform có thể 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ý 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, 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 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 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 làm 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?
    • Có thể hoàn toàn lấy kết quả từ 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 bạn có bắt buộc phải 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 hay thay vì 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 bạn muốn có độ trễ thấp, 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 một ngăn xếp công nghệ và các kỹ năng liên quan dưới dạng 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 cố gắng đáp ứng tiêu chuẩn 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ì đ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í. Duy trì chi phí 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 đỏ.
  • Trong giai đoạn thử nghiệm, việc giảm quy mô có thể 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 bạn linh hoạt mở rộng quy mô và giảm quy mô (lý tưởng nhất là 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ữ các dịch vụ có kết 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 để mất tính 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 mới sử dụng phương pháp dựa trên sự kiện hoặc truyền trực tuyến, thì bạn cần lưu ý một số khái niệm chính, trong đó có thể rất khác với việc xử lý hàng loạt.

  • Điều chỉnh theo tỷ lệ : Trái ngược với phương pháp xử lý hàng loạt (tức là bạn thường hiểu rõ về lượng dữ liệu cần xử lý), thì khi truyền trực tuyến, bạn không thể xử lý lượng dữ liệu cần xử lý. 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 kiểu máy và cấu hình phù hợp đáp ứng các 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 muốn đợi đến cuối cửa sổ để tạo sự kiện, mà thay vào đó, phát ra các 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 tiên, 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 có liên quan đến hoạt động 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 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ỳ 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. Sau đây là một số nội dung nên đọc để giúp bạn hiểu sâu hơn về từng nội dung.

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