Wydarzenia w czasie rzeczywistym w Fleet Engine

Sygnały z floty działającej w terenie, które są przesyłane w czasie zbliżonym do rzeczywistego, są przydatne dla firm na wiele sposobów. Firmy mogą na przykład używać tych funkcji, aby:

  • monitorować wydajność floty i wcześnie wykrywać potencjalne problemy;
  • poprawić obsługę klienta dzięki podawaniu dokładnych szacowanych czasów dotarcia na miejsce i informacji o śledzeniu przesyłek;
  • obniżyć koszty dzięki identyfikowaniu i eliminowaniu nieefektywnych działań;
  • Zwiększ bezpieczeństwo, monitorując zachowanie kierowców i identyfikując potencjalne zagrożenia.
  • optymalizować trasy i harmonogramy kierowców, aby zwiększyć wydajność;
  • Zgodność z przepisami dzięki śledzeniu lokalizacji pojazdu i godzin pracy

Ten dokument pokazuje, jak deweloperzy mogą przekształcać sygnały z usług mobilności Google Maps Platform (Last Mile Fleet Solution (LMFS) lub On-demand Rides and Deliveries Solution (ODRD)) w przydatne zdarzenia niestandardowe. Omówimy też kluczowe pojęcia i decyzje projektowe dotyczące rozwiązania referencyjnego zdarzeń floty dostępnego na GitHubie.

Ten dokument dotyczy:

  • Architekci znający „usługi mobilności” Google Maps Platform i jeden z ich podstawowych komponentów, czyli „Fleet Engine”. Jeśli dopiero zaczynasz korzystać z „usług mobilności”, zalecamy zapoznanie się z rozwiązaniem ostatniej mili lub rozwiązaniem do przejazdów i dostaw na żądanie, w zależności od Twoich potrzeb.
  • Architekci znający Google Cloud. Jeśli dopiero zaczynasz korzystać z Google Cloud, zalecamy zapoznanie się z artykułem Tworzenie potoków danych strumieniowych w Google Cloud.
  • Jeśli kierujesz reklamy na inne środowiska lub stosy oprogramowania, skup się na zrozumieniu punktów integracji Fleet Engine i najważniejszych kwestii, które powinny być nadal aktualne.
  • osoby, które chcą dowiedzieć się, jak można generować i wykorzystywać zdarzenia z flot.

Po przeczytaniu tego dokumentu będziesz mieć podstawową wiedzę o kluczowych elementach i kwestiach związanych z systemem strumieniowego przesyłania danych, a także o elementach składowych Google Maps Platform i Google Cloud, które tworzą rozwiązanie referencyjne zdarzeń floty.

Omówienie rozwiązania referencyjnego dotyczącego zdarzeń floty

Rozwiązanie referencyjne zdarzeń floty to rozwiązanie open source, które umożliwia klientom i partnerom korzystającym z usług mobilności generowanie kluczowych zdarzeń na podstawie komponentów Fleet Engine i Google Cloud. Obecnie rozwiązanie referencyjne obsługuje klientów korzystających z rozwiązania Last Mile Fleet Solution, a w przyszłości będzie obsługiwać przejazdy i dostawy na żądanie.

Rozwiązanie automatycznie generuje zdarzenia na podstawie zmian w określonych danych powiązanych z zadaniami lub przejazdami. Możesz używać tych zdarzeń do wysyłania powiadomień, takich jak te poniżej, do zainteresowanych osób lub do wywoływania innych działań dotyczących floty.

  • Zmiana szacowanego czasu dotarcia na miejsce w przypadku zadania
  • Względna zmiana szacowanego czasu dotarcia na miejsce w przypadku przybycia do zadania
  • Czas pozostały do przybycia zadania
  • Odległość do miejsca realizacji zadania
  • Zmiana stanu TaskOutcome

Każdy komponent rozwiązania referencyjnego można dostosować do potrzeb firmy.

Logiczne elementy składowe

Diagram : poniższy diagram przedstawia ogólne elementy składowe, które tworzą rozwiązanie referencyjne zdarzeń floty.

Omówienie zdarzeń floty i logiczne elementy składowe

