Orleans zasady projektowania architektury

Orleans jest projektem typu open source i ważne jest, aby jasno poznać cele i zasady. Te cele i zasady motywowały decyzje projektowe, Orleans tak aby nowe zmiany pasowały do tych ram lub jawnie i celowo zmieniały te cele i zasady.

Celem Orleans projektu było utworzenie struktury, która umożliwiłaby deweloperom głównego nurtu łatwe tworzenie skalowalnych aplikacji rozproszonych (w chmurze). Aby nieco to podzielić:

• Docelowi odbiorcy nie powinni wykluczać programistów, którzy nie wykonali tworzenia systemów rozproszonych. Chcemy umożliwić wszystkim deweloperom, zarówno ekspertom w chmurze, jak i początkującym osobom pracującym w chmurze, skupienie się na logice i funkcjach aplikacji — czyli o tym, co zapewnia wartość biznesową — a nie na ogólnych problemach z systemami rozproszonymi.

• Celem jest umożliwienie deweloperom głównego nurtu łatwego tworzenia aplikacji w chmurze. Łatwo oznacza, że nie powinny myśleć o dystrybucji więcej niż jest to wymagane. Łatwo oznacza również, że Orleans należy zaprezentować fasadę możliwie jak najbardziej znaną dla dewelopera. W kontekście platformy .NET oznacza to obiekty i interfejsy języka C#.

• Te aplikacje powinny być domyślnie skalowalne. Ponieważ docelowi użytkownicy nie muszą być ekspertami od systemów rozproszonych, chcemy udostępnić im strukturę, która prowadzi ich do tworzenia skalowalnych aplikacji bez jawnego myślenia o tym. Oznacza to, że struktura musi podejmować wiele decyzji, aby zagwarantować akceptowalny stopień skalowalności, nawet jeśli oznacza to, że skalowalność nie jest optymalna dla każdej aplikacji.

Uzupełniliśmy ten cel zestawem zasad architektury:

• Koncentrujemy się na przypadku 80%. Istnieją pewne aplikacje, które Orleans nie są odpowiednie; ale to nie problem. Istnieją aplikacje, które Orleans są odpowiednie do zastosowania, ale można uzyskać nieco lepszą wydajność przez ręczne dostrajanie, na które Orleans nie pozwala; i to też jest w porządku. 80%, które Orleans dobrze pasuje i działa wystarczająco dobrze w wielu interesujących aplikacjach, a wolelibyśmy zrobić świetną robotę na 80% niż marną na 99%.

• Skalowalność jest najważniejsza. Zrezygnujemy z części wydajności, jeśli to poprawi skalowanie.

• Dostępność jest najważniejsza. Aplikacja w chmurze powinna być jak narzędzie: zawsze tam, gdy chcesz.

• Wykryj i rozwiąż problemy, nie zakładaj, że możesz zapobiec 100%. W skali chmury złe rzeczy często się zdarzają, a wręcz zdarzają się i takie, które teoretycznie wydają się niemożliwe, tylko że rzadziej. Doprowadziło to do tego, co jest często określane jako "przetwarzanie zorientowane na odzyskiwanie", zamiast prób bycia odpornym na błędy. Doświadczenie pokazało, że odporność na uszkodzenia jest krucha i często iluzoryczne. Nawet matematycznie sprawdzone protokoły nie chronią przed losowymi zmianami bitów w pamięci ani przed kontrolerami dysków, które zgłaszają sukces, mimo że faktycznie zawiodły — oba te scenariusze miały miejsce w rzeczywistym świecie.

Poprzednie zasady doprowadziły nas do pewnych praktyk:

• Projektowanie oparte na interfejsie API: jeśli nie wiemy, jak udostępnimy funkcję deweloperowi, nie utworzymy jej. Oczywiście najlepszym sposobem jest, aby funkcja nie wymagała zaangażowania deweloperów w ogóle.

• Spraw, by robienie tego, co należy, było łatwe: zachowaj rzeczy tak proste, jak to możliwe (ale nie prostsze), nie używaj młotka, jeśli śrubokręt jest właściwym narzędziem. Jak to ujął jeden z naszych wczesnych użytkowników, staramy się pomóc naszym klientom "wpaść w dołkę sukcesu". Jeśli istnieje standardowy wzorzec, który będzie działać dobrze dla 80% aplikacji, nie martw się o włączenie każdej możliwej alternatywy. Orleans" przyjęcie asynchronii jest dobrym przykładem tego.

• Ułatw deweloperom rozszerzanie frameworka bez jego uszkadzania. Niestandardowi dostawcy serializacji i trwałości to kilka przykładów. Niestandardowe rozszerzenie planowania zadań byłoby przykładem antywzoru.

• Przestrzegaj zasady najmniejszego zaskoczenia: jak najwięcej rzeczy powinny być tak znane, ale wszystko powinno zachowywać się tak, jak wygląda.