Ola! Chámome Alexey Pyankov, son un programador da empresa Sportmaster. Niso Contei como comezaron os traballos na web de Sportmaster en 2012, que iniciativas conseguimos "impulsar" e viceversa, que rastrillo recollemos.
Hoxe quero compartir pensamentos que seguen a outro tema: escoller un sistema de almacenamento en caché para o backend java no panel de administración do sitio. Esta trama ten un significado especial para min: aínda que a historia se desenvolveu durante só 2 meses, durante estes 60 días traballamos 12-16 horas e sen un só día de descanso. Nunca pensei nin imaxinara que fose posible traballar tan duro.
Polo tanto, dividín o texto en 2 partes para non cargalo completamente. Pola contra, a primeira parte será moi lixeira: preparación, introdución, algunhas consideracións sobre o que é a caché. Se xa es un programador experimentado ou traballaches con cachés, desde o lado técnico probablemente non haxa nada novo neste artigo. Pero para un júnior, unha revisión tan pequena pode dicirlle en que dirección mirar se se atopa en tal encrucillada.
Cando se puxo en produción a nova versión do sitio web de Sportmaster, os datos recibíronse dun xeito que, por dicilo suavemente, non era moi cómodo. A base foron táboas preparadas para a versión anterior do sitio (Bitrix), que tiveron que ser incorporadas a ETL, levadas a unha nova forma e enriquecidas con varias pequenas cousas dunha ducia de sistemas máis. Para que apareza unha nova imaxe ou descrición do produto no sitio, tivo que esperar ata o día seguinte: as actualizacións só se actualizan pola noite, unha vez ao día.
Ao principio, houbo tantas preocupacións desde as primeiras semanas de entrada en produción que tales inconvenientes para os xestores de contidos foron un pouco. Pero, tan pronto como todo se axustou, o desenvolvemento do proxecto continuou: uns meses despois, a principios de 2015, comezamos a desenvolver activamente o panel de administración. En 2015 e 2016, todo vai ben, lanzamos regularmente, o panel de administración cobre cada vez máis a preparación de datos e estamos preparándonos para o feito de que pronto o noso equipo se lle encomendará o máis importante e complexo: o produto. circuíto (preparación completa e mantemento dos datos de todos os produtos). Pero no verán de 2017, xusto antes do lanzamento do circuíto de mercadorías, o proxecto atoparase nunha situación moi difícil, precisamente por problemas coa caché. Quero falar deste episodio na segunda parte desta publicación en dúas partes.
Pero neste post comezarei de lonxe, presentarei algunhas reflexións: ideas sobre a caché, que sería un bo paso para desprazarse antes dun proxecto grande.
Cando se produce unha tarefa de almacenamento na caché
A tarefa de almacenamento na caché non só aparece. Somos desenvolvedores, escribimos un produto de software e queremos que teña demanda. Se o produto é demandado e exitoso, virán os usuarios. E cada vez veñen máis. E despois hai moitos usuarios e despois o produto está moi cargado.
Nas primeiras etapas, non pensamos na optimización e no rendemento do código. O principal é a funcionalidade, lanzar rapidamente un piloto e probar hipóteses. E se a carga aumenta, bombeamos o ferro. Aumentámolo dúas ou tres veces, cinco veces, quizais 10 veces. En algún lugar aquí: as finanzas xa non o permitirán. Cantas veces aumentará o número de usuarios? Non será como 2-5-10, pero se ten éxito, será de 100-1000 a 100 mil veces. É dicir, tarde ou cedo, terás que facer optimización.
Digamos que algunha parte do código (chamemos a esta parte unha función) leva un tempo indecente e queremos reducir o tempo de execución. Unha función pode ser o acceso a unha base de datos, ou pode ser a execución dalgunha lóxica complexa - o principal é que leva moito tempo para completar. Canto pode reducir o tempo de execución? No límite, pode reducilo a cero, sen máis. Como se pode reducir o tempo de execución a cero? Resposta: eliminar a execución por completo. Pola contra, devolve o resultado inmediatamente. Como podes saber o resultado? Resposta: ou calculalo ou mira para algún lado. Leva moito tempo calcular. E espiar é, por exemplo, lembrar o resultado que produciu a función a última vez cando se chamou cos mesmos parámetros.
É dicir, a implementación da función non é importante para nós. Basta con saber de que parámetros depende o resultado. Entón, se os valores dos parámetros se representan en forma de obxecto que se pode usar como chave nalgún almacenamento, entón o resultado do cálculo pódese gardar e ler a próxima vez que se acceda a el. Se esta escritura e lectura do resultado é máis rápida que a execución da función, temos un beneficio en termos de velocidade. A cantidade de beneficios pode chegar a 100, 1000 e 100 mil veces (10 ^ 5 é máis ben unha excepción, pero no caso dunha base bastante atrasada, é moi posible).
Requisitos básicos para un sistema de caché
O primeiro que pode converterse nun requisito para un sistema de caché é a velocidade de lectura rápida e, en menor medida, a velocidade de escritura. Isto é certo, pero só ata que poñamos o sistema en produción.
Imos xogar a este caso.
Digamos que proporcionamos a carga actual con hardware e que agora estamos introducindo gradualmente a caché. O número de usuarios medra un pouco, a carga medra: engadimos un pouco de cachés, enróllamos aquí e alí. Isto continúa durante algún tempo, e agora as funcións pesadas practicamente xa non se chaman: toda a carga principal recae na caché. O número de usuarios durante este tempo aumentou N veces.
E se a subministración inicial de hardware podería ser 2-5 veces, entón coa axuda da caché poderiamos mellorar o rendemento por un factor de 10 ou, nun bo caso, por un factor de 100, nalgúns lugares quizais por un factor. de 1000. É dicir, no mesmo hardware: procesamos 100 veces máis solicitudes. Xenial, mereces o pan de xenxibre!
Pero agora, nun bo momento, por casualidade, o sistema fallou e a caché colapsou. Nada especial: despois de todo, a caché escolleuse en función do requisito de "alta velocidade de lectura e escritura, o resto non importa".
En relación á carga inicial, a nosa reserva de ferro foi de 2 a 5 veces e a carga durante este tempo aumentou de 10 a 100 veces. Usando a caché, eliminamos as chamadas de funcións pesadas e, polo tanto, todo funcionou. E agora, sen unha caché, cantas veces ralentizará o noso sistema? Que nos vai pasar? O sistema caerá.
Aínda que a nosa caché non fallase, senón que só se borrara durante un tempo, terá que quentala, e isto levará algún tempo. E durante este tempo, a principal carga recaerá na funcionalidade.
Conclusión: os proxectos de produción moi cargados requiren un sistema de caché non só para ter altas velocidades de lectura e escritura, senón tamén para garantir a seguridade dos datos e a resistencia aos fallos.
A agonía da elección
Nun proxecto cun panel de administración, a elección foi así: primeiro instalamos Hazelcast, porque Xa estabamos familiarizados con este produto pola experiencia do sitio principal. Pero aquí esta elección resultou ser infructuosa: baixo o noso perfil de carga, Hazelcast non só é lenta, senón terriblemente lenta. E nese momento xa nos apuntaramos para a data de estrea.
Spoiler: como se desenvolveron exactamente as circunstancias de que nos perdemos un negocio tan grande e acabamos cunha situación aguda e tensa -contovos na segunda parte- e como acabamos e como saímos. Pero agora, só direi que foi moito estrés e "pensar, de algunha maneira non podo pensar, estamos axitando a botella". "Shaking the bottle" tamén é un spoiler, sobre iso máis tarde.
O que fixemos:
- Facemos unha lista de todos os sistemas que suxiren Google e StackOverflow. Algo máis de 30
- Escribimos probas cunha carga típica para a produción. Para iso, gravamos os datos que pasan polo sistema nun ambiente de produción: unha especie de rastreador de datos non na rede, senón dentro do sistema. Exactamente estes datos utilizáronse nas probas.
- Con todo o equipo, todos seleccionan o seguinte sistema da lista, configúrao e realiza probas. Non pasa a proba, non leva a carga: botámolo e pasamos ao seguinte da fila.
- No sistema 17 quedou claro que todo estaba desesperado. Deixa de axitar a botella, é hora de pensar en serio.
Pero esta é unha opción cando necesitas escoller un sistema que "pase a velocidade" nas probas preparadas previamente. E se aínda non hai tales probas e queres escoller rapidamente?
Modelemos esta opción (é difícil imaxinar que un desenvolvedor medio+ vive no baleiro e no momento da selección aínda non formalizou a súa preferencia sobre que produto probar primeiro; polo tanto, un razoamento adicional é máis un teórico/filosofía/). sobre un junior).
Unha vez decididos os requisitos, comezaremos a seleccionar unha solución fóra da caixa. Por que reinventar a roda: imos tomar un sistema de caché preparado.
Se estás comezando e buscas en Google, dá ou recibe o pedido, pero en xeral, as pautas serán así. En primeiro lugar, atoparás a Redis, escóitase por todas partes. Entón descubrirás que EhCache é o sistema máis antigo e comprobado. A continuación escribiremos sobre Tarantool, un desenvolvemento doméstico que ten un aspecto único da solución. E tamén Ignite, porque agora está en aumento en popularidade e goza do apoio de SberTech. Ao final tamén está Hazelcast, porque no mundo empresarial adoita aparecer entre as grandes empresas.
A lista non é exhaustiva; hai decenas de sistemas. E só fomos unha cousa. Imos tomar os 5 sistemas seleccionados para o "concurso de beleza" e facer unha selección. Quen será o gañador?
Redis
Lemos o que escriben na web oficial.
- proxecto de código aberto. Ofrece almacenamento de datos en memoria, a capacidade de gardar no disco, partición automática, alta dispoñibilidade e recuperación de interrupcións da rede.
Parece que todo está ben, podes collelo e atornillalo, todo o que necesitas, faino. Pero só por diversión, vexamos os outros candidatos.
EhCache
- "a caché máis utilizada para Java" (tradución do slogan do sitio web oficial). Tamén de código aberto. E entón entendemos que Redis non é para java, senón xeral, e para interactuar con el necesitas un envoltorio. E EhCache será máis cómodo. Que máis promete o sistema? Fiabilidade, probada, funcionalidade completa. Pois tamén é o máis común. E almacena en caché terabytes de datos.
Redis está esquecido, estou preparado para escoller EhCache.
Pero un sentimento de patriotismo empúxame a ver o que ten de bo Tarantool.
Tarantool
- cumpre a denominación "Plataforma de integración de datos en tempo real". Parece moi complicado, así que lemos a páxina en detalle e atopamos unha afirmación forte: "Alcacha o 100% dos datos na memoria RAM". Isto debería suscitar dúbidas: despois de todo, pode haber moitos máis datos que memoria. A explicación é que significa que Tarantool non executa a serialización para escribir datos no disco desde a memoria. Pola contra, usa funcións de baixo nivel do sistema, cando a memoria simplemente se asigna a un sistema de ficheiros con moi bo rendemento de E/S. En xeral, fixeron algo marabilloso e chulo.
Vexamos as implementacións: Autoestrada corporativa Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Se aínda había dúbidas sobre Tarantool, entón o caso de implementación en Mastercard remátame. Tomo Tarantool.
Pero de todas formas...
Inflamar
... hai algo máis , está catalogada como unha "plataforma de computación en memoria... velocidades en memoria en petabytes de datos". Tamén hai moitas vantaxes aquí: caché distribuída en memoria, almacenamento e caché de valores clave máis rápidos, escalado horizontal, alta dispoñibilidade e integridade estrita. En xeral, resulta que o máis rápido é Ignite.
Implementacións: Sberbank, American Airlines, Yahoo! Xapón. E entón descubro que Ignite non só se implementa en Sberbank, senón que o equipo de SberTech envía a súa xente ao propio equipo de Ignite para perfeccionar o produto. Isto é completamente cautivador e estou listo para tomar Ignite.
Non está completamente claro por que, estou mirando o quinto punto.
avellana
Vou ao sitio , lectura. E resulta que a solución máis rápida para a caché distribuída é Hazelcast. É ordes de magnitude máis rápido que todas as outras solucións e, en xeral, é líder no campo da rede de datos en memoria. Neste contexto, tomar outra cousa é non respectarse. Tamén usa almacenamento de datos redundante para o funcionamento continuo do clúster sen perda de datos.
Iso é todo, estou listo para tomar Hazelcast.
Comparación
Pero se miras, os cinco candidatos descríbense de tal xeito que cada un deles é o mellor. Como elixir? Podemos ver cal é o máis popular, buscar comparacións e a dor de cabeza desaparecerá.
Atopamos un coma este , escolle os nosos 5 sistemas.
Aquí están ordenados: Redis está na parte superior, Hazelcast está en segundo lugar, Tarantool e Ignite están gañando popularidade, EhCache foi e segue sendo o mesmo.
Pero vexamos : ligazóns a sitios web, interese xeral no sistema, ofertas de traballo - xenial! É dicir, cando o meu sistema falle, direi: "Non, é fiable! Hai moitas ofertas de traballo..." Unha comparación tan sinxela non servirá.
Todos estes sistemas non son só sistemas de caché. Tamén teñen moita funcionalidade, incluso cando os datos non se bombean ao cliente para procesalos, pero viceversa: o código que hai que executar nos datos móvese ao servidor, execútase alí e devólvese o resultado. E non son tan frecuentemente considerados como un sistema separado para almacenar na caché.
Vale, non nos deamos por vencidos, busquemos unha comparación directa dos sistemas. Imos tomar as dúas opcións principais: Redis e Hazelcast. Interésanos a velocidade e compararémolas en función deste parámetro.
Hz vs Redis
Atopamos isto :
O azul é Redis, o vermello é Hazelcast. Hazelcast gaña en todas partes, e hai unha razón para iso: é multifío, altamente optimizado, cada fío funciona coa súa propia partición, polo que non hai bloqueos. E Redis é dun só fío; non se beneficia das modernas CPU multinúcleo. Hazelcast ten E/S asíncrona, Redis-Jedis ten sockets de bloqueo. Despois de todo, Hazelcast usa un protocolo binario e Redis está centrado no texto, o que significa que é ineficiente.
Por se acaso, imos a outra fonte de comparación. Que nos amosará?
Redis vs Hz
Un máis :
Aquí, pola contra, o vermello é Redis. É dicir, Redis supera a Hazelcast en canto ao rendemento. Hazelcast gañou a primeira comparación, Redis gañou a segunda. explicou moi precisamente por que Hazelcast gañou a comparación anterior.
Acontece que o resultado do primeiro foi en realidade manipulado: Redis foi levado na caixa base e Hazelcast foi adaptado para un caso de proba. Entón resulta: en primeiro lugar, non podemos confiar en ninguén e, en segundo lugar, cando finalmente escollemos un sistema, aínda temos que configuralo correctamente. Estas configuracións inclúen ducias, case centos de parámetros.
Axitando a botella
E podo explicar todo o proceso que fixemos agora coa seguinte metáfora: "Sacudir a botella". É dicir, agora non tes que programar, agora o principal é poder ler stackoverflow. E teño unha persoa no meu equipo, un profesional, que traballa exactamente así nos momentos críticos.
Que está facendo? Ve unha cousa rota, ve un rastro de pila, sácala algunhas palabras (cales son as súas experiencias no programa), busca en Google, atopa o stackoverflow entre as respostas. Sen ler, sen pensar, entre as respostas á pregunta, escolle algo máis parecido á frase "fai isto e aquilo" (elixir tal resposta é o seu talento, porque non sempre é a que recibiu máis gustos), aplícase, mira: se algo cambiou, entón xenial. Se non cambiou, retírao. E repita lanzamento-comprobación-busca. E deste xeito intuitivo, asegura que o código funciona despois dun tempo. Non sabe por que, non sabe o que fixo, non pode explicar. Pero! Esta infección funciona. E "o lume está apagado". Agora imos descubrir o que fixemos. Cando o programa funciona, é unha orde de magnitude máis fácil. E aforra moito tempo.
Este método está moi ben explicado con este exemplo.
Antes era moi popular recoller un veleiro nunha botella. Ao mesmo tempo, o veleiro é grande e fráxil e o pescozo da botella é moi estreito, é imposible empurralo dentro. Como montalo?
Hai tal método, moi rápido e moi eficaz.
O barco está formado por un montón de pequenas cousas: paus, cordas, velas, pegamento. Todo isto poñémolo nunha botella.
Collemos a botella coas dúas mans e comezamos a tremer. Axitámola e axitámola. E normalmente resulta ser un lixo completo, claro. Pero ás veces. Ás veces resulta ser un barco! Máis precisamente, algo parecido a un barco.
Mostrámoslle algo a alguén: "Seryoga, ves!?" E efectivamente, dende lonxe parece un barco. Pero non se pode permitir que isto continúe.
Hai outro xeito. Son usados por rapaces máis avanzados, como os hackers.
Deille unha tarefa a este rapaz, fixo de todo e marchou. E mira, parece que está feito. E despois dun tempo, cando hai que finalizar o código, isto comeza por el... É bo que xa conseguiu fuxir lonxe. Estes son os rapaces que, poñendo o exemplo dunha botella, farán isto: xa ves, onde está o fondo, o cristal dobra. E non está do todo claro se é transparente ou non. A continuación, os "hackers" cortan este fondo, introducen alí un barco e, a continuación, pegan o fondo de novo, e é como se se supón que debería ser así.
Desde o punto de vista da definición do problema, todo parece ser correcto. Pero usando os barcos como exemplo: por que facer este barco, quen o necesita? Non ofrece ningunha funcionalidade. Normalmente estes barcos son agasallos para persoas de moi alto rango, que o colocan nun estante por riba deles, como algún tipo de símbolo, como sinal. E se esa persoa, o xefe dunha gran empresa ou un alto funcionario, como será a bandeira para tal hack, cuxo pescozo foi cortado? Sería mellor que nunca o soubese. Entón, como acaban facendo estes barcos que se poden dar a unha persoa importante?
O único lugar clave no que realmente non podes facer nada é o corpo. E o casco do barco encaixa ben no pescozo. Mentres que o barco está montado fóra da botella. Pero non se trata só de montar un barco, é unha auténtica xoiaría. Engádense pancas especiais aos compoñentes, que despois permiten levantalos. Por exemplo, as velas dóbranse, lévanse coidadosamente dentro e despois, coa axuda dunhas pinzas, tíranse e érguense con moita precisión, con precisión. O resultado é unha obra de arte que se pode agasallar cunha conciencia tranquila e orgullo.
E se queremos que o proxecto teña éxito, debe haber polo menos un xoieiro no equipo. Alguén que se preocupa pola calidade do produto e ten en conta todos os aspectos, sen renunciar a nada, mesmo nos momentos de estrés, cando as circunstancias obrigan a facer o urxente a costa do importante. Todos os proxectos exitosos que son sostibles, que resistiron a proba do tempo, están construídos sobre este principio. Hai algo moi preciso e único neles, algo que aproveita todas as posibilidades dispoñibles. No exemplo co barco na botella, xógase o feito de que o casco do barco pasa polo pescozo.
Volvendo á tarefa de escoller o noso servidor de caché, como se pode aplicar este método? Ofrézoo esta opción de escoller entre todos os sistemas que existen: non axites a botella, non elixas, pero mira o que teñen en principio, que buscar ao elixir un sistema.
Onde buscar o pescozo de botella
Intentemos non axitar a botella, non pasar por todo o que hai un por un, pero vexamos que problemas xurdirán se de súpeto, para a nosa tarefa, deseñamos un sistema así. Por suposto, non montaremos a bicicleta, pero utilizaremos este diagrama para axudarnos a descubrir a que puntos debemos prestar atención nas descricións dos produtos. Imos esbozar un diagrama deste tipo.
Se o sistema está distribuído, entón teremos varios servidores (6). Digamos que son catro (é conveniente colocalos na imaxe, pero, por suposto, pode haber tantos como queiras). Se os servidores están en nodos diferentes, significa que todos executan algún código que se encarga de garantir que estes nodos formen un clúster e, en caso de ruptura, conéctanse e recoñécense entre si.
Tamén necesitamos a lóxica de código (2), que en realidade trata de almacenar na caché. Os clientes interactúan con este código a través dalgunha API. O código de cliente (1) pode estar dentro da mesma JVM ou acceder a el a través da rede. A lóxica implementada dentro é a decisión de que obxectos deixar na caché e cales tirar. Usamos a memoria (3) para almacenar a caché, pero se é necesario, podemos gardar algúns dos datos no disco (4).
Vexamos en que partes se producirá a carga. En realidade, cargaranse todas as frechas e todos os nodos. En primeiro lugar, entre o código do cliente e a API, se se trata dunha comunicación de rede, a subsidencia pode ser bastante perceptible. En segundo lugar, no marco da propia API: se esaxeamos con lóxica complexa, podemos atopar problemas coa CPU. E estaría ben que a lóxica non perdese o tempo na memoria. E queda a interacción co sistema de ficheiros: na versión habitual, isto é serializar / restaurar e escribir / ler.
O seguinte é a interacción co clúster. O máis probable é que estea no mesmo sistema, pero podería estar por separado. Aquí tamén cómpre ter en conta a transferencia de datos a el, a velocidade de serialización de datos e as interaccións entre o clúster.
Agora, por unha banda, podemos imaxinar "que engrenaxes xirarán" no sistema de caché ao procesar as solicitudes do noso código e, por outra banda, podemos estimar cales e cantas solicitudes xerará o noso código para este sistema. Isto é suficiente para facer unha elección máis ou menos sobria: escoller un sistema para o noso caso de uso.
avellana
Vexamos como aplicar esta descomposición á nosa lista. Por exemplo, Hazelcast.
Para poñer/tomar datos de Hazelcast, o código de cliente accede (1) á API. Hz permítelle executar o servidor como incrustado e, neste caso, acceder á API é unha chamada de método dentro da JVM, que pode considerarse gratuíta.
Para que a lóxica en (2) funcione, Hz depende do hash da matriz de bytes da chave serializada, é dicir, a chave será serializada en calquera caso. Isto é inevitable sobrecarga para Hz.
As estratexias de desafiuzamento están ben implementadas, pero para casos especiais podes engadir as túas propias. Non tes que preocuparte por esta parte.
Pódese conectar almacenamento (4). Genial. A interacción (5) para embebido pode considerarse instantánea. Intercambio de datos entre nodos do clúster (6) - si, existe. Este é un investimento en tolerancia a fallos a costa da velocidade. A función Hz Near-cache permítelle reducir o prezo: os datos recibidos doutros nodos do clúster almacenaranse na caché.
Que se pode facer en tales condicións para aumentar a velocidade?
Por exemplo, para evitar a serialización da chave en (2), anexa outra caché enriba de Hazelcast, para obter os datos máis quentes. Sportmaster escolleu a cafeína para este propósito.
Para torcer no nivel (6), Hz ofrece dous tipos de almacenamento: IMap e ReplicatedMap.
Paga a pena mencionar como Hazelcast entrou na pila de tecnoloxía Sportmaster.
En 2012, cando estabamos a traballar no primeiro piloto do futuro sitio, foi Hazelcast a que resultou ser a primeira ligazón que devolveu o buscador. O coñecido comezou "a primeira vez": quedamos cativados polo feito de que só dúas horas despois, cando atornillamos Hz ao sistema, funcionou. E funcionou ben. Ao final do día fixemos unha serie de probas e quedamos felices. E esta reserva de vigor foi suficiente para superar as sorpresas que Hz arroxou co paso do tempo. Agora o equipo Sportmaster non ten motivos para abandonar Hazelcast.
Pero argumentos como "a primeira ligazón no motor de busca" e "HelloWorld foi rapidamente montado" son, por suposto, unha excepción e unha característica do momento no que tivo lugar a elección. As probas reais para o sistema elixido comezan co lanzamento en produción, e é nesta fase na que debes prestar atención ao elixir calquera sistema, incluída a caché. En realidade, no noso caso podemos dicir que escollemos Hazelcast por casualidade, pero despois resultou que escollemos correctamente.
Para a produción, moito máis importante: vixilancia, xestión de fallos en nodos individuais, replicación de datos, custo de escalado. É dicir, paga a pena prestar atención ás tarefas que xurdirán durante o mantemento do sistema: cando a carga é decenas de veces superior á prevista, cando cargamos algo accidentalmente no lugar equivocado, cando necesitamos lanzar unha nova versión. do código, substituír os datos e facelo desapercibido para os clientes.
Para todos estes requisitos, Hazelcast certamente encaixa na factura.
Continuará
Pero Hazelcast non é unha panacea. En 2017, escollemos Hazelcast para a caché de administración, simplemente baseándonos en boas impresións da experiencia pasada. Isto xogou un papel fundamental nunha broma moi cruel, pola que nos atopamos nunha situación difícil e saímos "heroicamente" dela durante 60 días. Pero máis sobre iso na seguinte parte.
Mentres tanto... Feliz Código Novo!
Fonte: www.habr.com