Rozwiązanie referencyjne zawiera te komponenty:

  • Źródło zdarzenia: skąd pochodzi pierwotny strumień zdarzeń. Zarówno Last Mile Fleet Solution, jak i On-demand Rides and Deliveries Solution są zintegrowane z Cloud Logging, co pomaga przekształcać logi wywołań RPC Fleet Engine w strumienie zdarzeń dostępne dla deweloperów. To jest podstawowe źródło, z którego należy korzystać.
  • Przetwarzanie: nieprzetworzone rejestry połączeń RPC są konwertowane na zdarzenia zmiany stanu w tym bloku, który wykonuje obliczenia na strumieniu zdarzeń dziennika. Aby wykryć taką zmianę, ten komponent wymaga magazynu stanu, dzięki któremu nowe zdarzenia przychodzące można porównać z poprzednimi. Zdarzenia nie zawsze zawierają wszystkie interesujące informacje. W takich przypadkach ten blok może w razie potrzeby wykonywać wywołania wyszukiwania do backendów.
    • Magazyn stanu: niektóre platformy przetwarzania udostępniają dane pośrednie, które są trwałe same w sobie. Jeśli nie, to aby samodzielnie przechowywać stan, ponieważ powinien on być unikalny dla pojazdu i typu zdarzenia, dobrze sprawdzi się usługa trwałości danych typu klucz-wartość.
  • Ujście (zdarzenia niestandardowe): wykryta zmiana stanu powinna być udostępniana każdej aplikacji lub usłudze, która może z niej skorzystać. Dlatego naturalnym wyborem jest opublikowanie tego zdarzenia niestandardowego w systemie dostarczania zdarzeń do wykorzystania na dalszych etapach.
  • Usługa podrzędna: kod, który wykorzystuje wygenerowane zdarzenia i podejmuje działania unikalne dla Twojego przypadku użycia.

Wybór usługi

Jeśli chodzi o wdrażanie rozwiązania referencyjnego dla Last Mile Fleet Solution lub On-demand Rides and Deliveries Solution (dostępnego pod koniec III kwartału 2023 r.), wybór technologii dla „Źródła” i „Ujścia” jest prosty. Z kolei „Przetwarzanie” ma szeroki zakres opcji. W rozwiązaniu referencyjnym wybrano te usługi Google.

Diagram : poniższy diagram przedstawia usługę Google Cloud, która służy do wdrażania rozwiązania referencyjnego.

Komponenty rozwiązania referencyjnego zdarzeń floty

Układ projektu w chmurze

Zalecamy domyślne wdrażanie w wielu projektach. Dzięki temu wykorzystanie Google Maps Platform i Google Cloud można wyraźnie rozdzielić i powiązać z wybraną umową rozliczeniową.

Źródło zdarzeń

„Rozwiązanie dla floty ostatniej mili” i „Rozwiązanie do przejazdów i dostaw na żądanie” zapisują żądania do interfejsu API i odpowiedzi w Cloud Logging. Cloud Logging dostarcza logi do co najmniej 1 wybranej usługi. Kierowanie do Cloud Pub/Sub jest w tym przypadku idealnym rozwiązaniem, ponieważ umożliwia konwertowanie logów na strumień zdarzeń bez konieczności kodowania.

Ujście

W Google Cloud Cloud Pub/Sub jest preferowanym systemem dostarczania wiadomości w czasie zbliżonym do rzeczywistego. Podobnie jak zdarzenia ze źródła były dostarczane do Pub/Sub, zdarzenia niestandardowe są również publikowane w Pub/Sub do wykorzystania w dalszych procesach.

Przetwarzam

W przetwarzaniu zdarzeń biorą udział te komponenty: Podobnie jak inne elementy składowe, komponenty przetwarzania są całkowicie bezserwerowe i dobrze się skalują zarówno w górę, jak i w dół.

  • Cloud Functions jako platforma obliczeniowa dla pierwszej wersji (*)
    • Bezserwerowa, skaluje się w górę i w dół za pomocą ustawień skalowania, aby zarządzać kosztami
    • Java jako język programowania ze względu na dostępność bibliotek klienta dla interfejsów API związanych z Fleet Engine, które ułatwiają implementację.
  • Cloud Firestore jako magazyn stanu
    • Bezserwerowy magazyn kluczy-wartości
  • Cloud Pub/Sub jako punkt integracji z komponentami nadrzędnymi i podrzędnymi
    • Luźno sprzężona integracja w czasie zbliżonym do rzeczywistego

Funkcji można używać w niezmienionej postaci z ustawieniami domyślnymi, ale można je też ponownie skonfigurować. Parametry konfiguracji są ustawiane za pomocą skryptów wdrażania i są szczegółowo opisane w plikach README odpowiednich modułów Terraform.

*Uwaga: w ramach tego rozwiązania referencyjnego planujemy udostępnić alternatywne implementacje, które mogą pomóc w spełnieniu różnych wymagań.

Wdrożenie

