Podejścia architektoniczne do integracji najemcy i dostępu do danych

Typowe jest, aby systemy integrować się ze sobą, nawet przez granice organizacyjne. Podczas tworzenia rozwiązania wielodostępnego mogą istnieć wymagania dotyczące wysyłania danych z powrotem do systemów najemców lub odbierania danych z tych systemów. W tym artykule opisano kluczowe zagadnienia i podejścia do projektowania architektury i opracowywania integracji dla rozwiązania multitenant.

Kluczowe zagadnienia i wymagania

Kierunek przepływu danych

Ważne jest, aby zrozumieć kierunek przepływów danych. Kierunek przepływu danych ma wpływ na kilka aspektów architektury, takich jak zarządzanie tożsamością i topologią sieci rozwiązania. Istnieją dwa typowe przepływy danych:

• Eksportowanie, co oznacza, że dane przepływa z systemu wielodostępnego do systemów poszczególnych dzierżaw

• Importuj, co oznacza, że dane pochodzą z systemów najemców do systemu wielodostępnego

Ważne jest również, aby wziąć pod uwagę kierunek przepływu danych sieciowych, który niekoniecznie odpowiada kierunku przepływu danych logicznych. Możesz na przykład zainicjować połączenie wychodzące do dzierżawcy, aby zaimportować dane z jego systemu.

Pełny dostęp lub dostęp delegowany przez użytkownika

W wielu systemach dostęp do określonych danych jest ograniczony do poszczególnych użytkowników. Dane, do których uzyskuje dostęp jeden użytkownik, mogą się różnić od tego, do czego uzyskuje dostęp inny użytkownik. Ważne jest, aby rozważyć, czy pracujesz z kompletnymi zestawami danych, czy też dane importowane lub eksportowane zależą od uprawnień dostępu poszczególnych użytkowników.

Na przykład usługa Power BI to wielodostępna usługa, która zapewnia raportowanie i analizę biznesową na podstawie magazynów danych należących do klienta. Podczas konfigurowania usługi Power BI można skonfigurować źródła danych do ściągania danych z baz danych, interfejsów API i innych magazynów danych. Magazyny danych można skonfigurować na dwa różne sposoby:

• Zaimportuj wszystkie dane z bazowego magazynu danych. Takie podejście wymaga, aby usługa Power BI odbierała poświadczenia dla tożsamości, która ma uprawnienia do całego magazynu danych. Po zaimportowaniu danych administratorzy usługi Power BI konfigurują uprawnienia niezależnie. Usługa Power BI wymusza te uprawnienia.

• Zaimportuj podzbiór danych z bazowego magazynu danych na podstawie uprawnień użytkownika. Gdy użytkownik tworzy źródło danych, używa poświadczeń i skojarzonych uprawnień. Dokładny podzbiór danych importowanych przez usługę Power BI zależy od poziomu dostępu użytkownika, który tworzy źródło danych.

Obie metody mają zasadne przypadki użycia, dlatego ważne jest, aby jasno zrozumieć wymagania użytkowników.

Jeśli pracujesz z pełnymi zestawami danych, system źródłowy skutecznie traktuje system docelowy jako zaufany podsystem. W przypadku tego typu integracji należy również rozważyć użycie tożsamości obciążenia zamiast tożsamości użytkownika. Tożsamość środowiska pracy to tożsamość systemowa, która nie odpowiada jednemu użytkownikowi. Tożsamość zadaniowa ma wysokie uprawnienia do danych w systemie źródłowym.

Alternatywnie, jeśli pracujesz z danymi o zakresie użytkownika, może być konieczne użycie podejścia takiego jak delegowanie w celu uzyskania dostępu do poprawnego podzestawu danych z zestawu danych. Następnie system docelowy skutecznie uzyskuje takie same uprawnienia jak określony użytkownik. Aby uzyskać więcej informacji, zobacz Delegowany dostęp użytkowników. Jeśli używasz delegowania, rozważ, jak obsłużyć scenariusze, w których użytkownik zostanie pozbawiony dostępu lub zmienią się jego uprawnienia.

