ArchitektúrastílusokArchitecture styles

Az architektúrastílus olyan architektúrák családja, amelyeknek bizonyos tulajdonságai megegyeznek.An architecture style is a family of architectures that share certain characteristics. Az N szintű például egy gyakori architektúrastílus.For example, N-tier is a common architecture style. Újabban a mikroszolgáltatás-architektúrák is egyre népszerűbbé válnak.More recently, microservice architectures have started to gain favor. Az architektúrastílusok használatához nincs szükség adott technológiákra, egyes technológiák azonban kifejezetten alkalmasak bizonyos architektúrákhoz.Architecture styles don't require the use of particular technologies, but some technologies are well-suited for certain architectures. A tárolók például természetesen illeszkednek a mikroszolgáltatásokhoz.For example, containers are a natural fit for microservices.

Azonosítottuk a felhőalkalmazásokban gyakran alkalmazott architektúrastílusokat.We have identified a set of architecture styles that are commonly found in cloud applications. Az egyes stílusokkal foglalkozó cikkek a következőkre térnek ki:The article for each style includes:

  • Az adott stílus leírása és logikai diagramja.A description and logical diagram of the style.
  • A stílus alkalmazási területeire vonatkozó ajánlások.Recommendations for when to choose this style.
  • Előnyök, problémák és ajánlott eljárások.Benefits, challenges, and best practices.
  • Az üzembe helyezés javasolt módja a megfelelő Azure-szolgáltatások használatával.A recommended deployment using relevant Azure services.

A stílusok gyors bemutatásaA quick tour of the styles

Ez a szakasz röviden bemutatja az általunk azonosított architektúrastílusokat, valamint általános áttekintést ad az alkalmazási területeiket illetően.This section gives a quick tour of the architecture styles that we've identified, along with some high-level considerations for their use. További részleteket a kapcsolódó témakörökben olvashat.Read more details in the linked topics.

N szintűN-tier

Az N szintű egy hagyományos architektúra vállalati alkalmazások számára.N-tier is a traditional architecture for enterprise applications. A függőségek kezelése érdekében az alkalmazás szintekre van osztva, amely szintekhez logikai függvények vannak hozzárendelve, például a megjelenítés, az üzleti logika vagy az adatok hozzáférése.Dependencies are managed by dividing the application into layers that perform logical functions, such as presentation, business logic, and data access. Az egyes szintek csak az alattuk lévő szinteket tudják meghívni.A layer can only call into layers that sit below it. Az ilyen vízszintes szintelrendezés azonban problémákat okozhat.However, this horizontal layering can be a liability. Adott esetben nehézkes lehet az alkalmas valamely részét úgy módosítani, hogy az ne érintse az alkalmazás egészét.It can be hard to introduce changes in one part of the application without touching the rest of the application. Így a gyakori frissítések problémásnak bizonyulhatnak, ami lelassítja az új funkciók hozzáadásának tempóját.That makes frequent updates a challenge, limiting how quickly new features can be added.

Az N szintű architektúra természetes választás az eleve szintekre osztott architektúrával rendelkező meglévő alkalmazások migrálásához.N-tier is a natural fit for migrating existing applications that already use a layered architecture. Ezért az N szintű architektúra a szolgáltatásként kínált infrastruktúra (IaaS-) megoldások, illetve az IaaS-megoldások és felügyelt szolgáltatások kombinációját használó alkalmazások esetében a leggyakoribb.For that reason, N-tier is most often seen in infrastructure as a service (IaaS) solutions, or application that use a mix of IaaS and managed services.

Webüzenetsor-feldolgozóWeb-Queue-Worker

A tisztán PaaS-megoldások esetében érdemes lehet alkalmazni egy Webüzenetsor-feldolgozó architektúrát.For a purely PaaS solution, consider a Web-Queue-Worker architecture. Az ilyen stílusú architektúrákban az alkalmazás egy HTTP-kéréseket feldolgozó webes előtérrendszerrel és egy, a processzorigényes feladatokat és a hosszabb átfutású műveleteket végrehajtó háttérfeldolgozóval rendelkezik.In this style, the application has a web front end that handles HTTP requests and a back-end worker that performs CPU-intensive tasks or long-running operations. Az előtér egy aszinkron üzenetsor segítségével kommunikál a feldolgozóval.The front end communicates to the worker through an asynchronous message queue.