Aby proces wdrażania rozwiązania referencyjnego był powtarzalny, konfigurowalny, bezpieczny i umożliwiał kontrolę kodu źródłowego, jako narzędzie do automatyzacji wybrano Terraform. Terraform to powszechnie stosowane narzędzie IaC (infrastruktura jako kod) z rozbudowaną obsługą Google Cloud.

Moduły Terraform

Zamiast tworzyć jeden duży, monolityczny moduł wdrażania rozwiązania referencyjnego, wielokrotnego użytku bloki automatyzacji są wdrażane jako moduły Terraform, których można używać niezależnie. Moduły udostępniają szeroki zakres zmiennych, które można konfigurować. Większość z nich ma wartości domyślne, dzięki czemu można szybko rozpocząć pracę, ale można je też dostosować do własnych potrzeb i preferencji.

Moduły zawarte w rozwiązaniu referencyjnym:

  • Konfiguracja logowania Fleet Engine: automatyzacja konfiguracji związanych z Cloud Logging do użytku z Fleet Engine. W rozwiązaniu referencyjnym służy do kierowania logów związanych z Fleet Engine do określonego tematu Pub/Sub.
  • Wdrożenie funkcji w Cloud Functions dotyczącej zdarzeń floty: zawiera wdrożenie przykładowego kodu funkcji, a także obsługuje automatyzację ustawień zbiorów uprawnień wymaganych do bezpiecznej integracji między projektami.
  • Wdrożenie całego rozwiązania referencyjnego: wywołuje 2 poprzednie moduły i obejmuje całe rozwiązanie.

Bezpieczeństwo

Uprawnienia są stosowane w celu wdrożenia zasady jak najmniejszych uprawnień oraz sprawdzonych metod Google Cloud dotyczących bezpieczeństwa, takich jak przyjęcie tożsamości konta usługi. Zapoznaj się z tymi artykułami, aby dowiedzieć się więcej o tym, co oferuje Google Cloud, aby zapewnić Ci większą kontrolę nad bezpieczeństwem.

Następne działania

Możesz teraz uzyskać dostęp do rozwiązania referencyjnego dotyczącego zdarzeń we flocie i zapoznać się z nim. Aby rozpocząć, wejdź na GitHub.

Dodatek

Gromadzenie wymagań

Zalecamy zebranie wymagań na wcześniejszym etapie procesu.

Najpierw podaj szczegółowe informacje o tym, dlaczego interesują Cię zdarzenia w czasie zbliżonym do rzeczywistego lub dlaczego musisz z nich korzystać. Oto kilka pytań, które pomogą Ci określić Twoje potrzeby.

  • Jakie informacje są wymagane, aby strumień zdarzeń był przydatny?
    • Czy wynik można uzyskać wyłącznie na podstawie danych zebranych lub wygenerowanych w usługach Google? A może wymagane jest wzbogacanie danych za pomocą zintegrowanych systemów zewnętrznych? Jeśli tak, to jakie to systemy i jakie interfejsy integracji oferują?
    • Jakie dane chcesz mierzyć jako firma? Jak są definiowane?
    • Jeśli chcesz obliczyć dane dla różnych zdarzeń, jakiego rodzaju agregacji będziesz potrzebować? Spróbuj przedstawić logiczne kroki. (np. Porównaj szacowany czas dotarcia na miejsce i rzeczywisty czas dotarcia na miejsce z celami SLO w podzbiorze floty w godzinach największego zapotrzebowania, aby obliczyć wydajność przy ograniczeniach zasobów).
  • Dlaczego interesuje Cię model oparty na zdarzeniach, a nie na zbiorach? Czy chodzi o mniejsze opóźnienie (czas do działania) czy o luźno powiązaną integrację (elastyczność)?
    • Jeśli chodzi o małe opóźnienie, zdefiniuj, co oznacza „małe”. Minuty? Sekundy? Mniej niż sekunda? A co z opóźnieniem?
  • Czy Twój zespół zainwestował już w stos technologiczny i powiązane umiejętności? Jeśli tak, co to za system i jakie punkty integracji udostępnia?
    • Czy istnieją jakieś wymagania, których Twoje obecne systemy nie są w stanie spełnić lub które mogą sprawiać trudności podczas przetwarzania zdarzeń pochodzących z floty?

Zasady projektowania

