Die Implementierung basiert auf einem Java Open Source Stack. Spring 2.0 wird genutzt. Spring dient auch und vor allem als Integrations-Plattform der verschiedenen Technologien. Dann wird noch Hibernate 3, Velocity 1.5, YUI/JSON, EHCache, ROME, C3PO etc. Der Resin-Web-Server wird als Produktivumgebung genutzt und entwickelt wurde auf Jetty. Sie haben auch Ruby on Rails evaluiert, aber hatten damals nicht das Vertrauen in diese Plattform.
Als Design-Ansatz wurde Domain Driven Design (DDD) genutzt mit dem Ziel einer klaren und expliziten Modellierung der Domäne. Trotz der scheibaren trivialen Domäne - CMS ist ja eigentlich ein Thema für Standard-Software - gab es eine Menge spezifischem Business-Code. Vor allem das DDD-Prinzip der Ubiquitous Language wurde genutzt, also die gemeinsame Sprache im gesamten Projekt, die sowohl von den Nutzern, Entwicklern und auch im Code genutzt wird. Dadurch wird die Domäne auch im Code wirklich abgebildet.
In dem Projekt haben die Entwickler einen eigenen Aspekt gebaut, der bei einer Änderung an der Site auch gleich den Cache invalidiert. Dabei hängt sich der Aspekt an die Transaktions-Verwaltung, so dass beim Beenden der Transaktion auch dei Objekte aus dem Cache entsprechend entfernt werden. Hier sind man den Power von Spring und Spring AOP.
Ein wichtiges Problem ist natürlich Performance. Der Guardian hat im Schnitt 150 Millionen Hits pro Monat, wobei es sehr unterschiedlich viel Belastung gibt und vor allem die Lastspitzen sind das Problem - man denke nur an 9/11. Alle Seiten werden dynamisch erzeugt. Sie nutzen EHCache für Hibernate Objekte und für HTML-Komponenten. Die Hibernate-Objekte tauchen recht schnell im Cache auf, weil viele Seiten dieselben Objekte verwenden. Bei einem reinen HTML-Cache würde das deutlich länger dauern. Ein Server hat nach ungefähr 4 Minuten einen voll funktionsfähigen Cache. Außerdem machen sie in Bezug auf den Prozess Performance-Tests und ein einfaches Design. Auch beim Cache dominitert Einfachheit: Sie nutzen EHCache, der einfach ist und gut verstandende Konfigurations-Parameter hat.
Zuvor lief die Seite auf Vignette und TCL. Dadurch waren die Seiten mit URLs ausgestattet, wie http://www.guardian.co.uk/story/0,,125425,0.html . Das neue System hat URLs wie http://www.guardian.co.uk/news/iraq/2007/06/28/cabinet . Die alten Bookmarks sollten aber weiterhin funktioniere. Das ist notwendig, weil 30-40% des Traffics auf alte Seiten geht, also von alten Bookmarks kommt. Dazu haben sie mit Apache ein System gebaut, dass die alten URLs auf die neuen URLs abbildet. Sie nutzen mod_asis dafür und schicken den Inhalt eines Files auf der Platte als Antwort. Dieses File enthält dann das Redirect - ein recht einfacher Ansatz.
Der Talk zeigt recht deutlich, wie man sehr große Sites mit Technologien wie Spring implementieren kann. Dabei bekommt man auch sehr gute Performance hin - mit relativ "normalen" Ansätzen. Und man kann mit AOP dann auch interessante Features implementierten - wie zum Beispiel das Cache-Handling.
Labels: Erik Dörnenburg, Guardian, JAOO2007, Matt Wall, Spring, Spring MVC
¶ 17:22