A Webüzenetsor-feldolgozó architektúra néhány erőforrás-igényes feladattal rendelkező, viszonylag egyszerű tartományok esetében jelent megfelelő megoldást.Web-queue-worker is suitable for relatively simple domains with some resource-intensive tasks. Az N szintűhöz hasonlóan ez az architektúratípus is könnyen áttekinthető.Like N-tier, the architecture is easy to understand. A felügyelt szolgáltatások használata megkönnyíti az üzembe helyezést és az üzemeltetést.The use of managed services simplifies deployment and operations. Az összetettebb tartományok esetében azonban a függőségek kezelése nehézkesnek bizonyulhat.But with complex domains, it can be hard to manage dependencies. Az előtérrendszer és a feldolgozó hatalmas, monolitikus összetevőkké nőhetik ki magukat, amelyeket nehéz karbantartani és frissíteni.The front end and the worker can easily become large, monolithic components that are hard to maintain and update. Ez, ahogy az N szintű architektúra esetében, itt is csökkentheti a frissítések gyakoriságát, és korlátozhatja a fejlesztést.As with N-tier, this can reduce the frequency of updates and limit innovation.

MikroszolgáltatásokMicroservices

Ha az alkalmazás összetettebb tartománnyal rendelkezik, érdemes megfontolni a Mikroszolgáltatások architektúra használatát.If your application has a more complex domain, consider moving to a Microservices architecture. A mikroszolgáltatás-alkalmazásokat sok kisebb, független szolgáltatás alkotja.A microservices application is composed of many small, independent services. Mindegyik szolgáltatás egyetlen üzleti képességet valósít meg.Each service implements a single business capability. A szolgáltatások lazán vannak összekapcsolva, és API-egyezmények útján kommunikálnak.Services are loosely coupled, communicating through API contracts.

Az egyes szolgáltatások kialakításával kisebb, fókuszált fejlesztőcsapatok foglalkozhatnak.Each service can be built by a small, focused development team. Az egyes szolgáltatások anélkül vezethetők be, hogy ehhez nagy fokú koordinációra lenne szükség a csapatok között, ami elősegíti a gyakori frissítéseket.Individual services can be deployed without a lot of coordination between teams, which encourages frequent updates. A mikroszolgáltatási architektúra kiépítése és felügyelete összetettebb feladat, mint akár az N szintű, akár a webüzenetsor-feldolgozó architektúráé.A microservice architecture is more complex to build and manage than either N-tier or web-queue-worker. A használatához megalapozott fejlesztési és DevOps-kultúra szükséges.It requires a mature development and DevOps culture. Ha azonban jól van megvalósítva, ez a stílus hamarabb megjelentethető kiadásokat, gyorsabb fejlesztéseket és rugalmasabb architektúrát biztosít.But done right, this style can lead to higher release velocity, faster innovation, and a more resilient architecture.

Eseményvezérelt architektúraEvent-driven architecture

Az Eseményvezérelt architektúrák egy közzétételi-feliratkozási (pub-sub) modellt alkalmaznak, amelyben az adatalkotók közzétesznek eseményeket, az adatfelhasználók pedig feliratkoznak rájuk.Event-Driven Architectures use a publish-subscribe (pub-sub) model, where producers publish events, and consumers subscribe to them. Az adatalkotók függetlenek az adatfelhasználóktól, valamint az adatfelhasználók is egymástól.The producers are independent from the consumers, and consumers are independent from each other.

Az eseményvezérelt architektúra használata olyan alkalmazások esetében javasolt, amelyek nagy mennyiségű adatot olvasnak be és dolgoznak fel nagyon alacsony késleltetéssel. Ilyenek például az IoT-megoldások.Consider an event-driven architecture for applications that ingest and process a large volume of data with very low latency, such as IoT solutions. Ez az architektúrastílus akkor is hasznos, ha különböző alrendszereknek különböző típusú feldolgozási feladatokat kell elvégeznie ugyanazokon az eseményadatokon.The style is also useful when different subsystems must perform different types of processing on the same event data.