Zawsze warto mieć jakiś proces myślowy, który można śledzić. Pomaga to podejmować spójne decyzje projektowe, zwłaszcza gdy masz do wyboru wiele opcji.

  • Domyślnie wybieraj prostsze opcje.
  • Domyślnie krótszy czas do uzyskania wartości. Mniej kodu, łatwiejsza nauka.
  • W przypadku czasu oczekiwania i wydajności staraj się osiągnąć wyznaczony poziom, a nie maksymalną optymalizację. Unikaj też ekstremalnej optymalizacji, ponieważ często prowadzi ona do zwiększenia złożoności.
  • To samo dotyczy kosztu. Utrzymuj koszty na rozsądnym poziomie. Możesz jeszcze nie być na etapie, na którym możesz zobowiązać się do korzystania z wartościowych, ale stosunkowo droższych usług.
  • W fazie eksperymentalnej skalowanie w dół może być równie ważne jak skalowanie w górę. Rozważ platformę, która zapewnia elastyczność skalowania w górę z limitem, a także skalowania w dół (najlepiej do zera), dzięki czemu nie ponosisz kosztów, gdy nic nie robisz. Wysoką wydajność dzięki infrastrukturze zawsze włączonej można rozważyć na późniejszym etapie, gdy będziesz mieć pewność co do jej potrzeb.
  • Obserwuj i mierz, aby później określić, nad czym jeszcze trzeba popracować.
  • Utrzymuj luźne powiązania między usługami. Ułatwia to późniejszą wymianę poszczególnych elementów.
  • Ważna uwaga na koniec: zabezpieczenia nie mogą być luźne. Usługa działająca w środowisku chmury publicznej nie może mieć żadnych niezabezpieczonych drzwi do systemu.

Pojęcia związane ze strumieniowym przesyłaniem danych

Jeśli dopiero zaczynasz korzystać z przetwarzania opartego na zdarzeniach lub strumieniowego, warto poznać kluczowe pojęcia, z których niektóre mogą się bardzo różnić od przetwarzania wsadowego.

  • Skala : w przeciwieństwie do przetwarzania wsadowego, gdzie zwykle masz dobre pojęcie o ilości danych do przetworzenia, w przypadku strumieniowania nie jest to możliwe. Korek w mieście może nagle wygenerować wiele zdarzeń na danym obszarze, a Ty musisz być w stanie je przetworzyć.
  • Okno : zamiast przetwarzać zdarzenia pojedynczo, często chcesz pogrupować zdarzenia na osi czasu w mniejsze „okna” jako jednostkę obliczeniową. Istnieją różne strategie okien, takie jak „stałe okna (np. każdy dzień kalendarzowy)”, „przesuwane okna (ostatnie 5 minut)”, „okna sesji (podczas tej podróży)”, z których należy wybrać odpowiednią. Im dłuższe okno, tym dłuższe opóźnienia w generowaniu wyników. Wybierz model i konfigurację, które odpowiadają Twoim wymaganiom.
  • Aktywacja : w niektórych przypadkach nie masz innego wyboru, jak tylko użyć stosunkowo długich okien. Nie chcesz jednak czekać na koniec okna, aby wygenerować zdarzenia, ale wolisz emitować wyniki pośrednie. Tę koncepcję można wdrożyć w przypadkach, gdy warto najpierw zwrócić szybkie wyniki, a później je poprawić. Wyobraź sobie, że stan pośredni jest emitowany przy 25%, 50% i 75% realizacji dostawy.
  • Kolejność : zdarzenia nie muszą docierać do systemu w kolejności, w jakiej zostały wygenerowane. Dotyczy to zwłaszcza przypadków użycia, w których komunikacja odbywa się przez sieci komórkowe, co powoduje opóźnienia i złożone ścieżki routingu. Musisz znać różnicę między „czasem zdarzenia” (kiedy zdarzenie faktycznie miało miejsce) a „czasem przetwarzania” (kiedy zdarzenie dotarło do systemu) i odpowiednio obsługiwać zdarzenia. Zasadniczo zdarzenia powinny być przetwarzane na podstawie „czasu zdarzenia”.
  • Dostarczanie wiadomości – co najmniej raz a dokładnie raz: różne platformy zdarzeń obsługują te opcje w różny sposób. W zależności od przypadku użycia musisz rozważyć strategie ponawiania prób lub deduplikacji.
  • Kompletność : podobnie jak w przypadku zmiany kolejności, istnieje ryzyko utraty wiadomości. Może to być spowodowane wyłączeniem aplikacji i urządzenia z powodu rozładowania baterii, niezamierzonym uszkodzeniem telefonu, utratą połączenia w tunelu lub otrzymaniem wiadomości, ale tylko poza akceptowalnym oknem. Jak niekompletność wpłynęłaby na wyniki?

To nie jest pełna lista, ale wprowadzenie. Oto kilka polecanych artykułów, które pomogą Ci lepiej zrozumieć te zagadnienia.

Współtwórcy

Google zarządza tym dokumentem. Został on napisany przez tych współtwórców.

Główni autorzy: