Implantació d'Arquitectures Web
1. Aspectes generals d'arquitectures web
Una arquitectura web és l'estructura que defineix com s'organitzen i interactuen els components d'una aplicació web. Estableix com el client (navegador) i el servidor intercanvien informació, i com es gestionen les dades i serveis.
Els components bàsics de l'arquitectura són:
- client web
- servidor web
- servidor d'aplicacions
- sistema gestor de base de dades
- xarxa de comunicacions.
Els objectius d'aquesta arquitectura són millorar el rendiment, la seguretat, la mantenibilitat i l'escalabilitat de les aplicacions.
Els diferents components es poden comunicar mitjançant peticions HTTP/HTTPS, serveis web REST o SOAP, o protocols de xarxa.
El model TCP/IP
El model TCP/IP és la base de les comunicacions a Internet i a la majoria de xarxes locals.
Esta dividit en capes i cada capa té una funció pròpia i utilitza un sistema d’adreçament específic per identificar qui envia i rep la informació.
Capes del model TCP/IP
1. Capa d’aplicació
- Funció: proporciona serveis directament a l’usuari o a les aplicacions.
- Protocols típics: HTTP, FTP, DNS, SMTP.
- Unitat de dades: Dades (Data).
- Adreçament: noms simbòlics (per exemple,
www.exemple.com,proves.daw) que després es tradueixen a IP mitjançant DNS.
2. Capa de transport
- Funció: garanteix la comunicació d’un extrem a l’altre.
- Protocols: TCP (fiable, orientat a connexió), UDP (ràpid, sense connexió).
- Unitat de dades: Segments (TCP) o Datagrames (UDP).
- Adreçament: ports lògics (0–65535) que identifiquen processos o aplicacions.
- Exemple: HTTP → port 80, HTTPS → port 443, SSH → port 22.
3. Capa d’internet
- Funció: identificar i encaminar els paquets entre xarxes diferents.
- Protocols: IP, ICMP, ARP.
- Unitat de dades: Paquet (Packet).
- Adreçament: adreces IP (IPv4 o IPv6).
- Exemple IPv4:
192.168.1.10 - Exemple IPv6:
2001:db8::1
4. Capa d’accés a la xarxa (enllaç)
- Funció: defineix com enviar les dades físicament pel medi (cable, fibra, Wi-Fi...).
- Protocols: Ethernet, Wi-Fi (802.11), PPP.
- Unitat de dades: Trama (Frame).
- Adreçament: adreces físiques (MAC), úniques per a cada targeta de xarxa.
- Exemple:
00:1A:2B:3C:4D:5E
Tipus d’adreces IPv4
Privades (no enruten a Internet):
10.0.0.0 – 10.255.255.255172.16.0.0 – 172.31.255.255192.168.0.0 – 192.168.255.255
Públiques: qualsevol altra adreça utilitzada a Internet.
Especials:
127.0.0.1/8→ loopback (localhost).0.0.0.0→ adreça per defecte / desconeguda.255.255.255.255→ broadcast.
2. Escalabilitat, portabilitat i componentització
L'escalabilitat és la capacitat del sistema per suportar un augment de la càrrega de treball sense perdre rendiment. Hi ha dos tipus d'escalabilitat:
- Escalabilitat horitzontal: afegir més màquines (servidors).
- Escalabilitat vertical: augmentar els recursos d'un servidor (CPU, RAM).
La portabilitat és la facilitat per executar una aplicació en diferents entorns (sistemes operatius, maquinari, núvols). S'aconsegueix utilitzant tecnologies multiplataforma i contenidors.
El concepte de componentització fa referència a la divisió de l'aplicació en mòduls independents i reutilitzables. Dissenyar una aplicació basada en components millora la mantenibilitat i permet el treball paral·lel de diversos equips. Per a aconseguir-ho solen utilitzar-se patrons de disseny com MVC (Model-View-Controller), MVVM (Model-View-ViewModel) i microserveis, entre altres.
Patrons de disseny
Un patró de disseny és una solució general a un problema comú i recurrent en el disseny de programari. Un patró de disseny no és un disseny acabat que es pot transformar directament en codi; és una descripció o plantilla per resoldre un problema que es pot utilitzar en moltes situacions diferents.
3. Arquitectures web: models
Arquitectura de 2 capes
Una arquitectura client–servidor on la lògica es reparteix entre el client i el servidor de dades. El client (aplicació d’escriptori o web molt "pesada") accedeix directament a la base de dades.
Les característiques d'aquesta arquitectura són:
- Connexió directa del client a la BD (ODBC/JDBC/SQL cru).
- Molta lògica en el client: validacions, càlculs, regles.
- Desplegament ràpid en entorns petits.
Quant a avantatges:
- Simplicitat d’arquitectura i menor latència client↔BD en LAN.
- Menys components a administrar (no hi ha servidor d’aplicacions).
- Adequat per a entorns locals o d’oficina amb pocs usuaris.
I respecte als inconvenients:
- Escalabilitat limitada (cada client obri connexions a la BD).
- Seguretat: exposar la BD als clients implica més superfície d’atac.
- Mantenibilitat: actualitzar lògica requereix redeploy a tots els clients.
- Dificultats per a multi-capa (caché, API, CQRS…) i per a integracions.
Sol emprar-se en:
- Aplicacions internes petites, de backoffice, amb pocs usuaris i LAN fiable.
- Prototips o eines d’administració.
Arquitectura de 3 capes
Separa clarament Presentació, lògica de negoci i dades. El client no accedeix a la BD: ho fa a través d’un servidor d’aplicacions (API/servei).
(Web/Mòbil)"] <-- HTTP/HTTPS --> A["Servidor d'aplicacions"] A <-- SQL/ORM --> DB[(Base de dades)]
En el diagrama anterior es pot observar com la capa de presentació (web SPA/SSR o app mòbil) parla amb el servidor d'aplicacions. Aquest conté la capa de negoci on aplica les regles o estableix els nivells seguretat, entre altres coses. D'aquesta forma la capa de dades queda aïllada i protegida.
Els avantatges de l'arquitectura de 3 capes el podem resumir en:
- Escalabilitat: es pot escalar horitzontalment la capa d’API.
- Seguretat: la BD no s’exposa; control d’accés centralitzat.
- Mantenibilitat: lògica centralitzada; facilita testing i CI/CD.
- Reutilització: la mateixa API serveix web, mòbil, integracions.
Aquesta arquitectura sol emprar-se per a crear aplicacions web/mòbils de mida mitjana o gran.
Arquitectures orientades a serveis (SOA) i microserveis
Model més modern basat en dividir l'aplicació en serveis independents, cadascun amb la seua funció i, sovint, amb la seua pròpia base de dades.
En esta arquitectura cada servei és autònom i es comunica amb la resta via API o missatges. Es poden desplegar i actualitzar de manera independent.
Els principals avantatges són:
- Escalabilitat elevada (s’escala només el servei necessari).
- Facilita el treball en equips grans i independents.
- Major resiliència davant errors.
I quant a inconvenients:
- Més complexitat d’arquitectura i administració.
- Necessita una bona coordinació i eines de DevOps.
Sol utilitzar-se en aplicacions grans i amb molts usuaris i plataformes que evolucionen ràpid i necessiten desplegaments freqüents.
En el diagrama el client es comunica amb l'API Gateway, punt d'entrada als serveis, que es comunicarà en el servei demandat. En aquest exemple els tres serveis tenen bases de dades separades.
4. Plataformes web lliures i propietàries
Quan parlem de servidors i plataformes per al desplegament d’aplicacions web, és important distingir entre programari lliure i programari propietari.
El programari lliure —també conegut com open source— posa a disposició dels usuaris el codi font, cosa que permet modificar-lo, redistribuir-lo i adaptar-lo a necessitats concretes. A més, sol estar recolzat per comunitats molt actives que ofereixen suport, documentació i millores constants. En canvi, el programari propietari és desenvolupat i mantingut per una empresa que n’estableix les condicions d’ús a través d’una llicència. El codi font no és accessible, i l’ús sol estar subjecte al pagament d’una subscripció o llicència comercial.
A continuació, es descriuen les plataformes més representatives en cada àmbit.
Plataformes lliures
Entre les plataformes lliures més conegudes destaca Apache HTTP Server, probablement el servidor web més utilitzat del món. La seua popularitat es deu a la seua estabilitat, maduresa i la gran capacitat de configuració que ofereix a través de mòduls. Està disponible en múltiples sistemes operatius i és una solució habitual en serveis d’allotjament web compartit.
Una alternativa molt estesa és Nginx, un servidor web dissenyat per ser lleuger i eficient. S’ha consolidat com la millor opció per servir contingut estàtic i, al mateix temps, per actuar com a proxy invers i balancejador de càrrega. Això el fa especialment adequat per a aplicacions que gestionen un gran volum de tràfic concurrent o per arquitectures basades en microserveis.
En l’àmbit de les aplicacions Java, Apache Tomcat és un servidor especialitzat en l’execució de servlets i JSP. Tot i ser més senzill que altres plataformes empresarials, resulta molt pràctic per a projectes mitjans, prototips i entorns educatius, ja que és fàcil d’instal·lar, configurar i mantenir.
Plataformes propietàries
Entre les plataformes propietàries, una de les més conegudes és Microsoft IIS (Internet Information Services). Està integrada a Windows Server i ofereix una administració senzilla mitjançant interfícies gràfiques. Es tracta de l’opció natural per a entorns que treballen amb tecnologies Microsoft, com ASP.NET, i que necessiten una bona integració amb Active Directory o Exchange.
Per a entorns empresarials més exigents en l’àmbit Java, Oracle WebLogic és una de les opcions més potents. Està pensat per gestionar grans volums de transaccions i s’integra de manera òptima amb altres productes Oracle, com les bases de dades o el middleware corporatiu. El seu punt fort és el suport empresarial i l’estabilitat que ofereix en aplicacions mission critical.
5. Servidors web i d'aplicacions
En el desplegament d’una aplicació web és fonamental distingir entre el servidor web i el servidor d’aplicacions, ja que cadascun té un paper diferent dins de l’arquitectura.
El servidor web és el component encarregat de rebre i atendre les peticions HTTP dels clients. El seu objectiu principal és servir contingut estàtic, com ara fitxers HTML, fulls d’estil CSS, arxius JavaScript o imatges. Un exemple clàssic seria quan un usuari demana accés a una pàgina web senzilla i el servidor simplement envia el fitxer HTML corresponent al navegador. Plataformes com Apache HTTP Server o Nginx són representants típics d’aquesta categoria. A més, els servidors web poden actuar com a proxy invers o balancejadors de càrrega, distribuint el trànsit entre diversos servidors d’aplicacions per millorar el rendiment i la disponibilitat.
D’altra banda, el servidor d’aplicacions va més enllà de la gestió de fitxers estàtics: és el responsable d’executar la lògica de negoci i generar contingut dinàmic. Això vol dir que processa peticions més complexes, com consultes a bases de dades, càlculs interns o crides a serveis externs. Quan un usuari envia un formulari, per exemple, el servidor d’aplicacions és qui interpreta la informació, la valida i retorna una resposta adaptada. Alguns exemples de servidors d’aplicacions són Tomcat (per aplicacions Java), WildFly, WebLogic o .NET Application Server.
En molts entorns moderns, tots dos tipus de servidor treballen conjuntament. El servidor web rep totes les peticions i serveix directament el contingut estàtic, mentre que redirigeix les sol·licituds dinàmiques cap al servidor d’aplicacions. Aquest model permet optimitzar el rendiment i reforçar la seguretat, ja que la base de dades i la lògica de negoci no s’exposen directament a Inter
Navegador"] -->|HTTP/HTTPS| WS["Servidor Web
(Apache/Nginx)"] WS -->|Contingut estàtic| U WS -->|"Peticions dinàmiques"| AS["Servidor d'Aplicacions
(Java, .NET, PHP...)"] AS --> DB[(Base de dades)]
6. Tecnologies de virtualització
La virtualització és una de les bases fonamentals de la informàtica moderna i del desplegament d’aplicacions web. Aquesta tecnologia permet aprofitar al màxim els recursos d’un únic equip físic per executar-hi diverses màquines virtuals o entorns aïllats, cadascun amb les seues pròpies funcions i característiques.
En lloc de dedicar un ordinador complet a cada servei, la virtualització reparteix la potència del maquinari disponible —processador, memòria, disc i xarxa— entre diversos sistemes independents. Això permet optimitzar el rendiment, reduir costos i augmentar la flexibilitat i la seguretat en el desplegament d’aplicacions. En essència, un únic servidor físic pot convertir-se en molts “ordinadors virtuals” capaços de treballar com si cadascun fora un dispositiu real.
Virtualització completa
En el model de virtualització completa, un servidor físic es divideix en diverses màquines virtuals (VM), cadascuna amb el seu propi sistema operatiu. Aquest tipus de virtualització permet crear entorns totalment independents entre si: si una màquina falla, les altres continuen funcionant sense interrupcions.
Per aconseguir-ho s’utilitza un programa especial anomenat hipervisor, que gestiona els recursos físics i els reparteix entre les màquines virtuals. L’hipervisor controla la CPU, la memòria, el disc i la xarxa, i ofereix a cada VM una “visió pròpia” del maquinari, com si tinguera un ordinador exclusiu.
Tipus d’hipervisors
Els hipervisors es classifiquen en dos grans tipus segons com s’executen:
- Tipus 1 (bare-metal): funcionen directament sobre el maquinari físic, sense cap sistema operatiu intermedi. Són més eficients i s’utilitzen sobretot en entorns professionals o centres de dades. Exemples: VMware ESXi, Microsoft Hyper-V, KVM.
- Tipus 2 (hosted_): s’instal·len sobre un sistema operatiu existent i permeten crear màquines virtuals dins d’aquest entorn. Són ideals per a proves o per a ús docent. Exemples: VMware Workstation, Oracle VirtualBox.
Avantatges de la virtualització completa
Aquest model aporta nombrosos beneficis:
- Reducció de costos, ja que es necessita menys maquinari físic.
- Consolidació de servidors, permetent executar diversos serveis en un sol equip.
- Aïllament complet: una fallada en una màquina virtual no afecta la resta.
- Flexibilitat i alta disponibilitat, perquè les màquines virtuals es poden crear, eliminar o migrar amb facilitat.
Les eines més habituals per gestionar aquest tipus de virtualització són VMware vSphere, Microsoft Hyper-V i KVM, totes àmpliament utilitzades en entorns professionals.
Virtualització de sistemes operatius: els contenidors
Una altra forma de virtualitzar és la virtualització a nivell de sistema operatiu, més coneguda com a contenidors. En aquest cas no es creen màquines virtuals completes, sinó que s’executen diverses aplicacions aïllades dins d’un mateix sistema operatiu. Els contenidors comparteixen el nucli (kernel) del sistema host, la qual cosa els fa molt més lleugers i ràpids que les màquines virtuals tradicionals.
Cada contenidor encapsula una aplicació i totes les seues dependències (biblioteques, configuracions, etc.), garantint que s’executarà de la mateixa manera en qualsevol entorn.

Figura 1. Esquema comparatiu entre màquines virtuals i contenidors: les VM tenen un sistema operatiu propi, mentre que els contenidors comparteixen el nucli del host.
Els contenidors destaquen per:
- Lleugeresa, ja que requereixen menys recursos.
- Escalabilitat, poden crear-se o eliminar-se en segons.
- Portabilitat, funcionen igual en qualsevol entorn amb Docker instal·lat.
- Aïllament adequat, suficient per garantir estabilitat i seguretat sense sobrecàrrega.
Les eines més populars en aquest àmbit són Docker, Kubernetes, Docker Compose i LXC.
Docker i el món dels contenidors
Docker és la plataforma de referència per treballar amb contenidors. Es tracta d’una eina de codi obert que automatitza el desplegament d’aplicacions empaquetant-les amb tot el necessari per funcionar: codi, llibreries i configuracions.
L’element central és el Docker Engine, el motor que permet crear i executar contenidors. Al seu voltant hi trobem altres components com Docker Hub, un repositori públic d’imatges, i les pròpies imatges Docker, que són plantilles a partir de les quals es creen els contenidors.

Figura 2. Arquitectura de Docker: motor, imatges, contenidors i repositori Docker Hub.
El procés: del Dockerfile al contenidor
Per construir una imatge Docker, s’utilitza un fitxer anomenat Dockerfile.
Aquest fitxer conté una sèrie d’instruccions que indiquen a Docker com ha de crear la imatge pas a pas, de manera semblant a una recepta.
Per exemple:
FROM ubuntu:latest
RUN apt-get update && apt-get install -y python3
COPY . /app
CMD ["python3", "/app/main.py"]
Quan s’executa l'ordre següent, Docker llegeix el Dockerfile i construeix una imatge:
docker build -t app-python .
Aquesta imatge és de només lectura i conté tot el necessari per executar l’aplicació.
Després, podem crear un contenidor, que és una instància en execució d’aquesta imatge:
docker run -d -p 80:80 app-python
En aquest cas, es llança un contenidor basat en la imatge app-python, que exposa el port 80 per servir l’aplicació.
Gestió de recursos en Docker
Docker permet crear volums per emmagatzemar dades de manera persistent, encara que el contenidor s’elimine o reinicie, i xarxes per comunicar diversos contenidors entre si.
Algunes de les ordres més habituals són:
docker ps– llista els contenidors actiusdocker stop– atura un contenidordocker build– construeix una imatge a partir d’unDockerfiledocker pull– descarrega imatges des de Docker Hub
Orquestració amb Docker Compose
Quan una aplicació necessita diversos serveis (com un servidor web i una base de dades), entra en joc Docker Compose. Aquesta eina permet definir i executar aplicacions multi-contenidor mitjançant un fitxer docker-compose.yml, que descriu tots els serveis, xarxes i volums implicats.