Integracje w czasie rzeczywistym lub wsadowe

Zastanów się, czy planujesz używać danych w czasie rzeczywistym, czy wysyłać dane w partiach.

W przypadku integracji w czasie rzeczywistym typowe są następujące podejścia:

• Żądanie-odpowiedź to miejsce, w którym klient inicjuje żądanie do serwera i odbiera odpowiedź. Zazwyczaj integracje żądań-odpowiedzi są implementowane przy użyciu interfejsów API lub elementów webhook. Żądania mogą być synchroniczne, gdzie oczekują na potwierdzenie i odpowiedź. Alternatywnie żądania mogą być asynchroniczne i używać np. wzorca asynchronicznego Request-Reply, aby czekać na odpowiedź.

• Luźno sprzężona komunikacja jest często włączona za pośrednictwem składników obsługi komunikatów, które są przeznaczone do luźno sprzężonych systemów. Na przykład usługa Azure Service Bus udostępnia funkcje kolejkowania komunikatów, a usługi Azure Event Grid i Azure Event Hubs zapewniają możliwości obsługi zdarzeń. Te składniki są często używane w ramach architektur integracji.

Z kolei integracje wsadowe są często zarządzane za pośrednictwem zadania w tle, które może być wyzwalane o określonych porach dnia. Integracje wsadowe często odbywają się poprzez lokalizację przejściową, taką jak kontener magazynowania obiektów blob, ponieważ wymieniane zestawy danych mogą być duże.

Ilość danych

Ważne jest, aby zrozumieć ilość danych wymienianych za pośrednictwem integracji, ponieważ te informacje ułatwiają zaplanowanie ogólnej pojemności systemu. Podczas planowania pojemności systemu należy pamiętać, że różni najemcy mogą mieć różne ilości danych do wymiany.

W przypadku integracji w czasie rzeczywistym można mierzyć wolumin jako liczbę transakcji w określonym przedziale czasu. W przypadku integracji wsadowych można zmierzyć wolumin jako liczbę wymienianych rekordów lub ilość danych w bajtach.

Formaty danych

Gdy dane są wymieniane między dwiema stronami, ważne jest, aby zrozumieć format i strukturę danych. Rozważ następujące części formatu danych:

• Format pliku, taki jak JSON, Parquet, CSV lub XML

• Schemat, taki jak lista uwzględnionych pól, formaty dat i nienullowalność pól.

W przypadku pracy z systemem wieloznacznikowym, jeśli to możliwe, standaryzuj i używaj tego samego formatu danych dla wszystkich najemców. Takie podejście pomaga uniknąć konieczności dostosowywania i ponownego testowania składników integracji dla wymagań każdej dzierżawy. Jednak niektóre scenariusze wymagają różnych formatów danych do komunikacji z różnymi najemcami, więc może być konieczne implementowanie wielu integracji. Aby zapoznać się z podejściem, które może pomóc uprościć ten typ scenariusza, zobacz Komponenty integracyjne z możliwością komponowania.

Dostęp do systemów dzierżaw

Niektóre integracje wymagają nawiązania połączenia z systemami lub magazynami danych najemcy. Podczas nawiązywania połączenia z systemami najemcy należy dokładnie rozważyć elementy sieciowe i tożsamościowe połączenia.

Dostęp do sieci

Rozważ topologię sieci na potrzeby uzyskiwania dostępu do systemu dzierżawy, co może obejmować następujące opcje:

• Połączenia internetowe mogą budzić obawy dotyczące zabezpieczania połączenia i szyfrowania danych. Określ, jak zabezpieczyć połączenie i zaszyfrować dane podczas nawiązywania połączenia przez Internet. Jeśli dzierżawcy planują ograniczyć dostęp na podstawie adresów IP, upewnij się, że usługi platformy Azure używane przez rozwiązanie mogą obsługiwać statyczne adresy IP dla połączeń wychodzących. Rozważ na przykład użycie Azure NAT Gateway, aby zapewnić statyczne adresy IP, jeśli to konieczne. Jeśli potrzebujesz sieci VPN, rozważ bezpieczne wymienienie kluczy z najemcami.