Big Data, Big ComputeBig Data, Big Compute

A Big Data és a Big Compute olyan specializált architektúrastílusok, amelyek bizonyos egyedi profilokhoz illeszkednek.Big Data and Big Compute are specialized architecture styles for workloads that fit certain specific profiles. A Big Data architektúra egy nagyon nagy adathalmazt adattömbökké darabol, és a teljes halmazt párhuzamosan dolgozza fel elemzési és jelentéskészítési célból.Big data divides a very large dataset into chunks, performing parallel processing across the entire set, for analysis and reporting. A Big Compute vagy más néven nagy teljesítményű feldolgozás (high-performance computing, HPC) párhuzamosan végez egyidejű számításokat nagyon nagy számú (több ezer) magon.Big compute, also called high-performance computing (HPC), makes parallel computations across a large number (thousands) of cores. Az alkalmazási tartomány lehet szimuláció, modellezés és 3D renderelés.Domains include simulations, modeling, and 3-D rendering.

Az architektúrastílus mint korlátozásArchitecture styles as constraints

Az architektúrastílusok korlátozzák az alkalmazások kialakítását, beleértve a felhasználható elemek körét és a köztük fennálló kapcsolatokat.An architecture style places constraints on the design, including the set of elements that can appear and the allowed relationships between those elements. A korlátozások az elérhető lehetőségek leszűkítésével formálják az architektúrák „alakját”.Constraints guide the "shape" of an architecture by restricting the universe of choices. Ha egy architektúra igazodik egy adott stílus korlátaihoz, bizonyos kívánatos tulajdonságok alakulnak ki.When an architecture conforms to the constraints of a particular style, certain desirable properties emerge.

A mikroszolgáltatások korlátai például a következők:For example, the constraints in microservices include:

  • Minden szolgáltatás egyetlen felelősséget jelöl.A service represents a single responsibility.
  • Mindegyik szolgáltatás független a többitől.Every service is independent of the others.
  • Az adatok csak az azokat birtokló szolgáltatás számára érhetők el.Data is private to the service that owns it. A szolgáltatások nem osztoznak az adatokon.Services do not share data.

A korlátok betartásával egy olyan rendszert kapunk, amelyben a szolgáltatások egymástól függetlenül helyezhetők üzembe, a hibák elszigetelten fordulnak elő, lehetséges a gyakori frissítés, és könnyen vezethetők be új technológiák az alkalmazásba.By adhering to these constraints, what emerges is a system where services can be deployed independently, faults are isolated, frequent updates are possible, and it's easy to introduce new technologies into the application.

Az egyes architektúrastílusok kiválasztása előtt mindenképp érdemes megismerni az adott stílus mögött húzódó irányelveket és a rá jellemző korlátokat.Before choosing an architecture style, make sure that you understand the underlying principles and constraints of that style. Ennek elmulasztása esetén előfordulhat, hogy egy olyan kialakítás valósul meg, amely a felszínen ugyan megfelel az adott stílusnak, azonban nem sikerül kiaknázni a stílusban rejlő minden lehetőséget.Otherwise, you can end up with a design that conforms to the style at a superficial level, but does not achieve the full potential of that style. Az is fontos, hogy gyakorlatiasan közelítsük meg a kérdést.It's also important to be pragmatic. Néha jobb feloldani valamely korlátot, mint mereven ragaszkodni az architektúra tisztaságához.Sometimes it's better to relax a constraint, rather than insist on architectural purity.

Az alábbi tábla összefoglalja, hogyan kezelik az egyes stílusok a függőségeket, és hogy melyik milyen típusú alkalmazási tartományokhoz alkalmas.The following table summarizes how each style manages dependencies, and the types of domain that are best suited for each.

