Sahada çalışan filodan gelen gerçek zamanlıya yakın sinyaller, işletmeler için birçok açıdan faydalıdır. Örneğin, işletmeler bu raporları şu amaçlarla kullanabilir:
- Filolarının performansını izleyebilir ve olası sorunları erken tespit edebilir
- Doğru tahmini varış zamanları ve takip bilgileri sağlayarak müşteri hizmetlerini iyileştirin
- Verimli olmayan noktaları tespit edip gidererek maliyetleri azaltma
- Sürücünün davranışını izleyerek ve olası tehlikeleri tespit ederek güvenliği artırın
- Verimliliği artırmak için sürücü rotalarını ve programlarını optimize edin
- Araç konumunu ve çalışma saatlerini izleyerek düzenlemelere uyma
Bu belgede, geliştiricilerin Google Haritalar Platformu'nun "Mobilite hizmetlerinden" gelen sinyalleri ("Son Mil Filo Çözümü" (LMFS) veya "Araç Çağırma ve Teslimat Çözümü" (ODRD)) işlem yapılabilir özel etkinliklere nasıl dönüştürebileceği gösterilmektedir. GitHub'da bulunan Fleet Events Reference Solution'un temel kavramları ve tasarım kararları da ele alınmaktadır.
Bu belgenin konusu:
- Google Haritalar Platformu'nun "Mobilite hizmetleri" ve temel bileşenlerinden biri olan "Fleet Engine" hakkında bilgi sahibi mimarlar. "Mobilite hizmetlerine" yeni başlayanlar için ihtiyaçlarınıza bağlı olarak Son Mil Filo Çözümü ve/veya Araç Talep Et ve Teslimat Çözümü hakkında bilgi edinmenizi öneririz.
- Google Cloud'a aşina mimarlar. Google Cloud'da yeni olanlar için Google Cloud'da veri akışı ardışık düzenleri oluşturma başlıklı makaleyi okumanızı öneririz.
- Diğer ortamları veya yazılım yığınlarını hedefliyorsanız Fleet Engine'ın entegrasyon noktalarını ve önemli hususları anlamaya odaklanın. Bunlar, hâlâ geçerlidir.
- Filolardaki etkinliklerin nasıl oluşturulup kullanılabileceğini keşfetmeye genel olarak ilgi duyanlar.
Bu dokümanın sonuna geldiğinizde, bir akış sisteminin temel öğeleri ve dikkat edilmesi gereken noktalar hakkında temel bir bilgi edinmiş olacaksınız. Ayrıca, Fleet Events Referans Çözümü'nü oluşturan Google Haritalar Platformu ve Google Cloud yapı taşlarını da öğreneceksiniz.
Filo Etkinlikleri Referans Çözümüne Genel Bakış
Fleet Events Reference Solution, Mobility müşterilerinin ve iş ortaklarının Fleet Engine ile Google Cloud bileşenlerinin üzerine önemli etkinlikler oluşturmasını sağlayan açık kaynak bir çözümdür. Referans çözüm şu anda son mil filo çözümünü kullanan müşterileri desteklemektedir. Talep üzerine araç çağırma ve teslimat için destek de yakında eklenecektir.
Çözüm, görevler veya gezilerle ilişkili belirli verilerdeki değişikliklere göre otomatik olarak etkinlikler oluşturur. Aşağıdakiler gibi bildirimleri paydaşlara göndermek veya filonuz için başka işlemleri tetiklemek üzere bu etkinlikleri kullanabilirsiniz.
- Görev varışıyla ilgili tahmini varış zamanı değişikliği
- Görev varışıyla ilgili göreli tahmini varış zamanı değişikliği
- Görevin bitimine kalan süre
- Göreve varmak için kalan mesafe
- TaskOutcome durumu değişikliği
Referans çözümün her bir bileşeni, işletmenizin ihtiyaçlarına uyacak şekilde özelleştirilebilir.
Mantıksal yapı taşları
Şema : Aşağıdaki şemada, Fleet Events referans çözümünü oluşturan üst düzey yapı taşları gösterilmektedir.
Referans çözüm aşağıdaki bileşenleri içerir:
- Etkinlik Kaynağı: Orijinal etkinlik akışının kaynağı. Hem "Son Aşama Filo Çözümü" hem de "İsteğe Bağlı Yolculuk ve Teslimat Çözümü", Fleet Engine RPC çağrı günlüklerini geliştiricilerin kullanabileceği etkinlik akışlarına dönüştürmeye yardımcı olan Cloud Logging ile entegrasyona sahiptir. Bu, temel kaynaktır.
- İşleme: Ham RPC arama günlükleri, bir günlük etkinliği akışı üzerinde hesaplama yapan bu blok içinde durum değişikliği etkinliklerine dönüştürülür. Bu tür bir değişikliği algılamak için bu bileşenin bir durum deposu gerekir. Böylece, gelen yeni etkinliklerin öncekilerle karşılaştırılmasıyla değişiklik algılanabilir. Etkinlikler her zaman ilgilenilen
tüm bilgileri içermeyebilir. Bu tür durumlarda, bu blok gerektiğinde arka uçlara arama çağrıları gönderebilir.
- Durum deposu: Bazı işleme çerçeveleri, kendi başına kalıcı olan ara veriler sağlar. Ancak böyle bir durum söz konusu değilse durumu kendi başınıza depolamak için, bunların bir araca ve etkinlik türüne özel olması gerektiğinden, K-V türü veri kalıcılığı hizmeti uygundur.
- Alıcı (Özel Etkinlikler): Tespit edilen durum değişikliği, bundan yararlanabilecek tüm uygulama veya hizmetlere sunulmalıdır. Bu nedenle, bu özel etkinliği yayın akışı tüketimi için bir etkinlik yayınlama sistemine yayınlamak doğal bir seçimdir.
- Aşağı akış hizmeti: Oluşturulan etkinlikleri kullanan ve kullanım alanınıza özgü işlemler yapan kod.
Hizmet seçimi
"Son Mil Filo Çözümü" veya "Araç Talebi ve Teslimat Çözümü" (3. çeyreğin sonlarında kullanıma sunulacak) referans çözümünü uygulama konusunda "Kaynak" ve "Hedef" için teknoloji seçimi basittir. Öte yandan, "İşleniyor" bölümünde çok çeşitli seçenekler bulunur. Referans çözümde aşağıdaki Google hizmetleri seçilmiştir.
Şema : Aşağıdaki şemada, referans çözümü uygulamak için kullanılan Google Cloud hizmeti gösterilmektedir.
Cloud projesi düzeni
Varsayılan olarak çok projeli dağıtım kullanmanızı öneririz. Bu, Google Haritalar Platformu ve Google Cloud tüketimlerinin net bir şekilde ayrılabilmesi ve tercih ettiğiniz faturalandırma düzenlemenize bağlanabilmesi içindir.
Etkinlik Kaynağı
"Son Aşama Filo Çözümü" ve "İsteğe Bağlı Yolculuklar ve Teslimat Çözümü", API isteklerini ve yanıt yüklerini Cloud Logging'e yazar. Cloud Logging, günlükleri seçtiğiniz bir veya daha fazla hizmete gönderir. Cloud Pub/Sub'a yönlendirme burada mükemmel bir seçenektir ve günlüklerin kodlama olmadan etkinlik akışına dönüştürülmesini sağlar.
- Günlük kaydı | Filo Performansı (LMFS kullanıcıları için)
- Günlük Kaydı | Gezi ve Sipariş İlerlemesi (ODRD kullanıcıları için)
- Pub/Sub'a yönlendirilen günlükleri görüntüleme : Logging → Pub/Sub entegrasyonuna genel bakış
Sink
Google Cloud'da, Cloud Pub/Sub, neredeyse gerçek zamanlı mesaj yayınlama sistemi olarak tercih edilir. Kaynaktaki etkinliklerin Pub/Sub'a iletilmesi gibi özel etkinlikler de aşağı akış tüketimi için Pub/Sub'a yayınlanır.
İşleniyor
Aşağıdaki bileşenler etkinlik işlenmesinde rol oynar. Diğer yapı taşları gibi işleme bileşenleri de tamamen sunucusuzdur ve hem yukarı hem de aşağı ölçeklendirilebilir.
- İlk sürüm için hesaplama platformu olarak Cloud Functions (*)
- Sunucusuzdur, maliyetleri yönetmek için ölçeklendirme kontrolleri ile ölçeği artırıp azaltır
- Fleet Engine ile ilgili API'ler için istemci kitaplıklarının bulunması ve uygulama kolaylığına katkıda bulunması nedeniyle programlama dili olarak Java
- Eyalet deposu olarak Cloud Firestore
- Sunucusuz anahtar/değer mağazası
- Yukarı akış ve aşağı akış bileşenleriyle entegrasyon noktası olarak Cloud Pub/Sub
- Neredeyse gerçek zamanlı olarak esnek bağlantılı entegrasyon
İşlevler varsayılan ayarlarla olduğu gibi kullanılabilir ancak yeniden yapılandırılabilir. Yapılandırma parametreleri, dağıtım komut dosyaları aracılığıyla ayarlanır ve ilgili terraform modülü README'lerinde ayrıntılı olarak belgelenir.
*Not: Bu referans çözüm, farklı koşulları karşılamanıza yardımcı olabilecek alternatif uygulamalar yayınlamayı planlamaktadır.
Dağıtım
Referans çözüm dağıtım sürecinin tekrarlanabilir, özelleştirilebilir, kaynak kodu kontrol edilebilir ve güvenli olmasını sağlamak için otomasyon aracı olarak Terraform seçilmiştir. Terraform, Google Cloud için zengin destek sunan ve yaygın olarak kullanılan bir IaC (Kod Olarak Altyapı) aracıdır.
- Google Cloud Platform Sağlayıcısı: "Google Cloud Platform Sağlayıcısı" tarafından desteklenen kaynağın dokümanları
- Terraform'u kullanmayla ilgili en iyi uygulamalar: Google Cloud'da en iyi şekilde nasıl kullanılacağıyla ilgili zengin rehberlik
- Terraform Registery: Google ve topluluk tarafından desteklenen ek modüller
Terraform modülleri
Tek bir büyük monolitik referans çözüm dağıtım modülü oluşturmak yerine, yeniden kullanılabilir otomasyon blokları bağımsız olarak kullanılabilen Terraform modülleri olarak uygulanır. Modüller, çok çeşitli yapılandırılabilir değişkenler sağlar. Bu değişkenlerin çoğunda varsayılan değerler bulunur. Böylece, hızlı bir şekilde çalışmaya başlayabilir ve ihtiyaçlarınıza ve tercihlerinize göre özelleştirme yapabilirsiniz.
Referans çözüme dahil edilen modüller:
- Fleet Engine günlük kaydı yapılandırması: Fleet Engine ile kullanılmak üzere Cloud Logging ile ilgili yapılandırmaları otomatikleştirin. Referans çözümde, Fleet Engine ile ilgili günlükleri belirli bir Pub/Sub konusuna yönlendirmek için kullanılır.
- Fleet Events bulut işlevi dağıtımı: Örnek işlev kodu dağıtımını içerir ve güvenli projeler arası entegrasyon için gereken izin ayarlarının otomasyonunu da yönetir.
- Referans çözümün tamamını dağıtma: Önceki iki modülü çağırır ve çözümün tamamını sarar.
Güvenlik
IAM, en az ayrıcalık ilkelerinin yanı sıra Google Cloud'un hizmet hesabı kimliğine bürünme gibi güvenlikle ilgili en iyi uygulamaları da uygulamak için kullanılır. Google Cloud'un güvenlik konusunda size daha fazla kontrol sunmak için neler sunduğu hakkında daha fazla bilgi edinmek için aşağıdaki makalelere göz atın.
Sonraki işlemler
Artık Fleet Etkinlikleri Referans Çözümü'ne erişip daha ayrıntılı bir şekilde keşfetmeye hazırsınız. Başlamak için GitHub'a gidin.
Ek
Gereksinimlerinizi toplayın
Gereklilikleri sürecin başlarında toplamanızı öneririz.
Öncelikle, neden gerçek zamanlı etkinlikleri kullanmak istediğinize veya bu etkinlikleri neden kullanmanız gerektiğine dair ayrıntıları belirleyin. Aşağıda, ihtiyaçlarınızı netleştirmenize yardımcı olacak bazı sorular verilmiştir.
- Bir etkinlik akışının yararlı olması için hangi bilgiler gereklidir?
- Sonuç, yalnızca Google hizmetlerinde yakalanan veya üretilen verilerden elde edilebilir mi? Yoksa entegre harici sistemlerle veri zenginleştirme gerekli mi? Cevabınız evet ise bu sistemler nelerdir ve hangi entegrasyon arayüzlerini sunarlar?
- Bir işletme olarak ölçmek istediğiniz metrikler nelerdir? Bu metriklerin tanımı
- Etkinlikler genelinde metrikleri hesaplamanız gerekirse ne tür bir toplama gerekir? Mantıklı adımlar oluşturmaya çalışın. (ör. Kaynak kısıtlamaları altında performansı hesaplamak için yoğun saatlerde TVS/ATA'yı filonun bir alt bölümündeki SLO'larla karşılaştırın.)
- Neden toplu işlem yerine etkinlik tabanlı modelle ilgileniyorsunuz? Bu, daha düşük gecikme (işlem süresi) için mi yoksa gevşek bağlı bir entegrasyon (esneklik) için mi?
- Düşük gecikme için "düşük" değerini tanımlayın. Dakika? Saniye mi? Saniyenin altında mı? Gecikme nedir?
- Ekip olarak bir teknoloji grubuna ve ilgili becerilere yatırım yaptınız mı? Varsa nedir ve hangi entegrasyon noktalarını sağlar?
- Mevcut sistemlerinizin, filonuzdan gelen etkinlikleri işlerken karşılayamayacağı veya yapmakta zorlanabileceği herhangi bir gereklilik var mı?
Tasarım ilkeleri
Bir düşünce sürecinin takip edilmesinde fayda vardır. Bu, özellikle de aralarından seçim yapabileceğiniz çeşitli seçenekler olduğunda tutarlı tasarım kararları almanıza yardımcı olur.
- Varsayılan olarak daha basit seçenekler sunulur.
- Varsayılan olarak daha kısa bir yatırım getirisi süresi kullanılır. Daha az kod, daha düşük öğrenme eğrisi.
- Gecikme ve performans için maksimum optimizasyon yerine belirlediğiniz çıtayı karşılamayı hedefleyin. Ayrıca, genellikle karmaşıklığa yol açtığı için aşırı optimizasyondan da kaçının.
- Maliyet için de aynı durum geçerlidir. Maliyeti makul seviyede tutun. Henüz yüksek değerli ancak nispeten daha pahalı hizmetleri kullanmaya söz verebilecek bir aşamada olmayabilirsiniz.
- Deneysel aşamasında ölçeği azaltmak, ölçeği artırmak kadar önemli olabilir. Hiçbir şey yapmadığınızda harcama yapmamak için sınırla ölçeklendirme ve aynı zamanda ölçeği azaltma (ideal olarak sıfıra) esnekliği sunan bir platform kullanın. Her zaman açık altyapıyla yüksek performans, yolculuğun ilerleyen aşamalarında ve ihtiyaçlarına güvendiğinizde göz önünde bulundurulabilir.
- Daha sonra üzerinde daha fazla çalışmanız gereken alanları belirlemek için gözlem yapın ve ölçümler alın.
- Hizmetleri sıkı sıkıya bağlı tutun. Bu, daha sonra parça parça değiştirmeyi kolaylaştırır.
- Son olarak, güvenlik konusunda da gevşek davranmamanız gerekir. Herkese açık bir bulut ortamında çalışan bir hizmet olarak sisteme açılan güvenli olmayan kapılar olamaz.
Akış kavramları
Etkinliğe dayalı veya akışa nispeten yeni başladıysanız dikkate almanız gereken önemli kavramlar vardır. Bunlardan bazıları toplu işleme işleminden çok farklı olabilir.
- Ölçek : Genellikle işlenecek veri miktarı hakkında iyi bir fikriniz olan toplu işlemeye kıyasla akışta bu mümkün değildir. Bir şehirdeki trafik sıkışıklığı, belirli bir bölgede birdenbire çok fazla olaya neden olabilir ve bunu yine de işleyebilmeniz gerekir.
- Aralık oluşturma : Etkinlikleri tek tek işlemek yerine, genellikle etkinlikleri bir zaman çizelgesinde hesaplama birimi olarak daha küçük "pencereler" halinde gruplandırmak istersiniz. "Sabit pencereler (ör. her takvim günü)", "kaydırmalı pencereler (son 5 dakika)", "oturum pencereleri (bu seyahat sırasında)" gibi çeşitli pencere stratejileri vardır. Bunlardan birini seçmeniz gerekir. Pencere ne kadar uzun olursa, sonuçların üretilmesindeki gecikme de o kadar uzun sürer. İhtiyaçlarınıza uygun doğru modeli ve yapılandırmayı seçin.
- Tetikleme : Nispeten daha uzun pencereler kullanmanız gereken durumlar vardır. Yine de etkinlik oluşturmak için pencerenin sonunu beklemek yerine, aradaki süre içinde ara sonuçlar yayınlamak istersiniz. Bu kavram, önce hızlı sonuçlar döndürmenin ve ardından bunları daha sonra düzeltmenin yararlı olduğu kullanım alanları için uygulanabilir. Bir yayının %25, %50 ve% 75'inde ara durumu yayınlamayı düşünün.
- Sıralama : Etkinlikler sisteme oluşturuldukları sırayla ulaşmayabilir. Özellikle gecikmeye ve karmaşık yönlendirme yollarına neden olan mobil ağlar üzerinden iletişimin yer aldığı kullanım alanları için. "Etkinlik zamanı" (etkinliğin gerçekleştiği gerçek zaman) ile "işleme zamanı" (etkinliğin sisteme ulaştığı zaman) arasındaki farkın farkında olmanız ve etkinlikleri buna göre işleme almanız gerekir. Genel olarak, etkinlikleri "etkinlik zamanı"na göre işlemek istersiniz.
- Mesaj yayını - En az bir kez ve tam olarak bir kez: Farklı etkinlik platformları bu konuda farklı destek sunar. Kullanım alanınıza bağlı olarak yeniden deneme veya tekilleştirme stratejilerini değerlendirmeniz gerekir.
- Tamamlanmamış mesajlar : Sıralama değişikliğinde olduğu gibi, mesajların kaybolma ihtimali vardır. Bunun nedeni, cihazın pil ömrü, telefonda yanlışlıkla meydana gelen hasar, tüneldeyken bağlantının kesilmesi veya kabul edilebilir bir zaman aralığının dışında alınan bir mesaj olabilir. Eksik veri olması sonuçlarınızı nasıl etkiler?
Bu liste tam kapsamlı değildir. Aşağıda, her bir konu hakkında daha fazla bilgi edinmenize yardımcı olabilecek, kesinlikle okunması önerilen bazı kaynaklar verilmiştir.
Katkıda bulunanlar
Bu belge Google tarafından yönetilir. Bu makaleyi ilk olarak aşağıdaki katkıda bulunanlar yazdı.
Ana yazarlar:
- Mary Pishny | Ürün Yöneticisi, Google Haritalar Platformu
- Ethel Bao| Yazılım Mühendisi, Google Haritalar Platformu
- Mohanad Almiski | Google Haritalar Platformu Yazılım Mühendisi
- Naoya Moritani | Çözüm Mühendisi, Google Haritalar Platformu