• Agenci, którzy są wdrażani w środowisku dzierżawy, mogą zapewnić elastyczne podejście. Agenci mogą również pomóc uniknąć konieczności zezwalania dzierżawcom na połączenia przychodzące.

• Przekaźniki, takie jak Usługa Azure Relay, zapewniają również podejście do unikania połączeń przychodzących.

Aby uzyskać więcej informacji, zobacz Metody sieciowe dla wielodostępności.

Uwierzytelnianie

Podczas inicjowania połączenia należy zastanowić się nad sposobem uwierzytelniania w każdym lokatorze. Rozważ następujące podejścia:

• Wpisy tajne, takie jak klucze interfejsu API lub certyfikaty. Ważne jest, aby zaplanować sposób bezpiecznego zarządzania poświadczeniami dzierżaw. Wyciek tajemnic najemców może spowodować poważny incydent bezpieczeństwa, co może potencjalnie wpłynąć na wiele najemców.

• Tokeny Microsoft Entra, gdzie używasz tokenu wydanego przez katalog Microsoft Entra dzierżawy. Token może zostać wystawiony bezpośrednio dla obciążenia przy użyciu wielodostępnej rejestracji aplikacji firmy Microsoft Entra lub konkretnej jednostki usługi. Alternatywnie, zadanie może poprosić o delegowane uprawnienia do dostępu do zasobów w imieniu określonego użytkownika w katalogu dzierżawcy.

Niezależnie od wybranego podejścia upewnij się, że użytkownicy są zgodni z zasadą najmniejszych uprawnień i nie przyznają systemowi niepotrzebnych uprawnień. Jeśli na przykład system musi tylko odczytywać dane z magazynu danych dzierżawy, tożsamość używana przez system nie powinna mieć uprawnień do zapisu.

Dostęp najemców do twoich systemów

Jeśli dzierżawcy muszą łączyć się z systemem, rozważ udostępnienie dedykowanych interfejsów API lub innych punktów integracji. Następnie można modelować te punkty integracji w ramach obszaru powierzchni rozwiązania.

W niektórych scenariuszach możesz zdecydować się na zapewnienie dzierżawom bezpośredniego dostępu do zasobów platformy Azure. Należy uważnie rozważyć konsekwencje i upewnić się, że rozumiesz, jak udzielić dostępu najemcom w bezpieczny sposób. Możesz na przykład użyć jednej z następujących metod:

• Użyj wzorca klucza valet, który używa środków zabezpieczeń, takich jak tokeny sygnatur dostępu współdzielonego (SAS), aby udzielić ograniczonego dostępu do określonych zasobów platformy Azure.

• Użyj dedykowanych zasobów dla punktów integracji, takich jak dedykowane konto magazynowe. Dobrym rozwiązaniem jest oddzielenie zasobów integracji od podstawowych zasobów systemowych. Takie podejście pomaga zminimalizować zakres wpływu zdarzenia bezpieczeństwa. Gwarantuje również, że jeśli najemca przypadkowo zainicjuje dużą liczbę połączeń do zasobu i wyczerpie jego pojemność, reszta systemu będzie nadal działać.

Zgodność

W przypadku bezpośredniej interakcji z danymi najemców lub ich przesyłania, należy mieć jasne zrozumienie wymogów związanych z zarządzaniem i zgodnością najemców.

Podejścia i wzorce

Uwidacznianie interfejsów API

Integracje w czasie rzeczywistym często obejmują uwidacznianie interfejsów API dla klientów lub innych firm do użycia. Interfejsy API wymagają szczególnych zagadnień, szczególnie w przypadku korzystania z nich przez strony zewnętrzne. Rozważmy następujący czynniki:

• Zdefiniuj, kto może uzyskać dostęp do interfejsu API.

• Uwierzytelnianie użytkowników interfejsu API przy użyciu bezpiecznej i niezawodnej metody.

• Ustaw limit liczby żądań, które każdy użytkownik interfejsu API może wykonywać w określonym przedziale czasu.

• Podaj jasne informacje i dokumentację dla każdego interfejsu API. W razie potrzeby zaimplementuj portal dla programistów, aby wspierać odnajdywanie i wprowadzanie.

Dobrym rozwiązaniem jest użycie bramy API, takiej jak usługa Azure API Management, aby rozwiązywać te i wiele innych kwestii. Bramy interfejsów API zapewniają jedno miejsce do implementowania zasad, które są zgodne z interfejsami API. Również upraszczają implementację zaplecza systemów interfejsu API. Aby uzyskać więcej informacji, zobacz Używanie usługi API Management w rozwiązaniu wielodostępnym.

Wzorzec klucza portiera

Czasami najmca może potrzebować bezpośredniego dostępu do źródła danych, takiego jak Azure Storage. Rozważ zastosowanie wzorca klucza zastępczego, aby bezpiecznie udostępniać dane i ograniczyć dostęp do magazynu danych.

Na przykład można użyć tego podejścia do wsadowego eksportowania dużego pliku danych. Po wygenerowaniu pliku eksportu możesz zapisać go w kontenerze obiektów blob w Azure Storage, a następnie wygenerować czasową sygnaturę dostępu współdzielonego (SAS) tylko do odczytu. Ten podpis można przekazać najemcy wraz z adresem URL obiektu blob. Klient może następnie pobrać plik z Azure Storage do daty wygaśnięcia podpisu.

Podobnie można wygenerować sygnaturę dostępu współdzielonego z uprawnieniami do zapisu w określonym obiekcie binarnym. Po podaniu sygnatury dostępu współdzielonego (SAS) lokatorowi, może on zapisywać swoje dane do jego obiektu blob. Dzięki integracji usługi Event Grid dla usługi Azure Storage aplikacja może być następnie powiadamiana o przetwarzaniu i importowaniu pliku danych.

Webhooki

Webhooki umożliwiają wysyłanie zdarzeń do dzierżawców pod adresem URL, który oni tobie udostępniają. Gdy masz informacje do wysłania, zainicjujesz połączenie z webhookiem najemcy i dołączasz dane do treści żądania HTTP.

Jeśli zdecydujesz się utworzyć własny system obsługi zdarzeń webhook, rozważ zastosowanie standardu CloudEvents, aby uprościć wymagania dotyczące integracji użytkowników.

Alternatywnie możesz użyć usługi takiej jak Event Grid, aby zapewnić funkcję webhook. Usługa Event Grid działa natywnie z CloudEvents i obsługuje domeny zdarzeń, które są przydatne w przypadku rozwiązań wielodostępnych.

Delegowany dostęp użytkowników

Podczas uzyskiwania dostępu do danych z magazynów danych dzierżawy należy zastanowić się, czy użyć tożsamości określonego użytkownika w celu uzyskania dostępu do danych. W takim przypadku integracja podlega tym samym uprawnieniam, które ma użytkownik. Takie podejście jest często nazywane dostępem delegowanym.

Załóżmy na przykład, że usługa wielodostępowa uruchamia modele uczenia maszynowego na danych najemców. Musisz uzyskać dostęp do wystąpień usług każdej dzierżawy, takich jak obszary robocze usługi Microsoft Fabric na potrzeby analizy, usługi Azure Storage i usługi Azure Cosmos DB. Każdy lokator ma własny katalog Microsoft Entra. Twoje rozwiązanie może mieć delegowany dostęp do magazynu danych, aby można było pobrać dane, do których może uzyskać dostęp określony użytkownik.

