book

Nube Nativa Go

by Matthew A. Titmus

September 2024

Intermediate to advanced

436 pages

11h 33m

Spanish

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Quién debería leer este libroPor qué escribí este libroConvenciones utilizadas en este libroUtilizar ejemplos de códigoAprendizaje en línea O'ReillyCómo contactar con nosotrosAgradecimientos
La historia hasta ahora¿Qué es la Nube Nativa?EscalabilidadAcoplamiento sueltoResilienciaManejabilidadObservabilidad¿Por qué la Nube Nativa es una cosa?Resumen
La motivación detrás de GoFunciones para un mundo nativo en la nubeComposición y tipado estructuralComprensibilidadConcurrencia estilo CSPConstrucciones rápidasEstabilidad lingüísticaSeguridad de la memoriaRendimientoEnlace estáticoTipificación estáticaResumen
Tipos de datos básicosBooleanosNúmeros sencillosNúmeros complejosCuerdasVariablesDeclaraciones cortas de variablesValores ceroEl identificador en blancoConstantesTipos de Contenedores: Matrices, Rebanadas y MapasMatricesRebanadasMapasPunterosEstructuras de controlDiversión con forLa declaración ifLa Declaración del interruptorTratamiento de erroresCrear un errorLa diversión en las funciones: Variádicos y CierresFuncionesFunciones variádicasFunciones anónimas y cierresEstructuras, métodos e interfacesEstructurasMétodosInterfacesComposición con incrustación de tiposLo bueno: ConcurrenciaGoroutinesCanalesSeleccionaResumen
El Paquete ContextoLo que el contexto puede hacer por tiCrear contextoDefinir plazos y tiempos de espera del contextoDefinir valores de solicitudUtilizar un contextoEstructura de este capítuloPatrones de estabilidadDisyuntorReboteReintentarAceleradorTiempo de esperaPatrones de concurrenciaFan-InFan-OutFuturoFragmentaciónResumen
¡Construyamos un servicio!¿Qué es un almacén clave-valor?Requisitos¿Qué es la idempotencia y por qué es importante?El objetivo finalGeneración 0: La funcionalidad básicaTu API súper sencillaGeneración 1: El MonolitoConstruir un servidor HTTP con net/httpConstruir un servidor HTTP con gorilla/muxConstruir un servicio RESTfulCómo hacer que tu estructura de datos sea segura para la concurrenciaGeneración 2: Persistencia del estado de los recursos¿Qué es un Registro de Transacciones?Almacenar el estado en un archivo de registro de transaccionesAlmacenar el estado en una base de datos externaGeneración 3: Implementar la seguridad de la capa de transporteSeguridad de la capa de transporteArchivos de claves privadas y certificadosAsegurar tu servicio web con HTTPSResumen de la capa de transporteContainerizar tu almacén clave-valorConceptos básicos de Docker (absolutos)Construir tu contenedor de almacén clave-valorExternalizar datos de contenedoresResumen
¿Para qué sirve la Nube Nativa?Todo es cuestión de fiabilidad¿Qué es la fiabilidad y por qué es tan importante?Fiabilidad: Ya no es sólo para operacionesLograr la fiabilidadPrevención de fallosTolerancia a fallosEliminación de fallosPrevisión de averíasLa vigencia de la aplicación de los Doce FactoresI. Código baseII. DependenciasIII. ConfiguraciónIV. Servicios de apoyoV. Construir, liberar, ejecutarVI. ProcesosVII. Aislamiento de datosVIII. EscalabilidadIX. DesechabilidadX. Paridad desarrollo/producciónXI. RegistrosXII. Procesos administrativosResumen

