Udostępnij za pośrednictwem

Konfigurowanie i używanie koligacji usługi w usłudze Service Fabric

  • Artykuł

Koligacja to kontrola, która jest udostępniana głównie w celu ułatwienia przejścia większych aplikacji monolitycznych do świata chmury i mikrousług. Jest on również używany jako optymalizacja pod kątem poprawy wydajności usług, chociaż może to mieć skutki uboczne.

Załóżmy, że wprowadzasz większą aplikację lub taką, która nie została zaprojektowana z myślą o mikrousługach, do usługi Service Fabric (lub w żadnym środowisku rozproszonym). Ten typ przejścia jest powszechny. Zacznij od podniesienia całej aplikacji do środowiska, spakowania jej i upewnienia się, że działa bezproblemowo. Następnie zaczniesz dzielić go na różne mniejsze usługi, które wszyscy komunikują się ze sobą.

W końcu może się okazać, że w aplikacji występują pewne problemy. Problemy zwykle należą do jednej z następujących kategorii:

  1. Niektóre składniki X w aplikacji monolitycznej mają nieudokumentowaną zależność od składnika Y i właśnie zamieniono te składniki w oddzielne usługi. Ponieważ te usługi są teraz uruchomione w różnych węzłach w klastrze, są one uszkodzone.
  2. Te składniki komunikują się za pośrednictwem (lokalne nazwane potoki | pamięci współużytkowanej | plików na dysku) i naprawdę muszą mieć możliwość zapisu w udostępnionym zasobie lokalnym ze względu na wydajność w tej chwili. Ta twarda zależność zostanie usunięta później, być może.
  3. Wszystko jest w porządku, ale okazuje się, że te dwa składniki są w rzeczywistości wrażliwe na czacie/wydajność. Po przeniesieniu ich do oddzielnych usług ogólna wydajność aplikacji została zwiększona lub zwiększono opóźnienie. W związku z tym ogólna aplikacja nie spełnia oczekiwań.

W takich przypadkach nie chcemy tracić pracy refaktoryzacji i nie chcemy wracać do monolitu. Ostatni warunek może być nawet pożądany jako zwykła optymalizacja. Jednak dopóki nie będziemy mogli przeprojektować składników tak, aby działały naturalnie jako usługi (lub dopóki nie będziemy mogli rozwiązać oczekiwań dotyczących wydajności w inny sposób), będziemy potrzebować pewnego poczucia lokalności.

Postępowanie Cóż, możesz spróbować włączyć koligację.

Jak skonfigurować koligację

Aby skonfigurować koligację, należy zdefiniować relację koligacji między dwiema różnymi usługami. Koligację można traktować jako "wskazującą" jedną usługę na drugą i mówiąc: "Ta usługa może działać tylko wtedy, gdy ta usługa jest uruchomiona". Czasami odnosimy się do koligacji jako relacji nadrzędny/podrzędny (gdzie wskazujesz element podrzędny w obiekcie nadrzędnym). Koligacja zapewnia, że repliki lub wystąpienia jednej usługi są umieszczane w tych samych węzłach, co w przypadku innej usługi.

ServiceCorrelationDescription affinityDescription = new ServiceCorrelationDescription();
affinityDescription.Scheme = ServiceCorrelationScheme.Affinity;
affinityDescription.ServiceName = new Uri("fabric:/otherApplication/parentService");
serviceDescription.Correlations.Add(affinityDescription);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

Uwaga

Usługa podrzędna może uczestniczyć tylko w jednej relacji koligacji. Jeśli chcesz, aby dziecko było powiązane z dwoma usługami nadrzędnymi jednocześnie, masz kilka opcji:

  • Odwróć relacje (mają element parentService1 i element parentService2 w bieżącej usłudze podrzędnej) lub
  • Wyznaczyć jednego z rodziców jako centrum zgodnie z konwencją i mieć wszystkie usługi punktu w tej usłudze.

Wynikowe zachowanie umieszczania w klastrze powinno być takie samo.

Różne opcje koligacji

