Service Mesh é un patrón arquitectónico moi coñecido para integrar microservizos e migrar á infraestrutura na nube. Hoxe no mundo dos contedores na nube é bastante difícil prescindir del. No mercado xa están dispoñibles varias implementacións de malla de servizos de código aberto, pero a súa funcionalidade, fiabilidade e seguridade non sempre son suficientes, especialmente cando se trata dos requisitos das grandes empresas financeiras de todo o país. É por iso que en Sbertech decidimos personalizar o Service Mesh e queremos falar sobre o que é xenial sobre Service Mesh, o que non é tan xenial e o que imos facer ao respecto.
A popularidade do patrón Service Mesh está crecendo coa popularidade das tecnoloxías na nube. É unha capa de infraestrutura dedicada que simplifica a interacción entre diferentes servizos de rede. As aplicacións na nube modernas consisten en centos ou incluso miles de servizos deste tipo, cada un dos cales pode ter miles de copias.
A interacción entre e a xestión destes servizos é unha tarefa clave do Service Mesh. De feito, trátase dun modelo de rede de moitos proxies, xestionado de forma centralizada e que realiza un conxunto de funcións moi útiles.
A nivel de proxy (plano de datos):
- Asignación e distribución de políticas de enrutamento e equilibrio de tráfico
- Distribución de claves, certificados, fichas
- Recollida de telemetría, xeración de métricas de monitorización
- Integración coa infraestrutura de seguridade e vixilancia
A nivel do plano de control:
- Aplicación de políticas de enrutamento e equilibrio de tráfico
- Xestionar reintentos e tempo de espera, detectar nodos "mortos" (ruptura de circuíto), xestionar fallos de inxección e garantir a resistencia do servizo a través doutros mecanismos
- Autenticación/autorización de chamada
- Eliminación de métricas (observabilidade)
O abano de usuarios interesados no desenvolvemento desta tecnoloxía é moi amplo: desde pequenas startups ata grandes corporacións de Internet, por exemplo, PayPal.
Por que é necesaria Service Mesh no sector corporativo?
Hai moitos beneficios claros ao usar unha malla de servizo. Primeiro de todo, é simplemente conveniente para os desenvolvedores: para escribir código aparece unha plataforma tecnolóxica, o que simplifica significativamente a integración na infraestrutura da nube debido ao feito de que a capa de transporte está completamente illada da lóxica da aplicación.
Ademais, Service Mesh simplifica a relación entre provedores e consumidores. Hoxe é moito máis doado para os provedores de API e os consumidores acordar interfaces e contratos por si mesmos, sen implicar un intermediario e árbitro de integración especial: o bus de servizo empresarial. Este enfoque afecta significativamente a dous indicadores. A velocidade de traer novas funcionalidades ao mercado (time-to-market) aumenta, pero ao mesmo tempo aumenta o custo da solución, xa que a integración ten que facerse de forma independente. O uso de Service Mesh por parte dos equipos de desenvolvemento de funcións empresariais axuda a manter un equilibrio aquí. Como resultado, os provedores de API poden centrarse exclusivamente no compoñente de aplicación do seu servizo e simplemente publicalo no Service Mesh: a API estará inmediatamente dispoñible para todos os clientes e a calidade da integración estará lista para a produción e non requirirá nin un só. liña de código adicional.
A seguinte vantaxe é iso o programador, usando Service Mesh, céntrase unicamente na funcionalidade empresarial — sobre o produto máis que no compoñente tecnolóxico do seu servizo. Por exemplo, xa non tes que pensar no feito de que nunha situación na que se chama un servizo a través da rede, pode producirse un fallo de conexión nalgún lugar. Ademais, Service Mesh axuda a equilibrar o tráfico entre as copias do mesmo servizo: se unha das copias "morre", o sistema cambiará todo o tráfico ás copias en directo restantes.
Malla de servizo - esta é unha boa base para crear aplicacións distribuídas, que oculta ao cliente os detalles de prestación de chamadas aos seus servizos tanto interna como externamente. Todas as aplicacións que utilizan Service Mesh están illadas a nivel de transporte tanto da rede como entre si: non hai comunicación entre elas. Neste caso, o programador recibe o control total sobre os seus servizos.
Cómpre sinalar que A actualización de aplicacións distribuídas nun ambiente de malla de servizos faise máis fácil. Por exemplo, unha implantación azul/verde, na que hai dous contornos de aplicación dispoñibles para a instalación, un dos cales non está actualizado e está en modo de espera. O retorno á versión anterior en caso dunha versión non exitosa realízase mediante un enrutador especial, cuxo papel fai Service Mesh ben.. Para probar a nova versión, pode usar liberación canaria — cambiar á nova versión só o 10% do tráfico ou das solicitudes dun grupo piloto de clientes. O tráfico principal vai á versión antiga, non se rompe nada.
Tamén Service Mesh ofrécenos control de SLA en tempo real. O sistema proxy distribuído non permitirá que o servizo falle cando un dos clientes supere a cota asignada. Se o rendemento da API é limitado, ninguén poderá abordalo cunha gran cantidade de transaccións: o Service Mesh está diante do servizo e non permite o tráfico innecesario. Simplemente loitará na capa de integración e os propios servizos seguirán funcionando sen decatarse.
Se unha empresa quere reducir custos para o desenvolvemento de solucións de integración, Service Mesh tamén axuda a: Podes cambiar á súa versión de código aberto desde produtos comerciais. A nosa Enterprise Service Mesh baséase na versión de código aberto de Service Mesh.
Outra vantaxe - dispoñibilidade dun único conxunto completo de servizos de integración. Dado que toda a integración se constrúe a través deste middleware, podemos xestionar todo o tráfico de integración e as conexións entre aplicacións que forman o núcleo empresarial da empresa. É moi cómodo.
E finalmente Service Mesh anima a unha empresa a pasar a unha infraestrutura dinámica. Agora moitos miran cara a contenerización. Cortar un monólito en microservizos, implementar todo isto de xeito fermoso: o tema está en aumento. Pero cando tentas transferir un sistema que leva moitos anos en produción a unha nova plataforma, inmediatamente atopas unha serie de problemas: empurralo todo en contedores e implantalo na plataforma non é doado. E a implementación, sincronización e interacción destes compoñentes distribuídos é outro tema moi complexo. Como se comunicarán entre eles? Haberá fallos en cascada? Service Mesh permítelle resolver algúns destes problemas e facilitar a migración da arquitectura antiga á nova debido ao feito de que se pode esquecer da lóxica de intercambio de rede.
Por que precisa a personalización de Service Mesh?
Na nosa empresa conviven centos de sistemas e módulos, e o tempo de execución está moi cargado. Así que un simple patrón de que un sistema chame a outro e reciba unha resposta non é suficiente, porque na produción queremos máis. Que máis necesitas dunha malla de servizo empresarial?
Servizo de procesamento de eventos
Imaxinemos que necesitamos facer un procesamento de eventos en tempo real: un sistema que analiza as accións do cliente en tempo real e pode facerlle inmediatamente unha oferta relevante. Para implementar unha funcionalidade similar, use patrón arquitectónico denominado arquitectura impulsada por eventos (EDA). Ningunha das mallas de servizo actuais admite de forma nativa tales patróns, pero isto é moi importante, especialmente para un banco.
É bastante estraño que a chamada de procedemento remoto (RPC) sexa compatible con todas as versións de Service Mesh, pero non son amigables con EDA. Porque Service Mesh é unha especie de integración distribuída moderna e EDA é un patrón arquitectónico moi relevante que che permite facer cousas únicas en canto á experiencia do cliente.
A nosa Enterprise Service Mesh debería resolver este problema. Ademais, queremos ver nel a implementación de entrega garantida, streaming e procesamento de eventos complexos mediante unha variedade de filtros e modelos.
Servizo de transferencia de ficheiros
Ademais de EDA, sería bo poder transferir ficheiros: a escala empresarial, moitas veces só é posible a integración de ficheiros. En particular, utilízase o patrón arquitectónico ETL (Extract, Transform, Load). Nel, por regra xeral, todos intercambian ficheiros exclusivamente: utilízanse grandes datos, o que é pouco práctico para enviar solicitudes separadas. A capacidade de admitir de forma nativa as transferencias de ficheiros no Enterprise Service Mesh ofrécelle a flexibilidade que necesita a túa empresa.
Servizo de orquestración
As grandes organizacións case sempre teñen equipos diferentes que elaboran produtos diferentes. Por exemplo, nun banco, algúns equipos traballan con depósitos, mentres que outros traballan con produtos de préstamo, e hai bastantes casos deste tipo. Trátase de persoas diferentes, de equipos diferentes que fabrican os seus produtos, desenvolven as súas API e llos proporcionan a outros. E moitas veces hai que compoñer estes servizos, así como implementar unha lóxica complexa para chamar secuencialmente a un conxunto de API. Para solucionar este problema, necesitas unha solución na capa de integración que simplifique toda esta lóxica composta (chamar varias API, describir a ruta da solicitude, etc.). Este é o servizo de orquestración no Enterprise Service Mesh.
AI e ML
Cando os microservizos se comunican a través dunha única capa de integración, Service Mesh sabe todo sobre as chamadas de cada servizo. Recollemos telemetría: quen chamou a quen, cando, durante canto tempo, cantas veces, etc. Cando hai centos de miles destes servizos, e miles de millóns de chamadas, todo isto acumúlase e forma Big Data. Estes datos pódense analizar mediante IA, aprendizaxe automática, etc., e despois pódense facer algunhas cousas útiles en función dos resultados da análise. Sería apropiado ceder, polo menos parcialmente, o control de todo este tráfico de rede e chamadas de aplicacións integradas no Service Mesh á intelixencia artificial.
Servizo de pasarela API
Normalmente, unha malla de servizo ten proxies e servizos que falan entre si dentro dun perímetro de confianza. Pero tamén hai contrapartes externas. Os requisitos para as API expostas a este grupo de consumidores son moito máis severos. Dividimos esta tarefa en dúas partes principais.
- Безопасность. Problemas relacionados con ddos, vulnerabilidade de protocolos, aplicacións, sistemas operativos, etc.
- Escala. Cando o número de API que se deben servir aos clientes alcanza os miles ou mesmo centos de miles, é necesario algún tipo de ferramenta de xestión para este conxunto de API. Cómpre supervisar constantemente a API: se está funcionando ou non, cal é o seu estado, que tráfico está a fluír, que estatísticas, etc. Unha pasarela de API debería xestionar esta tarefa mentres fai que todo o proceso sexa manexable e seguro. Grazas a este compoñente, Enterprise Service Mesh aprende a publicar facilmente API tanto internas como externas.
Servizo de soporte para protocolos e formatos de datos específicos (pasarela AS)
Actualmente, a maioría das solucións de Service Mesh poden funcionar de forma nativa só co tráfico HTTP e HTTP2 ou nun modo reducido a nivel TCP/IP. O Enterprise Service Mesh está xurdindo con moitos outros protocolos de transferencia de datos moi específicos. Algúns sistemas poden usar corretores de mensaxes, outros están integrados a nivel de base de datos. Se a empresa ten SAP, tamén pode usar o seu propio sistema de integración. Ademais, todo isto funciona e é unha parte importante do negocio.
Non podes dicir simplemente: "Abandonemos o legado e creemos novos sistemas que poidan usar Service Mesh". Para conectar todos os sistemas antigos cos novos (nunha arquitectura de microservizos), os sistemas que poidan usar Service Mesh necesitarán algún tipo de adaptador, intermediario ou pasarela. De acordo, sería bo que viñese nunha caixa xunto co servizo. A pasarela AC pode admitir calquera opción de integración. Imaxínate que acabas de instalar Enterprise Service Mesh e estará listo para interactuar con todos os protocolos que necesites. Este enfoque é moi importante para nós.
Así é aproximadamente como imaxinamos a versión corporativa de Service Mesh (Enterprise Service Mesh). A personalización descrita resolve a maioría dos problemas que xorden cando se intenta utilizar versións de código aberto preparadas da plataforma de integración. Presentada hai só un par de anos, a arquitectura Service Mesh segue evolucionando e estamos encantados de poder contribuír ao seu desenvolvemento. Esperamos que a nosa experiencia vos sexa útil.
Fonte: www.habr.com