Dostęp delegowany jest łatwiejszy, jeśli magazyn danych obsługuje uwierzytelnianie firmy Microsoft Entra. Wiele usług platformy Azure obsługuje tożsamości firmy Microsoft Entra.

Załóżmy na przykład, że wielodostępna aplikacja internetowa i procesy w tle muszą uzyskiwać dostęp do usługi Azure Storage przy użyciu tożsamości użytkowników dzierżaw z identyfikatora Entra firmy Microsoft. Możesz wykonać następujące czynności:

1. Utwórz wielodostępną rejestrację aplikacji Microsoft Entra, która reprezentuje Twoje rozwiązanie.

2. Przyznaj aplikacji delegowane uprawnienie dostępu do usługi Azure Storage jako zalogowany użytkownik.

3. Skonfiguruj aplikację, aby uwierzytelniać użytkowników przy użyciu identyfikatora Entra firmy Microsoft.

Po zalogowaniu się użytkownika Microsoft Entra ID wystawia aplikacji token dostępu o krótkim czasie życia, który może być używany do uzyskania dostępu do usługi Azure Storage w imieniu użytkownika, oraz wystawia dłuższy token odświeżania. System musi bezpiecznie przechowywać token odświeżania, aby procesy w tle mogły uzyskać nowe tokeny dostępu i nadal uzyskiwać dostęp do usługi Azure Storage w imieniu użytkownika.

Messaging

Obsługa komunikatów umożliwia asynchroniczną, luźno połączoną komunikację między systemami lub składnikami. Komunikacja jest często wykorzystywana w scenariuszach integracji w celu oddzielenia systemów źródłowych i docelowych. Aby uzyskać więcej informacji na temat obsługi komunikatów i wielodostępności, zobacz Metody architektury obsługi komunikatów w rozwiązaniach wielodostępnych.

W przypadku korzystania z obsługi komunikatów w ramach integracji z systemami dzierżawców należy rozważyć, czy należy używać tokenów SAS dla usługi Service Bus czy Event Hubs. Tokeny sas zapewniają ograniczony dostęp do zasobów obsługi komunikatów użytkownikom zewnętrznym lub systemom bez umożliwienia im dostępu do pozostałej części podsystemu obsługi komunikatów.

W niektórych scenariuszach możesz zapewnić różne umowy dotyczące poziomu usług lub gwarancje jakości usług dla różnych dzierżawców. Na przykład, podzbiór twoich najemców może oczekiwać, że ich żądania eksportu danych będą przetwarzane szybciej niż inne. Korzystając ze wzorca kolejki priorytetu, można utworzyć oddzielne kolejki dla różnych poziomów priorytetu. Następnie można użyć różnych instancji pracowników, aby odpowiednio ustawić ich priorytety.

Komponowalne składniki integracji

Czasami może być konieczna integracja z wieloma różnymi dzierżawami, korzystającymi z różnych formatów danych lub różnych typów łączności sieciowej.

Typowe podejście do integracji polega na tworzeniu i testowaniu poszczególnych kroków, które wykonują następujące typy akcji:

• Pobieranie danych z magazynu danych.
• Przekształć dane w określony format lub schemat.
• Przesyłaj dane, korzystając z określonego transportu sieciowego lub do znanego docelowego adresu.

Zazwyczaj te poszczególne elementy są kompilowane przy użyciu usług, takich jak Azure Functions i Azure Logic Apps. Następnie zdefiniujesz ogólny proces integracji przy użyciu narzędzia takiego jak Logic Apps lub Azure Data Factory, które wywołuje każdy wstępnie zdefiniowany krok.

Podczas pracy ze złożonymi scenariuszami integracji wielodostępnej warto zdefiniować bibliotekę kroków integracji wielokrotnego użytku. Możesz tworzyć przepływy pracy dla każdej dzierżawy, komponując odpowiednie elementy na podstawie wymagań tej dzierżawy. Alternatywnie, możesz udostępnić niektóre zestawy danych lub składniki integracji bezpośrednio swoim dzierżawcom, aby mogli tworzyć własne procesy integracyjne.