¿Qué es la escalabilidad?Diferentes formas de escaladoLos cuatro cuellos de botella habitualesEstado y apatridiaEstado de la aplicación frente a estado del recursoVentajas de la apatridiaEscala aplazada: EficienciaAlmacenamiento en caché eficiente mediante una caché LRUSincronización eficazLas fugas de memoria pueden...error fatal: tiempo de ejecución: sin memoriaSobre la eficaciaArquitecturas de serviciosLa arquitectura del sistema monolitoLa arquitectura del sistema de microserviciosArquitecturas sin servidorResumen
Acoplamiento EstancoEl acoplamiento estrecho adopta muchas formasComunicaciones entre serviciosMensajería Solicitud-RespuestaImplementaciones comunes de solicitud-respuestaEmisión de solicitudes HTTP con net/httpLlamadas a procedimientos remotos con gRPCAcoplamiento suelto de recursos locales con plug-insPlug-ins en proceso con el paquete de plug-insSistema Go Plug-in de HashiCorp sobre RPCArquitectura hexagonalLa ArquitecturaImplantar un servicio hexagonalResumen
Seguir avanzando: Por qué es importante la resiliencia¿Qué significa que un sistema falle?Construir para resistirFallos en cascadaPrevenir la sobrecargaReintentar: Reintentar peticionesAlgoritmos de retrocesoInterrupción del circuitoTiempos muertosIdempotenciaRedundancia del servicioDiseñar para la redundanciaAutoescaladoChequeos médicos saludables¿Qué significa que una instancia sea "sana"?Los tres tipos de chequeos médicosFracaso AbiertoResumen
¿Qué es la gestionabilidad y por qué debería importarme?Configurar tu aplicaciónBuenas prácticas de configuraciónConfigurar con variables de entornoConfigurar con argumentos de la línea de comandosConfigurar con archivosViper: La navaja suiza de los paquetes de configuraciónGestión de características con indicadores de característicasLa evolución de una bandera de característicasGeneración 0: La implementación inicialGeneración 1: La Bandera de Características de Código DuroGeneración 2: La Bandera ConfigurableGeneración 3: Indicadores dinámicos de característicasResumen
¿Qué es la observabilidad?¿Por qué necesitamos la observabilidad?¿En qué se diferencia la observabilidad del monitoreo "tradicional"?Los "Tres Pilares de la Observabilidad"OpenTelemetryLos componentes de OpenTelemetryRastreandoConceptos de seguimientoRastreo con OpenTelemetryPonerlo todo junto: RastreandoMétricasColección Métrica Push Versus PullMétricas con OpenTelemetryPonerlo todo junto: MétricasRegistroMejores prácticas de registroRegistro con el paquete de registro estándar de GoEl paquete de registro ZapResumen

Content preview from Nube Nativa Go

Capítulo 6. Todo es cuestión de fiabilidad

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

La propiedad más importante de un programa es si cumple la intención de su usuario.¹

C.A.R. Hoare, Comunicaciones de la ACM (octubre de 1969)

El profesor Sir Charles Antony Richard (Tony) Hoare es un tipo brillante. Inventó el quicksort, es autor de la Lógica de Hoare para razonar sobre la corrección de los programas informáticos, y creó el lenguaje formal "procesos secuenciales comunicantes" (CSP) que inspiró el querido modelo de concurrencia de Go. Ah, y desarrolló el paradigma de programación estructurada² que constituye la base de todos los lenguajes de programación modernos de uso común en la actualidad. También inventó la referencia nula. Pero no se lo tengas en cuenta. Se disculpó públicamente³ públicamente por ello en 2009, calificándolo de "error multimillonario".

Tony Hoare inventó literalmente la programación tal y como la conocemos. Así que cuando dice que la propiedad más importante de un programa es si cumple la intención de su usuario, puedes tomártelo con cierta autoridad. Piénsalo un segundo: Hoare señala específicamente (y con razón) que es la intención de los usuariosde un programa -nola de sus creadores- la quedicta si un programa funciona correctamente. ¡Qué inconveniente que las intenciones de los usuarios de un programa no sean siempre las mismas que las de su creador!

Dada esta afirmación, es lógico ...