Koligacja jest reprezentowana za pomocą jednego z kilku schematów korelacji i ma dwa różne tryby. Najczęstszym trybem koligacji jest to, co nazywamy NonAlignedAffinity. W przypadku funkcji NonAlignedAffinity repliki lub wystąpienia różnych usług są umieszczane w tych samych węzłach. Drugi tryb to AlignedAffinity. Wyrównana koligacja jest przydatna tylko w przypadku usług stanowych. Skonfigurowanie dwóch usług stanowych w celu wyrównania koligacji gwarantuje, że prawybory tych usług są umieszczane w tych samych węzłach co siebie nawzajem. Powoduje to również umieszczenie każdej pary serwerów pomocniczych dla tych usług w tych samych węzłach. Istnieje również możliwość skonfigurowania funkcji NonAlignedAffinity dla usług stanowych (choć rzadziej). W przypadku funkcji NonAlignedAffinity różne repliki dwóch usług stanowych będą działać w tych samych węzłach, ale ich prawybory mogą trafić do różnych węzłów.

Tryby koligacji i ich efekty

Żądany stan najlepszego nakładu pracy

Relacja koligacji jest najlepszym rozwiązaniem. Nie zapewnia tych samych gwarancji kolokacji lub niezawodności, które działają w tym samym procesie wykonywalny. Usługi w relacji koligacji są zasadniczo różnymi jednostkami, które mogą zakończyć się niepowodzeniem i mogą być przenoszone niezależnie. Relacja koligacji może również przerwać, choć te przerwy są tymczasowe. Na przykład ograniczenia pojemności mogą oznaczać, że tylko niektóre obiekty usługi w relacji koligacji mogą mieścić się w danym węźle. W takich przypadkach, mimo że istnieje relacja koligacji, nie można jej wymusić z powodu innych ograniczeń. Jeśli jest to możliwe, naruszenie zostanie automatycznie skorygowane później.

Łańcuchy a gwiazdy

Obecnie Resource Manager klastra nie może modelować łańcuchów relacji koligacji. Oznacza to, że usługa, która jest elementem podrzędnym w jednej relacji koligacji, nie może być elementem nadrzędnym w innej relacji koligacji. Jeśli chcesz modelować ten typ relacji, musisz skutecznie modelować ją jako gwiazdę, a nie łańcuch. Aby przenieść się z łańcucha do gwiazdy, najbardziej dolnego elementu podrzędnego zostanie rodzicielstwo do rodzica pierwszego dziecka. W zależności od układu usług może być konieczne wielokrotne wykonanie tej czynności. Jeśli nie ma naturalnej usługi nadrzędnej, może być konieczne utworzenie takiej usługi, która służy jako symbol zastępczy. W zależności od wymagań możesz również przyjrzeć się grupom aplikacji.

Łańcuchy a gwiazdy w kontekście relacji koligacji

Kolejną rzeczą do zanotowania relacji koligacji jest to, że są one domyślnie kierunkowe. Oznacza to, że reguła koligacji wymusza tylko to, że element podrzędny umieszczony w obiekcie nadrzędnym. Nie zapewnia, że element nadrzędny znajduje się z elementem podrzędnym. W związku z tym w przypadku naruszenia koligacji i skorygowania naruszenia z jakiegoś powodu nie jest możliwe przeniesienie elementu podrzędnego do węzła nadrzędnego, nawet jeśli przeniesienie elementu nadrzędnego do węzła podrzędnego poprawiłoby naruszenie — element nadrzędny nie zostanie przeniesiony do węzła podrzędnego. Ustawienie właściwości MoveParentToFixAffinityViolation na wartość true spowoduje usunięcie kierunkowości. Należy również pamiętać, że relacja koligacji nie może być idealna ani natychmiast wymuszana, ponieważ różne usługi mają różne cykle życia i mogą niezależnie ulegać awarii i przenosić. Załóżmy na przykład, że element nadrzędny nagle ulegnie awarii do innego węzła, ponieważ uległ awarii. Klaster Resource Manager i Menedżer trybu failover obsługują najpierw tryb failover, ponieważ utrzymanie usług, spójność i dostępność jest priorytetem. Po zakończeniu pracy w trybie failover relacja koligacji zostanie przerwana, ale klaster Resource Manager uważa, że wszystko jest w porządku, dopóki nie zauważy, że element podrzędny nie znajduje się w obiekcie nadrzędnym. Te kontrole są wykonywane okresowo. Więcej informacji o tym, jak klaster Resource Manager ocenia ograniczenia, jest dostępny w tym artykule. Ten artykuł zawiera więcej informacji na temat sposobu konfigurowania cykli oceny tych ograniczeń.

Obsługa partycjonowania

Ostatnią rzeczą, którą należy zauważyć na temat koligacji, jest to, że relacje koligacji nie są obsługiwane w przypadku partycjonowania elementu nadrzędnego. Partycjonowane usługi nadrzędne mogą być obsługiwane w końcu, ale obecnie nie jest to dozwolone.

Następne kroki