Architektura usług to podejście do projektowania oprogramowania, które rozwiązuje problem z serią usług autonomicznych.

Analogia

Rozsądną analogią do architektury usług jest organizacja taka jak bank. Bank dzieli pracę na szereg usług, takich jak obsługa klienta, usługi informatyczne i usługi zarządzania zasobami ludzkimi. Każda usługa jest niezależna i może być wdrożona w różnych biurach. Klientom każdej usługi oferujemy umowę określającą, czego można oczekiwać od usługi. Na przykład zarządzanie zasobami ludzkimi może pomóc zespołowi w rekrutacji nowego personelu za pomocą formularza, który zespół wypełnia, aby zainicjować proces. Struktura usług firmy dzieli złożony problem prowadzenia banku na małe fragmenty funkcjonalności do zarządzania.

Usługi

Usługi to jednostki oprogramowania, które pełnić funkcję. Służą do rozbicia złożonych problemów na szereg prostszych problemów. Usługi są również zaprojektowane do oddzielnego wdrażania. Jest to główna zaleta, ponieważ pozwala budować wysoce skalowalne i odporne systemy.

Odporność

Odporność to termin oznaczający oprogramowanie, które jest niezawodne w rzeczywistych warunkach, które obejmują różne obciążenia i awarie. Architektura usług jest użyteczną techniką budowania systemów, które nadal działają, gdy coś zawodzi. Odbywa się to poprzez zaprojektowanie usług tak, aby były autonomiczne, tak aby nie były od siebie zależne. Usługi można następnie wdrażać w infrastrukturze chmury i skalować w górę iw dół zgodnie z wymaganiami. Gdy wystąpienie ulegnie awarii, usługi są wystarczająco inteligentne, aby to wykryć i automatycznie znaleźć działającą instancję.

Usługi a składniki

Usługi i komponenty to dwa różne sposoby dzielenia pracy na porcje, które można zarządzać i które można ponownie wykorzystać. Różnica polega na usługi mogą być wdrażane samodzielnie. Komponenty są wdrażane z czymś innym i dlatego nie są autonomiczne. Usługi mogą być budowane z komponentów. Podobnie komponenty mogą korzystać z usług.

Architektura zorientowana na usługi (SOA)

Architektura zorientowana na usługi była wczesnym terminem dla architektury usług, która została przyjęta i wprowadzona na rynek przez wielu dużych dostawców IT, którzy używali go do sprzedaży platform SOA i oprogramowania pośredniego. Była to wielka moda informatyczna około 2005 roku, w której pojawiło się wiele odgórnych wdrożeń, które obejmowały zakup pakietu oprogramowania, a następnie przeprojektowanie istniejących systemów, aby pasowały do paradygmatu SOA. Wiele z tych działań całkowicie pomijało sens SOA, a niepowodzenia projektów były powszechne. Zamieszanie spadło, gdy eksperci IT promowali lub krytykowali architekturę SOA, często poprzez tworzenie tak złożonych rzeczy, jak to tylko możliwe.

Mikrousługi

Wszystkie wielkie myślenie i nonsens , który otaczał architekturę SOA u szczytu popularności, nie powstrzymał wykwalifikowanych architektów przed wykorzystaniem jej podstawowych pomysłów w efektywny i lekki sposób, który pozwolił stworzyć niezawodne, skalowalne, łatwe w zarządzaniu i opłacalne systemy i aplikacje. To przekształciło się w nową kulturę projektowania oprogramowania, znaną jako mikrousługi, zorganizowaną wokół zestawu zasad projektowania usług.

Przykład

Firma telekomunikacyjna projektuje system bilingowy jako szereg oddzielnie wdrażanych usług. Każda usługa jest postrzegana jako oddzielny produkt, który może być rozwijany, utrzymywany i zarządzany przez różne osoby. Usługi są wdrażane w chmurze i luźno powiązane. Gdy wystąpienie usługi ulegnie awarii, inne usługi automatycznie przełączają się na wystąpienie, które nadal działa. Chociaż problem rozliczeń telekomunikacyjnych jest niezwykle złożony, żadna pojedyncza usługa w architekturze nie jest tak złożona, że każda z nich jest stosunkowo tania w opracowaniu i zarządzaniu. Usługi zasadniczo samoorganizują się. Każdy publikuje API dla innych usług. Każdy wie, czego potrzebuje od innych usług i jest wystarczająco inteligentny, aby kierować się wokół wystąpień, które uległy awarii, w celu znalezienia usług, które reagują. Innymi słowy, architektura nie ma centralnego kontrolera ani oprogramowania pośredniego.

Omówienie: architektura usług
Typ
Definicja	Podejście do projektowania oprogramowania, które rozwiązuje problem z serią usług autonomicznych.
Powiązane pojęcia