Figura 3. Exemple d’aplicació multi-contenidor amb Docker Compose: un servei web i una base de dades connectats en una mateixa xarxa virtual.
Exemple:
version: '3'
services:
web:
image: nginx
ports:
- "80:80"
depends_on:
- db
db:
image: mysql
environment:
MYSQL_ROOT_PASSWORD: exemple
volumes:
- db_data:/var/lib/mysql
volumes:
db_data:
Amb la simple ordre docker-compose up, es creen i s’executen tots els serveis definits al fitxer, comunicant-se entre ells de forma automàtica.
Contenidors vs màquines virtuals
Tot i que tant la virtualització completa com els contenidors permeten aprofitar millor els recursos i crear entorns aïllats, hi ha diferències clau entre ambdues tecnologies:
| Característica | Contenidors | Màquines virtuals |
|---|---|---|
| Pes | Lleugers (comparteixen el nucli) | Pesats (tenen un SO complet) |
| Aïllament | Mitjà | Complet |
| Velocitat d’inici | Molt ràpida | Més lenta |
| Ús de recursos | Més eficient | Més demandant |
En resum, la virtualització completa és ideal per a entorns on la seguretat i l’aïllament són prioritaris, mentre que els contenidors destaquen en escenaris on la rapidesa, la portabilitat i l’escalabilitat són essencials, com ara el desplegament de microserveis o aplicacions al núvol.
7. Estructura i recursos d'una aplicació web
- Client (frontend): HTML, CSS, JavaScript, imatges, fitxers multimèdia.
- Servidor (backend): lògica de negoci, APIs, gestió de dades i seguretat.
- Base de dades: sistema gestor (SQL o NoSQL) i els esquemes de dades.
- Arxius de configuració:
.env,config.yml, etc. - Descriptor de desplegament: defineix com s'ha d'executar l'aplicació (
web.xml,application.yml,Dockerfile, etc.).
8. Programari lliure vs. programari propietari
| Aspecte | Programari lliure | Programari propietari |
|---|---|---|
| Llicència | Oberta (GPL, MIT, Apache...) | Tancada |
| Cost | Normalment gratuït | Sol licència de pagament |
| Accés al codi font | Sí | No |
| Suport tècnic | Comunitari | Oficial de l'empresa |
| Personalització | Alta | Limitada |
Criteris de selecció: pressupost, necessitat de suport, grau de personalització i seguretat requerida.
9. Documentació dels processos realitzats
- Redactar un manual amb:
- Objectiu i entorn utilitzat.
- Passos d'instal·lació i configuració amb comandes i captures.
- Proves realitzades i resultats.
- Problemes trobats i solucions aplicades.
- Utilitzar eines de control de versions (Git) per registrar els canvis i millores.
- Guardar la documentació en formats reutilitzables (
.md,.pdf) i compartir-la amb l'equip.