Et t'as pas envie d'en parler ? T'utilises Revel, Gorilla, c'est interfacé avec une DB et un ORM, avec un reverse proxy ou en direct.
Ce projet en Go n'est pas une application web mais un "service" parmi d'autres (architecture SOA). On utilise aucun framework ou ORM et ça reçoit le trafic directement derrière un load-balancer cisco qui coûte les yeux de la tête.
Il y a énormément de business logic à l'intérieur de ce service, en fait pour être plus précis c'est un Ad-Network avec un système de real-time bidding auction, ça fait à la fois du CPC et du CPM.
Avec ce genre de trafic, ton principal bottleneck va être les I/O sur le network et le disque. Si tu veux avoir un nombre raisonnable de serveurs, tu ne peux donc pas aller lire/écrire directement dans une base de données et ce même en utilisant un pool de connexions car celui-ci va être atteints en quelques secondes et ainsi ralentir les autres goroutines qui attendent d'avoir une connection disponible. Sans pool, tu va très vite arriver à limite du nombre maximum de file descriptors même si tu personnalise cette valeur... bref je passe les détails...
La solution que l'on a adoptée est de tout faire en mémoire et d'avoir un démon le plus indépendant possible. Le service récupère ou reçoit les données qui vont bien à interval régulier. Une fois que tu a tweaker ton kernel aux petits oignons pour gérer autant de connexions TCP, ça roule comme sur des roulettes.
Pour info, l'ancien système tournait avec 30 serveurs PHP avec du hardware bien costaud et un cluster memcached, la plateforme ne scalait plus, en période de pointe le load average de certains serveur montaient à plus de 100 et le response time côté client pouvait dépasser la seconde. Le même système fonctionne aujourd'hui sur seulement 10 serveurs et la load est même pas à 1 ou 2 avec un response time de 4ms à 100ms, tout ça parce que l'on a éliminé un par un chacun des bottlenecks, surtout le fait de tout faire en mémoire on a plus de problème de IO. A la fin, on se retrouve avec une architecture vraiment simple car on a plus de cluster memcached/redis/mysql mais un simple démon sans dépendances.
On aurait pu faire la même chose en Java ou C++, mais en sachant que Go à été conçu exactement pour ce genre de problématique...
[^] # Re: Un troll juste pour moi :)
Posté par 0xfg . En réponse au journal S’il vous plaît... architecture-moi un Kanboard !. Évalué à 5.
Ce projet en Go n'est pas une application web mais un "service" parmi d'autres (architecture SOA). On utilise aucun framework ou ORM et ça reçoit le trafic directement derrière un load-balancer cisco qui coûte les yeux de la tête.
Il y a énormément de business logic à l'intérieur de ce service, en fait pour être plus précis c'est un Ad-Network avec un système de real-time bidding auction, ça fait à la fois du CPC et du CPM.
Avec ce genre de trafic, ton principal bottleneck va être les I/O sur le network et le disque. Si tu veux avoir un nombre raisonnable de serveurs, tu ne peux donc pas aller lire/écrire directement dans une base de données et ce même en utilisant un pool de connexions car celui-ci va être atteints en quelques secondes et ainsi ralentir les autres goroutines qui attendent d'avoir une connection disponible. Sans pool, tu va très vite arriver à limite du nombre maximum de file descriptors même si tu personnalise cette valeur... bref je passe les détails...
La solution que l'on a adoptée est de tout faire en mémoire et d'avoir un démon le plus indépendant possible. Le service récupère ou reçoit les données qui vont bien à interval régulier. Une fois que tu a tweaker ton kernel aux petits oignons pour gérer autant de connexions TCP, ça roule comme sur des roulettes.
Pour info, l'ancien système tournait avec 30 serveurs PHP avec du hardware bien costaud et un cluster memcached, la plateforme ne scalait plus, en période de pointe le load average de certains serveur montaient à plus de 100 et le response time côté client pouvait dépasser la seconde. Le même système fonctionne aujourd'hui sur seulement 10 serveurs et la load est même pas à 1 ou 2 avec un response time de 4ms à 100ms, tout ça parce que l'on a éliminé un par un chacun des bottlenecks, surtout le fait de tout faire en mémoire on a plus de problème de IO. A la fin, on se retrouve avec une architecture vraiment simple car on a plus de cluster memcached/redis/mysql mais un simple démon sans dépendances.
On aurait pu faire la même chose en Java ou C++, mais en sachant que Go à été conçu exactement pour ce genre de problématique...