Hola, sóc Stanislav Yablonskiy, desenvolupador principal de servidors de Pixonic (MY.GAMES). Els microservicis són un enfocament al desenvolupament de programari (principalment el desenvolupament de backend) on la funcionalitat es divideix en els components més petits possibles, cadascun dels quals funciona de forma independent.Cada component té la seva pròpia API. Els microservicis són molt populars avui en dia, però el seu ús introdueix una sobrecàrrega significativa en termes de xarxa, memòria i CPU. Cada trucada es converteix en la necessitat de serialització, enviament i recepció de dades a través de la xarxa.A més, ja no és possible utilitzar transaccions de base de dades clàssiques, el que condueix a transaccions distribuïdes o eventual coherència. Les transaccions distribuïdes són lentes i costoses, mentre que l'eventual coherència significa que els resultats de les operacions poden no aparèixer immediatament, i les dades poden ser temporalment inconsistents. L'ús de microservicis obliga els desenvolupadors a escriure més codi en cada servei individual a causa de les dificultats d'accedir a la lògica ja escrita d'altres serveis. De vegades, és difícil reutilitzar el codi existent, o potser ni tan sols sabeu que existeix - ja que altres persones poden estar treballant en un projecte diferent. Microservices’ Overheads Debú Overhead La depuració es fa molt més difícil amb els microservicis. Un depurador regular és gairebé inútil en aquestes condicions, ja que no es poden depurar tots els serveis alhora. Això vol dir que necessiteu un entorn especial on no només s'executi el servei que s'està corregint, sinó també totes les seves dependències (altres serveis, bases de dades, files d'espera, etc.). HTTP sobrecàrrega El protocol HTTP té una gran quantitat de funcionalitats integrades. dóna suport a diverses rutes, mètodes de passatge de paràmetres, codis de resposta i és recolzat per molts serveis preparats per a l'ús (inclosos els proxies). Protobuf sobre cap Es requereix serialització per a la comunicació de xarxa i deserialització en rebre missatges. Quan utilitzeu protobuf per a l'intercanvi de missatges, heu de: Creació d’objectes que els converteixin en canvis, Descarregueu-les immediatament després de l’ús. Això crea molta feina addicional per al col·lector d'escombraries o el gestor de memòria dinàmica. Xarxa Overhead La transmissió de dades a través de la xarxa augmenta el temps de resposta del servei i augmenta el consum de memòria i CPU, fins i tot si els microservicis s'executen en el mateix host. Memòria superior L'enviament i la recepció de missatges requereix el manteniment d'estructures de dades addicionals, utilitzant fils separats i sincronitzant-los.Cada procés separat, especialment un que s'executa en un contenidor, consumeix una quantitat significativa de memòria només per l'existent. Càtedra Overhead Per descomptat, tota aquesta comunicació entre processos i entre contenidors requereix recursos computacionals. Base de dades Overhead Les transaccions normals són impossibles quan les operacions s'estenen a múltiples microserveis. Les transaccions distribuïdes són molt més lentes i requereixen una coordinació complexa, sovint manual. Discs de xarxa Overhead Els contenidors de microservei sovint s'executen en discos muntats en xarxa. Això augmenta la latencia, redueix el rendiment (IOPS), i ho fa imprevisible. Projecte Border Overhead El disseny i el desenvolupament de microservicis comporta dificultats en l'evolució i refactoring d'un projecte. No és fàcil canviar la zona de responsabilitat d’un servei. No es pot simplement canviar el nom o eliminar alguna cosa. No es pot simplement moure el codi d'un servei a un altre. Això sol requerir: molt de temps i esforç, Diverses versions de les flames, i les migracions complexes abans que la funcionalitat es pugui redistribuir entre els serveis. A més, si voleu actualitzar o reemplaçar una biblioteca, haureu de fer-ho en tots els projectes, no només en un. Infraestructures superiors No es pot simplement "fer microservicis." Necessitarà infraestructura - no, INFRASTRUCTURA: contenidors (cadascun dels quals conté còpies de biblioteques compartides), El cubisme, serveis de núvol, les cadenes (RabbitMQ, Kafka) eines de sincronització de configuració (Zookeeper, Etcd, Consul), i així successivament. Tot això requereix enormes recursos tant de les màquines com de les persones. Desplegament independent en capçalera Donar suport a desplaçaments independents significa: Cada servei ha de ser desplegable per separat. Cadascú ha de tenir la seva pròpia canonada CI/CD, i la part més difícil - API versió. Cada servei haurà de donar suport a múltiples versions de l'API simultàniament, i els trucadors hauran de fer un seguiment d'aquestes versions i actualitzar les seves trucades a temps. La bola de fang distribuïda Hi ha una probabilitat de gairebé 100% que no obtinguis els límits del servei des del principi. En comptes de microservicis nets, acabaràs amb una bola de fang distribuïda - on la funcionalitat està mal distribuïda, les trucades externes desencadenen cadenes senceres de trucades de servei intern, i tot és terriblement lent. Realment el monòlit és tan espantós? Mòduls monolítics Els monòlits modulars us permeten evitar la major part de la superfície de microservei, tot i que proporcionen una separació que es pot utilitzar més tard si és necessari. Aquest enfocament implica escriure l'aplicació (principalment el backend) com un únic servei dividit en mòduls individuals amb: límits clarament definits, i Mínima interdependència. Això fa possible dividir-los en serveis si l’escalabilitat realment ho requereix. Espereu, podeu fer això? Molts dels beneficis atribuïts a l'arquitectura de microservei es poden aconseguir en un monòlit: La modularitat es pot implementar amb les característiques del llenguatge: classes, noms, projectes i assemblacions. Bases de dades múltiples - possible, si realment és necessari; Múltiples llenguatges: també és possible, per exemple, combinar C/C++/C#/Java amb llenguatges de scripting com JavaScript, Python o Erlang per al desenvolupament de nivell superior. Interop: moltes plataformes donen suport a la trucada de C/C++ des de Java, C#, Python, JavaScript o Erlang. Taules de missatges: només cal utilitzar l'estructura de dades adequada. I quan voleu depurar - un teclat, i tota l'aplicació està a les teves mans. Frameworks Actors Els marcadors d'actors permeten construir microservicis - sense els microservicis. Tota lògica es divideix en classes (actors) que es comuniquen només a través d'un bus de missatges (queixes). Aquests actors poden: existeix dins d'un únic procés, o Es distribueixen en diversos processos. D'aquesta manera, s'obté el model de programació de microservei, però la major part de la infraestructura es gestiona pel mateix marc. Conclusion Conclusió L'arquitectura s'ha de triar sobre la base de: Requisits del projecte, els recursos disponibles, Experiència de l’equip. Els microservicis no són una bala de plata: són útils per a grans projectes i equips, però el monòlit no és obsolet i no és un deute tècnic per defecte. El més important és l’equilibri entre flexibilitat i complexitat, escalabilitat i manteniment, de manera que el sistema que construïu sigui eficaç i sostenible.