Podobnie może być konieczne zaimportowanie danych z dzierżaw, które używają innego formatu danych lub innego transportu niż inne. Dobrym rozwiązaniem w tym scenariuszu jest tworzenie łączników specyficznych dla najemcy. Łączniki to przepływy pracy, które normalizują i importują dane do standardowego formatu i lokalizacji. Następnie wyzwalają główny udostępniony proces importowania.

Jeśli musisz utworzyć logikę lub kod specyficzny dla dzierżawy, rozważ użycie wzorca warstwy chroniącej przed uszkodzeniem. Ten wzorzec ułatwia hermetyzowanie komponentów specyficznych dla dzierżawcy i utrzymuje resztę rozwiązania nieświadomą dodatkowej złożoności.

Jeśli używasz modelu cen warstwowego, możesz wymagać, aby klienci w niższych poziomach cenowych byli zgodni ze standardowym podejściem z ograniczonym zestawem formatów i sposobów przesyłu danych. Najemcy w wyższych poziomach cenowych mogą mieć dostęp do większych możliwości dostosowania lub elastyczności w składnikach integracyjnych, które zapewniasz.

Antywzorce, których należy unikać

• Udostępnianie podstawowych magazynów danych bezpośrednio najemcom. Gdy dzierżawcy uzyskują dostęp do podstawowych magazynów danych, zabezpieczenie ich może być trudniejsze. Mogą one również przypadkowo powodować problemy z wydajnością, które wpływają na Rozwiązanie. Unikaj podawania poświadczeń do magazynów danych klientom. Nie replikuj bezpośrednio nieprzetworzonych danych z podstawowej bazy danych do replik do odczytu należących do klientów w tym samym systemie bazy danych. Zamiast tego utwórz dedykowane magazyny danych integracji. Użyj wzorca klucza valet , aby uwidocznić dane.

• Wystawianie interfejsów API bez bramy API. Interfejsy API mają szczególne obawy dotyczące kontroli dostępu, rozliczeń i pomiarów. Nawet jeśli początkowo nie planujesz używać zasad interfejsu API, warto wcześnie uwzględnić bramę interfejsu API. W ten sposób, jeśli później będziesz chciał dostosować zasady API, nie musisz dokonywać niezgodnych zmian w adresach URL, od których zależy zewnętrzny klient.

• Niepotrzebne ścisłe sprzężenie. Luźne sprzęganie, takie jak użycie podejść do przesyłania wiadomości, może zapewnić szereg korzyści w zakresie bezpieczeństwa, izolacji wyników oraz odporności. Jeśli to możliwe, należy luźno sprzężć integracje z systemami zewnętrznymi. Jeśli musisz ściśle połączyć się z systemem zewnętrznym, upewnij się, że stosujesz dobre rozwiązania, takie jak wzorzec ponawiania prób, wzorzec wyłącznika i wzorzec grodziowy.

• Niestandardowe integracje dla konkretnych najemców. Funkcje lub kod specyficzny dla najemcy mogą uczynić twoje rozwiązanie trudniejszym do testowania. Utrudnia to również modyfikowanie rozwiązania w przyszłości, ponieważ trzeba zrozumieć więcej ścieżek kodu. Zamiast tego spróbuj skompilować składniki komponowalne , które abstrakują wymagania dotyczące dowolnej konkretnej dzierżawy i ponownie użyj ich w wielu dzierżawach, które mają podobne wymagania.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy:

• John Downs | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure
• Arsen Vladimirskiy | Główny inżynier klienta, FastTrack dla Platformy Azure

Inni współautorzy:

• Will Velida | Inżynier Klienta 2, FastTrack dla platformy Azure
• Filipe Moreira | Architekt rozwiązań w chmurze

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Powiązany zasób

• Podejścia architektoniczne do komunikacji w rozwiązaniach dla wielu najemców