ArchitektúrastílusArchitecture style FüggőségkezelésDependency management Alkalmazási tartomány típusaDomain type
N szintűN-tier Alhálózatokba tagolt vízszintes szintekHorizontal tiers divided by subnet Hagyományos üzleti tartományok.Traditional business domain. Ritkán kerül sor frissítésekre.Frequency of updates is low.
Webüzenetsor-feldolgozóWeb-Queue-Worker Előtér- és háttérfeladatok, aszinkron üzenetküldéssel leválasztva.Front and backend jobs, decoupled by async messaging. Néhány erőforrás-igényes feladattal rendelkező, viszonylag egyszerű tartományok.Relatively simple domain with some resource intensive tasks.
MikroszolgáltatásokMicroservices Függőlegesen (funkcionálisan) elkülönített szolgáltatások, amelyek egymást API-kon keresztül hívják meg.Vertically (functionally) decomposed services that call each other through APIs. Összetett tartomány.Complicated domain. Gyakori frissítések.Frequent updates.
Eseményvezérelt architektúraEvent-driven architecture. Adatalkotó/adatfelhasználó.Producer/consumer. Alrendszerenként független nézet.Independent view per sub-system. IoT és valósidejű rendszerekIoT and real-time systems
Big DataBig data Hatalmas adatkészlet felosztása kisebb tömbökre.Divide a huge dataset into small chunks. A helyi adatkészletek párhuzamos feldolgozása.Parallel processing on local datasets. Kötegelt és valós idejű adatelemzés.Batch and real-time data analysis. Prediktív elemzés ML használatával.Predictive analysis using ML.
Big ComputeBig compute Adatok kiosztása több ezer magra.Data allocation to thousands of cores. Nagy számításigényű tartományok, például szimuláció.Compute intensive domains such as simulation.

A kihívások és az előnyök mérlegeléseConsider challenges and benefits

A korlátozások kihívásokat hordoznak magukban, ezért fontos tisztában lenni az előnyökkel és hátrányokkal az egyes stílusok alkalmazásakor.Constraints also create challenges, so it's important to understand the trade-offs when adopting any of these styles. Vajon az architektúrastílus előnyei túlsúlyban vannak az esetleges kihívásokkal szemben az adott altartomány és a kapcsolódó kontextus esetén?Do the benefits of the architecture style outweigh the challenges, for this subdomain and bounded context.

Néhány problématípus, amelyeket érdemes mérlegelni az architektúrastílus kiválasztásakor:Here are some of the types of challenges to consider when selecting an architecture style:

  • Összetettség.Complexity. Az adott tartomány valóban megköveteli egy összetett architektúra használatát?Is the complexity of the architecture justified for your domain? Vagy ellenkezőleg, esetleg túl egyszerű a választott stílus a tartományhoz?Conversely, is the style too simplistic for your domain? Ha ez a helyzet, egy „nagy sárgolyó” (egy átláthatatlan rendszer) lesz a végeredmény, mivel az architektúra nem segít a függőségek egyértelmű kezelésében.In that case, you risk ending up with a "big ball of mud", because the architecture does not help you to manage dependencies cleanly.

  • Aszinkron üzenetkezelés és végleges konzisztencia.Asynchronous messaging and eventual consistency. Az aszinkron üzenetkezelés használatával a szolgáltatások szétválaszthatók, növelhető a megbízhatóság (mivel az üzenetek újraküldhetőek) és a méretezhetőség.Asynchronous messaging can be used to decouple services, and increase reliability (because messages can be retried) and scalability. Ez azonban problémákhoz vezethet a végleges konzisztencia kezelésével, illetve a duplikált üzenetek esetleges előfordulásával kapcsolatban.However, this also creates challenges in handling eventual consistency, as well as the possibility of duplicate messages.

  • Szolgáltatások közötti kommunikáció.Inter-service communication. Az alkalmazások külön szolgáltatásokra való lebontásakor fennáll annak a kockázata, hogy a szolgáltatások közötti kommunikáció elfogadhatatlan mértékű késést vagy a hálózat túlterhelését okozza (például a mikroszolgáltatási architektúrákban).As you decompose an application into separate services, there is a risk that communication between services will cause unacceptable latency or create network congestion (for example, in a microservices architecture).

  • Kezelhetőség.Manageability. Milyen bonyolult az alkalmazás felügyelete, a monitorozás, a frissítések telepítése stb.?How hard is it to manage the application, monitor, deploy updates, and so on?