Récemment, la petite architecture de projet laissée par les prédécesseurs a été transplantée. En plus de certains noms de serveur et d'étranges segments de réseau vpc, elle peut fondamentalement être transférée en douceur vers le nouveau vpc pour refaire le serveur.
Cependant, lorsque cette pièce est sortie, une architecture saisissante a été découverte. À l'origine, la sortie des rails est très simple, vous pouvez facilement publier de nombreux serveurs avec la commande capistrano. En conséquence, plus je comprends la sortie de l'ancien serveur, plus je sens que les choses ne sont pas faciles.
À sa sortie, c'était un peu étrange. Le serveur doit être supprimé pour chaque version. À ce moment-là, je pensais, supprimer le serveur, puis raccrocher directement sans le service? Par conséquent, le service peut être libéré normalement et la branche peut être modifiée. À cette époque, j'avais une certaine admiration pour la vie de cette structure et un certain mépris. La libération du capuchon peut changer la branche (même si je vais le faire maintenant, elle peut mieux gérer), mais votre serveur est parti (cela en vaut-il la peine?).
Plus tard, j'ai vu qu'il y avait un get_repo nommé dans sa lambda, dans lequel un code py était écrit, et la partie contenant la branche écrivait quelque chose de dyanamodb. Je suis donc allé voir dynamodb, couché dans un creux, des branches existaient à l'intérieur.
De plus, lorsque j'ai repris ce projet auparavant, j'ai été vidé d'un document 1g . À cette époque, j'ai examiné 0,99 g de déchets solides. Il existe un script shell qui initialise le serveur. Je l'ai regardé et j'ai soudain ressenti un tonnerre, et c'était tellement bon!
Au cours des derniers jours, lorsque le serveur a été essentiellement transplanté, j'ai également trouvé un thème appelé dyanamodb dans le sns. C'est incroyable. Je vais être détective.
Combiné avec la fonction de suppression et de reconstruction automatique, il est temps de révéler le mystère de tout cela. Le tueur est le script lambda / DyanamoDB / autoscaling / sns / shell de Nima et cinq autres diamants.
Le processus de raisonnement est le suivant. Lors de la suppression du serveur ec2 quelques minutes plus tard, la mise à l'échelle automatique a constaté que le serveur se bloquait, il a donc automatiquement démarré ec2 et a automatiquement démarré un script shell, et a contacté lambda pour lire les informations de branche de dyanamoDB, puis a généré le code de version sur ec2 Enfin, le code de cette branche est publié. Une fois ceux-ci terminés, nous informerons sns d'envoyer un message. L'ensemble du processus est parfait. Je ne sais pas pourquoi il y a un sentiment de faiblesse et de faiblesse, et il y a aussi un sentiment de plaisir rafraîchissant. Après raisonnement, un fantôme! ! ! !
À cette époque, mon admiration pour les prédécesseurs était comme un ruisseau continu de rivières torrentielles (la composition complète de 1w de l'examen d'entrée au collège a été omise ici). Juste dans le but de publier le code, l'architecture est devenue si impressionnante, à laquelle je ne m'attendais pas. C'est peut-être ce que les meilleurs architectes comprennent. Préparez une grande cause!