Tín hiệu gần như theo thời gian thực từ các nhóm thiết bị đang hoạt động trên mặt đất hữu ích đối với doanh nghiệp theo một số cách. Ví dụ: doanh nghiệp có thể sử dụng những dữ liệu này để:
- Theo dõi hiệu suất của nhóm thiết bị và xác định các vấn đề tiềm ẩn ngay từ đầu
- Cải thiện dịch vụ khách hàng bằng cách cung cấp thời gian đến dự kiến (ETA) và thông tin theo dõi chính xác
- Giảm chi phí bằng cách xác định và giải quyết các hoạt động kém hiệu quả
- Cải thiện độ 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ế để cải thiện hiệu suất
- Tuân thủ quy định bằng cách theo dõi vị trí của xe và giờ bảo dưỡng
Tài liệu này minh hoạ cách nhà phát triển có thể biế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 nhóm cuối dặm" (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ể 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 được đề cập.
Tài liệu này liên quan đến:
- Các 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". Đối với những người mới làm quen với "Dịch vụ di chuyển", bạn nên làm quen với Giải pháp Last Mile Fleet và/hoặc Giải pháp gọi xe và giao hàng theo yêu cầu, tuỳ theo nhu cầu của bạn.
- Các kiến trúc sư quen thuộc với Google Cloud. Đối với người mới sử dụng Google Cloud, Xây dựng quy trình dữ liệu truyền trực tuyến trên Google Cloud là điều nên đọc trước khi đọc.
- 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 của Fleet Engine và các điểm chính cần cân nhắc (vẫn áp dụng được).
- Những người có chung sở thích muốn khám phá cách tạo và sử dụng các sự kiện trong các nhóm thiết bị.
Ở cuối tài liệu này, bạn sẽ nắm được kiến thức cơ bản về các yếu tố chính và những điểm 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 khối dựng từ Nền tảng Google Maps và Google Cloud để tạo nên Giải pháp tham khảo sự kiện cho nhóm.
Tổng quan về giải pháp tham khảo sự kiện cho nhóm thiết bị
Giải pháp tham chiếu sự kiện của nhóm là một giải pháp nguồn mở cho phép khách hàng và đối tác sử dụng tính năng di động tạo các sự kiện chính trên Fleet Engine và các thành phần của Google Cloud. Hiện nay, giải pháp tham chiếu này hỗ trợ những khách hàng sử dụng Giải pháp quy trình cuối cùng. Ngoài ra, giải pháp này còn hỗ trợ các dịch vụ 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 các thay đổi đối với dữ liệu cụ thể liên quan đến các việc cần làm 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ư các nội dung sau đây cho các bên liên quan hoặc kích hoạt các hành động khác cho nhóm thiết bị của bạn.
- Thay đổi ETA cho việc đến nơi
- Thay đổi ETA tương đối khi việc đến nơi
- Thời gian còn lại để đến nhiệm vụ
- Khoảng cách còn lại đến khi đến việc cần làm
- Thay đổi trạng thái của 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.
Khối xây dựng logic
Biểu đồ : Sơ đồ sau đây cho thấy các khối bản dựng cấp cao tạo nên giải pháp tham chiếu Sự kiện của nhóm thiết bị
Giải pháp tham chiếu chứa các thành phần sau:
- Nguồn sự kiện: Nguồn của luồng sự kiện gốc. Cả "Giải pháp nhóm máy bay cuối cùng" hoặc "Giải pháp đ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 nhằm giúp chuyển nhật ký cuộc gọi RPC của Fleet Engine thành các luồng sự kiện dành 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 sắp tới mới với các sự kiện trước đó nhằm phát hiện thay đổi. Không phải lúc nào sự kiện 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 tra cứu các lệnh gọi đến phần phụ trợ nếu cần.
- Kho lưu trữ trạng thái: Một số khung xử lý tự cung cấp dữ liệu trung gian ổn định. 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 dành riêng cho xe và loại sự kiện, thì dịch vụ lưu trữ dữ liệu kiểu K-V là lựa chọn 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ừ sự kiện đó. Do đó, việc phát hành sự kiện tuỳ chỉnh này lên một hệ thống phân phối sự kiện để tiêu thụ trong quá trình phát triển là một lựa chọn tự nhiên.
- Dịch vụ xuôi dòng: Mã sử dụng các sự kiện được tạo và lấy 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 nhóm hàng dặm cuối cùng" hoặc "Giải pháp gọi xe và giao hàng theo yêu cầu" (ra mắt cuối quý 3 năm 2023), việc lựa chọn công nghệ cho "Nguồn" và "Sink '" rất đơn giản. Mặt khác, "Đang xử lý" có nhiều tuỳ chọn. Giải pháp tham chiếu đã chọn các dịch vụ sau đây của Google.
Biểu đồ : Sơ đồ dưới đây minh hoạ 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 triển khai nhiều dự án. Việc này giúp các khoản chi tiêu trên Nền tảng Google Maps và Google Cloud có thể được tách biệt một cách rõ ràng và 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 "Last Mile Fleet" và "Giải pháp gọi xe và giao hàng theo yêu cầu" ghi các tải trọng dữ liệu yêu cầu API và phản hồi vào tính năng Ghi nhật ký trên đám mây. Tính năng Ghi nhật ký trên đám mây phân phối nhật ký cho 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 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.
- Ghi nhật ký | Hiệu suất của nhóm (dành cho người dùng LMFS)
- Ghi nhật ký | Tiến trình chuyến đi và đặt hàng (dành cho người dùng ODRD)
- Xem nhật ký được định tuyến đến Pub/Sub : Ghi nhật ký → Tổng quan về quá trình 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 như theo thời gian thực mà bạn 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, sự kiện tuỳ chỉnh cũng được xuất bản lên Pub/Sub để tiêu thụ theo sau.
Đ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 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 quy mô cả lên và xuống.
- Cloud Functions là một nền tảng điện toán cho bản phát hành đầu tiên (*)
- Mô hình không máy chủ, có thể tăng và giảm quy mô nhờ các chế độ kiểm soát mở rộng để quản lý chi phí
- Java làm 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 Fleet Engine, góp phần giúp dễ dàng triển khai
- Cloud Firestore dưới dạng một 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 xuôi và ngược
- Tích hợp thời gian thực gần như kết hợp lỏng lẻo
Các hàm có thể được sử 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 đặt thông qua các 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 và bảo mật bằng mã nguồn, Terraform được chọn làm công cụ tự động hoá. Terraform là công cụ IaC (Cơ sở hạ tầng dưới dạng mã) được sử dụng rộng rãi và có nhiều khả năng hỗ trợ Google Cloud.
- Nhà cung cấp Google Cloud Platform: Tài liệu về tài nguyên được "Nhà cung cấp Google Cloud Platform" hỗ trợ
- Các phương pháp hay nhất để sử dụng Teraform: Hướng dẫn đa dạng về cách sử 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ể tái sử dụng sẽ đượ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 trong số đó có giá trị mặc định để bạn có thể bắt đầu nhanh chóng nhưng cũng có khả năng tuỳ chỉnh linh hoạt dựa trên nhu cầu và lựa chọn ưu tiên của bạn.
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 tính năng Ghi nhật ký đám mây để sử dụng với Fleet Engine. Trong giải pháp tham chiếu, hàm 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.
- Cần triển khai chức năng đám mây cho nhóm Sự kiện: Chứa hoạt động triển khai mã hàm mẫu, đồng thời xử lý hoạt động tự động hoá các chế độ cài đặt quyền cần thiết để tích hợp nhiều dự án một cách an toàn.
- Triển khai giải pháp tham chiếu toàn bộ: Gọi 2 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 đặ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 tính năng mà Google Cloud cung cấp nhằm giúp bạn kiểm soát chặt chẽ hơn tính 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 Giải pháp tham khảo về sự kiện của nhóm. 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 của mình sớm hơn trong quá trình này.
Trước tiên, hãy thu thập 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 hiểu rõ nhu cầu của mình.
- Thông tin nào bắt buộc phải có để luồng sự kiện trở nên hữu ích?
- Có thể kết quả chỉ lấy 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 việc làm phong phú dữ liệu bằng các hệ thống tích hợp bên ngoài có bắt buộc không? Nếu có, những hệ thống đó là gì 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? Chúng được xác định như thế nào?
- Nếu cần tính toán các chỉ số trên các sự kiện, bạn sẽ cần loại tổng hợp nào? Cố gắng sắp xếp các bước hợp lý. (ví dụ: So sánh ETA/ATA với SLO trên một phương diện của nhóm thiết bị trong giờ cao điểm để tính toán hiệu suất theo các 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ô? Đây là dành cho độ trễ thấp hơn (thời gian hành động) hay để tích hợp kết nối lỏng lẻo (độ linh hoạt)?
- Nếu độ trễ thấp, hãy định nghĩa "thấp". Phút? Giây? Dưới giây? Và độ trễ là bao nhiêu?
- Với tư cách là một đội, bạn đã đầu tư vào một nhóm công nghệ và các kỹ năng liên quan chưa? Nếu có thì công cụ này là gì và nó mang lại những điểm tích hợp nào?
- Có yêu cầu nào mà các 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ý sự kiện đến từ nhóm thiết bị không?
Nguyên tắc thiết kế
Việc có quá trình suy nghĩ nào đó luôn hữu ích để 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 tuỳ chọn đơn giản hơn.
- Mặc định là thời gian đến giá trị ngắn hơn. Ít lập trình hơn, khó nắm bắt kiến thức hơn.
- Để có độ trễ và hiệu suất, hãy cố gắng đạt được mục tiêu mà bạn đã đặt ra, không phải tối ưu hoá ở mức tối đa. Ngoài ra, hãy tránh tối ưu hoá quá mức vì việc này thường dẫn đến việc tăng độ phức tạp.
- Chi phí cũng vậy. Duy trì chi phí hợp lý. Có thể bạn chưa đạt đến trạng thái mà mình 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 giảm 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 bạn linh hoạt mở rộng quy mô với giới hạn tối đa và cũng giảm quy mô (tốt nhất là bằng 0) để bạn không tốn chi phí trong khi không làm gì cả. Hiệu suất cao với cơ sở hạ tầng luôn hoạt động có thể được cân nhắc trong tương lai, khi bạn đã tin tưởng vào 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 việc cần làm tiếp theo.
- Duy trì kết nối lỏng lẻo cho các dịch vụ. Thao tá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, tính bảo mật không được tháo rời. Vì là một dịch vụ chạy trên môi trường đám mây công cộng, nên hệ thống không thể có bất kỳ cánh cửa nào không an toàn.
Khái niệm phát trực tuyến
Nếu bạn mới sử dụng tính năng phát trực tuyến dựa trên sự kiện hoặc phát trực tuyến, thì có một số khái niệm chính mà bạn nên lưu ý. Một số khái niệm trong số đó có thể rất khác với quá trình xử lý hàng loạt.
- Scale (Điều chỉnh quy mô): Trái ngược với quy trình xử lý hàng loạt, trong đó bạn thường nắm rõ lượng dữ liệu cần xử lý, nhưng khi truyền trực tuyến thì bạn không thể. Tắc nghẽn giao thông trong một thành phố có thể tạo ra rất nhiều sự kiện đột ngột từ một khu vực cụ thể và bạn vẫn cần phải xử lý được sự kiện đó.
- Cửa sổ : Thay vì xử lý từng sự kiện, thông thường, bạn sẽ muốn nhóm các sự kiện trên dòng thời gian vào các "cửa sổ" nhỏ hơn để làm đơn vị tính toán. Có nhiều chiến lược điều chỉnh khung thời gian, chẳng hạn như "cửa sổ cố định (ví dụ: mỗi ngày theo lịch)", "cửa sổ trượt (5 phút qua)", "thời lượng 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ì việc tạo kết quả càng chậm trễ. Chọn đúng kiểu máy và cấu hình đá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ó một khoảng thời gian tương đối dài. Tuy nhiên, bạn không nên đợi đến khi kết thúc cửa sổ để tạo sự kiện mà thay vào đó, hãy phát 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 mà trong đó giá trị này có giá trị trong việc trả về kết quả nhanh trước tiên và sau đó sửa kết quả. Hãy tưởng tượng phát ra trạng thái trung gian khi hoàn thành 25%, 50%, 75% việc phân phối.
- Sắp xếp : Các sự kiện không nhất thiết đế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 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ý 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 diễn ra sự kiện".
- Gửi tin nhắn – Ít nhất một lần so với Chỉ một lần: Các nền tảng sự kiện khác nhau sẽ có sự hỗ trợ khác nhau cho những sự kiện này. Tuỳ thuộc vào 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 đủ : Cũng giống như việc thay đổi thứ tự, có khả năng tin nhắn sẽ bị mất. Nguyên nhân 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 điện thoại ngoài ý muốn, mất kết nối khi đang ở trong đường hầm hoặc một thông báo đã nhận được nhưng chỉ ở bên ngoài cửa sổ được chấp nhận. Việc thiếu thông tin sẽ ảnh hưởng 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 mà bạn nên đọc để hiểu rõ hơn về từng bài viết.
Người đóng góp
Google lưu giữ tài liệu này. Những cộng tác viên sau đây ban đầu đã viết bài đăng 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