building-microservices-designing-fine-grained-systems-es

microservici
os
construcción
El diseño de sistemas de grano fino
Sam Newman
microservicios construcción
distributed sysTEMS hCra becommi mesre bien-grainere yonorte ºmi
past 10 años, Pasando de código-pesado aplicaciones monolíticas a microservicios más pequeños,
independientes. Pero el desarrollo de estos sistemas trae su propio conjunto de dolores de cabeza. Con una gran
cantidad de ejemplos y consejos prácticos, este libro tiene una visión integral de los temas que los arquitectos y
administradores de sistemas deben tener en cuenta al construir, gestionar, y la evolución de las arquitecturas
MICROSERVICE.
MICROSERVICE tecnologías se están moviendo rápidamente. Autor Sam
Newman le proporciona una base sólida en los conceptos, mientras que el
buceo en las soluciones actuales para el modelado, integración, pruebas,
implementación y seguimiento de sus propios servicios autónomos. Usted
seguirá una compañía ficticia a lo largo del libro para aprender cómo
construir una arquitectura microService afecta a un solo dominio.
■ Descubren cómo microservicios permiten alinear el diseño
de su sistema con objetivos de su organización
■
Aprender opciones para integrar un servicio con el resto de
su sistema
■
Tomar un enfoque gradual cuando se divide codebases
monolíticos
■
Implementar microservicios individuales a través de
la integración continua
■
Examinar la complejidad de las pruebas y el seguimiento de los
servicios distribuidos
■
Administrar la seguridad con los modelos de usuario-aservicio y Servicio-al-servicio
■
Entender los desafíos de intensificar las
arquitecturas MICROSERVICE
La arquitectura tiene
“muchas
microservicios
apelando cualidades,
pero el camino hacia
ella tiene trampas
dolorosas para los
incautos. Este libro le
ayudará a determinar
si este camino es para
usted, y cómo evitar
esas trampas en su
viaje.
”
-Martin Fowler
Jefe Científico, ThoughtWorks
Sam Newman es un tecnólogo en ThoughtWorks, donde divide su tiempo
entre ayudar a los clientes a nivel mundial y trabajar como arquitecto de
sistemas internos ThoughtWorks'. Ha trabajado con una variedad de
compañías en todo el mundo tanto en las operaciones de TI y de
desarrollo.
PROGRAMACIÓN
NOSOTROS $ 49.99 CAN $ 57.99
ISBN: 978-1-491-95035-7
Twitter: @oreillymedia
facebook.com/oreilly
microservicios
construcción
Sam Newman
microservicios construcción
por Sam Newman
Copyright © 2015 Sam Newman. Todos los derechos
reservados. Impreso en los Estados Unidos de
América.
Publicado por O'Reilly Media, Inc., 1005 Gravenstein Carretera Norte, Sebastopol, CA 95472.
libros de O'Reilly pueden ser adquiridos para uso educacional, comercial, o el uso promocional de ventas.
ediciones en línea también están disponibles para la mayoría de los títulos (http://safaribooksonline.com).
Para obtener más información, póngase en contacto con nuestro departamento corporativo / institucional
ventas: 800-998-9938 ocorporate@oreilly.com.
editores: Mike Loukides y Brian
MacDonald
Editor de Producción: Kristen
Brown Editor de copia: Rachel
Monaghan Corrector de
pruebas: Jasmine Kwityn
febrero 2015: Primera
indexador: Judith McConville
Diseñador de interiores: David
Futato Diseñador de la portada:
Ellie Volckhausen Illustrator:
Rebecca Demarest
Edición
Historial de revisiones para la primera edición
01/30/2014: Primera versión
Ver http://oreilly.com/catalog/errata.csp?isbn=9781491950357 para los detalles de la versión.
El logotipo de O'Reilly es una marca registrada de la imagen de portada de las abejas O'Reilly Media,
Inc. microservicios de construcción, y la imagen comercial son marcas comerciales de O'Reilly Media,
Inc.
Mientras que el editor y el autor han utilizado los esfuerzos de buena fe para asegurar que la información
y las instrucciones contenidas en este trabajo son exactos, el editor y el autor declinan toda
responsabilidad por errores u omisiones, incluyendo, sin responsabilidad limitación de los daños
producidos por el uso o dependencia de este trabajo. El uso de la información y las instrucciones
contenidas en este trabajo es bajo su propio riesgo. Si ninguna de las muestras de código u otra tecnología
este trabajo contiene o describe está sujeto a licencias de código abierto o los derechos de propiedad
intelectual de terceros, es su responsabilidad asegurarse de que el uso de los mismos cumple con dichas
licencias y / o derechos.
978-1-491-95035-7
[LSI]
Mesa Contenido
Preface.xiii ...........................................................................................................
1. Microservices.1 ...............................................................................................
¿Cuáles son microservicios?
Pequeña, y se centró en hacer una cosa bien
Autónomo
Beneficios clave
La heterogeneidad tecnología
Resiliencia
Escalada
Facilidad de implementación
La alineación organizacional
Compuestabilidad
Optimización para Reemplazabilidad
¿Qué hay de arquitectura orientada a servicios?
Otras técnicas descomposicional
Las bibliotecas compartidas
módulos
No Bala de plata
Resumen
2
2
3
4
4
5
5
6
7
7
7
8
9
9
10
11
11
2. el evolutiva Architect.13 ..................................................................................
Las comparaciones inexactas
Una visión evolutiva para el Arquitecto
zonificación
Un enfoque de principios
Metas estratégicas
13
15
dieciséis
17
18
iii
principios
prácticas
Combinando Principios y Prácticas
Un ejemplo del mundo real
El nivel requerido
Vigilancia
Interfaces
Seguridad arquitectónica
A través de la gobernabilidad Código
ejemplares
adaptada Plantilla de servicio
Técnico Deuda
Manejo de excepciones
Gobernabilidad y va desde el Centro
La construcción de un equipo
Resumen
18
19
19
19
20
21
21
21
22
22
22
24
24
25
26
27
3. Cómo Modelar Services.29 ..............................................................................
La introducción de MusicCorp
Lo que hace un buen servicio?
Bajo acoplamiento
alta cohesión
El contexto acotado
Compartida y Modelos Ocultos
Módulos y Servicios
La descomposición prematura
Las capacidades de negocio
tortugas Toda la calle abajo
La comunicación en términos de conceptos de negocio
El límite técnico
Resumen
29
30
30
30
31
31
33
33
34
34
36
36
37
4. Integration.39 .................................................................................................
En busca de la integración de la tecnología Ideal
Evitar Los cambios de última hora
Mantenga su independiente de la tecnología API
Hacer del Servicio simple para los consumidores
Ocultar detalle de implementación interna
Interfaz con Clientes
La base de datos compartida
Versus síncrono asíncrono
Orquestación Versus Coreografía
iv| Tabla de contenido
39
39
39
40
40
40
41
42
43
Llamadas a procedimiento remoto
46
tecnología de acoplamiento
Las llamadas locales no son como las llamadas remotas
fragilidad
Es RPC Terrible?
DESCANSO
REST y HTTP
Hipermedia como el motor del estado de la aplicación
JSON, XML, o algo más?
Cuidado con demasiada Conveniencia
Los inconvenientes se detuvo encima de HTTP
La implementación asíncrona Colaboración basado en eventos
opciones de tecnología
Complejidades de asincrónicos Arquitecturas
Servicios como Máquinas de Estado
Extensiones reactivas
SECO y los peligros de la reutilización de código en un mundo Microservice
bibliotecas de cliente
El acceso de Referencia
de versiones
Aplazar durante tanto tiempo como sea posible
Coger Breaking cambios tempranos
Utilizar Versiones semántica
Coexistir diferentes criterios de valoración
Utilizar Múltiples versiones de servicio concurrentes
Usuario Interfaces
Hacia Digital
restricciones
Composición API
Composición UI Fragmento
Backends para Frontends
Un enfoque híbrido
La integración con software de terceros
Falta de control
personalización
La integración de los espaguetis
En sus propios términos
El patrón de estrangulador
Resumen
47
47
47
49
49
50
51
53
54
54
55
55
57
58
58
59
59
60
62
62
63
64
64
66
67
67
68
68
69
71
73
73
74
74
74
75
77
78
5. la división de la Monolith.79 ...........................................................................
Sus Todo sobre costuras
79
v
Rompiendo Aparte MusicCorp
Las razones para dividir el monolito
Ritmo del cambio
Equipo Estructura
Seguridad
Tecnología
Enredado dependencias
La base de datos
Tener el control de la Problema
Ejemplo: Rompiendo clave Exteriores Relaciones
Ejemplo: compartido de datos estáticos
Ejemplo: datos compartidos
Ejemplo: compartido Tablas
Bases de datos de refactorización
Puesta en escena de las vacaciones
Los límites transaccionales
Tratar De nuevo más tarde
Abortar la operación entera
Las transacciones distribuidas
¿Entonces lo que hay que hacer?
informes
La base de datos de informes
Recuperación de datos a través de llamadas de servicio
Bombas de datos
destinos alternativos
Bomba de datos de eventos
Bomba de los datos de copia de seguridad
Hacia Tiempo real
Costo de Cambio
Causas comprensión
Resumen
80
81
81
81
81
82
82
82
82
84
85
86
87
88
89
89
91
91
92
93
93
93
95
96
98
98
99
100
100
101
102
6. Deployment.103 ..............................................................................................
Una breve introducción a la integración continua
¿Usted está haciendo realmente?
Mapeo de integración continua a microservicios
Construir oleoductos y Entrega Continua
Y las excepciones inevitables
Los artefactos Específicos de la Plataforma
Los artefactos del sistema operativo
Imágenes personalizadas
Imágenes como artefactos
vi| Tabla de contenido
103
104
105
107
108
109
110
111
113
Servidores inmutables
entornos
Configuración de servicio
Servicio-a-Host Mapping
Servicios Múltiples por host
contenedores de aplicaciones
Servicio individual por sistema
Plataforma como servicio
Automatización
Dos Los estudios de casos sobre el poder de la automatización
De físico a virtual
La virtualización tradicional
Vagabundo
Linux Contenedores
Estibador
Una interfaz de despliegue
Definición de Medio Ambiente
Resumen
113
114
115
116
116
118
119
120
121
122
122
123
124
124
126
127
128
130
7. Testing.131......................................................................................................
tipos de pruebas
Prueba Scope132
Unidad pruebas
Servicio pruebas
De extremo a extremo pruebas
Comercio-Offs135
Cómo Muchos? 136
Servicio de implementación de pruebas
burla o se Stubbing137
Un talón inteligente Service138
Aquellos End-to-End Tricky pruebas
Los inconvenientes de extremo a extremo Pruebas
Escamosa y quebradiza pruebas
Quien escribe estas Pruebas?
Cómo Tiempo? 141
El gran Pila-up142
los Metaversion143
Prueba No viajes, Stories143
Las pruebas dirigidos por el consumidor a la Rescue144
Pact145
Sus Acerca de Conversations147
Así que hay que usar End-to-End Pruebas?
131
134
134
135
136
138
140
140
141
147
vi
i
Pruebas Después Production148
La separación de despliegue desde Release148
Canario Releasing149
Tiempo medio de reparación Con el tiempo medio entre Fracasos? 150
De funciones cruzadas Pruebas
Actuación pruebas
Summary153
151
152
8. Monitoring.155 ...............................................................................................
Servicio sola, sola Server156
Servicio individual, múltiple Servers156
Servicios Múltiples, Múltiples Servers157
Troncos, troncos y aún Más Troncos ... 158
Seguimiento métrica a través de múltiples Services159
Servicio Metrics160
Sintético Monitoring161
La implementación de Semántica Monitoring162
Correlación IDs162
los Cascade164
Standardization165
Considera el Audience165
los Future166
Summary167
9. Security.169 ....................................................................................................
Autenticación y Authorization169
Común de sesión único Implementations170
Inicio de sesión único Gateway171
De grano fino Authorization172
Servicio-al-servicio de autenticación y Authorization173
Permitir todo dentro de la Perimeter173
HTTP (S) básico Authentication174
Utilizar SAML o OpenID Connect174
Cliente Certificates175
Durante HMAC HTTP176
API Keys177
El diputado Problem178
Asegurar los datos en Rest180
Vaya con el Pozo Known180
Sus Todo sobre el Keys181
Escoja su objetivos
descifrar el Demand181
viii| Tabla de contenido
181
Cifrar Backups181
defensa en Depth182
Firewalls182
Logging182
Detección de Intrusos (y prevención) System182
Red Segregation183
Operando System183
Un Trabajado Example184
Ser Frugal186
El humano Element187
El Dorado Rule187
Seguridad para hornear In187
Externo Verificación
Summary188
188
10. Conway Ley y el Sistema Design.191 ................................................................
Evidence191
Suelta y de estructura rígida Organizations192
ventanas Vista192
Netflix y Amazon192
¿Qué podemos hacer con Este? 193
La adaptación a la Comunicación vías
Servicio Ownership194
Controladores para Compartido Services195
También Difícil de Split195
Característica equipos
Entrega Bottlenecks196
Abrir interna Source196
El papel de la Custodians197
Maturity197
Estampación
Contextos acotadas y equipo Structures198
el Huérfano Servicio? 198
Caso de estudio: RealEstate.com.au199
Conway ley de Reverse201
People202
Summary203
193
195
198
11. microservicios en Scale.205 .............................................................................
El fracaso es Everywhere205
¿Cuánto es demasiado Mucho? 206
Degradante Functionality207
ix
Seguridad arquitectónica Measures208
el Antifragile Organization210
Timeouts211
Circuito Breakers212
Bulkheads214
Isolation215
Idempotency215
Scaling216
Ir Bigger217
Terrible Las cargas de trabajo
Su difusión Risk217
Carga Balancing219
Worker-Basado Systems220
Comenzando Again221
Escalada Databases222
Disponibilidad de servicio Versus Durabilidad de Data222
la ampliación de Reads222
la ampliación de escribe
Base de datos compartida Infrastructure224
CQRS224
Caching225
Del lado del cliente, Proxy, y del lado del servidor Caching226
El almacenamiento en caché en HTTP226
El almacenamiento en caché de escribe
El almacenamiento en caché de Resilience228
Cómo ocultar la Origin228
Quédatelo Simple229
El envenenamiento de la caché: A Cautionary Cuento
Autoscaling230
GORRA Theorem232
sacrificando Consistency233
sacrificando Availability233
partición sacrificar ¿Tolerancia?
AP o CP? 235
Sus No todos o Nothing235
Y el real Mundo
Servicio Discovery236
DNS237
Servicio dinámico Registries238
Zookeeper238
Consul239
Eureka240
x| Tabla de contenido
217
223
228
230
234
236
Su rodando Own241
no Olvida el Los seres humanos! 241
documentar Services241
Swagger242
HAL y el HAL Browser242
La auto-describen System243
Summary243
12. Bringing It All Together.245 .............................................................................
Principios de Microservices245
Alrededor de modelo de negocios Concepts246
Adoptar una cultura de Automation246
Ocultar implementación interna Details247
Todo el descentralizar Things247
Independientemente Deployable248
Aislar Failure248
Muy Observable249
¿Cuándo debe usted utilizar no Microservicios? 249
De despedida Palabras
250
Index.251 .............................................................................................................
xi
Prefacio
Microservicios son una aproximación a los sistemas distribuidos que promuevan el
uso de los servicios de grano fino con sus propios ciclos de vida, que colaboran
juntos. Debido a que los servicios de micro se modelan principalmente en torno a los
dominios de negocios, se evitan los problemas de las arquitecturas tradicionales
gradas. Microservicios también se integran las nuevas tecnologías y técnicas que han
surgido en la última década, lo que ayuda a evitar las caídas PIT muchas
implementaciones de arquitectura orientada a servicios.
Este libro está lleno de ejemplos concretos de uso microService en todo el mundo,
INCLUYENDO en organizaciones como Netflix, Amazon, dorado, y el grupo REA,
todos los cuales han encontrado que el aumento de la autonomía de esta arquitectura
da a sus equipos es una gran ventaja.
Quién debería leer este libro
El objetivo de este libro es amplio, ya que las implicaciones de las arquitecturas
MICROSERVICE de grano fino también son amplias. Como tal, se debería hacer un
llamamiento a las personas interesadas en los aspectos de diseño, desarrollo,
implementación, pruebas y mantenimiento de los sistemas. Aquellos de ustedes que
ya han emprendido el viaje hacia arquitecturas de grano más fino, ya sea para una
aplicación totalmente nueva o como parte de la descomposición de un sistema
existente, más monolítica, encontrará un montón de consejos prácticos para ayudarle.
También ayudará a aquellos de ustedes que quieren saber lo que todos los problemas
se trata, de manera que se puede determinar si microservicios son adecuados para
usted.
Por qué escribí este libro
Empecé a pensar en el tema de las arquitecturas de aplicaciones hace muchos años,
cuando se trabaja para ayudar a las personas entregan su software más rápido. Me di
cuenta de que si bien la automatización infra- estructura, pruebas y técnicas de
administración continuos podrían ayudar, si el diseño funda- mental del sistema no
xiii
hace que sea fácil hacer cambios, entonces hay límites a lo que puede lograrse.
xiv | Prefacio
Al mismo tiempo, muchas organizaciones estaban experimentando con arquitecturas
de grano más fino para lograr objetivos similares, sino también para lograr cosas
como la mejora de la escala, el aumento de la autonomía de los equipos, o para
abrazar con mayor facilidad las nuevas tecnologías. Mis propias experiencias, así
como los de mis colegas en ThoughtWorks y en otros lugares, reforzó el hecho de
que el uso de un mayor número de servicios con sus propios ciclos independientesvida resultó en más dolores de cabeza que tuvieron que ser tratados. En muchos
sentidos, este libro fue concebido como una ventanilla única que ayudaría a abarcar
la amplia variedad de ics Top- que son necesarios para la comprensión de
microservicios-algo que me han ayudado mucho en el pasado!
Una palabra en microservicios Hoy
Microservicios es un tema de rápido movimiento. Aunque la idea no es nueva
(aunque el término en sí es), las experiencias de la gente de todo el mundo, junto con
la aparición de nuevas tecnologías, están teniendo un profundo efecto en la forma en
que se utilizan. Debido al rápido ritmo del cambio, he tratado de enfocar este libro
sobre las ideas más de tecnologías específicas, sabiendo que los detalles de
implementación siempre cambian más rápido que los pensamientos detrás de ellos.
Sin embargo, estoy totalmente de esperar que en pocos años a partir de ahora vamos
a aprendido aún más acerca de dónde encajan microservicios, y cómo usarlos bien.
Así, mientras que yo he hecho todo lo posible para destilar la esencia del tema en este
libro, si te interesa el tema, debe estar preparado para muchos años de aprendizaje
continuo para mantener en la parte superior del estado del arte!
La navegación de este libro
Este libro está organizado principalmente en un formato basado en el tema. Como tal,
es posible que desee saltar en los temas específicos que más le interesen. Mientras
que he hecho todo lo posible para hacer referencia a términos e ideas en los capítulos
anteriores, me gustaría pensar que incluso las personas que se consideran bastante
experimentado encontrará algo de interés en todos los capítulos aquí. Sin duda
sugerir que tome un vistazo aCapitulo 2, Que afecta a la amplitud del tema, así como
proporcionar parte de la construcción de cómo hago las cosas en caso de que si
quieres profundizar más en algunos de los temas posteriores.
Para la gente nueva en el tema, he estructurado Los capítulos de una manera que
espero que tenga sentido para leer de principio a fin.
He aquí un resumen de lo que cubrimos:
Capítulo 1, microservicios
Comenzaremos con una introducción a microservicios, incluyendo los beneficios
clave, así como algunas de las desventajas.
xiii
Capítulo 2, el arquitecto evolutiva
Este capítulo trata de las dificultades que enfrentamos en términos de hacer
compensaciones como arquitectos, y cubre específicamente cuántas cosas
tenemos que pensar con microservicios.
Capítulo 3, Cómo modelo de servicios
Aquí vamos a empezar a definir los límites de microservicios, usando técnicas de
diseño de dominio impulsada para ayudar a enfocar nuestro pensamiento.
Capítulo 4, Integración
Aquí es donde comienza a recibir un poco más en las implicaciones tecnológicas
específicas, como veremos qué tipo de técnicas de colaboración de servicios nos
ayudará más. También vamos a profundizar en el tema de las interfaces de
usuario y la integración con el legado y (COTS) productos off-the-shelf
comerciales.
Capítulo 5, la división del monolito
Muchas personas se interesan en microservicios como un antídoto para sistemas
grandes y de difícil acceso de cambio monolíticas, y esto es exactamente lo que
vamos a cubrir en detalle en este capítulo.
Capítulo 6, despliegue
Aunque este libro es principalmente teórica, pocos temas en el libro han sido tan
afectados por los cambios recientes en la tecnología como la implementación, lo
que vamos a explorar aquí.
Capítulo 7, Testing
En este capítulo se adentra en el tema de las pruebas, un área de especial
preocupación cuando se manipula el despliegue de múltiples servicios discretos.
De particular interés será el papel que los contratos orientados al consumidor
pueden desempeñar para ayudar a asegurar la calidad de nuestro software.
Capítulo 8, Monitorización
Pruebas nuestro software antes de la producción no ayuda en caso de problemas,
una vez que vayamos en vivo, y este capítulo explora cómo podemos controlar
nuestros sistemas de grano fino y hacer frente a parte de la complejidad
emergente de los sistemas distribuidos.
Capítulo 9, Seguridad
Aquí vamos a examinar los aspectos de seguridad de microservicios y considerar
cómo manejar usuario-a-servicio y la autenticación de servicio a servicio y
autorización. La seguridad es un tema muy importante en la informática, que se
descuida con demasiada facilidad. Aunque soy de ninguna manera un experto en
seguridad, espero que este capítulo lo menos ayudarle a considerar algunos de
los aspectos que hay que tener en cuenta en la construcción de sistemas y
sistemas MICROSERVICE en particular.
XVI | Prefacio
Capítulo 10 de la Ley de Conway y Diseño de Sistemas
Este capítulo se centra en la interacción de la estructura organizativa y
arquitec- tura. Muchas organizaciones se han dado cuenta que los problemas
producirá si no se mantienen los dos en armonía. Vamos a tratar de llegar
fondo de este dilema, y con- Sider algunas diferentes maneras de alinear
diseño del sistema con la estructura de sus equipos.
la
se
al
el
Capítulo 11, microservicios en la Escala
Aquí es donde empieza a observar haciendo todo esto a escala, de manera que
podamos manejar el mayor riesgo de falla que puede ocurrir con un gran número
de servicios, así como grandes volúmenes de tráfico.
Capítulo 12, Uniendo fuerzas
Los intentos de los capítulos finales para destilar abajo de la esencia de la base
de lo que hace servicios de micro diferente. Incluye una lista de siete principios
microservicios, así como una recapitulación de los puntos clave del libro.
Las convenciones usadas en este libro
Las siguientes convenciones tipográficas se utilizan en este libro:
Itálico
Indica nuevos términos, direcciones URL, direcciones de correo electrónico, nombres de
archivos y extensiones de archivo.
anchura constante
Se utiliza para las listas de programas, así como dentro de los párrafos para
referirse a programar ele- mentos tales como nombres de variable o función,
bases de datos, tipos de datos, variables de entorno, sentencias y palabras clave.
Anchura constante negrita
Muestra los comandos u otro texto que debe ser escrito, literalmente, por parte del usuario.
Constant cursiva ancho
Muestra texto que debe ser reemplazado con valores proporcionados por el
usuario o por valores determinado por el contexto.
Libros en Safari®
Safari Books Online es una biblioteca digital bajo demanda
que deliv- ERS experto contenido tanto en forma de libros y
de vídeo de los autores más importantes del mundo en
tecnología y negocios.
profesionales de la tecnología, los desarrolladores de software, diseñadores web, y
los negocios y profesionales tivos crea- utilizan Safari Books Online como su
Prefacio | xv
principal recurso para la investigación, resolución de problemas, el aprendizaje y la
formación para la certificación.
XVI | Prefacio
Safari Books Online ofrece una gama de planes y precios para empresa, gobierno,
educacióne individuos.
Los miembros tienen acceso a miles de libros, videos de entrenamiento, y los
manuscritos originales, en una base de datos completa de búsqueda de editores como
O'Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft
Press, Sams, Que, Peachpit Press, Focal Press, Cisco prensa, John Wiley & Sons,
Syngress, Morgan Kaufmann, libros rojos de IBM, Packt, Adobe Press, FT Press,
Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Tecnología de golf y
cientos más. Para obtener más información sobre Safari Books Online, por favor
visiteen línea.
Cómo contactarnos
Por favor dirigirse a los comentarios y preguntas en relación con este libro a la editorial:
O'Reilly Media, Inc.
1005 carretera de Gravenstein Norte
Sebastopol, CA 95472
800-998-9938 (en los Estados Unidos o
Canadá) 707-829-0515 (internacional o local)
707-829-0104 (fax)
Tenemos una página web para este libro, en el que lista de erratas, ejemplos, y
cualquier información adicional. Puede acceder a esta página enhttp://bit.ly/buildingmicroservices.
Para comentar o hacer preguntas técnicas acerca de este libro, envía un correo
electrónico a bookques- tions@oreilly.com.
Para obtener más información acerca de nuestros libros, cursos, conferencias y
noticias, visite nuestro sitio en la Web http://www.oreilly.com.
Encuentranos en Facebook: http://facebook.com/oreilly
Síguenos en Twitter: http://twitter.com/oreillymedia
ver en YouTube: http://www.youtube.com/oreillymedia
Expresiones de gratitud
Este libro está dedicado a Lindy Stephens, sin los cuales no existiría. Ella me animó a
empezar en este viaje, me han apoyado durante todo el proceso a menudo estresante
de la escritura, y es el mejor socio que podría haber pedido. También me gustaría
dedicar esto a mi padre, Howard Newman, que siempre ha estado ahí para mí. Esto
es para los dos.
Prefacio | xvii
Me gustaría destacar Ben Christensen, Vivek Subramaniam, y Martin Fowler para
proporcionar retroalimentación detallada a lo largo del proceso de escritura,
ayudando a dar forma a lo convirtió en este libro. También me gustaría dar las
gracias a James Lewis, con los que he consumido muchas cervezas discuten las ideas
presentadas en este libro. Este libro sería una sombra de sí mismo sin su ayuda y
orientación.
Además, muchos otros proporcionaron ayuda y retroalimentación sobre las primeras
versiones del libro. En concreto, me gustaría dar las gracias (en ningún orden en
particular) Kane Venables, Anand Krishnaswamy, Kent McNeil, Charles Haynes,
Chris Ford, Aidy Lewis, Will Támesis, Jon Aleros, Rolf Russell, Badrinath
Janakiraman, Daniel Bryant, Ian Robinson, Jim Webber, Stewart Gleadow, Evan
Bottcher, Eric Espada, Olivia Leonard, y todos mis otros colegas en ThoughtWorks y
en toda la industria, que me han ayudado a llegar hasta aquí.
Por último, me gustaría dar las gracias a toda la gente de O'Reilly, incluyendo Mike
Loukides por conseguirme a bordo, mi editor Brian MacDonald, Rachel Monaghan,
Kristen Brown, Betsy Waliszewski, y todas las otras personas que han contribuido de
una manera que mayo Nunca conocer.
xviii | Prefacio
CAPÍTULO 1
microservicios
Desde hace muchos años, hemos ido encontrando mejores maneras de construir
sistemas. Hemos estado aprendiendo de lo que ha venido antes, la adopción de
nuevas tecnologías, y observando cómo una nueva ola de empresas de tecnología
operan en diferentes formas de crear siste- mas de TI que ayudan a hacer sus clientes
y sus propios desarrolladores más feliz.
Driven Design-Domain libro de Eric Evans (Addison-Wesley) nos ayudó a
comprender la importancia de representar el mundo real en nuestro código, y nos
mostró mejores maneras de modelar nuestros sistemas. El concepto de la entrega
continua mostró cómo podemos conseguir mayor eficacia y eficiencia de nuestro
software en producción, infundiendo en nosotros la idea de que debemos tratar a cada
registro de entrada como una versión candidata. Nuestra comprensión de cómo
funciona la Web nos ha llevado a desarrollar mejores maneras de tener máquinas
hablan con otras máquinas. concepto de Alistair Cockburnarquitectura hexagonal nos
guiaron lejos de las arquitecturas de capas donde la lógica de negocio podría ocultar.
plataformas de virtualización nos permite cambiar el tamaño y la disposición nuestras
máquinas a voluntad, con la infraestructura de automatización ción que nos da una
manera de manejar estas máquinas a escala. Algunos exitosas zaciones grandes,
organiza- como Amazon y Google acuerdo con la idea de pequeños equipos con el
ciclo de vida completo de sus servicios. Y, más recientemente, Netflix ha compartido
con nosotros los caminos de la construcción de sistemas antifragile a una escala que
habría sido difícil de comprender hace apenas 10 años.
Dominio impulsada por el diseño. El suministro continuo. virtualización bajo
demanda. automatización de infra- estructura. equipos autónomos pequeños.
Sistemas a escala. Microservicios han surgido de este mundo. Ellos no fueron
inventados o descritos antes del hecho; surgieron como una tendencia o un patrón, de
un uso en el mundo real. Pero existen sólo por todo lo que ha pasado antes. A lo
largo de este libro, voy a tirar de hilos de este trabajo previo para ayudar a pintar un
cuadro de cómo construir, gestionar y evolucionar microservicios.
1
Muchas organizaciones han encontrado que al abrazar de grano fino,
MICROSERVICE arquitecturas, pueden ofrecer software más rápido y abrazar las
nuevas tecnologías. Microser-
10 | Capítulo 1: microservicios
vicios nos dan significativamente más libertad para reaccionar y tomar decisiones
diferentes, que nos permite responder más rápido a los cambios inevitables que nos
impacta a todos.
¿Cuáles son microservicios?
Microservicios son pequeños servicios, autónomos que trabajan en conjunto. Vamos
a romper que inition def- un poco y considerar las características que hacen
microservicios diferente.
Pequeña, y se centró en hacer una cosa bien
Bases de código crecen mientras escribimos código para agregar nuevas
características. Con el tiempo, puede ser difícil saber por dónde hay que hacer un
cambio porque el código base es tan grande. A pesar de una unidad de bases de
código monolíticos claras, modulares, con demasiada frecuencia estos límites
arbitrarios en proceso descomponen. Código relacionado con funciones similares
empieza a ser extendido por todo, lo que hace corregir errores o implementaciones
más difícil.
Dentro de un sistema monolítico, que lucha contra estas fuerzas, tratando de asegurar
que nuestro código es más cohesiva, a menudo mediante la creación de abstracciones
o módulos. Cohesión-la unidad de código relacionado haber agrupado-es un concepto
importante cuando pensamos en microservicios. Esto se ve reforzado por la
definición de Robert C. MartinSoltero Principio de responsabilidad, Que establece
que “Reúnanse las cosas que cambian por la misma razón, y separan aquellas cosas
que cambian por diferentes razones.”
Microservicios toman este mismo enfoque a los servicios independientes. Nos
centramos nuestros límites del servicio en los límites de negocios, por lo que es obvio
que el código vive para una determinada pieza de funcionalidad. Y manteniendo este
servicio centrado en un límite explícito, evitamos la tentación para que crezca
demasiado grande, con todas las dificultades asociadas que esto puede introducir.
La pregunta a menudo me preguntan cómo es pequeño es pequeño? Dando un
número de líneas de código es problemático, ya que algunas lenguas son más
expresivos que otros y por lo tanto, pueden hacer más en menos líneas de código.
También hay que considerar el hecho de que podíamos estar tirando en varias
dependencias, que a su vez contienen muchas líneas de código. Además, una parte de
su dominio puede ser legítimamente complejo, que requiere más código. Jon Aleros
en RealEstate.com.au en Australia caracteriza a un microService como algo que
podría ser reescrito en dos semanas, una regla de oro que tenga sentido para su
contexto particular.
Otra respuesta un tanto trillada que puedo dar es lo suficientemente pequeño y no
más pequeño. Al hablar en conferencias, que casi siempre la pregunta que tiene un
sistema que es demasiado grande y que desea romper? Casi todos levantan sus
1
manos. Parece que tenemos un muy buen sentido de lo que es demasiado grande, y
por lo tanto se podría argumentar que una vez que una pieza de código ya no se
siente demasiado grande, es lo suficientemente pequeño, probablemente.
10 | Capítulo 1: microservicios
Un importante factor en ayudar a responder a lo pequeño? es lo bien que el servicio
se alinea al equipo estructuras. Si el código base es demasiado grande para ser
manejado por un equipo pequeño, mirando a descomponerlo es muy sensible.
Hablaremos más sobre alineación de la organización en el futuro.
Cuando se trata de lo pequeño que es lo suficientemente pequeño, me gusta pensar en
estos términos: cuanto menor sea el servicio, más que maximizar los beneficios y
desventajas de la arquitectura vice microser-. A medida que se hacen más pequeños,
los beneficios de todo aumento de la interdependencia. Pero también lo hace parte de
la complejidad que surge de tener más y más partes en movimiento, algo que vamos
a explorar en este libro. A medida que vaya mejor en el manejo de esta complejidad,
se puede luchar por los servicios cada vez más pequeños.
Autónomo
Nuestra microService es una entidad separada. Podría ser desplegado como un
servicio aislado en una plataforma como servicio (PaaS), o podría ser su propio
proceso del sistema operativo. Tratamos de evitar el embalaje múltiples servicios en
la misma máquina, aunque la definición de la máquina en el mundo actual es bastante
confusa! Como veremos más adelante, a pesar de este aislamiento puede añadir un
poco por encima, dando como resultado la simplicidad hace que nuestro sistema
distribuido mucho más fácil razonar sobre, y más nuevas tecnologías son capaces de
mitigar muchos de los desafíos asociados con esta forma de implementación.
Todas las comunicaciones entre los servicios que ellos mismos son a través de
llamadas de red, para hacer cumplir la separación entre los servicios y evitar los
peligros de acoplamiento fuerte.
Estos servicios deben ser capaces de cambiar de forma independiente el uno del otro,
y desplegarse por sí mismos sin exigir a los consumidores a cambiar. Tenemos que
pensar en lo que nuestros servicios deben exponer, y lo que debemos permitir que se
oculta. Si hay demasiada compartir, nuestros servicios de consumo se vuelven junto a
nuestras representaciones internas. Esto disminuye nuestra autonomía, ya que
requiere una coordinación adicional con los consumidores cuando se hacen cambios.
Nuestro servicio expone una interfaz de programación de aplicaciones (API), y los
servicios que colaboran comunican con nosotros por esas API. También tenemos que
pensar en lo que tecnologıa es apropiada para asegurar que esto mismo no lo hace par
de los consumidores. Esto puede significar recoger las API independiente de la
tecnología para asegurar que no limitan las opciones tecnológicas. Volveremos una y
otra vez a la importancia de las buenas, APIs desacoplados lo largo de este libro.
Sin desacoplamiento, todo se descompone para nosotros. La regla de oro: se puede
hacer un cambio a un servicio y desplegarlo por sí mismo sin cambiar nada más? Si
la respuesta es no, entonces muchas de las ventajas que se discuten en este libro será
difícil para que usted pueda lograr.
A hacer desacoplamiento así, tendrá que modelar sus servicios a la derecha y
¿Cuáles son microservicios? |3
conseguir la API derecha. Voy a estar hablando de que una gran cantidad.
4| Capítulo 1: microservicios
Beneficios clave
Los beneficios de microservicios son muchas y variadas. Muchos de estos beneficios
se pueden imputarse a la aplicación de cualquier sistema distribuido. Microservicios,
sin embargo, tienden a lograr estos beneficios a un grado mayor, debido
principalmente a la distancia que toman los conceptos detrás de los sistemas
distribuidos y la arquitectura orientada a servicios.
La heterogeneidad tecnología
Con un sistema compuesto de múltiples servicios, que colaboran, podemos decidir
utilizar dife- rentes tecnologías dentro de cada uno. Esto nos permite recoger la
herramienta adecuada para cada trabajo, en lugar de tener que seleccionar un más
estandarizado, una talla única para todos que a menudo termina siendo el
denominador común más bajo.
Si una parte de nuestro sistema necesita mejorar su rendimiento, podríamos decidir
usar una pila de tecnología diferente, que es más capaz de alcanzar los niveles de
rendimiento requeridos. También podemos decidir que la forma en que almacenamos
nuestros datos debe cambiar para diferentes partes de nuestro sistema. Por ejemplo,
para una red social, podríamos almacenar las interacciones de nuestros usuarios en
una base de datos orientada gráfico-para reflejar la naturaleza altamente
interconectada de un gráfico social, pero tal vez los mensajes que los usuarios hacen
podrían ser almacenados en un almacén de datos orientada a documentos, dando
lugar a una arquitectura heterogénea como la que se muestra en laFigura 1-1.
La Figura 1-1. Microservicios pueden permitir a abrazar con mayor facilidad las diferentes
tecnologías
Con microservicios, sino que también son capaces de adoptar la tecnología más
rápidamente, y entienda cómo los nuevos avances nos pueden ayudar. Uno de los
mayores obstáculos para probar y la adopción de la nueva tecnología es los riesgos
asociados a ella. Con una aplica- ción monolítico, si quiero probar un nuevo lenguaje
de programación, bases de datos o marco, cualquier cambio afectará a una gran
cantidad de mi sistema. Con un sistema que consta de múltiples servicios, tengo
varios nuevos lugares en los que probar una nueva pieza de tecnología. Puedo elegir
un servicio que es quizás menor riesgo y el uso de la tecnología allí, sabiendo que
¿Cuáles son microservicios? |5
puedo limitar cualquier posible impacto negativo. Muchas organizaciones consideran
esta capacidad de absorber más rápidamente nuevas tecnologías para ser una ventaja
real para ellos.
6| Capítulo 1: microservicios
Abrazando múltiples tecnologías no viene sin una sobrecarga, por supuesto. Algunas
organizaciones optan por colocar algunas restricciones sobre las opciones de idioma.
Netflix y Twitter, por ejemplo, sobre todo utilizar la máquina virtual de Java (JVM)
como una plataforma, ya que tienen una muy buena comprensión de la fiabilidad y el
rendimiento de ese sis- tema. También desarrollan las bibliotecas y utillaje para la
JVM que hacen que opera a escala mucho más fácil, pero hacen que sea más difícil
para los servicios o clientes no basados en Java. Pero ni Twitter ni Netflix utilizan
sólo una pila de tecnología para todos los puestos de trabajo, ya sea. Otro
contrapunto a las preocupaciones acerca de la mezcla de diferentes tecnologías es el
tamaño. Si realmente puedo reescribir mi microService en dos semanas, es posible
que así mitigar los riesgos de las nuevas tecnologías embrac- ing.
Ya que encontrará en este libro, al igual que muchas cosas en relación con
microservicios, se trata de encontrar el equilibrio adecuado. Discutiremos cómo
tomar decisiones de tecnología enCapitulo 2, Que se centra en la arquitectura
evolutiva; y enCapítulo 4, Que se ocupa de la integración, aprenderá la forma de
garantizar que sus servicios pueden evolucionar su tecnología de forma
independiente entre sí sin acoplamiento indebida.
Resiliencia
Un concepto clave en la ingeniería de la resiliencia es la mampara. Si uno de los
componentes de un sistema falla, pero que el fallo no se conectan en cascada, se
puede aislar el problema y el resto del sistema puede seguir trabajando. los límites
del servicio se convierten en sus mamparos obvias. En un servicio monolítico, si el
servicio falla, todo deja de funcionar. Con un sistema monolítico, que puede
ejecutarse en múltiples máquinas para reducir nuestras posibilidades de fracaso, pero
con microservicios, podemos construir sistemas que manejan el fracaso total de los
servicios y degradar la funcionalidad en consecuencia.
Nosotros tenemos que tener cuidado, sin embargo. Para asegurar que nuestros
sistemas MICROSERVICE puede abarcar adecuadamente esta mayor resistencia,
tenemos que entender las nuevas fuentes de fracaso que los sistemas distribuidos
tienen que tratar. Las redes pueden y se producirá un error, ya que las máquinas.
Tenemos que saber cómo manejar esto, y qué impacto (si lo hay) que debe tener en el
usuario final de nuestro software.
Hablaremos más sobre una mejor capacidad de recuperación de manipulación, y
cómo manejar los modos de fallo, en Capítulo 11.
Escalada
Con un servicio monolítica grande, tenemos que escalar todo junto. Una pequeña
parte de nuestro sistema global está limitado en el rendimiento, pero si ese
comportamiento es encerrado en una aplicación monolítica gigante, tenemos que
manejar escalamiento todo como una pieza. Con los servicios más pequeños, sólo
Beneficios clave | 5
podemos escalar los servicios que necesitan de escala, lo que nos permite ejecutar
otras partes del sistema en un hardware más pequeños, menos potentes, como
enFigura 1-2.
6| Capítulo 1: microservicios
La Figura 1-2. Puede orientar la ampliación a tan sólo aquellos que lo necesitan microservicios
Dorada, un minorista en línea de la manera, adoptó microservicios por esta razón
exacta. A partir de 2007 con una aplicación Rails monolítico, para el año 2009 el
sistema de la cerda joven fue incapaz de hacer frente a la carga que se le plantean. Al
dividir a cabo piezas de la base de su sistema, dorado fue ter BET capaz de tratar con
sus picos de tráfico, y en la actualidad cuenta con más de 450 microservicios, cada
uno que se ejecuta en múltiples máquinas separadas.
Cuando abrazar sistemas de aprovisionamiento bajo demanda como los
proporcionados por los Servicios Web de Amazon, incluso podemos aplicar esta
escala en la demanda de aquellas piezas que lo necesitan. Esto nos permite controlar
nuestros costos de manera más eficaz. No es frecuente que un enfoque arquitectónico
puede ser tan estrechamente correlacionada con un ahorro de costes casi inmediatos.
Facilidad de implementación
Un cambio de una línea para una aplicación monolítica millones de líneas de larga
requiere toda la aplicación para ser desplegado a fin de liberar el cambio. Eso podría
ser un impacto a gran, el despliegue de alto riesgo. En la práctica, de gran impacto,
las implementaciones de alto riesgo terminan sucediendo con poca frecuencia debido
al temor comprensible. Desafortunadamente, esto significa que nuestros cambios se
acumulan y se acumulan entre los lanzamientos, hasta que la nueva versión de
nuestra producción golpear aplicación tiene masas de cambios. Y cuanto mayor sea
el delta entre versiones, mayor es el riesgo de que vamos a llegar algo mal!
Con microservicios, podemos hacer un cambio a un único servicio y desplegarlo
inde- pendientemente del resto del sistema. Esto nos permite obtener nuestro código
desplegado más rápido. Si se produce un problema, se puede aislar rápidamente a un
servicio individual, haciendo rápida reversión fácil de lograr. También significa que
podemos conseguir nuestra nueva funcionalidad a tomers cliente central más rápidos.
Beneficios clave | 7
Esta es una de las razones principales por las organizaciones como Amazon y Netflix
utilizan estas arquitecturas para asegurar que eliminar la mayor cantidad de
impedimentos como posi- ble para conseguir el software fuera de la puerta.
8| Capítulo 1: microservicios
La tecnología en este espacio ha cambiado mucho en el último par de años, y vamos
a estar buscando más profundamente en el tema de la implementación en un mundo
en microService Capítulo 6.
La alineación organizacional
Muchos de nosotros hemos experimentado los problemas asociados a los grandes
equipos y grandes bases de código. Estos problemas pueden exacerbarse cuando el
equipo se distribuye. También sabemos que los equipos más pequeños que trabajan
en bases de código más pequeños tienden a ser más productivo.
Microservicios nos permiten alinear mejor nuestra arquitectura de nuestra
organización, ayudando a minimizar el número de personas que trabajan en una sola
base de código para golpear el punto dulce del tamaño del equipo y la productividad.
También podemos cambiar la propiedad de los servicios entre los equipos para tratar
de mantener a la gente que trabaja en un servicio colocated. Vamos a entrar en
muchos más detalles sobre este tema cuando hablemos de la ley de Conway
enCapítulo 10.
Compuestabilidad
Una de las promesas clave de los sistemas distribuidos y arquitecturas orientadas a
servicios es que abrimos oportunidades para la reutilización de funcionalidad. Con
microservicios, permitimos a nuestra funcionalidad para ser consumido en diferentes
maneras para diferentes propósitos. Esto puede ser especialmente importante cuando
pensamos en cómo los consumidores utilizan nuestro software. Se ha ido el tiempo
en que se podría pensar por poco acerca de nuestro sitio web ya sea de escritorio o
aplicación móvil. Ahora tenemos que pensar en las miles de maneras que podríamos
desear para entretejer capacidades para la Web, aplicaciones nativas, web móvil,
aplicación tableta o dispositivo portátil. A medida que las organizaciones se mueven
lejos de pensar en términos de canales estrechos a conceptos más globales de la
participación del cliente, necesitamos arquitecturas que pueden mantener el ritmo.
Con microservicios, pensar en nosotros abriendo las costuras en nuestro sistema que
son direccionables por terceros. A medida que cambian las circunstancias, podemos
construir cosas de diferentes maneras. Con una aplicación monolítica, que a menudo
tienen una costura de grano grueso que se puede utilizar desde el exterior. Si quiero
romper ese hasta conseguir algo más útil, necesitaré un martillo! EnCapítulo 5, Voy a
discutir maneras para que usted pueda romperse sistemas monolíticos existentes, y es
de esperar cambiarlos a algunos, re-ces componibles microservi- reutilizables.
Optimización para Reemplazabilidad
Si usted trabaja en una de tamaño medio o grande organización, es probable que
usted está enterado de algún gran sistema, herencia desagradable sentado en la
esquina. El que nadie quiere tocar. El que es de vital importancia a la forma en que su
Beneficios clave | 9
empresa funciona, pero eso pasa a ser escrito en Fortran alguna variante rara y sólo
se ejecuta en hardware que llegó a final de la vida hace 25 años. Por qué no ha sido
sustituido? ¿Sabe por qué: es demasiado grande y arriesgado trabajo.
10| Capítulo 1: microservicios
Con nuestros servicios individuales son pequeñas en tamaño, el costo para
reemplazarlos con una mejor aplicación, o incluso eliminar por completo, es mucho
más fácil de manejar. ¿Cuántas veces ha eliminado más de un centenar de líneas de
código en un solo día y no preocuparse demasiado acerca de él? Con microservicios
siendo a menudo de tamaño similar, las barreras para reescribir o eliminar por
completo los servicios son muy bajos.
equipos utilizando enfoques MICROSERVICE se sienten cómodos con reescribir por
completo los servicios cuando sea necesario, y acaba de matar a un servicio cuando
ya no se necesita. Cuando una base de código es sólo unos pocos cientos de líneas de
largo, es difícil que la gente se emoción- aliado unido a él, y el costo de la sustitución
es bastante pequeña.
¿Qué hay de arquitectura orientada a servicios?
arquitectura orientada al servicio (SOA) es un enfoque de diseño donde laborate
múltiples servicios COL- para proporcionar un conjunto final de las capacidades. Un
servicio aquí normalmente significa un proceso del sistema operativo independiente
completamente com-. La comunicación entre estos servicios se produce a través de
llamadas a través de una red en lugar de llamadas de método dentro de un límite
proceso.
SOA surgido como un enfoque para combatir los retos de las grandes aplica- ciones
monolíticos. Es un enfoque que tiene como objetivo promover la reutilización de
software; dos o más aplicaciones de usuario final, por ejemplo, podrían utilizar tanto
los mismos servicios. Su objetivo es hacer que sea más fácil de mantener o reescribir
el software, ya que en teoría se puede sustituir un servicio con otro sin que nadie lo
sepa, siempre que la semántica del servicio no cambian demasiado.
SOA en su corazón es una idea muy sensata. Sin embargo, a pesar de muchos
esfuerzos, hay una falta de buen consenso sobre cómo hacer bien SOA. En mi
opinión, gran parte de la industria ha dejado de mirar de manera integral lo suficiente
en el problema y presentar una alternativa convincente a la narrativa establecida por
varios vendedores en este espacio.
Muchos de los problemas establecidos en la puerta de SOA son en realidad
problemas con cosas como los protocolos de comunicación (por ejemplo, jabón),
middleware proveedor, una falta de orientación sobre el servicio granular, o la
dirección equivocada en recoger lugares para dividir su sistema. Vamos a hacer
frente a cada uno de estos a su vez a lo largo del resto del libro. Un cínico podría
Sugiérale que los vendedores cooptado (y en algunos casos condujo) el movimiento
SOA como una forma de vender más productos, y aquellos productos mismísimos en
el extremo socavado el objetivo de SOA.
Gran parte de la sabiduría convencional en torno a SOA no ayudará a entender cómo
dividir algo grande en algo pequeño. Que no habla de lo grande que es demasiado
grande. No habla lo suficiente sobre el mundo real, las formas prácticas para asegurar
Beneficios clave |
11
que los servicios no se vuelven excesivamente acoplados. El número de cosas que
van no se dice es que muchos de los problemas asociados con SOA se originan.
12| Capítulo 1: microservicios
El enfoque microService ha surgido de uso del mundo real, teniendo nuestra mejor
comprensión de los sistemas y la arquitectura SOA para hacerlo bien. Así que en su
lugar debe pensar en microservicios como un enfoque específico para SOA de la
misma manera que XP o Scrum son enfoques específicos para el desarrollo ágil de
software.
Otras técnicas descomposicional
Cuando pones a ello, muchas de las ventajas de una arquitec- tura basada en
microService provienen de su naturaleza granular y el hecho de que le da muchas
más opciones en cuanto a cómo resolver los problemas. Pero podrían técnicas
similares descomposicionales lograr los mismos beneficios?
Las bibliotecas compartidas
Una técnica descomposicional muy estándar que se integra en prácticamente
cualquier idioma está rompiendo una base de código en múltiples bibliotecas. Estas
bibliotecas pueden ser proporcionados por terceros, o se crean en su propia
organización.
Las bibliotecas que dan una forma de compartir funciones entre los equipos y
servicios. Podría crear un conjunto de utilidades de recolección útiles, por ejemplo, o
tal vez una biblioteca de estadísticas que se pueden volver a utilizar.
Los equipos pueden organizarse en torno a estas bibliotecas, y las propias bibliotecas
pueden ser reutilizados. Sin embargo, hay algunos inconvenientes.
En primer lugar, se pierde la heterogeneidad verdadera tecnología. La biblioteca
generalmente tiene que estar en el mismo idioma, o por lo menos se ejecutan en la
misma plataforma. En segundo lugar, la facilidad con que se puede escalar partes de
su sistema de forma independiente el uno del otro se ve reducida. A continuación, a
menos que estés usando bibliotecas de enlace dinámico, no se puede desplegar una
nueva biblioteca sin volver a desplegar todo el proceso, por lo que su capacidad de
implementar cambios en el aislamiento se reduce. Y tal vez el truco es que carecen
de las costuras evidentes alrededor de los cuales erigir las medidas de seguridad
arquitectónicas para garantizar la flexibilidad del sistema.
Las bibliotecas compartidas tienen su lugar. Se encontrará la creación de código para
tareas comunes que no son específicos de su ámbito empresarial que desee volver a
utilizar en toda la organización, que es un candidato obvio para convertirse en una
biblioteca reutilizable. Usted necesita tener cuidado, sin embargo. código compartido
utilizado para la comunicación entre los servicios puede convertirse en un punto de
acoplamiento, algo que discutiremos enCapítulo 4.
Los servicios pueden y deben hacer un uso intensivo de las bibliotecas de terceros
para reutilizar código común. Pero no nos reciben todo el camino.
Otras técnicas descomposicional | 9
módulos
Algunos lenguajes proporcionan sus propias técnicas de descomposición modulares
que van más allá de simples bibliotecas. Permiten cierta gestión del ciclo de vida de
los módulos, de tal manera que se pueden implementar en un proceso en ejecución,
que le permite hacer cambios sin tener todo el proceso.
La Iniciativa de Entrada de código abierto (OSGi) es digna de ser llamada como uno
de los enfoques Tecnología en concreto a la descomposición modular. Java en sí no
tiene un verdadero concepto de módulos, y vamos a tener que esperar al menos hasta
el 9 de Java para ver esto, añadido a la lengua. OSGi, que surgió como un marco para
permitir que los plug-ins que se instalarán en el IDE Java Eclipse, ahora se utiliza
como una manera de adaptar un concepto modular en Java a través de una biblioteca.
El problema con OSGi es que está tratando de hacer cumplir las cosas como la
gestión del ciclo de vida del módulo sin suficiente apoyo en el lenguaje mismo. Esto
se traduce en más trabajo que tiene que ser hecho por los autores de módulos para
entregar en el aislamiento del módulo adecuado. Dentro de un límite de proceso,
también es mucho más fácil caer en la trampa de hacer módu- excesivamente
acopladas entre sí, causando todo tipo de problemas. Mi propia experiencia con
OSGi, que se corresponde con la de los colegas de la industria, es que incluso con
buenos equipos es fácil para OSGi para convertirse en una fuente mucho más grande
de la complejidad de su orden de beneficios.
Erlang sigue un enfoque diferente, en el que los módulos se cuecen al horno en el
tiempo de ejecución de lenguaje. Por lo tanto, Erlang es un enfoque muy maduro a la
descomposición modular. Erlang módulos se pueden detener, arrancará de nuevo y
actualizar sin problema. Erlang incluso admite la ejecución de más de una versión del
módulo en un momento dado, lo que permite la actualización módulo más elegante.
Las capacidades de los módulos de Erlang son realmente impresionantes, pero
incluso si tenemos la suerte de usar una plataforma con estas capacidades, que
todavía tienen los mismos defectos como lo hacemos con las bibliotecas compartidas
normales. Estamos estrictamente limitados en nuestra capacidad de utilizar las
nuevas tecnologías, limitado en cómo podemos escalar de forma independiente,
puede derivar hacia técnicas de integración que son demasiado acoplamiento, y las
costuras de la falta de medidas de seguridad de arquitectura.
Hay una pena compartir observación final. Técnicamente, debería ser posible CRE
comían bien-factorizada, módulos independientes dentro de un solo proceso
monolítico. Y sin embargo, rara vez vemos que esto suceda. Los propios módulos
pronto se convertirá estrechamente unidos con el resto del código, la entrega de una
de sus principales ventajas. Tener un proceso de separación obligados- ary hace
cumplir la higiene limpio en este sentido (o al menos hace que sea más difícil de
hacer las cosas mal!). Yo no diría que este debe ser el principal impulsor para la
separación de procesos, por supuesto, pero es interesante que las promesas de
10| Capítulo 1: microservicios
separación modular dentro de los límites del proceso rara vez se entregan en el
mundo real.
Así, mientras que la descomposición modular dentro de un límite de proceso puede
ser algo que desea hacer, así como la descomposición de su sistema en los servicios,
por sí sola no va a ayudar
Otras técnicas descomposicional | 11
resolver todo. Si usted es una tienda de puro Erlang, la calidad del módulo de Erlang
Implementation puede conseguir que un camino muy largo, pero sospecho que
muchos de ustedes no están en esa situación. Para el resto de nosotros, hay que ver
como módulos que ofrece el mismo tipo de ataques benefactores como bibliotecas
compartidas.
No hay bala de plata
Antes de terminar, me llamo que microservicios hay almuerzo gratis o con una bala
de plata, y para hacer una mala elección como un martillo de oro. Tienen todas las
complejidades asociadas de sistemas distribuidos, y aunque hemos aprendido mucho
acerca de cómo administrar bien los sistemas distribuidos (del que hablaremos a lo
largo del libro) es todavía difícil. Si viene desde un punto de vista sistema
monolítico, que tendrá que ser mucho mejor en el manejo de implementación,
pruebas y monitoreo para desbloquear los beneficios que hemos cubierto hasta ahora.
También tendrá que pensar diferente acerca de cómo cambia la escala de sus sistemas
y asegurarse de que son resistentes. No se sorprenda si también cosas como las
transac- ciones distribuidas o teorema de tapa inicial que le da dolores de cabeza, ya
sea!
Toda empresa, organización, y el sistema es diferente. Una serie de factores se
juegan en si o no microservicios son adecuados para usted, y lo agresivo que puede
estar en adoptarlos. A lo largo de cada capítulo de este libro voy a tratar de darle
Ance guid- destacando los peligros potenciales, que deberían ayudar a trazar una
trayectoria constante.
Resumen
Esperemos que ahora que sabes lo que es un microService es, lo que lo hace diferente
de otras técnicas de composición, y cuáles son algunas de las principales ventajas
son. En cada uno de los siguientes capítulos vamos a entrar en más detalles sobre
cómo lograr estos beneficios y cómo evitar algunos de los problemas más comunes.
Hay una serie de temas a tratar, pero tenemos que empezar por alguna parte. Uno de
los principales retos a los que introducen microservicios es un cambio en el papel de
aquellos que a menudo guiar la evolución de nuestros sistemas: los arquitectos.
Veremos siguiente en algunos enfoques diferentes para este papel que pueden
garantizar que sacar el mayor provecho de esta nueva arquitectura.
No hay bala de plata |
11
CAPITULO 2
El arquitecto evolutiva
Como hemos visto hasta ahora, microservicios nos dan una gran variedad de
alimentos, y por lo tanto una gran cantidad de decisiones que tomar. Por ejemplo, el
número de tecnologías diferentes deberíamos usar, debemos dejar que diferentes
equipos utilizan diferentes lenguajes de programación, y debemos dividir o combinar
un servicio? ¿Cómo hacemos para tomar estas decisiones? Con el ritmo acelerado del
cambio, y el medio ambiente más fluido que estas arquitecturas permiten, el papel del
arquitecto también tiene que cambiar. En este capítulo, voy a tomar una visión
bastante obstinado de lo que es el papel de un arquitecto, y es de esperar lanzo un
último asalto a la torre de marfil.
Las comparaciones inexactas
Tú seguir usando esa palabra. No creo que significa lo que usted piensa que significa.
-Inigo Montoya, desde
La novia princesa
Los arquitectos tienen un trabajo importante. Ellos son los encargados de asegurarse
de que tenemos una visión técnica se unió en marcha, uno que debería ayudarnos a
entregar el sistema de nuestros clientes necesitan. En algunos lugares, que sólo
pueden tener que trabajar con un equipo, en cuyo caso el papel del arquitecto y
técnico principal suele ser el mismo. En otros casos, pueden ser defin- ing la visión
de todo un programa de trabajo, en coordinación con varios equipos de todo el
mundo, o tal vez incluso una organización entera. Cualquiera sea el nivel en que
operan, el papel es un asunto difícil de precisar, ya pesar de que a menudo siendo
sión de la carrera obvia progresión para los desarrolladores en las organizaciones
empresariales, sino que también es un papel que pone CISM más criti- que
prácticamente cualquier otro. Más que cualquier otra función, los arquitectos pueden
tener un impacto directo en la calidad de los sistemas construidos, en las condiciones
de trabajo de sus gues collea-, y en la capacidad de su organización para responder al
cambio, y sin embargo, por lo que parece fre- cuentemente para conseguir este papel
13
equivocado. ¿Porqué es eso?
14| Capítulo 2: El Arquitecto evolutiva
Nuestra industria es un joven. Esto es algo que parece que olvidamos, y sin embargo,
sólo han sido la creación de programas que se ejecutan en lo que reconocemos como
ordenadores de alrededor de 70 años. Por lo tanto, estamos constantemente buscando
a otras profesiones en un intento de explicar lo que hacemos. No somos médicos o
ingenieros, pero ni somos fontaneros o electricistas. En su lugar, se cae en un término
medio, lo que hace que sea difícil para que la sociedad nos entienden, o para nosotros
comprender dónde encajamos.
Así que tomamos prestada de otras profesiones. Nos llamamos “ingenieros de
software”, o “arquitectos”. Pero no estamos, ¿verdad? Arquitectos e ingenieros tienen
un rigor y la disci- plina que sólo podían soñar, y su importancia en la sociedad se
entiende bien. Recuerdo hablar con un amigo mío, el día antes de convertirse en un
arquitecto cualificado. “Mañana,” dijo, “si me dará consejos en el pub acerca de
cómo construir algu- cosa y que está mal, consigo rendir cuentas. Podría ser
demandado, al igual que en los ojos de la ley ahora soy un arquitecto cualificado y
que debería ser considerado responsable si se equivocan.”La importancia de estos
puestos de trabajo a la sociedad significa que las cualificaciones que debe sonas PLE
tienen que cumplir . En el Reino Unido, por ejemplo, se requiere un mínimo de siete
años de estudio antes de que pueda ser llamado un arquitecto. Sin embargo, estos
trabajos también se basan en un conjunto de conocimientos que se remonta miles de
años. ¿Y nosotros? No exactamente. ¿Cuál es la razón por la que ver la mayoría de
las formas de certificación de TI como sin valor, como se sabe muy poco acerca de lo
que parecen las buenas.
Una parte de nosotros quiere reconocimiento, por lo que pedir prestado los nombres
de otras profesiones que ya cuentan con el reconocimiento como industria
anhelamos. Pero esto puede ser doblemente perjudicial. En primer lugar, implica que
sabemos lo que estamos haciendo, cuando claramente no lo hacemos. Yo no diría que
los edifi- cios y puentes no se caigan, sino que caerá mucho menor que el número de
veces que nuestros programas se colgará, haciendo comparaciones con los ingenieros
bastante injusto. Segundo, las analogías se descomponen muy rápidamente cuando se
les da incluso una mirada superficial. Para cambiar las cosas, si la construcción de
puentes eran como la programación, a medio camino a través encontraríamos que la
otra orilla era ahora 50 metros más lejos, que en realidad era de barro en lugar de
granito, y que en lugar de construir un puente peatonal que se construye en vez - ing
un puente de carretera.
Tal vez el término arquitecto ha hecho el mayor daño. La idea de que alguien que
redacte un plan detallado de otros a interpretar, y espera que esto se lleve a cabo. La
ance equili- parte del artista, ingeniero parte, supervisando la creación de lo que
normalmente es una visión lar singu-, con todos otros puntos de vista ser servil, salvo
la de vez en cuando del ingeniero estructural en relación con las leyes de la física. En
nuestra industria, esta visión del arquitecto lleva a algunas prácticas terribles.
Diagrama tras diagrama, página tras página de documentación, creada con el fin de
informar la construcción del sistema perfecto, sin tener en cuenta el futuro
fundamentalmente incognoscible. Que carece por completo de cualquier
15
comprensión en cuanto a lo difícil que será la aplicación, o
16| Capítulo 2: El Arquitecto evolutiva
si es o no realmente funciona, y mucho menos tener ninguna posibilidad de cambiar a
medida que aprendemos más.
Cuando nos comparamos con los ingenieros o arquitectos, corremos el riesgo de
hacer a todos un mal servicio. Por desgracia, estamos atascados con la palabra
arquitecto por ahora. Así que lo mejor que podemos hacer es redefinir lo que
significa en nuestro contexto.
Una visión evolutiva para el Arquitecto
Nuestros requisitos cambian más rápidamente que lo hacen para las personas que
diseñan y construyen edificios-al igual que las técnicas y herramientas a nuestra
disposición. Las cosas que creamos no son puntos fijos en el tiempo. Una vez puesto
en marcha en la producción, nuestro software continuará evolucionando a medida
que la forma en que se utiliza cambios. Para la mayoría de las cosas que creamos,
tenemos que aceptar que una vez que el software se pone en manos de nuestros
clientes tendremos que reaccionar y adaptarse, en lugar de ser un artefacto que nunca
cambia. Por lo tanto, nuestros arquitectos necesitan cambiar su forma de pensar fuera
de la creación del producto final perfecto, y en lugar de centrarse en ing ayuda- crear
un marco en el que los sistemas adecuados pueden surgir, y seguirá creciendo a
medida que aprendemos más.
Aunque he pasado gran parte del capítulo hasta el momento que le advierte de
comparar a nosotros mismos demasiado a otras profesiones, hay una analogía que me
gusta cuando se trata de la función del arquitecto de TI y que creo que mejor resume
lo que queremos que este papel que sea. Erik Doernenburg primero compartió
conmigo la idea de que debemos pensar en nuestro papel más como urbanistas que
los arquitectos para el entorno construido. El papel del planificador de la ciudad debe
ser familiar para cualquiera de ustedes que han jugado antes SimCity. El papel de un
planificador de la ciudad es mirar a una multitud de fuentes de información, y luego
tratar de optimizar el diseño de una ciudad para adaptarse mejor a las necesidades de
los ciudadanos de hoy, teniendo en cuenta su uso futuro. La forma en que influye en
cómo evoluciona la ciudad, sin embargo, es interesante. No dice, “construir este
edificio específico allí”; en cambio, las zonas de una ciudad. Así como en SimCity,
es posible designar parte de su ciudad como una zona industrial, y otra parte como
una zona residencial. Le corresponde entonces a otras personas para decidir qué
edificios se crean exacta, pero hay restricciones: si usted quiere construir una fábrica,
que tendrá que ser en una zona industrial. En lugar de preocuparse demasiado acerca
de lo que ocurre en una zona, el planificador de la ciudad en su lugar pasar mucho
más tiempo de trabajo cómo per- sonas y las utilidades se mueven de una zona a otra.
Más de una persona ha comparado una ciudad a un ser vivo. La ciudad cambia con el
tiempo. Se cambia y evoluciona a medida que sus ocupantes utilizan de diferentes
maneras, o como fuerzas externas a darle forma. El urbanista hace todo lo posible
para anticipar estos cambios, pero acepta que tratar de ejercer un control directo
sobre todos los aspectos de lo que sucede es inútil.
Una visión evolutiva para el arquitecto | 15
La comparación con el software debería ser obvia. A medida que nuestros usuarios
utilizan nuestro software, tenemos que reaccionar y cambio. No podemos prever todo
lo que va a pasar, y así en lugar de plan para cualquier eventualidad, hay que
planificar para permitir el cambio evitando
16| Capítulo 2: El Arquitecto evolutiva
el impulso de overspecify hasta la última cosa. Nuestra ciudad-del-sistema tiene que
ser un buen lugar, feliz para todos los que lo utiliza. Una cosa que la gente suele
olvidar es que nuestro sistema no se limita a dar cabida a los usuarios; También tiene
capacidad para desarrolladores y opera- ciones personas que también tienen que
trabajar allí, y que tienen el trabajo de asegurarse de que puede cambiar según sea
necesario. Para tomar prestado un término de Frank Buschmann, arquitectos tienen el
deber de asegurar que el sistema es habitable para los desarrolladores también.
Un planificador de la ciudad, al igual que un arquitecto, también necesita saber
cuando no se está siguiendo su plan. Ya que es menos prescriptivo, el número de
veces que tiene que involucrarse para corregir dirección debe ser mínima, pero si
alguien decide construir una planta de aguas residuales en una zona residencial, tiene
que ser capaz de apagarlo.
Así como nuestros arquitectos urbanistas necesitan para fijar la dirección a grandes
rasgos, y sólo involucrarse en ser altamente específica sobre detalle de
implementación en casos limitados. Tienen que asegurar que el sistema es adecuado
para el propósito, pero también una plataforma para el futuro. Y que necesitan para
asegurarse de que es un sistema que hace que los usuarios y desarrolladores
igualmente feliz. Esto suena como una orden muy alto. ¿Donde empezamos?
zonificación
Así que, para continuar con la metáfora del arquitecto como planificador de la ciudad
por un momento, ¿cuáles son las zonas? Estos son nuestros límites de servicio, o tal
vez los grupos de grano grueso de los servicios. Como arquitectos, tenemos que
preocuparnos mucho menos de lo que sucede dentro de la zona de lo que sucede
entre las zonas. Eso significa que necesitamos para pasar el tiempo promueva su
acerca de cómo nuestros servicios de hablar unos con otros, o asegurar que podemos
moni- tor adecuadamente la salud general de nuestro sistema. ¿Qué tan involucrado
tenemos dentro de la zona puede variar un poco. Muchas organizaciones han
adoptado microservicios con el fin de maximizar la autonomía de los equipos, algo
que va a expandir en enCapítulo 10. Si se encuentra en dicha organización, se basan
más en el equipo para tomar la decisión derecha local.
Sin embargo, entre las zonas o las cajas en nuestro diagrama de la arquitectura
tradicional, tenemos que tener cuidado; hacer las cosas mal aquí conduce a todo tipo
de problemas y puede ser muy difícil de corregir.
Dentro de cada servicio, puede estar bien con el equipo que posee esa zona de la
selección de un conjunto de tecnología rentes o los datos dife- tienda. Otras
preocupaciones pueden entran en juego aquí, por supuesto. Su inclinación a dejar que
los equipos de recoger la herramienta adecuada para el trabajo puede ser atemperada
por el hecho de que se hace más difícil contratar a personas o moverlos entre los
equipos si tiene 10 pilas de tecnología diferente a apoyar. Del mismo modo, si cada
equipo elige un completamente dife- rentes de almacenamiento de datos, usted puede
Una visión evolutiva para el arquitecto | 17
encontrarse que carecen de experiencia suficiente para ejecutar cualquiera de ellos a
escala. Netflix, por ejemplo, ha estandarizado sobre todo en Cassandra como una
tecnología de almacenamiento de datos. Aunque puede no ser la mejor opción para
todos sus casos, Netflix siente que el valor obtenido mediante la construcción de
herramientas y experiencia en torno a Cassandra es más importante que tener que
soportar y operar a escala de múltiples otras plataformas que pueden ser una
18| Capítulo 2: El Arquitecto evolutiva
mejor ajuste para ciertas tareas. Netflix es un ejemplo extremo, donde es probable
que el factor primordial escala más fuerte, pero se entiende la idea.
Entre los servicios es donde las cosas pueden causar problemas, sin embargo. Si un
servicio decide exponer a través de HTTP REST, otro hace uso de búferes de
protocolo, y un tercero utiliza Java RMI, a continuación, la integración puede
convertirse en una pesadilla, ya que consumen los servicios tienen que Deben
conocerse y soportar múltiples estilos de intercambio. Esto es por lo que trate de
cumplir con la directriz que debemos “estar preocupado por lo que sucede entre las
cajas, y ser liberal en lo que sucede en su interior.”
El arquitecto
Codificación
Si hemos de asegurar que los sistemas que creamos son habitables para nuestros
desarrolladores, a continuación, nuestros arquitectos necesitan entender el impacto de
sus decisiones. Al menos, esto significa pasar tiempo con el equipo, y lo ideal es que
debe significar que estos desarrolladores en realidad pasan el tiempo de codificación
con el equipo también. Para aquellos de ustedes que practican par programa- ción, se
convierte en una cuestión simple para un arquitecto para unirse a un equipo durante
un corto período como uno de los miembros de la pareja. Idealmente, usted debe
trabajar en historias normales, para comprender realmente lo normal de trabajo es
similar. No puedo enfatizar lo importante que es para el arquitecto para sentarse en
realidad con el equipo! Esto es significativamente más eficaz que el que tiene una
llamada o simplemente mirando a su código.
En cuanto a la frecuencia con que debe hacer esto, eso depende en gran medida del
tamaño del equipo (s) que está trabajando. Pero la clave es que debe ser una actividad
rutinaria. Si está trabajando con cuatro equipos, por ejemplo, pasar medio día con
cada equipo cada cuatro semanas asegura a construir una conciencia y una mejor
comunicación con los equipos con los que trabaja.
Un enfoque de principios
Las reglas son para la obediencia de los tontos y de la orientación de los magos.
-Generalmente atribuido a Douglas Bader
La toma de decisiones en el diseño del sistema es todo acerca de las compensaciones,
y microService arquitecturas nos dan un montón de ventajas y desventajas de hacer!
Al escoger un almacén de datos, podemos recoger una plataforma que tenemos
menos experiencia con, pero eso nos da una mejor escala? ¿Está bien para nosotros
contar con dos pilas de tecnología diferentes en nuestro sistema? ¿Qué hay de tres?
Algunos las decisiones se pueden hacer por completo sobre el terreno con la
información disponible para nosotros, y estos son los más fáciles de hacer. Pero ¿qué
pasa con esas decisiones que podrían tener que hacerse en información incompleta?
Enmarcando aquí puede ayudar, y una gran manera de ayudar a enmarcar nuestra
toma de decisiones es definir un conjunto de principios y prácticas que la guían, en
base a los objetivos que estamos tratando de lograr. Veamos cada uno de ellos.
Un enfoque de principios |
17
Metas estratégicas
El papel del arquitecto ya está lo suficientemente desalentador, así que
afortunadamente no suelen tener también definir objetivos estratégicos! objetivos
estratégicos deben hablar a dónde va su empresa, y cómo se ve a sí mismo como el
mejor hacer felices a sus clientes. Estos serán los objetivos de alto nivel, y pueden no
incluir la tecnología en absoluto. Podrían definirse en un nivel com- pañía o un nivel
de división. Podrían ser cosas como “expandirse en el sudeste de Asia para abrir
nuevos mercados”, o “dejar que el cliente a lograr lo más posible el uso de autoservicio.” La clave es que aquí es donde se dirige su organización, por lo que necesita
para asegurarse la tecnología está alineado a la misma.
Si usted es la persona que define la visión técnica de la empresa, esto puede
significar que tendrá que pasar más tiempo con las partes no técnicos de su
organización (o el negocio, ya que a menudo se llaman). ¿Cuál es la visión de
conducción para el negocio? Y ¿cómo cambia?
principios
Los principios son normas que ha realizado con el fin de alinear lo que está haciendo
para algún objetivo más grande, y a veces cambiar. Por ejemplo, si uno de sus
objetivos estratégicos como organización es disminuir el tiempo de salida al mercado
de nuevas características, es posible definir un principio que dice que los equipos de
entrega tienen un control total sobre el ciclo de vida de su soft- ware para enviar
siempre que estén listos , independientemente de cualquier otro equipo. Si otro
objetivo es que su organización se está moviendo a crecer agresivamente su oferta en
otros países, es posible que decide poner en práctica un principio de que todo el
sistema debe ser portátil para permitir que se despliegue a nivel local con el fin de
respetar la soberanía de los datos.
Es probable que no quiere un montón de éstos. Menos del 10 es un buen número de
pequeñas suficiente como para que la gente puede recordar, o para caber en pequeños
carteles. Los ples más cipios que tienen, mayor es la probabilidad de que se
superponen o se contradicen entre sí.
Heroku de 12 Factores son un conjunto de principios de diseño estructurado en torno
a la meta de ayuda- ing crear aplicaciones que funcionan bien en la plataforma
Heroku. También pueden muy bien tener sentido en otros contextos. Algunos de los
principios son en realidad las restricciones basadas en los comportamientos de su
aplicación necesita para exhibir el fin de trabajar en Heroku. Una restricción es
realmente algo que es muy difícil (o prácticamente imposible) para cambiar, mientras
que los principios son cosas que decide elegir. Usted puede decidir llamar
explícitamente a cabo las cosas que son principios frente a los que son limitaciones, a
ayudar a indicar aquellas cosas que realmente no se puede cambiar. En lo personal,
creo que no puede haber algún valor en mantenerlos en la misma lista para animar a
las limitaciones difíciles de vez en cuando y ver si realmente son inamovibles!
18| Capítulo 2: El Arquitecto evolutiva
prácticas
Nuestras prácticas son cómo nos aseguramos de nuestros principios se están llevando
a cabo. Son un conjunto de orientación detallada y práctica para la realización de
tareas. Ellos serán a menudo Tecnología en específico, y debe ser lo suficientemente
bajo nivel que cualquier desarrollador puede entenderlos. Prácticas podrían incluir
pautas de codificación, el hecho de que todos los datos de registro tiene que ser CAPTured centralmente, o que HTTP / REST es el estilo estándar de integración. Debido
a su naturaleza técnica, las prácticas suelen cambiar más a menudo que los
principios.
Al igual que con los principios, a veces reflejan las limitaciones prácticas en su
organización. Por ejemplo, si sólo son compatibles con CentOS, esto tendrá que
reflejarse en sus prácticas.
Prácticas debe servir de base a nuestros principios. Un principio que indica que los
equipos de entrega de con- trol del ciclo de vida completo de sus sistemas puede
significar que tiene una práctica que indica que todos los servicios se implementan en
las cuentas de AWS aislados, proporcionando la gestión de auto-servicio de los
recursos y el aislamiento de otros equipos.
Combinando Principios y Prácticas
principios de una persona son las prácticas de los demás. Es posible que decida
llamar el uso de HTTP / descansar un principio más que una práctica, por ejemplo. Y
que iba a estar bien. El punto clave es que hay valor en tener ideas generales que
guían la forma en que evoluciona el sistema, y en tener el suficiente detalle para que
la gente sepa cómo poner en práctica esas ideas. Para un grupo lo suficientemente
pequeño, tal vez un solo equipo, combinando los principios y prácticas podrían estar
bien. Sin embargo, para las grandes organizaciones, donde la tecnología y las
prácticas de trabajo pueden ser diferentes, es posible que desee un conjunto diferente
de prácticas en diferentes lugares, siempre y cuando los dos se asignan a un conjunto
común de principios. Un equipo .NET, por ejemplo, podría tener un conjunto de
prácticas, y un equipo de Java otra, con un conjunto de prácticas comunes a ambos.
Los principios, sin embargo, podría ser el mismo para ambos.
Un ejemplo del mundo real
Mi colega Evan Bottcher desarrolló el diagrama mostrado en la Figura 2-1 en el
curso de trabajar con uno de nuestros clientes. La figura muestra la interacción de los
objetivos, principios y prácticas en un formato muy claro. En el transcurso de un par
de años, las prácticas de la extrema derecha va a cambiar con bastante regularidad,
mientras que los principios siguen siendo bastante estático. Un diagrama de este tipo
se puede imprimir bien en una sola hoja de papel y compartida, y cada idea es
bastante simple para el desarrollador promedio para recordar. Hay, por supuesto, con
más detalle detrás de cada punto aquí, pero ser capaz de articular esta en forma resuUn enfoque de principios |
19
men es muy útil.
20| Capítulo 2: El Arquitecto evolutiva
La Figura 2-1. Un ejemplo del mundo real de los principios y prácticas
Eso tiene sentido tener documentación de apoyo algunos de estos artículos. En
general, sin embargo, me gusta la idea de tener código de ejemplo que se puede
ver, inspeccionar y ejecutar, que encarna estas ideas. Aún mejor, podemos crear
herramientas que hace lo correcto fuera de la caja. Discutiremos eso con mayor
profundidad momentáneamente.
El nivel requerido
Cuando se trabaja a través de sus prácticas y pensando en las ventajas y desventajas
que hay que hacer, uno de los resultados básicos se encuentran a la cantidad de
variabilidad para permitir en su sistema. Una de las claves para identificar lo que
debe ser constante de servicio a servicio es definir lo que es un buen
comportamiento, buen servicio se parece. ¿Qué es un servicio de “buena Zen ciuda-”
en su sistema? ¿Qué capacidades Qué hay que tener para asegurarse de que su
sistema es manejable y que un mal servicio no hacer caer todo el sistema? Y, como
con las personas, lo que es un buen ciudadano en un contexto no refleja lo que parece
en otro lugar. Sin embargo, hay algunas caracterís- ticas comunes de los servicios de
buen comportamiento que creo que son bastante importante a observar. Estas son las
pocas áreas clave en las que permiten demasiada divergencia puede resultar en un
tiempo bastante tórrida.
Un enfoque de principios |
21
autonomía del individuo microService sin perder de vista el panorama general.
Definición de los atributos claro que cada servicio debe tener es una forma de ser
clara en cuanto a dónde se encuentra ese equilibrio.
Vigilancia
Eso Es esencial que seamos capaces de elaborar coherentes vistas, cruz de servicio de
nuestra salud del sistema. Esto tiene que ser una visión de todo el sistema, no un
punto de vista específico del servicio. Como veremos enCapítulo 8, Sabiendo que la
salud de un servicio individual es útil, pero a menudo sólo cuando se está tratando de
diagnosticar un problema más amplio o entender una tendencia más amplia. Para que
esto sea lo más fácil posible, sugeriría asegurar que todos los servicios de salud y
emiten las métricas generales derivadas del seguimiento de la misma manera.
Tú podrían optar por adoptar un mecanismo de empuje, donde cada servicio tiene que
empujar estos datos en una ubicación central. Por sus métricas de esto podría ser
grafito, y para su salud podría ser Nagios. O es posible que decida utilizar sistemas
de votación que raspan los datos de los propios nodos. Pero lo que usted elija, intenta
mantenerlo estandarizada. Hacer que la tecnología dentro de la caja opaca, y no
requieren que su monitoreo sis- tems cambio con el fin de apoyar la misma. Tala cae
en la misma categoría aquí: lo necesitamos en un solo lugar.
Interfaces
Escoger un pequeño número de tecnologías de interfaz definidos ayuda a integrar
nuevos con- sumidores. Tener un estándar es un buen número. Dos no es tan malo,
tampoco. Tener 20 estilos diferentes de integración es malo. Esto no es sólo acerca
de escoger la tecnología y el protocolo. Si usted escoge HTTP / REST, por ejemplo,
va a utilizar verbos o sustantivos? Cómo va a manejar la paginación de los recursos?
Cómo va a manejar versiones de los puntos finales?
Seguridad arquitectónica
Nosotros no puede permitirse el lujo de un servicio mal comportamiento de arruinar la
fiesta para todo el mundo. Tenemos que asegurarnos de que nuestros servicios se
escudan consecuencia de las llamadas riachuelo no saludable, Down-. Cuantos más
servicios que tenemos que no maneja adecuadamente el potencial Ure fail de las
llamadas aguas abajo, los más frágiles nuestros sistemas serán. Esto indica que
probablemente tendrá que autorice como mínimo que cada servicio de aguas abajo
tiene su propio conjunto de conexiones, e incluso se puede ir tan lejos como para
decir que cada uno también utiliza un interruptor de circuito. Esta quede cubierta con
mayor profundidad cuando discutimos microservicios a escala deCapítulo 11.
Las reglas del juego es importante cuando se trata de códigos de respuesta, también.
Si su disyuntores se basan en códigos HTTP, y un servicio decide enviar de vuelta
los códigos 2XX de errores, o confunde los códigos 4XX con códigos 5XX, a
continuación, estas medidas de seguridad pueden desmoronarse. Preocupaciones
22| Capítulo 2: El Arquitecto evolutiva
similares se aplicarían incluso si usted no está utilizando HTTP; conocer la dife-
El nivel requerido | 21
ferencia entre una solicitud de que estaba bien y procesado correctamente, una
petición que era malo y por lo tanto impide el servicio de hacer cualquier cosa con
ella, y una petición que podría estar bien, pero no podemos decir que el servidor
estaba abajo es clave para asegurar que puede fallar rápido y rastrear problemas. Si
nuestros servicios jugar rápido y libremente con estas normas, nos encontramos con
un sistema más vulnerable.
A través de la gobernabilidad Código
Reunirse y ponerse de acuerdo sobre cómo pueden hacerse las cosas es una buena
idea. Pero spend- ing tiempo de asegurar que las personas están siguiendo estas
directrices es menos divertido, como se supone una carga para los desarrolladores
implementar todas estas cosas normales que se pueden esperar de cada servicio que
debe hacer. Soy un gran creyente en lo que es fácil hacer lo correcto. Dos técnicas
que he visto el trabajo bien aquí están utilizando ejemplos y proporcionando
plantillas de servicio.
ejemplares
Escrito documentación es buena y útil. Veo claramente el valor; Después de todo,
he POR ESCRITO este libro. Sin embargo, los desarrolladores también les gusta
código y el código que puedan correr y explorar. Si usted tiene un conjunto de
normas o prácticas óptimas que le gustaría animar a continuación, tienen
ejemplares que se pueden señalar a la gente es útil. La idea es que la gente no
puede ir muy mal acaba imitando algunas de las mejores partes de su sistema.
Idealmente, estos deben ser los servicios del mundo real que tiene y que sale bien, en
lugar de los servicios aislados que solo se implementan para ser ejemplos perfectos.
Al garantizar que se están utilizando realmente sus ejemplares, se asegura de que
todos los principios que realmente han sentido.
Plantilla medida Servicio
¿No sería estupendo si pudiera hacer que sea muy fácil para todos los desarrolladores
a seguir la mayor parte de las directrices que tiene con muy poco trabajo? ¿Qué pasa
si, fuera de la caja, el ERS desarrollos tuvieron la mayor parte del código en lugar de
implementar el núcleo atributos que las necesidades de cada servicio?
Dropwizard y karyon son dos microrrecipientes fuente abierto, basado en JVM. Ellos
funcionan de manera similar, integrando una serie de bibliotecas para proporcionar
funciones como la comprobación de estado, sirviendo HTTP, o exponer las métricas.
Por lo tanto, fuera de la caja, que tiene un servicio completo con un contenedor de
servlets incrustado que puede ser lanzado desde la línea de Mand com-. Esta es una
gran manera de ponerse en marcha, pero ¿por qué detenerse allí? Mientras estás en
ello, por qué no hacer algo así como un Dropwizard o Karyon, y añadir más
características para que sea compatible para su contexto?
22| Capítulo 2: El Arquitecto evolutiva
Por ejemplo, es posible que desee ordenar el uso de los interruptores. En ese caso, es
posible integrar una biblioteca como disyuntorhystrix. O es posible que tenga una
práctica que deben ser enviados a un servidor central de grafito todas sus métricas, lo
que tal vez tire en una
A través de la gobernabilidad
Código | 23
biblioteca de código abierto como Dropwizard de Métrica y configurarlo para que,
fuera de la caja, los tiempos de respuesta y las tasas de error se envían
automáticamente a una ubicación conocida.
Mediante la adaptación de una plantilla de dicho servicio para su propio conjunto de
prácticas de desarrollo, se asegura de que los equipos pueden ponerse en marcha más
rápido, y también que los desarrolladores tienen que salir de su manera de hacer que
sus servicios se portan mal.
Por supuesto, si usted abrazado múltiples pilas de tecnología dispares, que había
necesidad de una plantilla de servicio que iguala las de cada uno. Esto puede ser una
forma en que la restringirá sutilmente opciones de idioma en sus equipos, sin
embargo. Si la plantilla de servicio en la casa sólo es compatible con Java, entonces
las personas pueden ser disuadidos de recoger pilas alternativas si tienen que hacer
mucho más trabajo por sí mismos. Netflix, por ejemplo, se refiere especialmente a
aspectos como la tolerancia a fallos, para asegurar que la interrupción de una parte de
su sistema no puede tomar lo every- abajo. Para controlar esto, una gran cantidad de
trabajo se ha hecho para asegurar que no son bibliotecas de cliente en la JVM para
proporcionar equipos con las herramientas que necesitan para mantener sus servicios
de buen comportamiento. Cualquiera que la introducción de una nueva tecnología de
pila significaría tener que reproducir todo este esfuerzo. La principal preocupación
para Netflix es menos acerca de la duplicación de esfuerzos, y más sobre el hecho de
que es tan fácil de conseguir este mal. El riesgo de un servicio de conseguir la
tolerancia a fallos de reciente aplicación incorrecta es alta si se pudiera tener un
impacto mayor del sistema. Netflix mitiga mediante el uso de los servicios del coche
lateral, que se comunican a nivel local con una JVM que está utilizando las
bibliotecas apropiadas.
Tú tiene que tener cuidado de que la creación de la plantilla de servicio no se
convierta en el trabajo de un equipo de herramientas o la arquitectura central de
quien dicta cómo deben hacerse las cosas, aunque sea a través de código. La
definición de las prácticas que utilice deben ser una actividad colectiva, por lo que
idealmente su equipo (s) debe asumir la responsabilidad conjunta para la
actualización de esta plantilla (un enfoque de código abierto interno funciona bien
aquí).
También he visto a muchos moral y la productividad de un equipo destruido por
tener un manda- Ted marco de empuje sobre ellos. En un intento por mejorar la
reutilización de código, más y más trabajo se coloca en un marco centralizado hasta
que se convierte en un strosity MON abrumadora. Si decide utilizar una plantilla de
servicio a medida, pensar muy cuidadosamente acerca de lo que es su trabajo.
Idealmente, su uso debe ser puramente opcional, pero si usted va a ser más
contundente en su adopción es necesario comprender que la facilidad de uso para los
desarrollos ERS ha de ser una fuerza primordial de guía.
También ser conscientes de los peligros de código compartido. En nuestro deseo de
crear código reutilizable, podemos introducir fuentes de acoplamiento entre los
24| Capítulo 2: El Arquitecto evolutiva
servicios. Al menos una organización que habló es tan preocupado por esto que en
realidad copia su código de plantilla de servicio manualmente en cada servicio. Esto
significa que una actualización a la plantilla de servicio básico requiere más tiempo
para ser aplicado a través de su sistema, pero esto es menos preocupante para él que
el peligro de acoplamiento. Otros equipos que han hablado con simplemente han
tratado la plantilla de servicio como una dependencia binaria compartida, aunque
tienen que ser muy diligente en no dejar que la tendencia de DRY (no repita usted
mismo) resultará en un sistema demasiado junto! Este es un tema lleno de matices, lo
que vamos a explorar en mayor detalle en elCapítulo 4.
A través de la gobernabilidad
Código | 23
Deuda técnica
Nosotros a menudo se ponen en situaciones en las que no se puede seguir a través de
la carta en nuestra visión técnica. A menudo, tenemos que hacer una elección para
cortar algunas esquinas para obtener algunas características urgentes a cabo. Este es
sólo uno más disyuntiva que nos encontraremos tener que hacer. existe nuestra visión
técnica por una razón. Si nos desviamos de este motivo, podría tener un beneficio a
corto plazo, pero un coste a largo plazo. Un concepto que nos ayuda a comprender
esta disyuntiva es la deuda técnica. Cuando devenga la deuda técnica, al igual que la
deuda en el mundo real que tiene un costo en curso, y es algo que queremos pagar.
A veces la deuda técnica no es sólo algo que causamos al tomar atajos. ¿Qué pasa si
nuestra visión de los cambios en el sistema, pero no todos de nuestro sistema de
partidos? En esta situación, también, hemos creado nuevas fuentes de deuda técnica.
El trabajo del arquitecto es mirar el cuadro más grande, y comprender este equilibrio.
Hav- ing algún punto de vista en cuanto al nivel de la deuda, y dónde participar, es
importante. Dependiendo de su empresa, es posible que pueda proporcionar
orientación suave, pero tienen los equipos deciden por sí mismos cómo realizar el
seguimiento y pagar la deuda. Para otras organizaciones, es posible que tenga que ser
más estructurado, tal vez el mantenimiento de un registro de la deuda que se revisa
periódicamente.
Manejo de excepciones
Así que nuestros principios y prácticas guían cómo se deben construir nuestros
sistemas. Pero lo HAP plumas cuando nuestro sistema se desvía de esto? A veces
tomamos una decisión que es sólo una excepción a la regla. En estos casos, puede ser
que valga la captura de una decisión de este tipo en un registro en alguna parte para
referencia futura. Si se encuentran bastantes excepciones, puede eventu- aliado
sentido para cambiar el principio o en la práctica para reflejar una nueva
comprensión del mundo. Por ejemplo, podríamos tener una práctica que los estados
que siempre vamos a utilizar MySQL para el almacenamiento de datos. Pero
entonces vemos razones de peso para utilizar Cassandra para el almacenamiento
altamente escalable, momento en el que cambiamos nuestra práctica decir, “Use
MySQL para la mayoría de los requisitos de almacenamiento, a menos que se puede
esperar un gran crecimiento en los volúmenes, en cuyo caso el uso de Cassandra”.
Sus probablemente vale la pena reiterar, sin embargo, que cada organización es
diferente. He trabajado con algunas empresas en las que los equipos de desarrollo
tienen un alto grado de confianza y autonomía, y no los principios son ligeros (y la
necesidad de tratamiento de excepciones abierta se reduce en gran medida si no se
elimina). En organiza- ciones más estructuradas en las que los desarrolladores tienen
menos libertad, excepciones de rastreo pueden ser vitales para asegurar que las reglas
puestas en marcha reflejan adecuadamente los retos que se enfrentan las personas.
Con todo lo dicho, soy un fan de microservicios como una forma de optimizar la
26| Capítulo 2: El Arquitecto evolutiva
autonomía de los equipos, dándoles tanta libertad como sea posible para resolver el
problema en cuestión. Si está trabajando en una organización que coloca un montón
de restricciones sobre cómo los desarrolladores pueden hacer su trabajo, entonces
microservicios no puede ser para usted.
A través de la gobernabilidad
Código | 23
Gobernabilidad y va desde el Centro
Parte de lo que los arquitectos tienen que manejar es la gobernabilidad. ¿Qué quiero
decir por el gobierno? Resulta que los Objetivos de Control para la Información y
Tecnología Relacionada (COBIT) tiene una definición bastante buena:
Gobernabilidad se asegura de que la empresa objetivos se logran mediante la
evaluación de las partes interesadas necesidades, condiciones y opciones; establecer
la dirección a través de establecimiento de prioridades y la toma de decisiones; y
monitorear el desempeño, el cumplimiento y el progreso contra la dirección y
objetivos acordados en.
-COBIT 5
Gobernabilidad puede aplicar a varias cosas en el foro de TI. Queremos centrarnos en
el aspecto de la gestión técnica, algo que siento es el trabajo del arquitecto. Si uno de
los puestos de trabajo del arquitecto es asegurar que hay una visión técnica, a
continuación, la gobernabilidad se trata de garantizar lo que estamos construyendo
partidos esta visión, y la evolución de la visión si es necesario.
Los arquitectos son responsables de una gran cantidad de cosas. Tienen que asegurar
que haya un conjunto de principios que pueden guiar el desarrollo, y que estos
principios que coincida con la estrategia de la organiza- ción. Tienen que asegurarse
así de que estos principios no requieren prácticas que hacen los desarrolladores
miserables de trabajo. Que necesitan para mantenerse al día con las nuevas
tecnologías, y saber cuándo hacer las correctas soluciones de compromiso. Se trata
de una gran cantidad de responsabilidad. Todo eso, y ellos también tienen que llevar
a la gente con ellos, es decir, para garantizar que los colegas que están trabajando a
entender las decisiones que se toman y se traen a llevarlas a cabo. Ah, y como ya
hemos mencionado: que necesitan para pasar algún tiempo con los equipos de
entender el impacto de sus decisiones, y tal vez incluso el código también.
¿Una orden grande? Absolutamente. Pero yo soy de la firme opinión de que no deben
hacer esto solo. Un grupo de gobierno que funcione adecuadamente pueden trabajar
juntos para compartir el trabajo y dar forma a la visión.
Normalmente, gobierno es una actividad de grupo. Podría ser una charla informal con
un equipo lo suficientemente pequeño, o una reunión regular más estructurada con
membresía formal de grupo para un mayor alcance. Aquí es donde creo que los
principios que cubrimos anteriormente deben discutirse y modificarse según sea
necesario. Este grupo necesita ser dirigido por un técnico, y se compone
fundamentalmente de personas que están ejecutando el trabajo que se rige. Este
grupo también debe ser responsable para el seguimiento de la gestión de riesgos y
técnicas.
Un modelo Favorezco en gran medida está teniendo la silla arquitecto del grupo, pero
que tiene la mayor parte del grupo dibujado a partir de los tecnólogos de cada entrega
de equipo los cables de cada equipo en un mínimo. El arquitecto es responsable de
asegurarse de que funciona el grupo, pero el grupo en su conjunto es responsable de
26 | Capítulo 2: El Arquitecto evolutiva
la gestión pública. Esta comparte la carga, y asegura que hay un mayor nivel de
aceptación. También asegura que la información fluye libremente de los equipos en
el grupo, y como resultado, la toma de decisiones es mucho más sensato e informado.
Gobernabilidad y va desde el Centro | 25
A veces, el grupo puede tomar decisiones con las que no está de acuerdo el
arquitecto. En este punto, ¿cuál es el arquitecto que hacer? Después de haber estado
en esta posición antes, te puedo decir que esta es una de las situaciones más difíciles
de enfrentar. A menudo, tomo el enfoque que debería ir con la decisión del grupo.
Considero que he hecho todo lo posible para convencer a la gente, pero en última
instancia no estaba lo suficientemente convincente. El grupo es a menudo mucho más
sabia que el individuo, y he ha equivocado más de una vez! E imaginar cómo
debilitante que puede ser para un grupo que se ha dado espacio para llegar a una
deci- sión, y en última instancia ser ignorado. Pero a veces me he anulado el grupo.
Pero ¿por qué, y cuándo? ¿Cómo elegir las líneas?
Piense en enseñar a los niños a montar en bicicleta. No se puede andar por ellos. Si se
les mira bamboleo, pero si intervino cada vez que parecía que podrían caerse,
entonces nunca iba a aprender, y en todo caso de que se caigan mucho menos de lo
que lo harán! Pero si los ves a punto de virar hacia el tráfico, o en un estanque de
patos cerca, entonces usted tiene que intervenir. Del mismo modo, como arquitecto,
es necesario tener una firme comprensión de que, en sentido figurado, su equipo está
dirigiendo en un pato estanque. También es necesario tener en cuenta que incluso si
usted sabe que está a la derecha y hacer caso omiso del equipo, esto puede minar su
posición y también hacer que el equipo sienten que no tienen voz. A veces lo
correcto es ir junto con una decisión que no está de acuerdo con. Saber cuándo
hacerlo y cuándo no es difícil, pero a veces es vital.
La construcción de un equipo
Siendo el principal punto de responsable de la visión técnica de su sistema y asegurar
que se está ejecutando en esta visión no se trata sólo de hacer que la tecnología decisiones. Es la gente que trabaja con los que va a hacer el trabajo. Gran parte del papel
del líder técnico se trata de ayudar al crecimiento de ellos, para ayudarles a entender
la visión a sí mismos, y también asegurando que puedan participar activamente en la
elaboración y aplicación de la visión también.
Ayudar a las personas a su alrededor en su propio crecimiento profesional puede
tomar muchas formas, la mayoría de los cuales están fuera del alcance de este libro.
Hay un aspecto, sin embargo, donde una arquitectura microService es especialmente
relevante. Con los sistemas más grandes, monolíticos, hay menos oportunidades para
la gente para subir y poseer algo. Con los servicios de micro, por otro lado, tenemos
múltiples bases de código autónomas que tendrán sus propios ciclos de vida
independientes. Ayudar a las personas incrementen haciendo que toman buque
propietario- de los servicios individuales antes de aceptar más responsabilidad puede
ser una gran manera de ayudar a alcanzar sus propios objetivos de carrera, y al
mismo tiempo aligera la carga en el que está a cargo!
Soy una firme creyente de que un gran software proviene de grandes personas. Si
usted se preocupa sólo por el lado de la tecnología de la ecuación, que se está
perdiendo mucho más de la mitad de la imagen.
26 | Capítulo 2: El Arquitecto evolutiva
Resumen
Para resumir este capítulo, he aquí lo que veo como las principales responsabilidades
del arquitecto lutionary evo-:
Visión
Asegúrese de que haya una visión técnica comunicado claramente para el sistema
que ayudará a su sistema cumple con los requisitos de sus clientes y la
organización
Empatía
Comprender el impacto de sus decisiones en sus clientes y colegas
Colaboración
Comprometerse con mayor número de sus compañeros y colegas como sea
posible para ayudar a definir, refinar, y ejecutar la visión
Adaptabilidad
Asegúrese de que la visión técnica cambia a medida que sus clientes u
organización lo requiere
Autonomía
Encontrar el equilibrio adecuado entre la estandarización y permitir la autonomía
para sus equipos
Gobernancia
Asegúrese de que el sistema que está siendo implementado ajusta a la visión técnica
El arquitecto evolutiva es aquel que entiende que quitar de esta hazaña es un acto de
equilibrio cons- tante. Las fuerzas están siempre empujando una manera u otra, y la
comprensión de dónde hacer retroceder ni a dónde ir con el flujo es a menudo algo
que sólo se logra con la experiencia. Pero la peor reacción a todas estas fuerzas que
nos empujan hacia el cambio es llegar a ser más rígido o fijo en nuestro pensamiento.
Aunque gran parte de los consejos de este capítulo se puede aplicar a cualquier
arquitecto de sistemas, servicios de micro nos dan muchas más decisiones que tomar.
Por lo tanto, estar en mejores condiciones para equilibrar todas estas compensaciones
es esencial.
En el siguiente capítulo, vamos a tomar algo de nuestra nueva conciencia del papel
del arquitecto con nosotros a medida que empezamos a pensar acerca de cómo
encontrar los límites adecuados para nuestros microservicios.
resumen | 27
CAPÍTULO 3
Cómo al modelo de servicios
el razonamiento de mi oponente Me recuerda a los paganos, que, le pide en lo que se puso el
mundo, respondió: “En una tortuga.” Pero en lo que significan las siglas la tortuga? “En
otra tortuga.”
-Joseph Barker (1854)
Así que ya sabes lo que son microservicios, y es de esperar tener un sentido de sus
principales ventajas. Probablemente usted está ansioso por ir ahora y empezar a hacer
ellos, ¿verdad? Pero por dónde empezar? En este capítulo, vamos a ver cómo pensar
acerca de los límites de sus microservicios que se espera maximizar los aspectos
positivos y evitar algunas de las desventajas potenciales. Pero primero, necesitamos
algo con que trabajar.
La introducción de MusicCorp
Libros sobre ideas funcionan mejor con ejemplos. Siempre que sea posible, voy a
compartir historias de situaciones del mundo real, pero he encontrado que es también
útil disponer de un dominio ficticio con el que trabajar. A lo largo del libro, que
volveremos a este dominio, viendo cómo el concepto de microservicios funciona
dentro de este mundo.
Así que vamos a centrar nuestra atención a la vanguardia en línea minorista
MusicCorp. MusicCorp fue recientemente una tienda de ladrillo y mortero, pero
después de la parte inferior se retiró de la industria del disco de gramófono se
centró cada vez más de sus esfuerzos en línea. La compañía tiene un sitio web,
pero siente que ahora es el momento de doblar hacia abajo en el mundo en línea.
Después de todo, los iPods son sólo una moda pasajera (Zunes son mucho mejor,
obviamente) y aficionados a la música son muy felices de esperar a los CD para
llegar a sus puertas. Calidad sobre la conveniencia, ¿verdad? Y ya que estamos
en ello, ¿qué es este Spotify sigue hablando-algún tipo de tratamiento de la piel
para los adolescentes?
29
A pesar de ser un poco detrás de la curva, MusicCorp tiene grandes ambiciones. Por
suerte, se ha decidido que su mejor oportunidad de tomar el mundo es asegurándose
de que puede hacer cambios tan fácilmente como sea posible. Microservicios para la
victoria!
30| Capítulo 3: Cómo modelo de
servicios
Lo que hace un buen servicio?
Antes de que el equipo de MusicCorp arranca en la distancia, la creación de un
servicio después de servicio en un intento de entregar las cintas de ocho pistas a todo
el mundo, vamos a poner el freno y hablar un poco acerca de la idea subyacente más
importante que necesitamos para mantener en mente. Lo que hace un buen servicio?
Si has sobrevivido a una implementación SOA fallado, es posible que tenga alguna
idea de dónde voy siguiente. Pero por si acaso usted no es que (des) nate Afortunada, quiero que se centra en dos conceptos clave: acoplamiento débil y una alta
cohesión. Hablaremos en detalle a lo largo del libro sobre otras ideas y prácticas,
pero son todo para nada si conseguimos estas dos cosas mal.
A pesar de que estos dos términos se utilizan mucho, sobre todo en el contexto de los
sistemas orientados a objetos, vale la pena discutir lo que significan en términos de
microservicios.
Bajo acoplamiento
Cuando los servicios están débilmente acoplados, un cambio a un servicio no debe
requerir un cambio a otro. El punto entero de un microService es ser capaz de hacer
un cambio a un servicio y desplegarlo, sin necesidad de cambiar ninguna otra parte
del sistema. Esto es realmente muy importante.
¿Qué tipo de cosas causan estrecho acoplamiento? Un error clásico es elegir un estilo
de integración que se une fuertemente un servicio a otro, provocando cambios dentro
del servicio a requerir un cambio a los consumidores. Vamos a discutir la forma de
evitar esto con más profundidad enCapítulo 4.
Un servicio débilmente acoplado sabe tan poco como necesita acerca de los servicios
con los que colabora. Esto también significa que probablemente desee limitar el
número de diferentes tipos de llamadas de un servicio a otro, porque más allá del
potencial pro- blema de rendimiento, comunicación hablador puede conducir a un
acoplamiento apretado.
alta cohesión
Nosotros desee el comportamiento relacionado para sentarse juntos, y el
comportamiento relacionado a sentarse en otro lugar. ¿Por qué? Bueno, si queremos
cambiar el comportamiento, queremos ser capaces de cambiar en un solo lugar, y
liberar ese cambio tan pronto como sea posible. Si tenemos que cambiar ese
comportamiento en muchos lugares diferentes, vamos a tener que soltar un montón
de diferentes servicios (tal vez al mismo tiempo) para entregar ese cambio. Hacer
cambios en muchos lugares diferentes es más lento, y el despliegue de una gran
cantidad de servicios a la vez es arriesgado, tanto de los cuales queremos evitar.
Por lo que queremos encontrar los límites dentro de nuestro dominio del problema
que ayudan a asegurar que la conducta relacionada está en un lugar, y que se
31
comunican con otros límites tan libremente como sea posible.
32| Capítulo 3: Cómo modelo de
servicios
El contexto acotado
Driven Design-Domain libro de Eric Evans (Addison-Wesley) se centra en cómo
crear sistemas que los dominios del mundo real modelo. El libro está lleno de
grandes ideas como el uso del lenguaje en todas partes, las abstracciones del
repositorio, y similares, pero hay un concepto muy importante que introduce Evans
me pasó completamente por al primero: contexto acotado. La idea es que cualquier
dominio dado se compone de límites múltiples contextos, y que reside dentro de cada
uno son las cosas (Eric usa la palabra modelo mucho, lo que es probablemente la
BET-ter que las cosas) que no deben ser comunicadas exterior, así como cosas que se
comparten externamente con otros contextos delimitadas. Cada contexto delimitada
tiene una interfaz explícita, donde se decide qué modelos para compartir con otros
contextos.
Otra definición de contextos acotadas me gustan es “una responsabilidad específica
que se aplica por límites explícitos.” 1 Si desea información de un contexto limitado,
o si desea hacer peticiones de funcionalidad dentro de un contexto acotado, se
comunica con su límite explícita el uso de modelos. En su libro, Evans usa la
analogía de las células, donde “[c] pueden existir ells porque sus membranas definen
lo que está dentro y fuera y determinan lo que puede pasar.”
Vamos volver por un momento a la empresa MusicCorp. Nuestro dominio es todo el
Ness Busi- en el que estamos operando. Abarca todo, desde el almacén hasta el
mostrador de recep- ción, desde las finanzas a pedido. Podemos o no ser
representativos de todo eso en nuestro software, pero que, sin embargo el dominio en
el que estamos operando. Vamos a pensar en partes de ese dominio que se parecen a
los contextos acotadas que se refiere a Evans. En MusicCorp, nuestro almacén es un
hervidero de actividad órdenes-gestión de ser enviados a cabo (y el retorno impar), la
recepción de nuevas acciones, hacer carreras de carretillas elevadoras, y así
sucesivamente. En otra parte, el departamento de finanzas es quizás menos amante de
la diversión, pero todavía tiene una función muy importante dentro de nuestra
organización. Estos empleados a manejar la nómina, mantener las cuentas de la
empresa, y producen informes importantes. Un montón de informes.
Compartida y Modelos Ocultos
Para MusicCorp, podemos considerar el departamento financiero y el almacén para
ser acotadas dos contextos distintos. Ambos tienen una interfaz explícita al mundo
exterior (en términos de informes de inventario, recibos de pago, etc.), y tienen
detalles que sólo ellos necesitan saber acerca de (carretillas elevadoras, calculadoras).
Ahora el departamento de finanzas no necesita saber sobre el funcionamiento interno
detallado del depósito. Se necesita saber algunas cosas, aunque, por ejemplo que
necesita saber acerca de los niveles de existencias para mantener las cuentas al
día.Figura 3-1 muestra un ejemplo
El contexto acotado | 31
1 http://bit.ly/bounded-context-explained
32| Capítulo 3: Cómo modelo de
servicios
diagrama contextual. Vemos conceptos que son internos al almacén, como Selector
(PEO ples que recogen órdenes), estantes que representan lugares de valores, y así
sucesivamente. Del mismo modo, contabilidad general de la empresa es parte integral
de la financiación, pero no es compartida externamente aquí.
La Figura 3-1. Un modelo compartido entre el departamento financiero y el almacén
Para ser capaz de trabajar a cabo la valoración de la empresa, sin embargo, los
empleados financieros necesitan información acerca de las acciones que tenemos. El
artículo común se convierte entonces en un modelo compartido entre los dos
contextos. Sin embargo, tenga en cuenta que no es necesario exponer a ciegas todo lo
relacionado con el tema de valores del contexto almacén. Por ejemplo, aunque
internamente mantenemos un registro en un artículo común en cuanto a dónde debe
vivir dentro del alma- cén, que no necesita ser expuesta en el modelo compartido. Por
lo que no es el único de su tipo, interna, y la representación exterior exponemos. En
muchos sentidos, esto prefigura la discusión en torno a descansar enCapítulo 4.
A veces podemos encontrar los modelos con el mismo nombre que tienen
significados muy diferentes en diferentes contextos también. Por ejemplo, podríamos
tener el concepto de un retorno, lo que representa un cliente de enviar algo a cambio.
Dentro del contexto del cliente, una vuelta es todo sobre cómo imprimir una etiqueta
de envío, el envío de un paquete, ya la espera de un reembolso. Para el almacén, esto
podría representar un paquete que está a punto de llegar, y un artículo común que
necesita ser reabastecido. De ello se desprende que dentro del almacén almacenamos
información adicional asociada con el rendimiento que se refiere a las tareas que se
llevarán a cabo; por ejemplo, podemos generar una petición de volver a surtir. El
modelo compartido de la devolución se asocia con diferentes procesos y entidades
ING Soporte- dentro de cada contexto acotado, pero eso es en gran medida una
preocupación interna dentro del propio contexto.
El contexto acotado | 33
Módulos y Servicios
Al pensar con claridad acerca de lo que los modelos deben ser compartidos, y no
compartir nuestras representaciones internas, evitamos uno de los peligros
potenciales que pueden resultar en estrecho acoplamiento (lo contrario de lo que
queremos). También hemos identificado un límite dentro de nuestro dominio en el
que todas las capacidades de negocio afines deben vivir, que nos da la alta cohesión
que queremos. Estos contextos delimitadas, a continuación, se prestan muy bien a ser
los límites de composición.
Como ya comentamos en Capítulo 1, Tenemos la opción de utilizar los módulos
dentro de un límite proceso para mantener el código relacionado juntos y tratar de
reducir el acoplamiento a otros módulos en el sistema. Cuando estás empezando en
una nueva base de código, esto es probablemente un buen lugar para comenzar. Así
que una vez que haya encontrado sus contextos limitados en su dominio, asegúrese
de que se modelan dentro de su código base como módulos, con modelos
compartidos y ocultos.
Estos límites modulares se convierten en excelentes candidatos para microservicios.
En general, deben alinearse microservicios limpiamente a los contextos acotados.
Una vez que sea muy competente, puede decidir omitir el paso de mantener el
contexto acotado mo- Eled como un módulo dentro de un sistema más monolítica, y
saltar directamente a un servicio separado. Al comenzar, sin embargo, mantener un
nuevo sistema en el lado más monolítica; obtener los límites de servicio incorrecto
puede ser costoso, así que esperar que las cosas se estabilizan como se llega a
enfrentarse con un nuevo dominio es sensato. Discutiremos esto más enCapítulo 5,
Junto con técnicas para ayudar a romper aparte los sistemas existentes en
microservicios.
Por lo tanto, si nuestros límites del servicio se alinean con los contextos delimitados
en nuestro dominio, y nuestros microservicios representan esos contextos
delimitadas, estamos frente a un excelente comienzo para asegurar que nuestros
microservicios están relacionadas de forma flexible y fuertemente cohesionada.
La descomposición prematura
A ThoughtWorks, nosotros mismos experimentó los problemas de rotura de los
vicios a cabo microser- demasiado rápido. Aparte de consultoría, también creamos
unos pocos productos. Uno de ellos es SnapCI, una integración continua alojada y
una herramienta de liberación continua (discutiremos más adelante en esos
conceptosCapítulo 6). El equipo había trabajado previamente en otra herramienta
simi- lar, Go-CD, una herramienta de administración continua fuente abierta que se
puede implementar de forma local en lugar de estar alojada en la nube.
Aunque había algo de reutilización de código muy temprano entre el SnapCI y
proyectos de CD Ir, al final SnapCI resultó ser un nuevo código base. Sin embargo,
la experiencia previa del equipo en el dominio de las herramientas de CD les animó a
34| Capítulo 3: Cómo modelo de
servicios
moverse con mayor rapidez en la identificación de las fronteras, y la construcción de
su sistema como un conjunto de microservicios.
Al cabo de unos meses, sin embargo, se hizo evidente que los casos de uso de
SnapCI eran sutilmente lo suficientemente diferentes que la captura inicial sobre los
límites del servicio no estaba del todo bien. Esta
El contexto acotado | 35
dado lugar a una gran cantidad de cambios realizados a través de los servicios, y un
alto costo asociado al cambio. Eventualmente, el equipo combinó los servicios de
nuevo en un sistema monolítico, dándoles tiempo para comprender mejor dónde
deben existir los límites. Un año más tarde, el equipo fue capaz de dividir el sistema
monolítico aparte en microservicios, cuyos límites demostrado ser mucho más
estable. Esto está lejos de ser el único ejemplo de esta situación que he visto.
Prematuramente descomponer un sistema en microservicios puede ser costoso,
especialmente si usted es nuevo en el dominio. En muchos sentidos, con una base de
código existen- tes desea descomponer en microservicios es mucho más fácil que
tratar de ir a microservicios desde el principio.
Las capacidades de negocio
Cuando se empieza a pensar en los contextos limitados que existen en su
organización, debe ser no pensar en términos de datos que se comparte, sino de las
capacidades de aquellos contextos proporcionar al resto del dominio. El almacén
puede proporcionar la capa- bilidad para obtener una lista actual de las acciones, por
ejemplo, o el contexto financiero bien puede exponer a las cuentas de fin de mes o
permitirá configurar la nómina para un nuevo recluta. Estos lazos capabili- pueden
requerir el intercambio de información compartida-modelos-pero he visto demasiado
a menudo que pensar en los datos conduce a anemia, a base de CRUD (crear, leer,
actualizar, eliminar) los servicios. Así que pregunte primero “¿Qué hace este
contexto?”, Y luego “Entonces, ¿qué datos no se necesita hacer eso?”
Cuando modelado como los servicios, estas capacidades se convierten en las
operaciones clave que serán expuestos a través del cable a otros colaboradores.
Tortugas todo el camino
Al principio, es probable que identificar una serie de contextos acotados de
granularidad gruesa. Pero estos contextos delimitadas pueden a su vez contienen más
acotada contextos. Por ejem- plo, se puede descomponer el almacén en capacidades
asociadas con el fin fillment Fulbright, gestión de inventario, o recepción de
mercancías. Al considerar los límites de sus microservicios, primero pensar en
términos de los contextos más grandes, de grano más grueso, y luego subdividir a lo
largo de estos contextos anidados cuando se está en busca de los beneficios de la
división a cabo estas costuras.
He visto estos contextos anidados permanecen ocultos a otra, colaborando microservicios con gran efecto. Para el mundo exterior, que siguen haciendo uso de capacidades de negocio en el almacén, pero son conscientes de que sus solicitudes en
realidad están siendo asignados de forma transparente a dos o más servicios por
separado, como se puede ver enFigura 3-2. A veces, usted decidirá que tiene más
sentido para el contexto acotado de nivel superior no puede modelar de forma
explícita como un límite de servicio, como enFigura 3-3, Por lo que en lugar de una
36| Capítulo 3: Cómo modelo de
servicios
sola frontera de almacén, en su lugar podría dividir a cabo el inventario,
cumplimiento de pedidos y recepción de mercancías.
El contexto acotado | 37
Figura 3-2. Microservicios que representan contextos anidados delimitadas
ocultos en el interior del almacén
Figura 3-3. Los contextos delimitados en el interior del almacén se aparecieron en
sus propios contextos de alto nivel
En general, no hay una regla dura y rápida en cuanto a qué enfoque tiene más
sentido. Sin embargo, si se elige el enfoque anidado sobre el enfoque de la
separación completa debe basarse en su estructura organizativa. Si el cumplimiento
de pedidos, gestión de inventario y recepción de los bienes son administrados por
diferentes equipos, es probable que merecen su condición de microservicios de alto
nivel. Si, por el contrario, todos ellos son gestionados por un equipo, entonces el
modelo anidado tiene más sentido. Esto se debe a la interacción de las estructuras de
organización y arquitectura de software, lo que vamos a discutir hacia el final del
libro deCapítulo 10.
Otra razón para preferir el enfoque anidado podría ser a su trozo de arquitectura para
simplificar las pruebas. Por ejemplo, al probar los servicios que consumen el
almacén, no tengo a stub cada servicio dentro del contexto de almacén, sólo la API
de grano más coarse-. Esto también le puede dar una unidad de aislamiento cuando se
consideran grandes las pruebas de ámbito. Puede que, por ejemplo, decidir tener
pruebas de extremo a extremo en el que poner en marcha todos los servicios dentro
del contexto de almacén, sino para todos los demás colaboradores que podría
dejamos vacías. Vamos a estudiar más sobre las pruebas y el aislamiento deCapítulo
7.
Tortugas hasta el fondo | 35
La comunicación en términos de conceptos de negocio
Los cambios que implementamos en nuestro sistema son a menudo acerca de los
cambios que la empresa quiere hacer a cómo se comporta el sistema. Estamos
cambiando la funcionalidad de las capacidades- que están expuestos a nuestros
clientes. Si nuestros sistemas se descomponen a lo largo de los contextos acotados
que representan nuestro dominio, los cambios que queremos hacer son más
propensos a ser aislado a uno, límite microService sola. Esto reduce el número de
lugares que tenemos que hacer un cambio, y nos permite desplegar rápidamente que
el cambio.
Sus También es importante pensar en la comunicación entre estos microservicios en
términos de los mismos conceptos de negocio. El modelado de software Después de
su dominio Ness Busi- no debe detenerse en la idea de contextos acotados. Los
mismos términos e ideas que se comparten entre las partes de su organización deben
reflejarse en sus interfaces. Puede ser útil pensar en formas de ser enviados entre
estos microservicios, tanto como las formas se envían alrededor de una organización.
El límite técnico
Eso puede ser útil para ver lo que puede salir mal cuando los servicios se modelan de
forma incorrecta. Hace un tiempo, unos colegas y yo estábamos trabajando con un
cliente en California, ayudando a la compañía adoptar algunas prácticas de código
más limpio y se mueven más hacia las pruebas automatizadas. Habíamos empezado
con algo de la fruta madura, como el servicio decomposi- ción, cuando nos dimos
cuenta de algo mucho más preocupante. No puedo entrar en detalles en cuanto a lo
que hizo la solicitud, pero era una aplicación de cara al público con una gran base de
clientes global.
El equipo y el sistema, habían crecido. Originalmente la visión de una persona, el
sistema había tomado más y más características, y más y más usuarios. Con el
tiempo, la or- ganización decidió aumentar la capacidad del equipo por tener un
nuevo grupo de res desarrollos basados en Brasil asuma una parte del trabajo. El
sistema quedó dividido, con la mitad delantera de la aplicación siendo esencialmente
sin estado, implementar el sitio de cara al público en web, como se muestra enFigura
3-4. La media parte posterior del sistema era simplemente una interfaz remota
llamada procedi- miento (RPC) durante un almacén de datos. Esencialmente, imagina
que había tomado una capa de repositorio en su base de código y hecho de este un
servicio independiente.
36| Capítulo 3: Cómo modelo de
servicios
La Figura 3-4. Una fracción de frontera de servicio a través de una costura técnico
Los cambios tenían con frecuencia que deben introducirse en ambos servicios.
Ambos servicios hablaban en términos de bajo nivel, el método de estilo llamadas
RPC, que eran demasiado frágiles (discutiremos esto en futherCapítulo 4). La
interfaz de servicio también era muy hablador también, lo que resulta en problemas
de rendimiento. Esto dio lugar a la necesidad de mecanismos RPC-lotes elaborados.
Me llamó esta arquitectura de cebolla, ya que tenía un montón de capas y me hizo
llorar cuando tuvimos que cortar a través de él.
Ahora, en vista de ello, la idea de dividir el sistema monolítico previamente a lo largo
de líneas geográficas / organización tiene mucho sentido, ya que vamos a ampliar en
en Capítulo 10. Aquí, sin embargo, en lugar de tomar una rebanada vertical, centrada
en el negocio a través de la pila, el equipo recogió lo que antes era una API en
proceso e hizo un corte horizontal.
La toma de decisiones para modelar los límites del servicio a lo largo de las costuras
técnicas no siempre es malo. Ciertamente, he visto esto hace mucho sentido cuando
una organización está tratando de lograr ciertos objetivos de rendimiento, por
ejemplo. Sin embargo, debe ser su controlador secundario para la búsqueda de estas
costuras, no su primaria.
Resumen
En este capítulo, usted ha aprendido un poco acerca de lo que hace un buen servicio,
y cómo encontrar las costuras en nuestro espacio del problema que nos dan el doble
beneficio de ambos bajo acoplamiento y alta cohesión. contextos acotadas son una
herramienta vital en ayudarnos a encontrar estas costuras, y alineando nuestros
microservicios a estos límites nos aseguramos de que el sistema resultante tiene todas
las posibilidades de mantener intactas las virtudes. También tenemos una pista sobre
cómo podemos subdividir aún más nuestros microservicios, algo que vamos a
explorar en mayor profundidad más adelante. Y también introdujimos MusicCorp, el
resumen | 37
dominio de ejemplo que vamos a utilizar en este libro.
38| Capítulo 3: Cómo modelo de
servicios
Las ideas presentadas en Diseño guiado por el dominio de Eric Evans son muy útiles
para nosotros en la búsqueda de límites razonables para nuestros servicios, y yo sólo
hemos arañado la superficie aquí. Recomiendo Driven Design-libro de dominio de
aplicación de Vaughn Vernon (Addison-Wesley) para ayudar a entender los aspectos
prácticos de este enfoque.
Aunque en este capítulo ha sido en su mayoría de alto nivel, tenemos que conseguir
mucho más téc- nico en el siguiente. Hay muchos problemas asociados con la
implementación de las interfaces entre los servicios que pueden conducir a todo tipo
de problemas, y vamos a tener que tomar una inmersión profunda en este tema si
queremos mantener nuestros sistemas de convertirse en un gigante, maraña.
resumen | 39
CAPÍTULO 4
Integración
Conseguir la derecha de integración es el aspecto más importante de la tecnología
asocia- dos con microservicios en mi opinión. Hacerlo bien, y sus microservicios
conservan su autonomía, que le permite cambiar y liberarlos independiente del
conjunto. Se equivocan, y la catástrofe que nos espera. Con suerte, una vez que haya
leído este capítulo usted aprenderá cómo evitar algunas de las mayores dificultades
que han afectado a otros intentos de SOA y sin embargo podría le esperan en su viaje
a microservicios.
En busca de la integración de la tecnología Ideal
Hay una desconcertante variedad de opciones que hay para cómo uno microService
puede hablar con otro. Pero cual es la correcta: jabón? XML-RPC? ¿DESCANSO?
tampones protocolo? Vamos a bucear en los que en un momento, pero antes de
hacerlo, vamos a pensar en lo que queremos de cualquier tecnología que elegimos.
Evitar Los cambios de última hora
De vez en cuando, podemos hacer un cambio que requiere nuestros consumidores a
cambiar también. Vamos a discutir cómo manejar esto más adelante, pero queremos
recoger tecnología que garantiza esto sucede lo menos posible. Por ejemplo, si un
microService añade nuevos campos a una parte de los datos que envía, los
consumidores existentes no deberían verse afectados.
Mantenga su independiente de la tecnología API
Si usted ha estado en la industria de TI durante más de 15 minutos, no hace falta que
decir que trabajamos en un espacio que está cambiando rápidamente. La única
certeza es el cambio. Nuevas herramientas, marcos y lenguas están saliendo todo el
tiempo, la aplicación de nuevas ideas que pueden ayudar a trabajar más rápido y con
mayor eficacia. En este momento, es posible que una tienda de .NET. Pero ¿qué pasa
39
en un año a partir de ahora, o cinco años a partir de ahora? Que si tu
40| Capítulo 4: Integración
desee experimentar con una pila de tecnologías alternativas que podrían hacer más
productivo?
Soy un gran fan de mantener mis opciones abiertas, por lo que yo soy un fan de
vicios tales microser-. También es por eso que creo que es muy importante para
asegurarse de que mantener las API utilizadas para la comunicación entre
microservicios independiente de la tecnología. Esto significa evitar la tecnología de
integración que dicta lo que la tecnología pilas que podemos utilizar para poner en
práctica nuestros microservicios.
Hacer del Servicio simple para los consumidores
Nosotros querer hacer más fácil para los consumidores a utilizar nuestro servicio.
Tener un microService reada bellamente fac- no cuenta para mucho si el costo de
utilizarlo como un consumidor está por las nubes! Así que vamos a pensar en lo que
hace que sea fácil para los consumidores a utilizar nuestro nuevo servicio
maravilloso. Idealmente, nos gustaría para permitir a nuestros clientes completa
libertad en su elección de la tecnología, pero por otro lado, proporcionar una
biblioteca de cliente puede aliviar la adopción. A menudo, sin embargo, dichas
bibliotecas son incompatibles con otras cosas que queremos lograr. Por ejemplo,
podríamos utilizar bibliotecas de cliente para hacer más fácil para los consumidores,
pero esto puede llegar a costa de un mayor acoplamiento.
Ocultar detalle de implementación interna
Nosotros no hacemos queremos que nuestros consumidores a estar unidos a nuestra
aplicación interna. Esto conduce a un aumento de acoplamiento. Esto significa que si
queremos cambiar algo dentro de nuestra microService, podemos romper nuestros
consumidores al obligarles a cambiar también. Esto incrementa el coste del cambioel resultado exacto que estamos tratando de evitar. También significa que son menos
propensos a querer hacer un cambio por temor a tener que actualizar nuestros
consumidores, que pueden conducir a un aumento de la deuda técnica dentro del
servicio. Por lo que cualquier tecnología que nos empuja a exponer detalladamente
representación interna debe ser evitado.
Interfaz con Clientes
Ahora que tenemos algunas pautas que pueden ayudar a seleccionar una buena
tecnología a utilizar para la integración entre los servicios, vamos a ver algunas de las
opciones más comunes por ahí y tratar de averiguar qué funciona mejor para
nosotros. Para ayudarnos a pensar en esto, vamos a elegir un ejemplo del mundo real
desde MusicCorp.
creación del cliente a primera vista podría ser considerado como un simple conjunto
de opera- ciones CRUD, pero para la mayoría de los sistemas es más complejo que
eso. Registro de una nueva cliente puede necesitar para poner en marcha procesos
41
adicionales, como la creación de pagos financieros o Enviar- ing mensajes de correo
electrónico de bienvenida. Y cuando cambiar o eliminar un cliente, otros procesos de
negocio puede ser que consiga disparado también.
Así que con esto en mente, debemos mirar algunas maneras diferentes en las que lo
que se quiere trabajar con los clientes en nuestro sistema MusicCorp.
42| Capítulo 4: Integración
La base de datos compartida
Con mucho, la forma más común de integración que yo o cualquiera de mis colegas
veo en la industria es la base de datos (DB) de integración. En este mundo, si quieren
otros servicios de informa- ción de un servicio, que llegan a la base de datos. Y si
quieren cambiarlo, que llegan a la base de datos! Esto es muy simple cuando se
piensa en ello en primer lugar, y es probablemente la forma más rápida de la
integración a comenzar con-lo que probablemente explica su popularidad.
Figura 4-1 nuestra muestra la interfaz de usuario de registro, que crea los clientes
mediante la realización de operaciones SQL directamente en la base de datos.
También muestra nuestra aplicación de centro de llamadas que ve y edita los datos
del cliente mediante la ejecución de SQL en la base de datos. Y el almacén actualiza
la información sobre pedidos de los clientes mediante la consulta de la base de datos.
Este es un patrón bastante com- mon, pero es uno lleno de dificultades.
La Figura 4-1. Usando la integración DB para acceder y cambiar la información del cliente
En primer lugar, estamos permitiendo que las partes externas a ver y se unen a los
detalles de implementación interna. Las estructuras de datos que almacenamos en la
base de datos son un juego justo para todos; que se comparten en su totalidad con
todas las demás partes con acceso a la base de datos. Si decido cambiar mi esquema
para representar mejor a mis datos, o hacer mi sistema más fácil de mantener, puedo
romperme los consumidores. El DB es efectivamente una API muy grande,
compartida que también es bastante frágil. Si quiero cambiar la lógica asociada con,
por ejemplo, cómo el servicio de asistencia gestiona los clientes y esto requiere un
cambio en la base de datos, tengo que tener mucho cuidado de que no se rompen las
partes del esquema utilizado por otros servicios. Esta situación da lugar normalmente
a que requiere una gran cantidad de pruebas de regresión.
En segundo lugar, mis consumidores están ligados a una elección específica de la
tecnología. Tal vez en este momento que tiene sentido para almacenar los clientes en
una base de datos relacional, por lo que mis consumidores utilizan un controlador
adecuado (potencialmente DB-específico) para hablar con él. ¿Qué pasa si el paso del
tiempo nos damos cuenta de que sería mejor almacenar datos en una base de datos
relacional? Puede tomar esa decisión? Así que los consumidores están íntimamente
ligados a la implementación del servicio al cliente. Como hemos comentado
La base de datos compartida
| 41
anteriormente, que realmente queremos para asegurar que detalle de implementación
se oculta a los consumidores para que nuestro servicio de un nivel de autonomía en
términos de cómo cambia su funcionamiento interno a través del tiempo. Adiós,
acoplamiento suelto.
42| Capítulo 4: Integración
Por último, vamos a pensar en el comportamiento por un momento. No va a ser
lógica asociada con la forma en que se cambia un cliente. ¿Dónde es que la lógica? Si
los consumidores están manipulando directamente la base de datos, entonces tienen
que poseer la lógica asociada. La lógica para per- formar el mismo tipo de
manipulación para un cliente puede ahora ser extendido entre los consumidores
multi- ples. Si el almacén, la interfaz de usuario de registro y centro de llamadas de
interfaz de usuario toda la necesidad de editar la información del cliente, lo que
necesito para corregir un error o cambiar el comportamiento en tres lugares
diferentes, e implementar esos cambios también. Adiós, la cohesión.
Recuerde que cuando hablamos de los principios básicos detrás de buenas
microservicios? Fuerte cohesión y la suelta de acoplamiento con la integración de la
base de datos, se pierden ambas cosas. la integración de bases de datos hace que sea
fácil para los servicios para compartir datos, pero no hace nada acerca de compartir
comportamiento. Nuestra representación interna se expone sobre el alambre a
nuestros con- sumidores, y puede ser muy difícil de evitar hacer cambios de última
hora, lo que inevitablemente conduce a un temor de cualquier cambio en absoluto.
Evitar a (casi) todos los costes.
Para el resto del capítulo, vamos a explorar diferentes estilos de integración que
involucran servicios laborating COL-, que a su vez ocultar sus propias
representaciones internas.
Versus síncrono asíncrono
Antes de empezar a bucear en los detalles de las diferentes opciones de tecnología,
debemos discutir una de las decisiones más importantes que podemos hacer en
términos de cómo colaboran los servicios. En caso de que la comunicación sea
síncrona o asíncrona? Esta elección funda- mental, inevitablemente, nos guía hacia
cierto detalle de implementación.
Con la comunicación síncrona, se realiza una llamada a un servidor remoto, que
bloquea hasta que se completa la operación. Con la comunicación asincrónica, la
persona que llama no espera a que se complete la operación, antes de regresar, y
puede incluso no importa si la operación se completa en absoluto.
comunicación sincrónica puede ser más fácil de razonar acerca. Sabemos que cuando
las cosas se han completado con éxito o no. La comunicación asíncrona puede ser
muy útil para trabajos de larga duración, donde mantener una conexión abierta
durante un largo período de tiempo entre el cliente y el servidor es poco práctico.
También funciona muy bien cuando se necesita una latencia baja, donde el bloqueo
de una llamada mientras se espera el resultado puede retrasar las cosas. Debido a la
naturaleza de las redes móviles y dispositivos, disparando las solicitudes y las cosas
asumiendo han trabajado (a menos que se diga lo contrario) puede asegurar que la
interfaz de usuario se mantenga sensible incluso si la red es muy perezoso. En el otro
lado, la tecnología para manejar la comunicación asyn- chronous puede ser un poco
La base de datos compartida
| 43
más complicado, como veremos en breve.
Estos dos modos diferentes de comunicación pueden habilitar dos estilos diferentes
idiomáticas de colaboración: petición / respuesta o basadas en eventos. Con petición /
respuesta, un ent CLI- inicia una petición y espera la respuesta. Este modelo se alinea
claramente bien a la comunicación síncrona, pero puede trabajar para la
comunicación asincrónica también. yo
44| Capítulo 4: Integración
podría poner en marcha una operación y registrar una devolución de llamada,
pidiendo al servidor para que me haga saber cuando mi operación se ha completado.
Con una colaboración basada en eventos, invertimos cosas. En lugar de un cliente
que inicia solicitudes que piden cosas por hacer, en lugar dice que esto sucedió y
espera que otras partes sepan qué hacer. Nunca cuentes a nadie lo que debe hacer.
Los sistemas basados en eventos, por su naturaleza son asíncronas. Los inteligencia
son distributed- de manera más uniforme es decir, la lógica de negocio no se
centraliza en los cerebros de núcleo, pero en vez empujado hacia fuera de manera
más uniforme a los diversos colaboradores. La colaboración basada en evento
también es altamente desacoplado. El cliente que emite un evento no tiene ninguna
manera de saber quién o qué va a reaccionar a ella, lo que también significa que se
pueden añadir nuevos suscriptores a estos eventos sin que el cliente ni siquiera tenga
que saber.
Así que ¿hay otros conductores que nos puedan empujar a elegir un estilo sobre otro?
Un factor importante a considerar es lo bien que se adaptan estos estilos para resolver
un problema complejo a menudo-: ¿Cómo manejamos procesos que abarcan los
límites del servicio y pueden ser de larga data?
Orquestación Versus Coreografía
A medida que comienzan a modelar más y más compleja lógica, tenemos que lidiar
con el problema de la gestión de procesos de negocio que se extienden a través del
límite de servi- cios individuales. Y con microservicios, vamos a golpear este límite
antes de lo habitual. Tomemos un ejemplo de MusicCorp, y veamos lo que sucede
cuando creamos un cliente:
1. Un nuevo registro se crea en el banco de puntos de fidelidad para el cliente.
2. Nuestro sistema postal envía un paquete de bienvenida.
3. Nosotros enviar un mensaje de bienvenida a los clientes.
Esto es muy fácil de modelar conceptualmente como un diagrama de flujo, como lo hacemos en
Figura 4-2.
Cuando se trata de la aplicación real de este flujo, hay dos estilos de la arquitectura
que podríamos seguir. Con la orquestación, nos basamos en un cerebro central para
guiar y conducir el proceso, al igual que el conductor de una orquesta. Con
coreografía, se informa a cada parte del sistema de su trabajo, y dejar que actúe en
los detalles, como bailarines ing todo hallazgo su camino y que reaccionan a otros a
su alrededor en un ballet.
Orquestación Versus Coreografía | 43
La Figura 4-2. El proceso para crear un nuevo cliente
Vamos a pensar en lo que es una solución de orquestación se vería de este flujo. En
este caso, probablemente la cosa más sencilla de hacerlo sería tener nuestro acto de
servicio al cliente como el cerebro central. En la creación, que habla con el banco de
puntos de fidelidad, servicio de correo electrónico, y el servicio postal como vemos
enFigura 4-3, A través de una serie de llamadas de petición / respuesta. El propio
servicio de cliente puede realizar un seguimiento de que un cliente está en este
proceso. Se puede comprobar para ver si la cuenta del cliente se ha establecido, o el
correo electrónico enviado o entregado el cargo. Tenemos la oportunidad de tomar el
diagrama de flujo deFigura 4-2 y modelar directamente en código. Podríamos incluso
utilizar herramientas que implementa esto por nosotros, tal vez utilizando un motor
de reglas apropiado. existen herramientas comerciales para este fin en forma de
software de modelado de procesos de negocio. Suponiendo que utilizamos síncrono
de solicitud / respuesta, incluso podríamos saber si cada etapa ha funcionado.
La Figura 4-3. Manejo de creación del cliente a través de la orquestación
La desventaja de este enfoque es que la orquestación de servicio al cliente puede
llegar a ser demasiado de una autoridad de gobierno central. Puede llegar a ser el
44| Capítulo 4: Integración
centro de operaciones en el medio de una
Orquestación Versus Coreografía | 45
web, y un punto central donde la lógica comienza a vivir. He visto a este resultado
enfoque en un pequeño número de servicios inteligentes “dios” contar los servicios
basados en CRUD anémica qué hacer.
Con un enfoque coreografía, que podría tener lugar sólo el servicio al cliente emite
un evento de manera asíncrona, diciendo creado cliente. El servicio de correo
electrónico, servicio postal, y los puntos de fidelidad bancaria a continuación, sólo se
suscriben a estos eventos y reaccionar en consecuencia, como enFigura 4-4. Este
enfoque es significativamente más desacoplado. Si algún otro servicio necesario para
llegar a la creación de un cliente, sólo tiene que suscrip- ción a los acontecimientos y
hacer su trabajo cuando sea necesario. La desventaja es que la visión explícita de los
procesos de negocio que vemos enFigura 4-2 Ahora se refleja de manera implícita en
nuestro sistema.
La Figura 4-4. Manipulación del cliente a través de la creación de la coreografía
Esto significa que se necesita trabajo adicional para asegurarse de que puede
controlar y realizar un seguimiento de que se han sucedido las cosas correctas. Por
ejemplo, puedes saber si el banco puntos de fidelidad tenía un error y por alguna
razón no se estableció la cuenta correcta? Uno de los enfoques que me gusta para
hacer frente a esto es crear un sistema de control que coincide explícitamente el
punto de vista del proceso de negocio deFigura 4-2, Pero luego las pistas lo que cada
uno de los servicios que lo hace como entidades independientes, que le permite ver
excepciones impares mapeados en el flujo de proceso más explícito. El diagrama de
flujo que vimos anteriormente no es la fuerza motriz, pero sólo un lente a través del
cual podemos ver cómo el sistema se está comportando.
En general, he encontrado que los sistemas que tienden más hacia el enfoque
coreografía son más débilmente acoplado, y son más flexibles y susceptibles de
cambio. Sí es necesario realizar un trabajo extra para controlar y realizar un
seguimiento de los procesos a través de los límites del sistema, sin embargo. He
encontrado implementaciones más fuertemente orquestado a ser extremadamente
frágil, con un coste más alto de cambio. Con esto en mente, yo prefiero firmemente
el objetivo de un sistema de coreografía, donde cada servicio es lo suficientemente
inteligente como para Deben conocerse su papel en todo el baile.
Hay bastantes factores para desempaquetar aquí. llamadas síncronas son más
46| Capítulo 4: Integración
simples, y llegar a saber si las cosas funcionaron de inmediato. Si nos gusta la
semántica de petición /
Orquestación Versus Coreografía | 47
respuesta, pero se trata de procesos de larga vida, que sólo podría iniciar solicitudes
nous asynchro- y esperar a que las devoluciones de llamada. Por otro lado, la ración
de eventos asíncronos colabora- nos ayuda a adoptar un enfoque coreografía, lo que
puede producir significativamente más desacoplado servicios de algo que queremos
luchar por asegurar que nuestros servicios son de forma independiente liberable.
Estamos, por supuesto, libre de mezclar y combinar. Algunas tecnologías se ajuste
más natural en un estilo u otro. Nosotros, sin embargo, necesitamos apreciar algunos
de los detalles de implementación diferentes técnicas que ayudarán aún más a hacer
la decisión correcta.
Para empezar, vamos a ver dos tecnologías que se adapten bien cuando estamos
considerando petición / respuesta: las llamadas a procedimiento remoto (RPC) y
Representational State Transfer (REST).
Llamadas a procedimiento remoto
Llamada a procedimiento remoto se refiere a la técnica de hacer una llamada local y
hacer que se eje- lindo en un servicio remoto en alguna parte. Hay un número de
diferentes tipos de tecnología de RPC que hay. Algunas de esta tecnología se basa en
tener una definición de interfaz (SOAP, Thrift, búferes de protocolo). El uso de una
definición de interfaz separada puede hacer que sea más fácil para generar recibos de
cliente y servidor para diferentes pilas de tecnología, por lo que, por ejem- plo,
podría tener un servidor Java exponiendo una interfaz SOAP, y un cliente .NET
generada desde el servicio Web Definition Language (WSDL) definición de la
interfaz. Otras tecnologías, como Java RMI, exige un acoplamiento estrecho entre el
cliente y el servidor, lo que requiere que ambos utilizan la misma tecnología
subyacente pero evita la necesidad de una definición de interfaz compartida. Todas
estas tecnologías, sin embargo, tienen la misma,
Muchos de estas tecnologías son de naturaleza binaria, como Java RMI, Thrift, o
tampones de protocolo, mientras que de SOAP utiliza XML para sus formatos de
mensaje. Algunas implementaciones están vinculados a un protocolo de red
específico (como SOAP, que hace uso nominal de HTTP), mientras que otros
podrían permitir el uso de diferentes tipos de protocolos de red, que a su vez puede
proporcionar funciones adicionales. Por ejemplo, TCP ofrece garantías acerca de la
entrega, mientras que UDP no, pero tiene una cabeza mucho más bajo. Esto puede
permitir el uso de la tecnología de redes diferentes para diferentes casos de uso.
Esas implementaciones RPC que le permiten generar recibos de cliente y servidor
ayudarle a empezar muy, muy rápido. Puedo ser el envío de contenido a través de
una frontera de la red en ningún momento a todos. Esto es a menudo uno de los
principales puntos de venta de RPC: su facilidad de uso. El hecho de que solo puedo
hacer una llamada a un método normal y, teóricamente, ignorar el resto es una
ventaja enorme.
Algunas implementaciones RPC, sin embargo, vienen con algunos inconvenientes
48| Capítulo 4: Integración
que pueden causar problemas. Estos problemas no son siempre evidentes al principio,
pero, no obstante, pueden ser lo suficientemente grave como para superar los
beneficios de ser tan fácil de poner en marcha rápidamente.
Orquestación Versus Coreografía | 49
tecnología de acoplamiento
Algunos mecanismos RPC, como Java RMI, están fuertemente ligados a una
plataforma específica, lo que puede limitar la cual la tecnología se puede utilizar en
el cliente y el servidor. De segunda mano y de protocolo amortiguadores tienen una
cantidad impresionante de soporte para lenguajes alternativos, lo que puede reducir
este inconveniente poco, pero tenga en cuenta que a veces la tecnología de RPC
viene con restricciones a la interoperabilidad.
En cierto modo, este acoplamiento tecnología puede ser una forma de exponer los
detalles técnicos mentación Implementers internos. Por ejemplo, el uso de RMI lazos
no sólo el cliente para la JVM, pero el servidor también.
Las llamadas locales no son como las llamadas remotas
La idea central de RPC es ocultar la complejidad de una llamada remota. Muchas
implementaciones de RPC, sin embargo, esconden demasiado. La unidad en algunas
formas de RPC para hacer llamadas a métodos remotos parecen llamadas a métodos
locales oculta el hecho de que estas dos cosas son muy diferentes. Puedo hacer un
gran número de llamadas locales, en proceso y sin Worry ing excesivamente sobre el
rendimiento. Con RPC, sin embargo, el costo de cálculo de referencias y cargas útiles
de clasificación de ONU-puede ser importante, por no mencionar el tiempo necesario
para enviar cosas por la red. Esto significa que hay que pensar de manera diferente
sobre el diseño de la API para las interfaces remotas frente a las interfaces locales.
Sólo tomando una API local y tratar de hacer que un límite de servicio sin es
probable que meter en problemas más pensamiento. En algunos de los peores
ejemplos,
Tú que pensar en la propia red. Lo conocido, la primera de las falacias de la
computación dis- tribuido es“La red es fiable”. Las redes no son fiables. Ellos pueden
y fallan, incluso si su cliente y el servidor que está hablando están bien. Ellos pueden
fallar rápido, pueden fallar lento, e incluso pueden malform sus paquetes. Usted debe
asumir que sus redes están plagadas de entidades malévolas listos para dar rienda
suelta a su ira en un capricho. Por lo tanto, los modos de fallo que puede esperar son
diferentes. Un Ure fail podría ser causado por el servidor remoto devolver un error, o
por usted haciendo una mala decisión. ¿Puede usted decir la diferencia, y si es así, se
puede hacer nada al respecto? Y, ¿qué hacer cuando el servidor remoto simplemente
empieza a responder lentamente? Vamos a cubrir este tema cuando hablamos de la
capacidad de resistencia deCapítulo 11.
fragilidad
Algunas de las implementaciones más populares de RPC puede conducir a algunas
formas desagradables de fragilidad, RMI de Java es un muy buen ejemplo. Vamos a
considerar una interfaz Java muy simple que hemos decidido hacer una API de
control remoto para la atención al cliente.Ejemplo 4-1 declara los métodos que
Llamadas a procedimientos
remotos | 47
vamos a exponer de forma remota. RMI de Java genera entonces los talones de
cliente y servidor para nuestro método.
48| Capítulo 4: Integración
Ejemplo 4-1. Definiendo un extremo de servicio usando Java RMI
importar java.rmi.Remote;
importar java.rmi.RemoteException;
interfaz pública ClienteRemote se extiende Remoto {
público Cliente findCustomer(ID de cadena) lanza RemoteException;
público Cliente createCustomer(Nombre de cuerdas, apellido cadena, cadena emailAddress)
lanza RemoteException;
}
En esta interfaz, findCustomer toma el primer nombre, apellido y dirección de correo
electrónico. ¿Qué ocurre si decidimos permitir que el objeto del cliente también
puede crear con sólo una dirección de correo electrónico? Podríamos añadir un nuevo
método en este punto con bastante facilidad, así:
...
público Cliente createCustomer(cadena emailAddress) lanza RemoteException;
...
El problema es que ahora hay que regenerar los stubs cliente también. Los clientes
que desean consumir el nuevo método necesitan los nuevos talones, y dependiendo
de la naturaleza de los cambios en la especificación, los consumidores que no
necesitan el nuevo método puede también necesitan que sus talones mejorado
también. Esto es manejable, por supuesto, pero hasta cierto punto. La realidad es que
los cambios de este tipo son bastante comunes. puntos finales RPC a menudo acaban
teniendo un gran número de métodos para diferentes formas de crear o interactuar
con los objetos. Esto se debe en parte al hecho de que todavía estamos pensando en
estas llamadas remotas como las locales.
Hay otro tipo de fragilidad, sin embargo. Vamos a echar un vistazo a lo que nuestro cliente
objeto se parece a:
clase pública Cliente implementos serializable {
privado cadena primerNombre;
privado apellido cadena;
privado cadena emailAddress;
privado cadena edad;
}
Ahora, ¿y si resulta que aunque exponemos el campo de la edad en nuestros objetos
de clientes, ninguno de nuestros consumidores cada vez se utiliza? Decidimos que
queremos eliminar este campo. Pero si la implementación del servidor elimina la
edad de su definición de este tipo, y no hacemos lo mismo para todos los
consumidores, a continuación, a pesar de que nunca se utiliza el campo, el código
asociado a deserializar el objeto al cliente en el lado del consumidor se romperá .
Para distribuir este cambio, tendría que implementar tanto un nuevo servidor y los
clientes al mismo tiempo. Este es un desafío clave con cualquier mecanismo RPC
que promueve el uso de la generación de código auxiliar binaria: usted no consigue
separar las implementaciones de cliente y servidor. Si utiliza esta tecnología,
Llamadas a procedimientos
remotos | 49
comunicados de bloqueo de paso pueden ser en el futuro.
50| Capítulo 4: Integración
Problemas similares se producen si quiero reestructurar el objeto al cliente, incluso si
no eliminar campos, por ejemplo, si quería encapsular primerNombre y apellidos en
un nuevo tipo de denominación para que sea más fácil de manejar. Podría, por
supuesto, arreglar esto pasando alrededor de los tipos de diccionario como los
parámetros de mis llamadas, pero en ese momento, voy a perder muchos de los
beneficios de los módulos de programa generados porque todavía tiene que coincidir
manualmente y extraer los campos que quiero .
En la práctica, los objetos utilizados como parte de serialización binaria a través del
cable pueden ser considerados como ampliar-únicos tipos. Este fragilidad resultados
en los tipos expuestos sobre el alambre y convertirse en una masa de campos,
algunos de los cuales ya no se utilizan, pero no se pueden eliminar de forma segura.
RPC es terrible?
A pesar de sus deficiencias, yo no iría tan lejos como para llamar RPC terrible.
Algunas de las implementaciones comunes que he encontrado puede llevar a la clase
de problemas que he descrito aquí. Debido a los retos de la utilización RMI, sin duda
dará que la tecnología de un gran rodeo. Muchas operaciones caen bastante bien en el
modelo basado en RPC, y más mecanismos modernos como búferes de protocolo o
Thrift mitigar algunos de los pecados del pasado, evitando la necesidad de
comunicados de bloqueo de paso de cliente y el código del servidor.
Acaba de ser conscientes de algunos de los peligros potenciales asociados con RPC si
se va a recoger este modelo. No abstractos sus llamadas remotas hasta el punto donde
la red está completamente oculto, y asegúrese de que puede evolucionar la interfaz de
servidor sin ing hav- insistir en las actualizaciones de bloqueo de paso para los
clientes. Encontrar el equilibrio adecuado para su código ent CLI- es importante, por
ejemplo. Asegúrese de que sus clientes no son ajenos al hecho de que una llamada a
la red se va a realizar. bibliotecas de cliente se utilizan a menudo en el contexto de la
RPC, y si no estructurado derecho que puede ser problemático. Hablaremos más
sobre ellos en breve.
En comparación con la integración de bases de datos, RPC es sin duda una mejora
cuando pensamos acerca de las opciones para la colaboración de solicitud / respuesta.
Pero hay otra opción para con- Sider.
DESCANSO
Representational State Transfer (REST) es un estilo arquitectónico inspirado en la
Web. Hay muchos principios y limitaciones detrás del estilo REST, pero vamos a
centrar en los que realmente nos ayude cuando nos enfrentamos a los retos de
integración en un mundo ces microservi-, y cuando estamos buscando un estilo
alternativo de RPC para nuestro servicio interfaces.
Lo más importante es el concepto de recursos. Se puede pensar en un recurso como
una cosa que el servicio en sí conoce, como un cliente. El servidor crea diferentes
RESTO | 49
representaciones de este cliente bajo petición. Como un recurso se muestra
externamente es
50| Capítulo 4: Integración
completamente desacoplado de la forma en que se almacena internamente. Un cliente
puede pedir una representación JSON de un cliente, por ejemplo, incluso si se
almacena en un formato completamente diferente. Una vez que un cliente tiene una
representación de este cliente, entonces se puede hacer peticiones para cambiarlo, y
el servidor puede o no puede cumplir con ellos.
Hay muchos estilos diferentes de descanso, y me tocan sólo brevemente sobre ellos
aquí. Os recomiendo echar un vistazo a laRichardson Modelo de Madurez, Donde se
comparan los diferentes estilos de descanso.
RESTO sí en realidad no hablar de protocolos subyacentes, aunque es más
comúnmente utilizado a través de HTTP. He visto las implementaciones de REST
utilizando diferentes protocolos antes, como serie o USB, aunque esto puede requerir
mucho trabajo. Algunas de las características que nos da HTTP como parte de la
especificación, como los verbos, hacer que la implementación de REST a través de
HTTP más fácil, mientras que con otros protocolos que tendrá que manejar estas
características sí mismo.
REST y HTTP
HTTP en sí define algunas capacidades útiles que juegan muy bien con el estilo
REST. Por ejemplo, los verbos HTTP (por ejemplo, GET, POST, y PUT) ya han bien
entendido significados en la especificación HTTP en cuanto a cómo deben trabajar
con recursos. El estilo arquitectónico REST realidad nos dice que los métodos deben
comportarse de la misma manera en todos los recursos, y la especificación HTTP
pasa a definir un montón de métodos que podemos utilizar. GET recupera un recurso
de una manera idempotente, y POST crea un nuevo recurso. Esto significa que
podemos evitar un montón de diferentes métodos createCustomer o editCustomer. En
su lugar, simplemente se puede publicar un representación al cliente para solicitar
que el servidor crea un nuevo recurso, e iniciar una petición GET para recuperar una
representación de un recurso. Conceptualmente, hay un punto final en forma de un
recurso de atención al cliente en estos casos,
HTTP también trae un gran ecosistema de herramientas y tecnología de apoyo.
Tenemos la oportunidad de utilizar servidores proxy caché HTTP como barniz y
equilibradores de carga como mod_proxy, y muchas herramientas de seguimiento ya
tienen un montón de soporte para HTTP fuera de la caja. Estos bloques de
construcción nos permiten manejar grandes volúmenes de tráfico HTTP y ruta con
inteligencia, de una manera bastante transparente. También recibimos a utilizar todos
los controles de seguridad con- disponibles con HTTP para asegurar nuestras
comunicaciones. A partir de autenticación básica de certificados de clientes, el
ecosistema HTTP nos da una gran cantidad de herramientas para hacer más fácil el
proceso de seguridad, y vamos a explorar este tema más enCapítulo 9. Dicho esto,
para obtener estos beneficios, usted tiene que utilizar HTTP también. Usar mal, y
puede ser tan insegura y difícil de escalar a medida que cualquier otra tec- nología
por ahí. Utilice bien, sin embargo, y se obtiene una gran cantidad de ayuda.
RESTO | 51
Tenga en cuenta que HTTP se puede utilizar para implementar RPC también. SOAP,
por ejemplo, va a parar a través de HTTP, pero desafortunadamente utiliza muy poco
de la especificación. Los verbos son ignorados, como son las cosas simples, como
códigos de error HTTP. Con demasiada frecuencia, al parecer, el vigente, bien
52| Capítulo 4: Integración
Estándares y Tecnología entendidos son ignorados en favor de nuevas normas que
sólo se pueden implementar utilizando tecnología de nuevo convenientemente
proporcionada por las mismas compañías que ayudan a diseñar las nuevas normas en
el primer lugar!
Hipermedia como el motor del estado de la aplicación
Otro principio introducido en REST que puede ayudar a evitar el acoplamiento entre
el cliente y el servidor es el concepto de hipermedia como el motor del estado de la
aplicación (a menudo abreviado como HATEOAS, y chico, no lo necesitan una
abreviatura). Esto es bastante densa redacción y un concepto bastante interesante, así
que vamos a romper un poco.
Hipermedia es un concepto por el cual un fragmento de contenido contiene enlaces a
otros elementos de contenido en una variedad de formatos (por ejemplo, texto,
imágenes, sonidos). Esto debe ser muy familiar para usted, ya que es lo que hace la
página web promedio: usted sigue los enlaces, que son una forma de controles
hipermedia, para ver contenido relacionado. La idea detrás de HATEOAS es que los
clientes deben realizar interacciones (que puede conducir a transiciones de estado)
con el servidor a través de estos enlaces a otros recursos. No necesita saber
exactamente donde los clientes viven en el servidor por saber qué URI para golpear;
en cambio, el cliente busca y navega enlaces para encontrar lo que necesita.
Esto es un poco de un concepto extraño, así que vamos primer paso atrás y
considerar cómo las personas inter-actuar con una página web, que ya hemos
establecido es rico con los controles de hipermedia.
Piense en el sitio de compras en Amazon.com. La ubicación de la cesta de la compra
ha cambiado con el tiempo. El gráfico ha cambiado. El enlace ha cambiado. Pero a
medida que los seres humanos somos lo suficientemente inteligente como para seguir
viendo un carro de compras, saber lo que es, e interactuar con él. Tenemos una
comprensión de lo que significa un carrito de compras, aunque la forma exacta y
control subyacente utilizado para representarla ha cambiado. Sabemos que si
queremos ver el carro, esto es el control que queremos interactuar con él. Esta es la
razón por páginas web pueden cambiar gradualmente con el tiempo. Mientras se
siguen cumpliendo estos contratos implícitos entre el al cliente central y el sitio web,
los cambios no tienen que estar rompiendo cambios.
Con controles hipermedia, que están tratando de lograr el mismo nivel de inteligencia
para nuestros consumidores electrónicos. Veamos un control hipermedia que
podríamos tener para MusicCorp. Hemos accedido a un recurso que representa una
entrada de catálogo para un álbum dado enEjemplo 4-2. Junto con la información
sobre el álbum, vemos una serie de controles de medios hiper.
Ejemplo 4-2. hipermedia controles utilizados en una lista álbum
<Álbum>
RESTO | 53
<Nombre>Donar sangre</ Name>
<link rel ="/artista" href ="/ artista / theBrakes" />
<Description>
Impresionante, corta, brutal, divertido y ruidoso. ¡Debes comprar!
</ Description>
54| Capítulo 4: Integración
<link rel ="/ Instantpurchase" href ="/ InstantPurchase / 1234" />
</ Álbum>
Este control hipermedia nos muestra dónde encontrar la información sobre el
artista. Y si queremos comprar el álbum, ahora sabemos a dónde ir.
En este documento, tenemos dos controles hipermedia. El cliente de la lectura de un docu- tales
ción necesita saber que un control con una relación del artista es donde necesita la
Navegación puerta para obtener información sobre el artista, y que instantpurchase es
parte del protocolo utilizado para comprar el álbum. El cliente tiene que entender la
semántica de la API o menos de la misma manera que un ser humano tiene que
entender que en un sitio web de ping tienda- el carro es donde los elementos para ser
adquiridos serán.
Como cliente, no necesito saber qué esquema URI para acceder a comprar el disco,
sólo necesito para acceder al recurso, encontrar el control de compra, y vaya a eso. El
Trol con- compra podría cambiar la ubicación, el URI podría cambiar, o en el sitio
podría incluso me envíe a otro servicio por completo, y como un cliente que no le
importaría. Esto nos da una enorme cantidad de desacoplamiento entre el cliente y el
servidor.
Nosotros se abstraen en gran medida del detalle subyacente aquí. Podríamos cambiar
completamente la implementación de cómo se presenta siempre el control como el
cliente todavía puede encontrar un control que coincide con su comprensión del
protocolo, de la misma manera que un control carrito de la compra puede pasar de ser
un simple enlace a una más compleja control de JavaScript. También es libre de
añadir nuevos controles al documento, tal vez representando nuevas transiciones de
estado que podemos realizar sobre el recurso en cuestión. Nos gustaría terminar
rompiendo nuestros consumidores sólo si cambiamos radicalmente la semántica de
uno de los controles por lo que se comportó de manera muy diferente, o si quitamos
un control completo.
El uso de estos controles para desacoplar el cliente y el servidor proporciona
beneficios significativos en el tiempo que compensan en gran medida el pequeño
aumento en el tiempo que se necesita para obtener estos protocolos en
funcionamiento. Siguiendo los enlaces, el cliente obtiene a descubrir
progresivamente la API, que puede ser una capacidad muy útil cuando estamos
implementando nuevos clientes.
Una de las desventajas es que esta navegación de los controles puede ser muy
hablador, ya que el cliente tiene que seguir los enlaces para encontrar la operación
que desea realizar. En última instancia, esto es una solución de compromiso. Yo
sugeriría que comience con tener a sus clientes a navegar estos controles conprimero, y luego optimizar más tarde si es necesario. Recuerde que tenemos una gran
cantidad de ayuda de la caja mediante el protocolo HTTP, que hemos comentado
anteriormente. Los males de la optimización prematura han sido bien documentados
RESTO | 55
antes, así que no es necesario ampliar sobre ellos aquí. También tenga en cuenta que
muchos de estos enfoques se han desarrollado para crear sistemas de hipertexto distribuido, y no todos ellos en forma! A veces se encontrará que sólo quieren buena
RPC pasada de moda.
56| Capítulo 4: Integración
Personalmente, soy un fan de la utilización enlaces para permitir a los consumidores
a navegar por los puntos finales de API. Los beneficios de descubrimiento progresivo
de la API y el acoplamiento puede ser reducida no puede signifi-. Sin embargo, está
claro que no todo el mundo se vende, ya que no veo que sea utilizado en cualquier
lugar cerca tanto como me gustaría. Creo que una gran parte de esto es que hay algo
de trabajo por adelantado inicial requerida, pero las recompensas a menudo vienen
después.
JSON, XML, o algo más?
El uso de formatos de texto estándar ofrece a sus clientes una gran flexibilidad en
cuanto a cómo mismos consumen recursos, y descansar sobre HTTP nos permite
utilizar una variedad de formatos. Los ejemplos que he dado hasta ahora utilizan
XML, pero en esta etapa, JSON es un mucho más popular tipo de contenido para
servicios que funcionan a través de HTTP.
El hecho de que JSON es un formato mucho más simple significa que el consumo es
también más fácil. Algunos defensores también citan su compacidad relativa en
comparación con XML como otro factor ganador, aunque esto no suele ser un
problema del mundo real.
JSON tiene algunas desventajas, sin embargo. XML define el control de enlace
utilizamos oído: Lier como control hipermedia. El estándar JSON no define nada
parecido, por lo que en la casa estilos se utilizan con frecuencia para calzador este
concepto. Lahipertexto Idioma de la aplicación (HAL) los intentos de solucionar este
problema mediante la definición de algunos SDRA Standards comunes para los
hipervínculos para JSON (XML y también, aunque sin duda XML necesita menos
ayuda). Si sigue la HAL estándar, puede utilizar herramientas como el navegador
HAL basado en la web para explorar controles hipermedia, que puede hacer la tarea
de crear un ent CLI- mucho más fácil.
No estamos limitados a estos dos formatos, por supuesto. Podemos enviar casi
cualquier cosa a través de HTTP, si queremos, incluso binario. Estoy viendo más y
más gente simplemente utilizando HTML como un formato en lugar de XML. Para
algunas interfaces, el HTML puede hacer una doble función como una interfaz de
usuario y una API, aunque hay trampas que hay que evitar aquí, ya que las
interacciones de un ser humano y una computadora son muy diferentes! Pero sin
duda es una idea atractiva. Hay un montón de programas de análisis de HTML por
ahí, después de todo.
Personalmente, sin embargo, todavía soy un fan de XML. Algunos de soporte de la
herramienta es mejor. Por ejemplo, si quiero extraer sólo ciertas partes de la carga
útil (una técnica que va a maldecir dis- más en“Versiones” en la página 62) Puedo
utilizar XPath, que es un estándar bien entendida con las porciones de soporte de
herramientas, o incluso los selectores CSS, que muchos encuentran IER incluso fácil. Con JSON, tengo JSONPATH, pero esto no es apoyado ampliamente. Me parece
extraño que la gente elige JSON porque es agradable y ligero, a continuación, tratar
RESTO | 57
de empujar los conceptos en él como controles hipermedia que ya existen en XML.
Acepto, sin embargo, que probablemente estoy en la minoría aquí y que JSON es el
formato de elección para la mayoría de la gente!
58| Capítulo 4: Integración
Cuidado con demasiada Conveniencia
Como el descanso se ha vuelto más popular, también lo han hecho los marcos que
nos ayudan a crear servicios web REST. Sin embargo, algunas de estas herramientas
de comercio fuera demasiado en términos de ganancia a corto plazo para el dolor a
largo plazo; al tratar de conseguir que ir rápido, pueden fomentara algunos malos
comportamientos. Por ejemplo, algunos marcos en realidad hacen que sea muy fácil
de tomar simplemente representaciones de base de datos de objetos, deserializar en
objetos en proceso, y luego se exponen directamente a éstos externamente. Recuerdo
que en una conferencia de ver esto demuestra usando la primavera de arranque y citó
como una de las principales ventajas. El acoplamiento inherente que esta
configuración promueve voluntad en la mayoría de los casos causa mucho más dolor
que el esfuerzo requerido para desacoplar adecuadamente estos conceptos.
Hay un problema más general en el juego aquí. Cómo decidimos para almacenar
nuestros datos, y cómo nos exponemos a nuestros consumidores, puede dominar
fácilmente nuestro pensamiento. Uno de los dibujos que vi utilizarse eficazmente por
uno de nuestros equipos fue para demorar la implementación de persistencia
apropiado para el microService, hasta que la interfaz se había estabilizado lo
suficiente. Durante un período transitorio, las entidades se acaba persistieron en un
archivo en el disco local, lo que obviamente no es una solución adecuada a largo
plazo. Esto aseguró que la forma en que los consumidores querían utilizar el servicio
condujo las decisiones de diseño e implementación. La razón dada, que se confirma
en los resultados, es que es demasiado fácil para la manera de almacenar las
entidades de dominio en un almacén de respaldo para influir abiertamente los
modelos que enviamos a través del cable a los colaboradores. Una de las desventajas
de este enfoque es que estamos aplazando el trabajo necesario para cablear nuestro
almacén de datos. Creo que para los nuevos límites del servicio, sin embargo, esto es
un compromiso aceptable.
Los inconvenientes se detuvo encima de HTTP
En términos de facilidad de consumo, no se puede generar fácilmente un resguardo
del cliente para su descanso sobre protocolo de aplicación HTTP como se hace con
RPC. Sin duda, el hecho de que HTTP está siendo utilizado significa que se llega a
tomar ventaja de todas las excelentes bibliotecas de cliente HTTP por ahí, pero si se
desea implementar y utilizar los controles de hipermedia como un cliente que está
bastante por su propia cuenta. En lo personal, creo que las bibliotecas de cliente
podrían hacer mucho mejor en esto que lo hacen, y son sin duda mejor ahora que en
el pasado, pero he visto este aparente aumento del resultado de la complejidad en las
personas recaídos en RPC contrabando a través de HTTP o bibliotecas de cliente de
construcción compartida. código compartido entre el cliente y el servidor puede ser
muy peligroso, como veremos en"SECO y el Los peligros de la reutilización de
código en un mundo Microservice”en la página 59.
Un punto más importancia es que algunos marcos de servidor web en realidad no
RESTO | 59
soportan bien todos los verbos HTTP. Eso significa que podría ser fácil para usted
para crear un controlador para peticiones GET o POST, pero puede que tenga que
pasar por el aro para conseguir poner o eliminar solicitudes para trabajar. marcos
descanso adecuado como Jersey no tienen este proble- ma, y que normalmente
pueden solucionar este problema, pero si usted está bloqueado en ciertas opciones de
trabajo marco esto podría limitar qué estilo de REST que puede utilizar.
60| Capítulo 4: Integración
El rendimiento también puede ser un problema. RESTO sobre cargas útiles HTTP en
realidad puede ser más compacto que el jabón porque es compatible con formatos
alternativos como JSON o incluso binario, pero todavía estará lejos de ser tan
delgado como un protocolo binario Thrift podría ser. La cabeza excesiva de HTTP
para cada solicitud también puede ser una preocupación para los requisitos de baja
latencia.
HTTP, mientras que puede ser adecuado también para grandes volúmenes de tráfico,
no es muy grande para las comunicaciones de baja latencia en comparación con los
protocolos alternativos que se construyen en la parte superior de Protocolo de
Control de Transmisión (TCP) u otra tecnología de red. A pesar del nombre,
WebSockets, por ejemplo, tiene muy poco que ver con la Web. Después del saludo
inicial de HTTP, que es sólo una conexión TCP entre el cliente y el servidor, pero
puede ser una manera mucho más eficiente para la emisión continua de datos para un
navegador. Si esto es algo que le interesa, tenga en cuenta que usted no está
realmente utilizando gran parte de HTTP, y mucho menos Any-que hay que hacer
con el descanso.
Para las comunicaciones de servidor a servidor, si una latencia extremadamente baja
o el tamaño pequeño mensaje es importante, las comunicaciones HTTP en general
puede no ser una buena idea. Es posible que necesite para recoger diferentes
protocolos subyacentes, como el Protocolo de datagramas de usuario (UDP), para
lograr el rendimiento que desea, y muchos marcos RPC felizmente ejecutar en la
parte superior de protocolos de red distintos de TCP.
El consumo de las cargas útiles a sí mismos requiere más trabajo que es
proporcionado por algunas implementaciones RPC que soportan los mecanismos de
serialización y deserialización avanzadas. Estos pueden convertirse en un punto de
acoplamiento por derecho propio entre cliente y servidor, como la aplicación de los
lectores tolerantes es una actividad trivial (hablaremos de esto en breve), pero desde
el punto de vista de levantarse y correr, que puede ser muy atractivo.
A pesar de estas desventajas, REST a través de HTTP es una opción por defecto
razonable para las interacciones servicio- a-servicio. Si quieres saber más,
recomiendoRESTO EN LA PRÁCTICA (O'Reilly), que cubre el tema de REST a
través de HTTP en profundidad.
La implementación asíncrona Colaboración basado en
eventos
Hemos hablado un poco acerca de algunas tecnologías que pueden ayudar a
implementar patrones de petición / respuesta. ¿Qué pasa con la comunicación
asíncrona basada en eventos?
opciones de tecnología
La implementación asíncrona colaboración basado en
eventos | 55
Hay dos partes principales que tenemos que considerar aquí: una manera para que
nuestros microservicios que emiten eventos, y una forma para que los consumidores
han sucedido nuestros para encontrar esos eventos.
Tradicionalmente, los intermediarios de mensajes como RabbitMQ tratan de manejar
ambos problemas. pro- ductores utilizan una API para publicar un evento para el
corredor. El agente se encarga de suscripciones, lo que permite a los consumidores a
ser informados cuando llega un evento. Estos corredores pueden incluso manejar el
estado de los consumidores, por ejemplo, ayudando a mantener un registro de qué
mensajes
56| Capítulo 4: Integración
que han visto antes. Estos sistemas están diseñados normalmente para ser escalable y
resil- ient, pero eso no viene de forma gratuita. Se puede añadir complejidad al
proceso de desarrollo, ya que es otro sistema puede que tenga que ejecutar para
desarrollar y probar sus servicios. máquinas y conocimientos adicionales también
pueden ser necesarios para mantener esta infraestructura en funcionamiento. Pero una
vez que lo hace, puede ser una manera muy eficaz para implementar arquitecturas
orientadas a eventos de forma flexible. En general, yo soy un fan.
No tener cuidado, sin embargo, sobre el mundo del middleware, de los cuales el
intermediario de mensajes es sólo una pequeña parte. Colas en sí mismas son útiles,
cosas perfectamente razonables. Sin embargo, los vendedores tienden a querer
empaquetar un montón de software con ellos, que pueden conducir a más y más
inteligencia siendo empujados hacia el middleware, como se evidencia por cosas
como el bus de servicios empresariales. Asegúrese de saber lo que está recibiendo:
mantener su middleware mudo, y mantener la inteligencia en los puntos finales.
Otro enfoque es tratar de utilizar HTTP como una forma de propagar eventos.
ATOM es una especificación REST-compatible que define la semántica (entre otras
cosas) para los piensos Lishing pu- de recursos. Existen muchas bibliotecas de cliente
que nos permitirá crear y consumen por estas fuentes. Por lo que nuestro servicio al
cliente sólo podría publicar un evento para tal alimentación cuando nuestros cambios
en el servicio al cliente. Nuestros consumidores simplemente sondean la
alimentación, en busca de cambios. Por un lado, el hecho de que podemos reutilizar
la especificación ATOM existente y las librerías asociadas es útil, y sabemos que
maneja HTTP escalar muy bien. Sin embargo, HTTP no es bueno a baja latencia
(donde algunos intermediarios de mensajes Excel), y todavía tenemos que lidiar con
el hecho de que los consumidores necesitan para realizar un seguimiento de lo que
los mensajes que han visto y gestionar su propio programa de sondeo.
He visto personas pasan la implementación de una edad cada vez más de los
comportamientos que se obtienen fuera de la caja con un intermediario de mensajes
adecuada para hacer el trabajo ATOM para algunos casos de uso. Por ejemplo, el
patrón del Consumidor Competir describe un método por el que abrir varias
instancias del trabajador para competir por los mensajes, que funciona bien para la
ampliación del número de trabajadores de manejar una lista de trabajos
independientes. Sin embargo, queremos evitar el caso de que dos o más trabajadores
ven el mismo men- saje, como vamos a terminar haciendo la misma tarea más de lo
que necesitamos. Con un intermediario de mensajes, una cola estándar se encargará
de esto. Con ATOM, ahora tenemos que gestionar nuestro propio estado compartida
entre todos los trabajadores para tratar de reducir las posibilidades de reproducción
de esfuerzo.
Si ya tiene una buena, intermediario de mensajes resistentes disponibles para usted,
considere usarlo para manejar la publicación y la suscripción a los eventos. Pero si
usted no tiene ya uno, dar ATOM un vistazo, pero estar al tanto de la falacia costo
hundido. Si usted se encuentra con ganas de más y más del apoyo que un
La implementación asíncrona colaboración basado en
eventos | 57
intermediario de mensajes le da, en cierto punto es posible que desee cambiar su
enfoque.
En términos de lo que en realidad enviar a través de estos protocolos asíncronos, las
mismas consideraciones se aplican al igual que con la comunicación sincrónica. Si
actualmente se encuentra feliz con las peticiones y las respuestas de codificación
utilizando JSON, palo con ella.
58| Capítulo 4: Integración
Complejidades de asincrónicos Arquitecturas
Algunas de estas cosas asíncrono parece divertido, ¿verdad? arquitecturas
controladas por eventos parecen conducir a sistemas significativamente más
desacoplados y escalables. Y que pueden. Pero estos estilos programa- ción conducen
a un aumento de la complejidad. Esto no es sólo la complejidad requerida para
gestionar la publicación y la suscripción a los mensajes que acabamos de discutir,
sino también en los otros problemas que podría enfrentar. Por ejemplo, cuando se
considera a largo corriendo petición asincrónico / respuesta, tenemos que pensar en
qué hacer cuando llega la respuesta. ¿Viene de nuevo al mismo nodo que inició la
solicitud? Si es así, ¿y si ese nodo está inactivo? Si no es así, ¿necesito para
almacenar información en algún lugar para que pueda actuar en consecuencia?
asíncrono de corta duración puede ser más fácil de manejar si usted tiene las API
adecuadas, pero aún así,
Hora para una advertencia. Ya en 2006, yo estaba trabajando en la construcción de un
sistema de fijación de precios para un banco. Miraríamos eventos del mercado, y
calcular con qué elementos en una cartera necesitaba ser repriced. Una vez que se
determinó la lista de cosas para trabajar a través, ponemos todos éstos en una cola de
mensajes. Estábamos haciendo uso de una rejilla para crear un grupo de trabajadores
de precios, lo que nos permite escalar hacia arriba y abajo de la granja de precios
bajo petición. Estos trabajadores utilizan el patrón de consumo que compiten, cada
uno engullendo mensajes tan rápido como sea posible hasta que no quedaba nada
para procesar.
El sistema estaba en funcionamiento, y que se sentía bastante presumida. Un día, sin
embargo, justo después de que empujó a cabo un comunicado, llegamos a un
problema desagradable. Nuestros trabajadores mantienen morir. Y muriendo. Y
muriendo.
Con el tiempo, nos ubicaron el problema. Un error en el que se había introducido un
cierto tipo de solicitud de fijación de precios haría que un trabajador se bloquee.
Estábamos usando una cola de transacción: como murió el trabajador, su cerradura de
la solicitud ha caducado, y la solicitud de fijación de precios se volvió a poner en la
cola sólo por otro trabajador para recogerlo y morir. Este fue un ejemplo clásico de lo
que Martin Fowler llama unaconmutación por error catastrófico.
Aparte del propio insecto, que había fallado para especificar un límite máximo de
reintentos para el trabajo en la cola. Hemos corregido el error en sí, y también
configurado un máximo de reintentos. Pero también nos dimos cuenta que
necesitábamos una manera de ver, y potencialmente jugar de nuevo, estos malos
mensajes. Terminamos tener que implementar un hospital mensaje (o cola de
mensajes), donde jes sabios fue expulsado si fallaban. También hemos creado una
interfaz de usuario para acceder a esos mensajes y vuelva a intentar si es necesario.
Este tipo de problemas no son inmediatamente obvias si sólo está familiarizado con
la comunicación sincrónica de punto a punto.
La implementación asíncrona colaboración basado en
eventos | 59
La complejidad asociados con las arquitecturas orientadas a eventos y programación asíncrona, en general, me lleva a creer que usted debe tener cuidado en la
forma de empezar con impaciencia la adopción de estas ideas. Asegúrese de que
tiene un buen seguimiento en su lugar, y considerar seriamente el uso de
identificadores de correlación, que le permite rastrear solicitudes a través de los
límites del proceso, ya que vamos a cubrir en profundidad enCapítulo 8.
60| Capítulo 4: Integración
También recomiendo encarecidamente patrones de integración empresarial (AddisonWesley), que contiene muchos más detalles sobre los diferentes patrones de
programación que puede que tenga que tener en cuenta en este espacio.
Servicios como Máquinas de Estado
Ya sea que elija para convertirse en un ninja REST, o un palo con un mecanismo
basado en RPC como el jabón, el concepto básico del servicio como una máquina de
estados es de gran alcance. Hemos hablado antes (probablemente hasta la saciedad
por este punto) sobre nuestros servicios siendo fash- ioned alrededor delimitada
contextos. Nuestra microService cliente posee toda la lógica asociada con el
comportamiento en este contexto.
Cuando un consumidor quiere cambiar un cliente, envía una solicitud apropiada para
el servicio al cliente. El servicio al cliente, sobre la base de su lógica, puede decidir si
acepta esa solicitud o no. Nuestro servicio al cliente controla todos los eventos del
ciclo de vida asociados con el propio cliente. Queremos evitar que los servicios
mudos, anémicos que son poco más que envoltorios CRUD. Si la decisión sobre lo
que se permite cambios a realizar a una fuga de clientes de la propia atención al
cliente, estamos perdiendo la cohesión.
Tener el ciclo de vida de los conceptos clave de dominio modelados de forma
explícita como este es muy poderoso. No sólo tenemos un lugar para hacer frente a
las colisiones de estado (por ejemplo, alguien que intenta actualizar un cliente que ya
ha sido eliminado), pero también tenemos un lugar para fijar el comportamiento
basado en los cambios de estado.
Todavía pienso que descansan sobre HTTP hace que para una integración mucho
más sensato tecnologıa que muchos otros, pero lo que sea que elija, mantener esta
idea en mente.
Extensiones reactivas
extensiones reactivas, A menudo abreviado como Rx, son un mecanismo para
componer los resultados de múltiples llamadas entre sí y ejecutar operaciones sobre
ellos. Las llamadas a sí mismos podrían estar bloqueando o sin bloqueo de llamadas.
En el fondo, Rx invierte flujos tradicionales. En lugar de pedir algunos datos, a
continuación, realizar operaciones en él, se observa el resultado de una operación (o
conjunto de operaciones) y reaccionar cuando algo cambia. Algunas
implementaciones de Rx le permiten realizar funciones de estos observables, tales
como RxJava, lo que permite que las funciones tradicionales como mapa o un filtro
para usarse.
Las diversas implementaciones Rx han encontrado un hogar muy feliz en siste- mas
distribuidos. Ellos nos permiten abstraer los detalles de cómo se hacen las llamadas,
y la razón de las cosas más fácilmente. Observo el resultado de una llamada a un
servicio de aguas abajo. No me importa si era una llamada de bloqueo o sin bloqueo,
La implementación asíncrona colaboración basado en
eventos | 61
sólo tiene que esperar por la respuesta y de reacción. La belleza es que puedo
componer varias llamadas en conjunto, por lo que el manejo de llamadas simultáneas
a los servicios de aguas abajo mucho más fácil.
62| Capítulo 4: Integración
A medida que se encuentra haciendo más llamadas de servicio, especailly al realizar
varias llamadas para realizar una sola operación, echar un vistazo a las extensiones
de reactivos para su pila tecnología elegida. Usted se sorprenderá de lo mucho más
simple su vida puede llegar a ser.
Seco y los peligros de la reutilización de código en un
mundo Microservice
Uno de los acrónimos nosotros los desarrolladores oye mucho es seco: No te repitas.
A pesar de su definición a veces se simplifica como tratando de evitar la duplicación
de código, DRY significa más precisión que queremos evitar la duplicación de
nuestro comportamiento del sistema y El conocimiento. Este es un consejo muy
sensible en general. Tener una gran cantidad de líneas de código que hacen lo mismo
que hace que su código base más grande de lo necesario, y por lo tanto más difícil de
razonar acerca. Cuando desee cambiar el comportamiento, y que el comportamiento
se repite en muchas partes de su sistema, es fácil olvidar todas partes que necesita
para hacer un cambio, que puede conducir a errores. Así, utilizando seco como un
mantra, en general, tiene sentido.
DRY es lo que nos lleva a crear código que puede ser reutilizado. Tiramos código
duplicado en abstracciones que entonces podemos llamar desde múltiples lugares.
Tal vez vamos tan lejos como MAK- ing una biblioteca compartida que se puede
utilizar en todas partes! Este enfoque, sin embargo, puede ser engañosamente
peligrosa en una arquitectura microService.
Una de las cosas que queremos evitar a toda costa es un acoplamiento excesivamente
microService y los consumidores de manera que cualquier pequeño cambio en la
propia microService puede causar cambios innecesarios para el consumidor. A veces,
sin embargo, el uso de código compartido puede crear este mismo acoplamiento. Por
ejemplo, a un cliente que tenía una biblioteca de objetos de dominio común que
representaban las entidades centrales en uso en nuestro sistema. Esta biblioteca fue
utilizada por todos los servicios que teníamos. Pero cuando se hizo un cambio a uno
de ellos, todos los servicios tenían que ser actualizado. Nuestro sistema comunica a
través de colas de mensajes, que también tenían que ser drenado de su contenido
ahora no válidas, y pobre del que si se le olvidó.
Si el uso de código compartido siempre se escapa fuera de su límite de servicio, que
ha introducido unas una forma potencial de acoplamiento. El uso de código común
como bibliotecas madereras está muy bien, ya que son conceptos internos que son
invisibles para el mundo exterior. RealEstate.com.au hace uso de una plantilla de
servicio a medida para ayudar a bootstrap creación de nuevos servicios. En lugar de
hacer este código compartido, la empresa lo copia para cada nuevo servicio para
asegurar que el acoplamiento no se escapa en.
Mi regla general: no violan DRY dentro de un microService, pero estar relajado en
violar seco a través de todos los servicios. Los males del exceso de acoplamiento
entre servi- cios son mucho peores que los problemas causados por la duplicación de
código. Hay un caso de uso específico vale la pena explorar más lejos, sin embargo.
bibliotecas de cliente
He hablado con más de un equipo que ha insistido en que la creación de bibliotecas
de cliente para sus servicios es una parte esencial de la creación de servicios en el
primer lugar. El argumento
Seco y los peligros de la reutilización de código en un mundo Microservice |
59
64| Capítulo 4: Integración
es que esto hace que sea fácil de usar su servicio, y evita la duplicación de código
necesario para consumir el servicio en sí.
El problema, por supuesto, es que si las mismas personas crean tanto la API de
servidor y el cliente API, existe el peligro de que la lógica que debe existir en el
servidor comienza a escaparse en el cliente. Que debo saber: He hecho esto por mí
mismo. La más lógica que se arrastra en la biblioteca de cliente, los más arranques de
cohesión a descomponer, y usted se encuentra ING hav- cambiar varios clientes a
desplegar correcciones a su servidor. También limitar las opciones tec- nología,
especialmente si el mandato de que la biblioteca cliente tiene que ser utilizado.
Un modelo para las bibliotecas de cliente que me gusta es el de Amazon Web
Services (AWS). El jabón o REST llamadas de servicio web subyacentes se pueden
hacer directamente, pero todos terminan usando sólo uno de los diversos kits de
desarrollo de software (SDK) que existen, que proporcionan abstracciones más de la
API subyacente. Estos SDK, sin embargo, son escritos por la comunidad o pueblo
AWS distintos de los que trabajan en la misma API. Este grado de separación parece
funcionar, y evita algunos de los problemas de las bibliotecas de cliente. Parte de la
razón por la que esto funciona tan bien es que el cliente tiene a su cargo cuando las
plumas HAP actualización. Si vas por el camino de Bibliotecas de cliente usted
mismo, asegúrese de que este es el caso.
Netflix en particular, pone especial énfasis en la biblioteca de cliente, pero me
preocupa que la gente ve que simplemente a través de la lente de evitar la duplicación
de código. De hecho, las bibliotecas ent CLI- utilizados por Netflix son tanto (si no
más) trata de garantizar la fiabilidad y escalabilidad de sus sistemas. Las bibliotecas
de cliente de Netflix manejan descubrimiento de servicios, modos de perecer; ure,
registro y otros aspectos que no son realmente acerca de la naturaleza del servicio en
sí. Sin estos clientes compartidos, sería difícil asegurar que cada pieza de
comunicaciones cliente / servidor se comportó bien en la escala masiva en la que ates
Netflix oper-. Su uso en Netflix sin duda ha hecho que sea fácil de poner en marcha y
una mayor productividad garantizando al mismo tiempo el sistema se comporta bien.
Sin embargo, accord- ing a por lo menos una persona en Netflix,
Si el enfoque de biblioteca cliente es algo que está pensando, puede ser importante
separar el código del cliente para manejar el protocolo de transporte subyacente, que
puede hacer frente a cosas como el descubrimiento de servicios y el fracaso, de lo
relacionado con el servicio de su destino en sí . Decidir si o no se va a insistir en la
biblioteca de cliente que se utiliza, o si lo permiten las personas que utilizan la
tecnología de pilas diferentes para realizar llamadas a la API subyacente. Y, por
último, nos aseguramos de que los clientes están a cargo de cuándo actualizar sus
bibliotecas de cliente: tenemos que asegurarnos de que mantenemos la capacidad de
liberar nuestros servicios de forma independiente el uno del otro!
El acceso de Referencia
60| Capítulo 4: Integración
Una consideración que quiero mencionar es cómo se pasa alrededor de la
información acerca de nuestras entidades de dominio. Necesitamos abrazar la idea de
que un microService abarcará el
ciclo de vida de nuestras entidades de dominio principales, como el Cliente. Ya
hemos hablado de la importancia de la lógica asociada con el cambio de
esteCliente que se celebra en el servicio al cliente, y que si queremos cambiar
lo que tenemos que emitir una solicitud al servicio al cliente. Pero también se
deduce que debemos tener en cuenta el servicio al cliente como la fuente de
la verdad paraClientes.
Cuando recuperamos un determinado Cliente recurso de la atención al cliente,
vamos a ver lo que parecía recursos cuando hicimos la petición. Es posible que
después de que habíamos pedido queCliente de recursos, algo más ha cambiado.
Lo que tenemos enefecto es un recuerdo de lo que el Cliente de recursos una
vez que parecía. Cuanto más tiempo nos aferramos a esta memoria, mayor
será la probabilidad de que esta memoria será falsa. Por supuesto, si evitamos
la solicitud de datos más que necesitamos, nuestros sistemas pueden llegar a
ser mucho más eficiente.
A veces esta memoria es lo suficientemente bueno. Otras veces lo que
necesita saber si ha cambiado. Así que si usted decide pasar alrededor de un
recuerdo de lo que una vez que una entidad parecía, asegúrese de que
también incluyen una referencia al recurso original, de modo que el nuevo
estado puede ser recuperada.
Vamos considere el ejemplo donde pedimos el servicio de correo electrónico para
enviar un correo electrónico cuando un pedido ha sido enviado. Ahora
podríamos enviar la solicitud al servicio de correo electrónico con los detalles
dirección de correo electrónico, el nombre y el pedido del cliente. Sin embargo, si
el servicio de correo electrónico esen realidad haciendo cola estas solicitudes, o
tirando de ellos de una cola, las cosas podrían cambiar en el ínterin. Podría
tener más sentido, envíanos un URI para elCliente y Orden recursos, y dejar
que el servidor de correo electrónico ir mirar hacia arriba cuando es el
momento de enviar el correo electrónico.
Una gran contrapunto a esto surge cuando consideramos la colaboración basada
en eventos. Con eventos, estamos diciendo que esto sucediera, pero necesitamos
saber lo que pasó. Si estamos recibiendo actualizaciones debido a unaCliente
cambio de recursos, por ejemplo, podría ser Val- uable para nosotros saber lo que
el Cliente que parecía que se produjo el evento. En tantocomo también obtener
una referencia a la propia entidad para que podamos mirar hacia arriba su
estado actual, entonces podemos obtener lo mejor de ambos mundos.
Hay otras soluciones de compromiso que se hizo aquí, por supuesto, cuando
estamos accediendo por referen- cia. Si siempre nos vamos a la atención al cliente
para mirar la información asociadacon un dado Cliente, La carga en el servicio
al cliente puede ser demasiado grande. Si nos pro- vide información
adicional cuando se recupere el recurso, que nos deja saber en qué momento
el recurso estaba en el estado dado y tal vez cuánto tiempo podemos
considerar
esta información para ser fresco, entonces podemos hacer mucho
62| Capítulo 4: Integración
con el almacenamiento en caché para reducir la carga . HTTP nosotros gran
parte de este apoyo da fuera de la caja con una amplia variedad de controles
de caché, algunos de los cuales hablaremos con más detalle enCapítulo 11.
Otro problema es que algunos de nuestros servicios que no necesite saber
sobre el conjunto Cliente recursos, y al insistir en que van búsquelo somos
potencialmente
El acceso de Referencia | 61
el aumento de acoplamiento. Se podría argumentar, por ejemplo, que nuestro servicio
de correo electrónico debe ser más tonto, y que sólo debe enviar la dirección de
correo electrónico y el nombre del al cliente central. No hay una regla dura y rápida
aquí, pero ser muy cuidadosos de que pasa alrededor de los datos en las solicitudes
cuando no conoce su frescura.
de versiones
En cada charla que he hecho sobre microservicios, me pregunta ¿cómo se hace de
versiones? La gente tiene la preocupación legítima de que, finalmente, van a tener
que realizar un cambio en la interfaz de un servicio, y quieren entender cómo
manejar eso. Vamos a romper el problema un poco y mirar a las diversas medidas
que podemos tomar para manejarlo.
Aplazar durante tanto tiempo como sea posible
La mejor manera de reducir el impacto de hacer cambios de última hora es evitar
hacerlas en el primer lugar. Se puede lograr mucho de esto tomando la tecnología de
integración de la derecha, como hemos discutido en este capítulo. la integración de
bases de datos es un gran ejemplo de tecnología que puede hacer que sea muy difícil
de evitar cambios de ruptura. REST, por el contrario, ayuda porque los cambios en
los detalles de implementación interna es menos probable que resulte en un cambio
en la interfaz de servicio.
Otra clave para el aplazamiento de un cambio importante es fomentar el buen
comportamiento de sus clientes y evitar dichas prácticas con demasiada fuerza
vinculante a sus servicios en el primer lugar. Vamos a considerar nuestro servicio de
correo electrónico, cuyo trabajo consiste en enviar correos electrónicos a nuestros
clientes de vez en cuando. Se pone pidió que enviara una orden de correo electrónico
enviado a los clientes con el ID 1234. Se apaga y recupera al cliente con ese ID, y
vuelve algo así como la respuesta se muestra en laEjemplo 4-3.
Ejemplo 4-3. Ejemplo de respuesta desde el servicio al cliente
<Cliente>
<Nombre>Sam</ Apellido>
<Apellido>Hombre nuevo</ Apellido>
<Correo electrónico>sam@magpiebrain.com</ Email>
<TelephoneNumber>555-1234-5678</ TelephoneNumber>
</ Cliente>
Ahora para enviar el correo electrónico, necesitamos sólo el nombre, apellido y
campos de correo electrónico. No necesitamos saber la telephoneNumber. Queremos
sacar simplemente aquellos campos que nos interesan, e ignorar el resto. Algunas
tecnologías de unión, especialmente la utilizada por idiomas inflexible, se puede
tratar de obligar a todos los campos si el consumidor los quiere o no. ¿Qué pasa si
nos damos cuenta de que nadie está utilizando el telephoneNumber y decidimos
62| Capítulo 4: Integración
quitarlo? Esto podría hacer que los consumidores se rompan innecesariamente.
de versiones | 63
Del mismo modo, lo que si queríamos para reestructurar nuestro objeto de atención al
cliente para que admita más detalles, tal vez añadiendo alguna otra estructura como
en Ejemplo 4-4? Los datos de nuestro servicio de correo electrónico que quiere es
todavía allí, y aún con el mismo nombre, pero si nuestro código hace suposiciones
muy explícitos en cuanto a donde se almacenarán el apellido y campos Apellidos,
entonces podría romper de nuevo. En este caso, se podría utilizar en su lugar XPath
para extraer los campos que nos interesan, que nos permite ser ambivalente acerca de
donde los campos son, siempre y cuando los podemos encontrar. Este patrón de la
implementación de un lector capaz de ignorar los cambios que no se preocupan por
lo que es-Martin Fowler llama unaLector tolerantes.
Ejemplo 4-4. Un recurso al cliente reestructurado: los datos están todavía allí, pero
nuestros consumidores puede encontrarlo?
<Cliente>
<Naming>
<Nombre>Sam</ Apellido>
<Apellido>Hombre nuevo</ Apellido>
<Apodo>Magpiebrain</ Apodo>
<Nombre completo>Sam "Magpiebrain" Newman</ Nombre completo>
</ Nombrando>
<Correo electrónico>sam@magpiebrain.com</ Email>
</ Cliente>
El ejemplo de un cliente tratando de ser lo más flexible posible en el consumo de un
servicio demuestra Postel de Ley (También conocido como el principio de robustez),
que establece: “Sea conservador en lo que hace, ser liberal en lo que acepta de otros”
El contexto inal orig- para esta pieza de sabiduría era la interacción de dispositivos a
través de redes, donde debe esperar todo tipo de cosas extrañas sucedan. En el
contexto de nuestra interacción petición / respuesta, nos puede llevar a hacer todo lo
posible para que el servicio que se consumen a cambios sin que nos obliga a cambiar.
Coger Breaking cambios tempranos
Sus crucial para asegurarse de que recoger los cambios que rompan los consumidores
tan pronto como sea posible, porque incluso si elegimos la mejor tecnología posible,
se rompe aún pueden ocurrir. Estoy muy a favor de la utilización de contratos
orientados al consumidor, lo que vamos a cubrir enCap- 7 ter, para ayudar a detectar
estos problemas desde el principio. Si usted está apoyando varias bibliotecas ent CLIdiferentes, la ejecución de pruebas utilizando cada biblioteca se apoya contra el
último Service es otra técnica que puede ayudar. Una vez que se da cuenta que se va
a romper un consumidor, usted tiene la opción de o bien tratar de evitar la ruptura por
completo o bien abrazarlo y comenzar a tener las conversaciones correctas con las
personas que cuidan de los servicios que consumen.
64| Capítulo 4: Integración
Uso semántico de versiones
no lo haría sería grande si como cliente usted podría mirar justo en el número de
versión de un ser- vicio y saber si se puede integrar con ella? semántica de versiones
es una especificación que permite precisamente eso. Con versiones semántica, cada
número de versión es en forma MAJOR.MINOR.PATCH. Cuando aumenta el
número MAJOR, significa que se han hecho cambios incompatibles atrasadas.
Cuando incrementos menores, nueva funcionalidad se ha añadido que debe ser
compatible con versiones anteriores. Por último, un cambio al parche de estados que
correcciones de errores han hecho a la funcionalidad existente.
A ver lo útil que puede ser de versiones semántica, vamos a ver un simple caso de
uso. Nuestra aplicación de servicio de asistencia está diseñado para trabajar en contra
de la versión 1.2.0 del servicio al cliente. Si se añade una nueva característica,
haciendo que el servicio al cliente para cambiar a 1.3.0, nuestra solicitud de
asistencia debe ver ningún cambio en el comportamiento y no se debe esperar para
hacer cualquier cambio. No podríamos garantizar que podríamos trabajar en contra
de la versión 1.1.0 del servicio al cliente central, sin embargo, como podemos
depender de mayor funcionalidad en la versión 1.2.0. También se puede esperar a
tener que realizar cambios en nuestra aplicación si una nueva 2.0.0 liberación de la
atención al cliente salga.
Usted puede decidir tener una versión semántica para el servicio, o incluso de un
punto final individual en un servicio si ellos coexisten como se detalla en la siguiente
sección.
Este esquema de versiones nos permite empacar una gran cantidad de información y
expectativas en tan sólo tres campos. La especificación completa describe en
términos muy sencillos los clientes pueden tener expectativas de cambios a estos
números, y pueden simplificar el proceso de com- carse sobre si los cambios deben
afectar a los consumidores. Por desgracia, no he ver este enfoque utilizado lo
suficiente en el contexto de los sistemas distribuidos.
Coexistir diferentes criterios de valoración
Si hemos hecho todo lo posible para evitar la introducción de un cambio en la
interfaz de ruptura, nuestra siguiente tarea es la de limitar el impacto. Lo que
queremos evitar está obligando a los consumidores a actualizar en el bloqueo de paso
con nosotros, ya que siempre queremos mantener la capacidad de liberar ces
microservi- de forma independiente el uno del otro. Uno de los enfoques que se han
utilizado con éxito para manejar esta situación es que coexistan ambas las viejas y
nuevas interfaces en el mismo servicio en ejecución. Así que si queremos conocer un
cambio importante, hacemos uso de una nueva versión del servicio que expone tanto
las viejas y nuevas versiones del punto final.
Esto nos permite obtener la nueva microService a cabo tan pronto como sea posible,
junto con la nueva interfaz, pero dar tiempo para que los consumidores se mueven
de versiones | 65
sobre. Una vez que todos los consumidores ya no están usando el viejo punto final,
puede eliminarlo junto con cualquier código asociado, como se muestra enFigura 4-5.
66| Capítulo 4: Integración
La Figura 4-5. Coexistencia diferentes versiones de punto final permite a los consumidores para
migrar gradualmente
La última vez que utiliza este enfoque, habíamos conseguido nosotros mismos en un
poco de un desastre con el número de consumidores que teníamos y el número de
cambios de última hora que habíamos hecho. Esto significaba que en realidad
estábamos coexistiendo tres versiones diferentes del punto final. Esto no es algo que
recomiendo! Manteniendo todo el código por todas partes y las pruebas, que se
requieren para asegurar que todo funcionaba era absolutamente una carga adicional.
Para que esto sea más manejable, que la transforman todas las peticiones al punto
final V1 a una solicitud V2, V2 y luego solicitudes a la variable V3. Esto significa
que podía delimitar claramente qué código iba a ser retirado cuando el viejo criterio
de valoración (s) murió.
Esta es, en efecto, un ejemplo del patrón de expandirse y contraerse, lo que permite a
la fase de romper los cambios en. Estamos ampliando las capacidades que ofrecemos,
el apoyo a las antiguas y nuevas formas de hacer algo. Una vez que los viejos
consumidores hacen las cosas en la nueva forma, contratamos nuestra API, la
eliminación de la funcionalidad de edad.
Si va a coexistir puntos finales, necesita una forma para que las personas que llaman
a sus peticiones de ruta en consecuencia. Para los sistemas que hacen uso de HTTP,
he visto este hecho con los dos números de versión en los encabezados de solicitud y
también en el mismo, por ejemplo, / v1 / cliente / o / v2 / cliente / URI. Estoy
dividida en cuanto a cuál es el enfoque que tiene más sentido. Por un lado, me gusta
URI siendo opaco para disuadir a los clientes de las plantillas hardcoding URI, pero
por otro lado, este enfoque no hacer las cosas muy evidente y puede simplificar la
solicitud de enrutamiento.
Para RPC, las cosas pueden ser un poco más complicado. He manejado esto con
de versiones | 67
tampones protocolo poniendo mis métodos en los diferentes espacios de nombres,
por ejemplo, v1.createCustomer y v2.createCustomer, pero cuando usted está
tratando de soportar diferentes versiones de los mismos tipos que se envían por la
red, esto puede llegar a ser muy doloroso .
68| Capítulo 4: Integración
El uso de múltiples versiones de servicio concurrentes
Otra solución de versiones a menudo citado es tener diferentes versiones del servicio
en vivo a la vez, y para los consumidores de más edad a la ruta su tráfico a la versión
anterior, con las nuevas versiones viendo la nueva, como se muestra en Figura 4-6.
Este es el enfoque utilizado de forma moderada, por Netflix en situaciones donde el
costo de cambiar consumidores de mayor edad es demasiado alto, especialmente en
los casos excepcionales en los dispositivos heredados todavía están vinculados a las
versiones anteriores de la API. Personalmente, no soy un fan de esta idea, y entiendo
por qué Netflix utiliza raramente. En primer lugar, si necesito para corregir un error
interno en mi servicio, ahora tengo que corregir y desplegar dos conjuntos diferentes de servicios. Esto probablemente significa que tenga que ramificar el código
base para mi servicio, y esto siempre es problemático. En segundo lugar, significa
que necesito inteligencia para manejar dirigir a los consumidores a la microService
derecha. Este comportamiento es inevitable que se sen- tado en algún lugar
intermedio o un montón de guiones nginx, haciendo más difícil a reason sobre el
comportamiento del sistema. Por último, considerar cualquier estado persistente de
nuestro servicio puede gestionar. Los clientes creados por cualquiera de las versiones
del servicio necesitan ser almacenados y se hace visible a todos los servicios,
independientemente de la versión utilizada para crear los datos en el primer lugar.
Esto puede ser una fuente adicional de complejidad.
Figura 4-6. La ejecución de varias versiones de un mismo servicio de apoyo a los puntos finales
de edad
La coexistencia de versiones concurrentes de servicios para un corto período de
tiempo puede hacer mucho sentido, sobre todo cuando estás haciendo las cosas como
las implementaciones azul / verde o lanzamientos de Canarias (vamos a estar
de versiones | 69
discutiendo estos patrones más en Capítulo 7). En estas situaciones, podemos estar
coexistiendo versiones sólo para unos pocos minutos o tal vez horas, y normalmente
sólo habrá dos versiones diferentes del servicio presentes al mismo tiempo. Cuanto
más tiempo se necesita para que usted obtenga los consumidores actualizado a la
versión más reciente y liberados,
70| Capítulo 4: Integración
cuanto más se debe buscar coexistir diferentes criterios de valoración de la misma
microService en lugar de coexistir versiones completamente distintas. Sigo sin estar
convencido de que este trabajo es la pena que el promedio de los proyectos.
Interfaces de usuario
Hasta ahora, no hemos tocado en el mundo de la interfaz de usuario. Algunos de
ustedes por ahí sólo podría ser proporcionar una API de frío, duro, clínica a sus
clientes, pero muchos de nosotros nos encontramos con ganas de crear interfaces de
usuario bellos y funcionales que harán las delicias de nuestros clientes. Pero
realmente necesitamos pensar en ellos en el contexto de la integración. La interfaz de
usuario, después de todo, es donde vamos a estar tirando todos estos ces microservijuntos en algo que tenga sentido para nuestros clientes.
En el pasado, cuando empecé la computación, que eran en su mayoría hablando de
grandes entos, CLI- grasa que se ejecutaban en nuestros escritorios. He pasado
muchas horas con motivo y luego salta tratando de hacer mi software tan agradable
de usar como sea posible. A menudo, estos sistemas eran sólo para la creación y
manipulación de archivos locales, pero muchos de ellos tenían un compo- nente del
lado del servidor. Mi primer trabajo en ThoughtWorks preveía la creación de un
sistema electrónico de punto-a base de oscilación de venta que era sólo una parte de
un gran número de piezas móviles, la mayoría de los cuales estaban en el servidor.
Luego vino la Web. Empezamos a pensar de nuestras interfaces de usuario como ser
delgado en vez, con más lógica en el lado del servidor. En el principio, nuestros
programas de servidor procesa la página entera y la enviaron al navegador del
cliente, lo que hizo muy poco. Cualquier interacciones fueron manejados en el lado
del servidor, a través de GET y POST desencadenados por el usuario haga clic en
enlaces o rellenar formularios. Con el tiempo, JavaScript convirtió en una opción
más popular para añadir comportamiento dinámico a la interfaz de usuario basada en
navegador, y algunas aplicaciones ahora podría argumentar que ser tan gordo como
los antiguos clientes de escritorio.
hacia digital
Durante el último par de años, las organizaciones han comenzado a moverse
lejos de pensar que web o móviles deben ser tratados de manera diferente; que
están pensando en su lugar tal DIGI- más integral. ¿Cuál es la mejor manera para
nuestros clientes a utilizar los servicios que ofrecemos? Y lo que hace eso a
nuestra arquitectura de sistema? El entendimiento de que no podemos predecir
exactamente cómo un cliente podría terminar interactuar con nuestra empresa ha
impulsado la adopción de las API más granulares, como los entregados por
microservicios. Al combinar las capacidades de nuestros servicios exponen en
diferentes formas, podemos comisariar diferentes experiencias para nuestros
clientes en su aplicación de escritorio, dispositivos móviles, weara- dispositivo
ble, o incluso en forma física si visitan nuestra tienda de ladrillo y mortero.
Interfaces de usuario |
67
Así que pensar en las interfaces de usuario como de composición capas lugares en los
que se entrelazan los distintos aspectos de las capacidades que ofrecemos. Así que
con eso en mente, ¿cómo podemos reunir todos estos aspectos juntos?
68| Capítulo 4: Integración
restricciones
Las restricciones son las diferentes formas en las que nuestros usuarios interactúan
con nuestro sistema. En una aplicación web de escritorio, por ejemplo, tenemos en
cuenta las limitaciones tales como lo que los visitantes del navegador están usando, o
su resolución. Pero móvil ha traído toda una serie de nuevas restricciones. La forma
en nuestras aplicaciones móviles se comunican con el servidor puede tener un
impacto. No se trata sólo de problemas de ancho de banda puros, donde las
limitaciones de las redes móviles pueden jugar un papel. Diferentes tipos de
interacciones pueden drenar vida de la batería, lo que lleva a algunos clientes
cruzadas.
La naturaleza de las interacciones cambia, también. No puedo fácilmente haga clic
derecho en una tableta. En un teléfono móvil, es posible que quiera diseñar mi
interfaz que se utiliza sobre todo con una sola mano, con la mayoría de las
operaciones están controladas por un pulgar. En otros lugares, podría permitir que las
personas interactúan con los servicios a través de SMS en lugares donde el ancho de
banda es un bien escaso, el uso de SMS como una interfaz es muy importante en los
países del sur, por ejemplo.
Entonces, A pesar de nuestros servicios de nuestra oferta básica-núcleo podría ser el
mismo, necesitamos una manera de adaptarlos a las diferentes limitaciones que
existen para cada tipo de interfaz. Cuando nos fijamos en los diferentes estilos de
composición interfaz de usuario, tenemos que asegurar que abordan este reto.
Veamos unos pocos modelos de interfaces de usuario para ver cómo esto podría
lograrse.
Composición API
Suponiendo que nuestros servicios ya hablan XML o JSON entre sí a través de
HTTP, una opción obvia disponible para nosotros es tener nuestra interfaz de usuario
interactúan directamente con estas API, como en Figura 4-7. Una interfaz de usuario
basada en la web podría usar JavaScript peticiones GET para recuperar datos, o las
peticiones POST para cambiarlo. Incluso para aplicaciones móviles nativas, iniciando
las comunicaciones HTTP es bastante sencillo. La interfaz de usuario necesitaría
entonces para crear los distintos componentes que conforman la interfaz, el manejo
de la sincronización de estado y similares con el servidor. Si estábamos usando un
protocolo binario para la comunicación de servicio a servicio, esto sería más difícil
para los clientes basados en la web, pero podría estar bien para dispositivos móviles
nativas.
Hay un par de inconvenientes con este enfoque. En primer lugar, tenemos poca
capacidad de ajustar el equilibrio respuestas para diferentes tipos de dispositivos. Por
ejemplo, cuando yo recuperar un registro al cliente central, qué tengo que tirar de
todos los mismos datos para una tienda de teléfonos móviles como hago para una
aplicación de servicio de ayuda? Una solución a este enfoque es que los
Interfaces de usuario |
69
consumidores puedan especificar qué campos de retirarse cuando lo soliciten, pero
esto supone que cada servicio es compatible con esta forma de interacción.
Otra cuestión clave: ¿quién crea la interfaz de usuario? Las personas que se ocupan
de los servicios se eliminan de la forma en que sus servicios son surgieron a los
usuarios, por ejemplo, si otro equipo está creando la interfaz de usuario, que podría
ser la deriva de nuevo en los viejos tiempos de
70| Capítulo 4: Integración
arquitectura en capas, donde haciendo que incluso pequeños cambios requiere
solicitudes de cambio a varios equipos.
La Figura 4-7. El uso de múltiples APIs para presentar una interfaz de usuario
Esta comunicación también podría ser bastante hablador. La apertura de un montón
de llamadas directamente a servi- cios puede ser bastante intensa para los
dispositivos móviles, y podría ser un uso muy ineficiente del plan de telefonía móvil
de un cliente! Tener una puerta de enlace API puede ayudar aquí, ya que podría
exponer a las llamadas que agregan múltiples llamadas subyacentes, a pesar de que
en sí mismo puede tener algunos inconvenientes que vamos a explorar en breve.
Composición UI Fragmento
En lugar de tener nuestra interfaz de usuario hacer llamadas a la API y mapa todo de
nuevo a controles de IU, podríamos tener nuestros servicios de partes de la interfaz
de usuario directamente, y luego simplemente tirar de estos fragmentos para crear
una interfaz de usuario, como en Figura 4-8. Imagínese, por ejemplo, que el servicio
de recomendación proporciona un widget recomendación que se combina con otros
controles o fragmentos de interfaz de usuario para crear una interfaz de usuario en
general. Puede ser que consiga mostrada como un cuadro en una página web, junto
con otros contenidos.
Una variación de este enfoque que puede trabajar bien es ensamblar una serie de
piezas de grano coarser- de una interfaz de usuario. Así que en lugar de crear
pequeños widgets, que está ensamblando paneles enteros de una aplicación de cliente
pesado, o tal vez un conjunto de páginas de un sitio web.
Estos fragmentos de grano más grueso se sirven de las aplicaciones de servidor que a
Interfaces de usuario |
71
su vez están haciendo las llamadas a la API apropiadas. Este modelo funciona mejor
cuando los fragmentos se alinean bien al equipo propiedad. Por ejemplo, tal vez el
equipo que se ocupa de la gestión de pedidos en la tienda de música sirve todas las
páginas asociadas a la gestión de pedidos.
72| Capítulo 4: Integración
La Figura 4-8. Los servicios directamente sirviendo componentes de interfaz de montaje
Todavía es necesario algún tipo de capa de ensamblaje para tirar de estas piezas
juntas. Esto podría ser tan simple como algunos de plantillas del lado del servidor, o,
en cada conjunto de páginas proviene de una aplicación diferente, tal vez usted va a
necesitar algo de enrutamiento inteligente URI.
Una de las principales ventajas de este enfoque es que el mismo equipo que realiza
cambios en los servicios también puede ser el encargado de realizar cambios en
aquellas partes de la interfaz de usuario. Esto nos permite obtener cambios más
rápidamente. Sin embargo, hay algunos problemas con este enfoque.
En primer lugar, garantizar la coherencia de la experiencia del usuario es algo que
tenemos que hacer frente. Los usuarios quieren tener una experiencia transparente, no
sentir que las diferentes partes de la obra interfase de diferentes maneras, o presentar
un lenguaje de diseño diferente. Hay ques técnicamente para evitar este problema, sin
embargo, como guías de estilo de vida, donde los activos como componentes HTML,
CSS y las imágenes se pueden compartir para ayudar a dar un cierto nivel de
consistencia.
Otro problema tomando es más difícil de tratar. ¿Qué ocurre con las aplicaciones
nativas o clientes pesados? No podemos servir a los componentes de interfaz de
usuario. Podríamos utilizar un enfoque híbrido y el uso de aplicaciones nativas para
servir a los componentes HTML, pero este enfoque ha demostrado una y otra vez a
tener inconvenientes. Así que si usted necesita una experiencia nativa, vamos a tener
que recurrir a un enfoque en la aplicación frontend hace llamadas a la API y se ocupa
de la propia interfaz de usuario. Pero incluso si tenemos en cuenta únicamente las
interfaces de usuario web, todavía puede querer muy diferentes tratamientos para
Interfaces de usuario |
73
diferentes tipos de dispositivos. La construcción de los componentes sensibles puede
ayudar, por supuesto.
74| Capítulo 4: Integración
Hay un problema fundamental con este enfoque que no estoy seguro puede ser
resuelto. Algunas veces las capacidades ofrecidas por un servicio no encajan
perfectamente en un widget o una página. Claro, yo podría querer recomendaciones
en un rectángulo en una página en nuestro sitio web, pero lo que si quiero tejer en las
recomendaciones dinámicos en otras partes de la superficie? Cuando busco, quiero
que el tipo delante para disparar automáticamente recomendaciones frescos, por
ejemplo. Cuanto más transversales de una forma de interacción es, menos probable
este modelo se ajusta y lo más probable es que vamos a caer de nuevo a sólo hacer
llamadas a la API.
Backends para Frontends
Una solución común al problema de interfaces hablador con servicios de backend, o
la necesidad de variar el contenido para diferentes tipos de dispositivos, es tener un
punto final de la agregación del lado del servidor, o puerta de enlace API. Esto puede
reunir varias llamadas de back-end, variar y agregación de contenido puerta si es
necesario para diferentes dispositivos, y servir para arriba, como vemos enFigura 4-9.
He visto este enfoque conduce a un desastre cuando estos criterios de valoración del
lado del servidor se convierten en capas gruesas con demasiada comportamiento.
Ellos terminan siendo gestionados por equipos independientes, y siendo otro lugar
donde la lógica tiene que cambiar cada vez que algunos cambios de funcionalidad.
Figura 4-9. El uso de una única pasarela monolítico para manejar las llamadas a / desde las
interfaces de usuario
Interfaces de usuario |
75
El problema que puede ocurrir es que normalmente tendremos una capa gigante para
todos nuestros servicios. Esto lleva a que todo ser lanzado en conjunto, y de repente
empezamos a perder el aislamiento de nuestras diversas interfaces de usuario, lo que
limita nuestra capacidad para liberarlos de forma independiente. Un modelo prefiero
y que yo he visto bien el trabajo es para restringir el uso de estos backends a una
interfaz de usuario o aplicación específica, como vemos enFigura 4-10.
Figura 4-10. Que utilizan terminales dedicados para interfaces
Este patrón se refiere a veces como backends para interfaces (BFFs). Permite que el
equipo se centra en cualquier interfaz de usuario dado para manejar también sus
propios componentes del lado del servidor. Se puede ver estos backends como partes
de la interfaz de usuario que le pasan a ser incorporados en el servidor. Algunos tipos
de interfaz de usuario pueden necesitar una huella mínima del lado del servidor,
mientras que otros pueden necesitar mucho más. Si necesita una capa de
autenticación y autorización de la API, esto puede sentarse entre nuestros mejores
amigos y nuestros interfaces de usuario. Vamos a explorar esto más enCapítulo 9.
El peligro de este enfoque es el mismo que con cualquier capa de agregación; se
puede tomar en la lógica no debería. La lógica de negocio para las diversas
capacidades de estos backends uso debe permanecer en los propios servicios. Estos
mejores amigos sólo deben contener CIFIC comportamiento espe- a ofrecer una
experiencia de usuario en particular.
76| Capítulo 4: Integración
Un enfoque híbrido
Muchos de las opciones antes mencionadas no tienen que ser de una talla única para
todos. Pude ver una organización adoptar el enfoque de reunión basada en
fragmentos para crear un sitio web, pero utilizando un enfoque backends fines de
interfaces cuando se trata de su aplicación móvil. El punto clave es que tenemos que
mantener la cohesión de las capacidades subyacentes que ofrecemos a nuestros
usuarios. Tenemos que asegurarnos de que la lógica asociada con el pedido de la
música o el cambio de los datos del cliente vidas dentro de los servicios que se
ocupan de esas operaciones, y no mancharse en todo nuestro sistema. Evitar la
trampa de poner demasiado el comportamiento en cualquier capa intermedia es un
acto de equilibrio delicado.
La integración con software de terceros
hemos mirado enfoques para romper los sistemas existentes, aparte de que están bajo
nuestro control, pero ¿qué pasa cuando no podemos cambiar las cosas que hablamos?
Por muchas razones válidas, las organizaciones para las que trabajamos compra de
software comercial off-the-shelf (COTS) o hacer uso de software como servicio
(SaaS) sobre los que tenemos poco control. Entonces, ¿cómo se integran con
sensatez?
Si usted está leyendo este libro, es probable que trabaja en una organización que
escribe el código. Es posible escribir software para sus propios fines internos o para
un cliente externo, o ambos. Sin embargo, incluso si usted es una organización con la
capacidad de crear una cantidad no puede signifi- de software a medida, podrás
seguir utilizando los productos de software que aporten las partes exter- nos, ya sea
comercial o de código abierto. ¿Por qué es esto?
En primer lugar, su organización es casi seguro que tiene una mayor demanda de
software que puede ser satisfecho internamente. Piense en todos los productos que
usa, desde herramientas de productividad de oficina como Excel de los sistemas
operativos a los sistemas de nómina. La creación de todos aquellos para su propio
uso sería una tarea gigantesca. En segundo lugar, y más importante, no sería rentable!
El costo para que usted construya su propio sistema de correo electrónico, por
ejemplo, es probable que empequeñecer el costo de utilizar una combinación
existente de servidor de correo y el cliente, incluso si vas para las opciones
comerciales.
Mi Los clientes a menudo luchan con la pregunta “¿Debo construir, o debería
comprar?” En ge- neral, el consejo que doy a mis colegas y al tener esta conversación
con la organización de la empresa promedios de edad se reduce a “Construir si es
aplicable sólo a lo que haces, y puede ser considerado un activo estratégico; comprar
si el uso de la herramienta no es tan especial “.
Por ejemplo, la organización promedio no consideraría su sistema de nómina para ser
un activo estratégico. La gente, en su conjunto se les paga el mismo en todo el
La integración con software de terceros | 73
mundo. Del mismo modo, la mayoría de las organizaciones tienden a comprar los
sistemas de gestión de contenidos (CMS de más) fuera de la plataforma, ya que su
uso de una herramienta de este tipo no se considera algo que es clave para su
negocio. Por otra parte, yo estaba involucrado desde el principio en la reconstrucción
de la página web de The Guardian, y me hicieron allí la decisión de construir un
sistema de gestión de contenidos a medida, ya que era central para el negocio del
periódico.
74| Capítulo 4: Integración
Así que la idea de que vamos a encontrar ocasionalmente comercial, software de
terceros es sensible, y para ser bienvenida. Sin embargo, muchos de nosotros
terminamos maldiciendo algunos de estos siste- mas. ¿Porqué es eso?
Falta de control
Uno de los retos asociados con la integración y que se extienden las capacidades de
los productos COTS como herramientas CMS o SaaS es que por lo general muchas
de las técnicas siones terio se han hecho para usted. ¿Cómo integra con la
herramienta? Esa es una decisión vendedor. ¿Qué lenguaje de programación se puede
utilizar para extender la herramienta? Hasta el vendedor. Se puede almacenar la
configuración para la herramienta de control de versiones, y reconstruir desde cero,
con el fin de permitir la integración continua de las personalizaciones? Depende de
las opciones del vendedor hace.
Si tiene suerte, lo fácil, o con problemas que es trabajar con la herramienta desde el
punto de vista del desarrollo ha sido considerado como parte del proceso de selección
de la herramienta. Pero incluso entonces, que están cediendo efectivamente cierto
nivel de control a un interlocutor externo. El truco es llevar la integración y
personalización de trabajo de nuevo en sus términos.
personalización
Muchos herramientas que las organizaciones empresariales compran venderse a sí
mismos en su capacidad de ser muy personalizada sólo para usted. ¡Tener cuidado! A
menudo, debido a la naturaleza de la cadena de herramientas tiene acceso a, el costo
de personalización puede ser más caro que construir algo desde cero a medida! Si
usted ha decidido comprar un producto, sino las capacidades particu- lar que ofrece
no es tan especial para usted, podría tener más sentido para cambiar el
funcionamiento de su organización en lugar de embarcarse en la personalización
compleja.
gestores de contenidos son un gran ejemplo de este peligro. He trabajado con varios
sistemas CMS que por su diseño no son compatibles con la integración continua, que
tienen torios API bles, y para el que incluso una actualización menor de punto en la
herramienta subyacente puede romper cualquier personalización que haya realizado.
Salesforce es especialmente problemático en este sentido. Durante muchos años se ha
llevado a su plataforma Force.com, que requiere el uso de un lenguaje de
programación, Apex, que sólo existe dentro del ecosistema Force.com!
La integración de los espaguetis
Otro desafío es cómo se integran con la herramienta. Como hemos comentado
anteriormente, promueva su cuidado acerca de cómo se integran entre los servicios es
importante, y lo ideal es que quieren estandarizar en un pequeño número de tipos de
integración. Pero si un producto decide utilizar un protocolo propietario binaria, otro
La integración con software de terceros | 75
poco de sabor de SOAP y XML-RPC otra, ¿qué queda? Peor aún son las
herramientas que le permiten
76| Capítulo 4: Integración
llegar a la derecha dentro de sus almacenes de datos subyacentes, lo que lleva a todos
los mismos problemas de acoplamiento que discutimos anteriormente.
En sus propios términos
COTS y productos SAAS absolutamente tienen su lugar, y no es factible (o Sensible) para la mayoría de nosotros para construir todo desde cero. Entonces, ¿cómo
resolver estos desafíos? La clave es mover las cosas de nuevo en sus propios
términos.
La idea central aquí es para hacer cualquier personalización en una plataforma a
controlar y limitar el número de consumidores diferentes de la propia herramienta.
Para explorar esta idea en detalle, vamos a ver un par de ejemplos.
Ejemplo: CMS como un servicio
En mi experiencia, el CMS es uno de los productos más utilizados que debe ser
personalizado o integrado con. La razón de esto es que a menos que desee un sitio
estático básico, la organización medio de las empresas quiere enriquecer la
funcionalidad de su sitio web con contenido dinámico, como registros de clientes o
de las últimas ofertas de productos. La fuente de este contenido dinámico es
típicamente otros servicios dentro de la organización, que en realidad se puede
mismo ha construido.
La tentación, y con frecuencia el punto de venta de la CMS-es que se puede
personalizar el CMS para tirar en todo este contenido especial y mostrarlo al mundo
exterior. SIN EMBARGO, el entorno de desarrollo para el promedio de la CMS es
terrible.
Vamos mirar lo que el promedio de CMS se especializa en, y lo que es probable
que lo compró por: creación de contenidos y la gestión de contenidos. La
mayoría de los sistemas CMS son bastante malos, incluso a hacer diseño de
página, generalmente proporcionando herramientas de arrastrar y soltar que no
cortan la mostaza. E incluso entonces, se termina la necesidad de tener a alguien
que entiende HTML y CSS para ajustar las plantillas CMS. Tienden a ser
terribles plataformas sobre las cuales construir un código personalizado.
¿La respuesta? Frente al CMS con su propio servicio que ofrece la página web con el
mundo exterior, como se muestra enFigura 4-11. El tratamiento de la CMS como un
servicio cuya función es permitir la creación y recuperación de contenido. En su
propio servicio, se escribe el código y la integración con los servicios de la forma que
desee. Usted tiene control sobre la ampliación del sitio web (muchos sistemas CMS
comerciales proporcionan sus propios patentados complementos para manejar la
carga), y se puede escoger el sistema de plantillas que tenga sentido.
La mayoría de los sistemas CMS también proporcionan API para permitir la creación
de contenidos, por lo que también tiene la capacidad de frente que con su propia
fachada servicio. Para algunas situaciones, incluso hemos utilizado una fachada tales
La integración con software de terceros | 77
abstraer a cabo las API para recuperar el contenido.
78| Capítulo 4: Integración
Figura 4-11. Ocultación de un CMS con su propio servicio
hemos se utiliza este patrón varias veces a través de ThoughtWorks en los últimos
años, y lo he hecho más de una vez a mí mismo. Un ejemplo notable fue un cliente
que estaba buscando para empujar a cabo un nuevo sitio web para sus productos.
Inicialmente, se quería construir toda la solución en el CMS, pero aún tenía que
elegir uno. En su lugar sugirió este enfoque, y comenzó el desarrollo de la página
web al frente. A la espera de la herramienta CMS para ser seleccionado, que fingí por
tener un servicio web que simplemente surgió contenido estático. Terminamos yendo
en vivo con el sitio del pozo antes de que el CMS fue seleccionado mediante el uso
de nuestro servicio de contenido falso en la producción a la superficie de contenido
para el sitio activo. Más tarde, hemos sido capaces de dejar caer simplemente en la
herramienta seleccionada finalmente sin ningún cambio en la aplicación al frente.
Usando este enfoque, mantenemos el alcance de lo que el CMS hace a un mínimo y
nos movemos personalizaciones en nuestra propia tecnología de pila.
Ejemplo: El sistema de CRM multirole
La relación de CRM o cliente Gestión-herramienta es una bestia a menudo
encontrados, que puede infundir miedo en el corazón de incluso el arquitecto más
resistentes. Este sector, como se tipifica por los vendedores como Salesforce o SAP,
está plagada de ejemplos de herramientas que tratan de hacer todo por ti. Esto puede
conducir a la propia herramienta convertirse en un punto único de fallo, y un nudo
enmarañado de dependencias. Muchas implementaciones de herramientas de CRM
que he visto son algunos de los mejores ejemplos de adhesivo (en oposición a
cohesivos) servicios.
El alcance de una herramienta de este tipo normalmente empieza pequeño, pero con
el tiempo se convierte en una parte cada vez más importantes de cómo funciona su
organización. El problema es que la direc- ción y se tomen decisiones en torno a este
sistema ahora vitales se hacen a menudo por el propio proveedor de herramientas, no
por usted.
La integración con software de terceros | 79
Yo estaba involucrado recientemente en un ejercicio para tratar de arrebatar algún
control posterior. La organiza- ción estaba trabajando con cuenta de que a pesar de
que estaba usando la herramienta de CRM para muchos
80| Capítulo 4: Integración
de las cosas, que no estaba recibiendo el valor de los crecientes costos asociados con
la plata- forma. Al mismo tiempo, múltiples sistemas internos estaban usando las API
de menos que ideales CRM para la integración. Queríamos mover la arquitectura del
sistema hacia un lugar donde tuvimos servicios que modelan nuestro dominio las
empresas, así como sentar las bases para una migración potencial.
Lo primero que hicimos fue identificar los conceptos básicos a nuestro dominio que
el sistema CRM actualmente propiedad. Uno de ellos fue el concepto de un proyecto,
es decir, algo a lo que se podría asignar un miembro del personal. Varios otros
sistemas necesitan la información del proyecto. Lo que hicimos fue crear un servicio
en lugar del proyecto. Este servicio de proyectos como los recursos REST expuesto,
y los sistemas externos se podía mover sus puntos de integración al nuevo, fácil-atrabajar-con el servicio. Internamente, el servicio del proyecto era sólo una fachada,
ocultando los detalles de la integración subyacente. Esto se puede ver enFigura 4-12.
Figura 4-12. El uso de servicios de fachada para enmascarar el CRM subyacente
La obra, que en el momento de escribir estas líneas aún estaba en curso, fue
identificar otros conceptos de dominio que el CRM se manejo, y crear más fachadas
para ellos. Cuando llegue el momento de la migración lejos de la CRM subyacente,
podríamos buscar en cada fachada a su vez para decidir si una solución de software
interno o algo fuera de la plataforma podrían ajustarse a la ley.
El patrón de estrangulador
Cuando se trata de legado o incluso plataformas COTS que no están totalmente bajo
nuestras posibilidades de control, también tenemos que hacer frente a lo que sucede
cuando queremos eliminarlos o al menos alejarse de ellos. Un modelo útil en este
caso es laDibujo Aplicación estrangulador. Al igual que con nuestro ejemplo de
frente al sistema de CMS con nuestro propio código, con un estrangulador permite
capturar y interceptar las llamadas al sistema antiguo. Esto le permite decidir si
enruta las llamadas a estos existente, el código heredado, o dirigirlos a nuevo código
que puede
La integración con software de terceros | 81
haber escritó. Esto le permite reemplazar la funcionalidad con el tiempo sin
necesidad de una gran reescritura explosión.
Cuando se trata de microservicios, en lugar de tener una sola aplicación monolítica
interceptar todas las llamadas al sistema heredado existente, es posible que en lugar
de utilizar una serie de microservicios para llevar a cabo esta intercepción. Capturar y
desviar las llamadas originales, pueden llegar a ser más compleja en esta situación, y
puede requerir el uso de un proxy para hacer esto para usted.
Resumen
hemos Miré a un número de diferentes opciones en la integración, y que he
compartido mis ideas sobre qué opciones tienen más probabilidades de asegurar que
nuestros microservicios permanecen como desacoplado como sea posible de sus
otros colaboradores:
• Evitar la integración de bases de datos a toda costa.
• Entender las ventajas y desventajas entre REST y RPC, pero considerar
seriamente RESTO como un buen punto de partida para la integración de
solicitud / respuesta.
• Prefiero coreografía sobre la orquestación.
• Evitar rompiendo los cambios y la necesidad de versión mediante la comprensión
de la ley de Postel y el uso de lectores tolerantes.
• Piense de interfaces de usuario como capas de composición.
Hemos cubierto mucho aquí, y no pudimos entrar en profundidad sobre todos estos
temas. No obstante, esto debería ser una buena base para que te vas y te orientará en
la dirección correcta si desea obtener más información.
Nosotros también pasó algún tiempo a la forma de trabajar con sistemas que no están
completamente bajo nuestro control en forma de productos COTS. Resulta que esta
descripción se puede aplicar con la misma facilidad con el software que escribimos!
Algunos de los enfoques descritos aquí se aplican igualmente bien al software
heredado, pero lo que si queremos hacer frente a la tarea a menudo-monumental de
llevar estos sistemas más antiguos hasta el talón y descomponerlos en partes más
usables? Discutiremos eso en detalle en el siguiente capítulo.
82| Capítulo 4: Integración
CAPÍTULO 5
La división de la Monolith
hemos discute lo que un buen servicio se parece, y por qué servidores más pequeños
puede ser mejor para nosotros. También hemos discutido anteriormente la
importancia de ser capaz de evolucionar el diseño de nuestros sistemas. Pero, ¿cómo
manejamos el hecho de que puede que ya tenga un gran nú- mero de bases de código
mentir acerca de que no siguen estos patrones? ¿Cómo hacemos para descomponer
estas aplicaciones monolíticas sin tener que embarcarse en una gran explosión
reescribir?
El monolito crece con el tiempo. Se adquiere nuevas funciones y líneas de código a
un ritmo alarmante. En poco tiempo se convierte en una gran presencia, miedo
gigante en nuestra organización que la gente tiene miedo de tocar o cambiar. ¡Pero no
todo está perdido! Con las herramientas adecuadas a nuestra disposición, podemos
matar a esta bestia.
Sus Todo sobre costuras
Nosotros discutido en Capítulo 3 que queremos que nuestros servicios sean altamente
cohesivo y débilmente acoplado. El problema con el monolito es que demasiado a
menudo es lo contrario de ambos. En lugar de tender hacia la cohesión, y mantener
las cosas juntas que tienden a cambiar juntos, adquirimos y mantenemos juntos todo
tipo de código no relacionado. Del mismo modo, la articulación flexible no existe
realmente: si quiero hacer un cambio a una línea de código, que puede ser capaz de
hacer eso con bastante facilidad, pero no se puede implementar ese cambio sin
afectar potencialmente gran parte del resto del monolito, y sin duda va a tener que
volver a implementar todo el sistema.
En su libro de trabajo efectivo con el código heredado (Prentice-Hall), Michael
plumas define el concepto de una costura, es decir, una parte del código que puede
ser tratado de forma aislada y trabajó en sin afectar al resto de la base de código.
También queremos identificar las costuras. Pero en lugar de la búsqueda de ellos con
79
el propósito de limpiar nuestra base de código-, queremos identificar las costuras que
pueden convertirse en los límites del servicio.
80| Capítulo 5: La división de la
Monolith
Entonces, ¿qué hace que una buena costura? Bueno, como hemos comentado
anteriormente, delimitada contextos son excelentes costuras, ya que, por definición,
que representan los límites de cohesión y, sin embargo débilmente acoplados en una
organización. Así que el primer paso es empezar a identificar estos límites en nuestro
código.
La mayoría de los lenguajes de programación proporcionan conceptos de espacio de
nombres que nos permiten agrupar código similar juntos. concepto de paquete de
Java es un ejemplo bastante débil, pero nos da mucho más de lo que necesitamos.
Todos los otros lenguajes de programación convencionales tienen conceptos
similares incorporados, con JavaScript siendo muy posiblemente una excepción.
Rompiendo Aparte MusicCorp
Imaginemos que tenemos un gran servicio monolítica back-end que representa una
cantidad sustancial del comportamiento de los sistemas en línea de MusicCorp. Para
empezar, hay que identificar el alto nivel acotado contextos que creemos que existen
en nuestra organización, ya que dis- cussed enCapítulo 3. A continuación, queremos
tratar de entender lo que limita los mapas contextos monolito a. Imaginemos que en
un principio identificamos cuatro contextos creemos que nuestra backend monolítica
cubre:
Catalogar
Todo lo relacionado con los metadatos de los artículos que ofrecemos a la venta
Financiar
Los informes de cuentas, pagos, devoluciones, etc.
Almacén
El envío y la devolución de pedidos de los clientes, la gestión de los niveles de inventario,
etc.
Recomendación
Nuestra patente pendiente, sistema de recomendación revolucionaria, que es el
código de gran complejidad escrita por un equipo con más doctores que el
laboratorio de la ciencia media
Lo primero que debe hacer es crear paquetes que representan estos contextos, y luego
pasar el código existente en ellos. Con entornos de desarrollo modernos, el
movimiento de código se puede hacer automática- mente a través de
refactorizaciones, y se puede hacer de forma incremental, mientras estamos haciendo
otras cosas. No obstante, deberá pruebas para detectar cualquier roturas hechas
moviendo el código, sin embargo, especialmente si está usando un lenguaje de tipos
dinámicos, donde los entornos de desarrollo tienen un tiempo más difícil de llevar a
cabo la refactorización. Con el tiempo, comenzamos a ver lo que el código quede
bien, y lo que queda de código una y realmente no encaja en cualquier lugar. Este
código restante a menudo identificar contextos acotados se pueden haber omitido!
81
Durante este proceso, podemos utilizar código para analizar las dependencias entre
estas edades PACK- también. Nuestro código debe representar a nuestra
organización, por lo que nuestros paquetes que representan los contextos acotadas en
nuestra organización deben interactuar de la misma manera los grupos de
organización de la vida real en nuestra interactúan dominio. Por ejemplo,
herramientas como la estructura 101 nos permiten ver las dependencias entre los
paquetes de forma gráfica. Si detectamos que las cosas
82| Capítulo 5: La división de la
Monolith
mira mal, por ejemplo, el paquete de almacén depende de código en el paquete de
financiación cuando no existe tal dependencia en la organización real, entonces
podemos investigar este problema y tratar de resolverlo.
Este proceso podría tomar una tarde en una pequeña base de código, o de varias
semanas o meses cuando se está tratando con millones de líneas de código. Puede
que no necesite para ordenar todo el código en paquetes orientado a dominio antes de
separarse a cabo su primer servicio, y de hecho puede ser más valioso para
concentrar sus esfuerzos en un solo lugar. No hay necesidad de que se trata de un
enfoque de la gran explosión. Es algo que se puede hacer poco a poco, día a día, y
tenemos una gran cantidad de herramientas a nuestra disposición para seguir nuestro
progreso.
Así que ahora que tenemos nuestro código base organizada en torno a estas costuras, ¿qué sigue?
Las razones para dividir el monolito
La decisión de que desea un servicio o aplicación monolítica a ser más pequeño es un
buen comienzo. Pero te recomiendo muchísimo a hacer mella a estos sistemas. Un
enfoque gradual le ayudará a aprender acerca microservicios a medida que avanza, y
también limitará el impacto de conseguir algo mal (y obtendrá cosas mal!). Pensar en
nuestro monolito como un bloque de mármol. Pudiéramos hacer volar todo el asunto,
pero que rara vez termina bien. Tiene mucho más sentido para simplemente hacer
mella en él de forma incremental.
Así que si vamos a romper el monolito una pieza a la vez, donde debemos empezar?
Tenemos nuestras costuras ahora, pero ¿cuál deberíamos sacar primero? Lo mejor es
pensar dónde va a obtener el mayor beneficio de alguna parte de su base de códigoser separados, en lugar de sólo cosas para dividir el bien de ella. Vamos a considerar
algunos conductores que podrían ayudar a guiar nuestro cincel.
Ritmo del cambio
Tal vez sabemos que tenemos una carga de cambios va a ser pronto en la forma de
gestionar el inventario. Si dividimos la costura de almacén como un servicio ahora,
podríamos cambiar que un servicio más rápido, ya que es una unidad autónoma
independiente.
Estructura de equipo
MusicCorp de equipo de entrega es en realidad dividida en dos regiones geográficas.
Un equipo está en Londres, y el otro en Hawai (algunas personas lo tienen fácil!).
Sería muy bueno si pudiéramos dividir el código que el equipo de Hawai trabaja en la
mayoría, por lo que puede tener la plena propiedad. Vamos a explorar esta idea aún
más enCapítulo 10.
Las razones para dividir el monolito | 81
Seguridad
MusicCorp ha tenido una auditoría de seguridad, y ha decidido reforzar su protección
de la información sensible. En la actualidad, todo esto es manejado por el código
relacionado con las finanzas. Si
82| Capítulo 5: La división de la
Monolith
Dividimos a cabo este servicio, podemos proporcionar protecciones adicionales a
este servicio individual en términos de vigilancia, protección de los datos en
tránsito, y la protección de datos en reposo ideas vamos a ver con más detalle en
Capítulo 9.
Tecnología
El equipo de cuidado de nuestro sistema de recomendación se ha Rematar algunos de
los nuevos algoritmos utilizando una biblioteca de programación lógica en el Clojure
lenguaje. El equipo piensa que esto podría beneficiar a nuestros clientes mediante la
mejora de lo que les ofrecemos. Si pudiéramos dividir el código de recomendación
en un servicio independiente, sería fácil de con- Sider la construcción de una
implementación alternativa que hemos podido probar en contra.
Enredado dependencias
El otro punto a tener en cuenta cuando se haya identificado un par de costuras para
separar es la forma enredada que el código es con el resto del sistema. Queremos
sacar la costura que está menos dependía de si podemos. Si puede ver las diferentes
costuras que ha encontrado como un grafo acíclico dirigido de dependencias (algo
que el paquete de herramientas de modelado que he mencionado anteriormente son
muy buenos), esto puede ayudar a detectar las costuras que probablemente van a ser
más difíciles de desenredar.
Esto nos lleva a lo que suele ser la madre de todas las dependencias enredadas: la base de datos.
La base de datos
Ya hemos discutido en detalle los retos de la utilización de bases de datos como
método de integración de múltiples servicios. Como ya he hecho bastante claro antes,
yo no soy un fan! Esto significa que tenemos que encontrar las costuras en nuestras
bases de datos también, así que podemos dividir a cabo limpiamente. Bases de datos,
sin embargo, son bestias difíciles.
Tener el control de la Problema
El primer paso es tomar un vistazo al código sí mismo y ver qué partes de ella leen y
escriben a partir de la base de datos. Una práctica común es tener una capa de
repositorio, respaldado por algún tipo de marco como Hibernate, para vincular a su
código a la base de datos, lo que facilita el mapa objetos o estructuras de datos hacia
y desde la base de datos. Si ha sido siguien- tes a lo largo hasta el momento, se le han
agrupado nuestro código en paquetes que representan nuestros contextos delimitadas;
queremos hacer lo mismo para nuestra base de datos de código de acceso. Esto puede
requerir la división hasta la capa de depósito en varias partes, como se muestra
enFigura 5-1.
Las razones para dividir el monolito | 83
La Figura 5-1. La división de nuestras capas de repositorio
Tener el código base de datos de mapeo colocated dentro del código para un
determinado contexto puede ayudarnos a comprender qué partes de la base de datos
son utilizados por qué bits de código. Hiber- nate, por ejemplo, puede hacer esto muy
claro si está utilizando algo así como un archivo de asignación por contexto acotado.
Esto no nos da toda la historia, sin embargo. Por ejemplo, podemos ser capaces de
decir que el código de finanzas utiliza la tabla del libro mayor, y que el código de
catálogo utiliza la tabla de partidas individuales, pero puede que no sea evidente que
la base de datos impone una relación de clave externa de la tabla de registro en que la
línea tabla de elementos. Para ver estas restricciones a nivel de base de datos, que
pueden ser un obstáculo, tenemos que utilizar otra herramienta para visualizar los
datos. Un gran lugar para comenzar es utilizar una herramienta como la libre
disposiciónSchemaSpy, Que puede generaciones representaciones gráficas erate de
las relaciones entre las tablas.
Todo esto ayuda a entender el acoplamiento entre las tablas que puede abarcar lo que
eventualmente se convertirá en los límites del servicio. Pero, ¿cómo cortar esos
lazos? Y ¿qué pasa con los casos en que se utilizan las mismas tablas de múltiples
contextos diferentes acotados? El manejo de problemas como estos no es fácil, y hay
muchas respuestas, pero es factible.
Volviendo a algunos ejemplos concretos, vamos a considerar nuestra tienda de
música de nuevo. Hemos identificado cuatro contextos acotados, y quiere seguir
adelante con haciéndolos cuatro, servicios que colaboran distintas. Vamos a mirar
algunos ejemplos concretos de los problemas que podría enfrentar, y sus posibles
soluciones. Y mientras que algunos de estos ejemplos hablar específicamente de los
problemas encontrados en ses databa- relacionales estándar, se encuentran problemas
similares en otras tiendas NoSQL alternativa.
Tener el control de la Problema | 83
Ejemplo: Rompiendo clave Exteriores Relaciones
En este ejemplo, nuestro código de catálogo utiliza una tabla de partidas individuales
genérico para almacenar información sobre un álbum. Nuestro código de finanzas
utiliza una tabla de libro de contabilidad para rastrear las transacciones financieras.
Al final de cada mes tenemos que generar informes de varias personas en la
organiza- ción para que puedan ver cómo lo estamos haciendo. Queremos hacer que
los informes agradable y fácil de leer, por lo que en lugar de decir, “Hemos vendido
400 copias de SKU 12345 e hicimos $ 1.300” nos gustaría añadir más información
acerca de lo que se vendió (es decir, “Hemos vendido 400 copias de los golpes más
grandes de Bruce Springsteen y el hecho $ 1.300” ). Para ello, nuestro código de
transmisión en el paquete de financiación llegará a la tabla de partidas individuales
para sacar el título para el SKU. También puede tener una restricción de clave
externa de la contabilidad a la tabla de partidas individuales, como vemos enFigura
5-2.
La Figura 5-2. relación de clave externa
Entonces, ¿cómo arreglar las cosas aquí? Bueno, tenemos que hacer un cambio
en dos lugares. En primer lugar, tenemos que dejar el código de finanzas de
alcanzar en la tabla de partidas individuales, como esta mesa pertenece realmente
al código de catálogo, y no queremos que la integración de bases de datos ocurre
una vez catalogar y las finanzas son los servicios en sus propios derechos. La
forma más rápida para hacer frente a esto es en lugar de tener el código en
finanzas llegar a la tabla de partidas individuales, vamos a exponer los datos a
través de una llamada a la API en el paquete de catálogo que el código de
finanzas puede llamar. Esta llamada a la API será el precursor de una llamada
haremos sobre el alambre, como vemos enFigura 5-3.
84| Capítulo 5: La división de la
Monolith
La Figura 5-3. la eliminación de puestos de la relación de clave externa
En este punto se hace evidente que bien podemos llegar a tener que hacer dos bases
de datos llama para generar el informe. Esto es correcto. Y lo mismo sucederá si se
trata de dos servicios por separado. Típicamente preocupaciones en torno a
rendimiento están levantadas. Tengo una respuesta bastante fácil de aquellos: ¿a qué
velocidad el sistema necesita ser? Y qué tan rápido está ahora? Si usted puede probar
su funcionamiento actual y saber qué buen rendimiento parece, entonces usted debe
tener confianza en hacer un cambio. A veces hacer una cosa más lenta, a cambio de
otras cosas es lo que hay que hacer, espe- cialmente si es más lenta todavía
perfectamente aceptable.
Pero ¿qué pasa con la relación de clave externa? Así, perdemos esta completo. Esto
se convierte en un obstáculo que necesitamos para gestionar ahora en nuestros
servicios resultantes en lugar de en el nivel de base de datos. Esto puede significar
que tenemos que aplicar nuestra propia verificación de consistencia a través de los
servicios, o bien activar acciones para limpiar los datos relacionados. Sea o no esto es
necesario a menudo no es la elección de un técnico para hacer. Por ejemplo, si
nuestro servicio de pedidos contiene una lista de ID para artículos del catálogo, lo
que sucede si se elimina un elemento de catálogo y una orden se refiere ahora a un
catálogo ID no válido? Debemos permitirlo? Si lo hacemos, entonces ¿cómo se
representa en el orden cuando se muestra? Si no lo hacemos, entonces ¿cómo
podemos comprobar que esto no es violada? Estas son preguntas que usted necesita
para obtener respuesta por las personas que definen cómo debe comportarse el
sistema para sus usuarios.
Ejemplo: compartido de datos estáticos
He visto quizás como muchos códigos de país almacenados en bases de datos (que se
muestra en Figura 5-4) Como he escrito StringUtils clases Java para proyectos
internos. Esto parece implicar que estamos pensando en cambiar los países de nuestro
sistema admite manera más frecuencia que desplegaremos nuevo código, pero
cualquiera que sea la verdadera razón, estos ejemplos de datos estáticos compartidos
se almacenan en bases de datos vienen un montón. Entonces, ¿qué es lo que hacemos
Ejemplo: compartido de datos
estáticos | 85
en nuestra tienda de música si todos nuestros servicios potenciales leen de la misma
tabla como ésta?
86| Capítulo 5: La división de la
Monolith
La Figura 5-4. Los códigos de país en la base de datos
Bueno, tenemos algunas opciones. Una de ellas es duplicar esta tabla para cada uno
de nuestros paquetes, con la visión a largo plazo que se duplicará dentro de cada
servicio también. Esto lleva a un desafío potencial consistencia, por supuesto: ¿qué
ocurre si actualizo una tabla para reflejar la creación de Newmantopia frente a la
costa este de Australia, pero no en otro?
Una segunda opción es tratar a este lugar, los datos estáticos compartidos como
código. Tal vez podría estar en un fichero propiedad desplegado como parte del
servicio, o tal vez sólo como una enumeración. Los problemas en torno a la
consistencia de los datos se mantienen, aunque la experiencia ha demostrado que es
mucho más fácil de empujar a cabo cambios a los archivos de configuración de
alterar tablas de bases de datos en vivo. Esto es a menudo un enfoque muy sensible.
Una tercera opción, que bien puede ser extrema, es empujar estos datos estáticos en
un servicio de su propio derecho. En un par de situaciones que he encontrado, el
volumen, la complejidad y las reglas asociadas con los datos de referencia estáticos
fueron suficientes que se justifica este enfoque, pero es algo excesivo si estamos
hablando de códigos de país!
Personalmente, en la mayoría de situaciones que iba a tratar de empujar para
mantener estos datos en los archivos de configuración o directamente en el código,
ya que es la opción simple para la mayoría de los casos.
Ejemplo: datos compartidos
Ahora vamos a bucear en un ejemplo más complejo, pero que puede ser un problema
común cuando se está tratando de separar los sistemas: compartían los datos
mutables. Nuestro código de seguimiento de las finanzas pagos realizados por los
clientes por sus órdenes, y también realiza un seguimiento reembolsos dados a ellos
cuando regresan artículos. Mientras tanto, el código de almacén actualiza los
registros para mostrar que los pedidos de los clientes se han enviado o recibido. Toda
esta información se visualiza en un lugar conveniente en el sitio web para que los
Ejemplo: compartido de datos
estáticos | 87
clientes puedan ver lo que está pasando con su cuenta. Para simplificar las cosas,
hemos almacenado toda esta informa- ción en una tabla de registro de cliente
bastante genérica, como se muestra enFigura 5-5.
88| Capítulo 5: La división de la
Monolith
Figura 5-5. Acceso a los datos del cliente: nos estamos perdiendo algo?
Por lo tanto la financiación y el código de almacén están escribiendo a, y,
probablemente, de vez en cuando la lectura de la misma mesa. ¿Cómo podemos
burlan de esto aparte? Lo que en realidad tenemos aquí es algo que se verá a menudo
un concepto de dominio que no se modela en el código, y de hecho es implícitamente
modelado en la base de datos. En este caso, el concepto de dominio que falta es el de
cliente.
Nosotros que tenga que hacer el concepto abstracto actual del hormigón cliente. Como
paso ent transición, creamos un nuevo paquete llamado de atención al cliente.
entonces podemos utilizar una API para exponer Código de cliente a otros paquetes,
como las finanzas o almacén. Rodando esto todo el camino a seguir, podemos ahora
terminar con un servicio al cliente distinta (Figura 5-6).
Figura 5-6. Reconocer el contexto acotado del cliente
Ejemplo: compartido Tablas
Figura 5-7 muestra nuestro último ejemplo. Nuestro catálogo tiene que almacenar el
nombre y el precio de los registros que vendemos, y el almacén tiene que mantener
un registro electrónico de inven- tario. Decidimos mantener estas dos cosas en el
mismo lugar en una tabla de partidas individuales genérico. Antes, con todo el código
se fusionaron en conjunto, no estaba claro que somos en realidad
Ejemplo: Tablas compartido | 87
90| Capítulo 5: La división de la
Monolith
conflating preocupaciones, pero ahora podemos ver que, de hecho, tenemos dos
conceptos diferentes que podrían ser almacenados de manera diferente.
La Figura 5-7. Mesas se comparten entre los diferentes contextos
La respuesta en este caso es la de dividir la tabla en dos, como tenemos en Figura 58, Tal vez la creación de una tabla de lista de acciones para el almacén, y una mesa de
entrada de catálogo para los detalles del catálogo.
Figura 5-8. Separando la mesa compartida
Bases de datos de refactorización
Lo que hemos cubierto en los ejemplos anteriores son unos refactorizaciones base de
datos que pueden ayudar a separar sus esquemas. Para una discusión más detallada
del tema, es posible que desee echar un vistazo a las bases de datos de refactoración
por Scott J. Ambler y Pramod
J. Sadalage (Addison-Wesley).
88| Capítulo 5: La división de la
Monolith
Puesta en escena de las vacaciones
Por lo que hemos encontrado en nuestra costuras código de la aplicación,
agrupándola contextos alrededor acotadas. Hemos utilizado este para identificar las
costuras en la base de datos, y lo hemos hecho todo lo posible para dividirlos uno.
¿Qué sigue? ¿Haces un comunicado de la gran explosión, yendo de un ser- vicio
monolítica con un único esquema a dos servicios, cada uno con su propio esquema?
De hecho, me recomienda dividir a cabo el esquema, pero mantener el servicio juntos
antes de split-ting el código de aplicación a cabo en microservicios separados, como
se muestra enFigura 5-9.
Figura 5-9. La organización de un servicio de separación
Con un esquema separado, estaremos aumentando potencialmente el número de bases
de datos llama a realizar una sola acción. Donde antes podríamos haber sido capaces
de tener todos los datos que queríamos en una sola instrucción SELECT, ahora es
posible que tenga que tirar de los datos de nuevo desde dos lugares y participar en la
memoria. Además, terminamos rompiendo la integridad transaccional cuando nos
movemos a dos esquemas, que podrían tener un impacto significativo en nuestras
aplica- ciones; vamos a estar discutiendo este lado. Al dividir los esquemas a cabo,
pero manteniendo el código de aplica- ción juntos, nos damos la posibilidad de
volver a nuestros cambios o continuar a modificar las cosas sin afectar a cualquier
consumidor de nuestro servicio. Una vez que estamos convencidos de que la
separación DB tiene sentido, entonces podemos pensar en dividir el código de aplicación en dos servicios.
Los límites transaccionales
Las transacciones son cosas útiles. Ellos nos permiten decir estos eventos ocurren o
bien todos juntos, o ninguno de ellos ocurren. Son muy útiles cuando estamos
insertar datos en una base de datos; nos dejaron actualizar varias mesas a la vez,
sabiendo que si algo falla, todo se deshace, lo que garantiza que nuestros datos no
Los límites transaccionales | 89
entrar en un estado incoherente. En pocas palabras, una transacción nos permite
agrupar múltiples actividades diferentes que
90| Capítulo 5: La división de la
Monolith
tomar nuestro sistema de un estado consistente a otro, todo funciona, o nada cambia.
Las transacciones no sólo se aplican a las bases de datos, a pesar de que más a
menudo los usamos en ese contexto. intermediarios de mensajes, por ejemplo, han
permitido por mucho tiempo le permite enviar y recibir mensajes dentro de las
transacciones también.
Con un esquema monolítico, todo nuestro crean o actualizaciones probablemente se
realizan dentro de un único límite transaccional. Cuando nos separamos nuestras
bases de datos, se pierde la seguridad que nos brinda por tener una sola transacción.
Consideremos un ejemplo simple en el contexto MusicCorp. Al crear una orden,
quiero actualizar la tabla de orden que indica que un pedido del cliente ha sido
creado, y también poner una entrada en una tabla para el equipo del almacén por lo
que sabe que hay un orden que tiene que ser recogido para su envío. Hemos llegado
tan lejos como la agrupación de nuestro código de la aplicación en paquetes
separados, y también hemos separado las partes del cliente y del almacén del
esquema lo suficientemente bien que estamos listos para ponerlos en sus propios
esquemas antes de separar el código de la aplicación.
En una sola transacción en nuestro esquema existente monolítica, la creación de la
orden e insertando el récord para el equipo del almacén se lleva a cabo en una sola
transacción, como se muestra en Figura 5-10.
Figura 5-10. Actualizar dos tablas en una sola transacción
Pero si hemos tirado aparte del esquema en dos esquemas distintos, uno para los
datos relacionados con el cliente, incluyendo nuestra tabla de orden, y otro para el
almacén, hemos perdido esta seguridad transaccional. El proceso de poner orden
ahora se extiende por dos límites cionales transac- separadas, como vemos enFigura
5-11. Si nuestra inserción en la tabla para falla, podemos detener claramente todo,
dejándonos en un estado coherente. ¿Pero qué sucede cuando la inserción en la tabla
fin funciona, pero la inserción en la tabla recogida de falla?
Los límites transaccionales | 91
Figura 5-11. Abarcando límites transaccionales para una sola operación
Inténtelo más tarde
El hecho de que la orden fue capturado y colocado podría ser suficiente para
nosotros, y podrá decidir que se vuelva a intentar la inserción en mesa de recogida
del almacén en una fecha posterior. Podríamos cola esta parte de la operación en una
cola o archivo de registro, y vuelve a intentarlo más tarde. Para algunos tipos de
operaciones de esto tiene sentido, pero tenemos que asumir que un reintento lo
arreglaría.
En muchos sentidos, esta es otra forma de lo que se llama consistencia eventual. En
lugar de utilizar un límite transaccional para asegurar que el sistema está en un estado
consistente cuando se complete la transacción, en vez aceptamos que el sistema
obtendrá sí mismo en un estado coherente en algún momento en el futuro. Este
enfoque es especialmente útil con las operaciones Ness Busi- que podrían ser de
larga duración. Vamos a discutir esta idea con mayor profundidad enCapítulo 11
cuando cubrimos los patrones de escala.
Abortar la operación entera
Otra opción es rechazar toda la operación. En este caso, tenemos que poner el sistema de nuevo en un estado coherente. La mesa de recogida es fácil, ya que la
inserción no, pero tenemos una transacción comprometida en la tabla de orden.
Necesitamos descansar esto. Lo que tenemos que hacer es emitir una transacción de
compensación, dando inicio a una nueva transacción, para cerrar de nuevo lo que
acaba de ocurrir. Para nosotros, eso podría ser algo tan simple como la emisión de
una instrucción DELETE para eliminar el orden de la base de datos. Entonces
también tendríamos que informar a través de la interfaz de usuario que ha fallado la
operación. Nuestra aplicación puede manejar ambos aspectos dentro de un sistema
monolítico, sino que había que tener en cuenta lo que podríamos hacer cuando nos
92| Capítulo 5: La división de la
Monolith
separamos el código de la aplicación. ¿La lógica para manejar la transac- ción de
compensación en vivo en el servicio al cliente, el servicio de orden, o en otro lugar?
Los límites transaccionales | 93
Pero, ¿qué ocurre si falla nuestra transacción de compensación? Es ciertamente
posible. Entonces tendríamos una orden en la tabla de orden con ninguna instrucción
de selección correspondiente. En esta situa- ción, que te sea necesario para volver a
intentar la operación de compensación, o permitir algún proceso en segundo plano
para limpiar la inconsistencia más adelante. Esto podría ser algo tan simple como una
pantalla de mantenimiento que el personal de administración tenía acceso a, o un
proceso automatizado.
Ahora piensa en lo que sucede si no tenemos uno o dos operaciones que queremos
ser coherentes, sino tres, cuatro, o cinco. Manejo de transacciones de compensación
para cada modo fail Ure se hace muy difícil de comprender, y mucho menos poner en
práctica.
Las transacciones distribuidas
Una alternativa a orquestando manualmente compensar transacciones es utilizar una
transacción buido dis-. Las transacciones distribuidas intentan abarcar varias
transacciones dentro de ellos con algún proceso general de gobierno llamado un
administrador de transacciones de orquestación dencia las diversas transacciones que
se realizan por los sistemas subyacentes. Al igual que con una operación normal, una
transacción distribuida intenta que todo permanece en un estado Consistente, sólo en
este caso se trata de hacerlo a través de múltiples sistemas diferentes Run-Ning en
diferentes procesos, a menudo la comunicación entre redes.
El algoritmo más común para el manejo de transacciones distribuidas, especialmente
a corto transacciones vivió, como en el caso del manejo de nuestros clientes de
pedidos es el uso de cometer un dos fases. Con una confirmación en dos fases,
primero viene la fase de votación. Aquí es donde cada participante (también llamado
una cohorte en este contexto) en la transacción distribuida dice el administrador de
transacciones si se piensa que su transacción local puede seguir adelante. Si el
administrador de transacciones consigue un voto a favor de todos los participantes,
entonces se dice que todos ellos van por delante y llevar a cabo sus confirmaciones.
Una sola sin voto es suficiente para que el administrador de transacciones para enviar
una reversión a todas las partes.
Este enfoque se basa en todas las partes que paran hasta que el proceso de
coordinación central les dice proceder. Esto significa que somos vulnerables a las
interrupciones. Si el administrador de transacciones disminuye, las transacciones
pendientes nunca es completa. Si una cohorte no responde de votación ing Du-, todo
lo bloquea. Y también está el caso de lo que sucede si una confirmación falla después
de votar. No es una suposición implícita en este algoritmo que esto no puede suceder:
si una cohorte dice sí durante el período de votación, entonces tenemos que asumir
que va a cometer. Cohortes necesitan una manera de hacer esta confirmación trabajo
en algún momento. Esto significa que este algoritmo no es infalible, sino que
simplemente trata de atrapar la mayoría de los casos de fracaso.
Este proceso de coordinación también significa cerraduras; es decir, las transacciones
pendientes pueden mantener bloqueos en los recursos. Cerraduras de recursos pueden
94| Capítulo 5: La división de la
Monolith
conducir a la contención, por lo que los sistemas de escala mucho más difícil,
especialmente en el contexto de los sistemas distribuidos.
Las transacciones distribuidas se han implementado para pilas de tecnología
específicos, como la API de transacciones de Java, permitiendo recursos dispares
como una base de datos y una cola de men- saje a todos participar en la misma
transacción, general. Los diversos algo-
Los límites transaccionales | 95
ritmos son difíciles de conseguir la derecha, por lo que te sugiero que evitar tratar de
crear su propia cuenta. En su lugar, hacer un montón de investigación sobre este
tema, si esto parece la ruta que desea tomar, y ver si se puede utilizar una
implementación existente.
¿Entonces lo que hay que hacer?
Todas estas soluciones añaden complejidad. Como se puede ver, las transacciones
distribuidas son difíciles de conseguir la derecha, y realmente puede inhibir la escala.
Los sistemas que finalmente convergen a través compensar la lógica de reintento
puede ser más difícil de razonar acerca, y es posible que otros comportamientos de
compensación para arreglar las inconsistencias en los datos.
Cuando se encuentre con las operaciones comerciales que existen actualmente en una
sola ción transac-, pregúntese si realmente necesitan. Pueden ocurrir en diferentes
transac- ciones locales, y se basan en el concepto de consistencia eventual? Estos
sistemas son mucho más fáciles de construir y la escala (discutiremos esto más
enCapítulo 11).
Si encuentra que el estado realmente quiere que se le mantenga constante, hacer todo
lo posible para evitar su división en el primer lugar. Tratar muy duro. Si realmente
necesita para seguir adelante con la separación, pensar en pasar de una visión
puramente técnica del pro- ceso (por ejemplo, una transacción de base de datos) y, de
hecho crear un concepto concreto para representar a la propia transacción. Esto le da
un mango o un gancho, en el que ejecutar otras aciones oper- como transacciones de
compensación, y una manera de controlar y gestionar estos conceptos más complejos
en su sistema. Por ejemplo, puede crear la idea de un “in- proceso del pedido” que le
da un lugar natural para centrar toda la lógica alrededor de procesar el pedido de
extremo a extremo (y tratar con excepciones).
informes
Como ya hemos visto, en la división de un servicio en partes más pequeñas,
necesitamos también potencial- mente dividido cómo y dónde se almacenan los
datos. Esto crea un problema, sin embargo, cuando se trata de un caso importante y
de uso común: la presentación de informes.
Un cambio en la arquitectura tan fundamental como la adopción de una arquitectura
microservicios hará que una gran cantidad de trastornos, pero no significa que
tengamos que abandonar todo lo que hacemos. La audiencia de nuestros sistemas de
información son usuarios como cualquier otra, y tenemos que tener en cuenta sus
necesidades. Sería arrogante para cambiar fundamentalmente nuestra arquitectura y
sólo pide que adaptarse. Aunque no estoy sugiriendo que el espacio de la
información no está maduro para la interrupción-sin duda es-hay valor en la
determinación de cómo trabajar con los procesos existentes en primer lugar. A veces
tenemos que escoger nuestras batallas.
informes | 93
La base de datos de informes
Informes normalmente necesita para agrupar los datos de juntas en varias partes de
nuestra organización con el fin de generar una salida útil. Por ejemplo, puede ser que
deseemos
94| Capítulo 5: La división de la
Monolith
enriquecer los datos de nuestro libro mayor con las descripciones de lo que se vendió,
que obtenemos de un catálogo. O es posible que desee ver en el comportamiento de
compra de los clientes específicos, de alto valor, lo que podría requerir información
de su historial de compras y su perfil de cliente.
En una arquitectura de servicio estándar, monolítico, todos nuestros datos se
almacenan en una Base de datos se grande. Esto significa que todos los datos están
en un solo lugar, por lo que la presentación de informes a través de toda la
información es en realidad bastante fácil, como se puede simplemente unirse a través
de los datos a través de consultas SQL o similares. Normalmente no vamos a ejecutar
estos informes en la base de datos principal, por temor a la carga gene- ado por
nuestras consultas que afectan el rendimiento del sistema principal, por lo que a
menudo estos sistemas de información colgar en una réplica de lectura como se
muestra enFigura 5-12.
Figura 5-12. la replicación de lectura estándar
Con este enfoque tenemos una boca que considerable todos los datos ya está en un
solo lugar, por lo que podemos utilizar herramientas bastante sencillas para consultar
la misma. Pero también hay un par de inconvenientes con este enfoque. En primer
lugar, el esquema de la base de datos es ahora efectivamente una API compartida
entre las que se ejecutan los servicios monolíticos y cualquier sistema de
información. Por lo que un cambio en el esquema tiene que ser cuidadosamente
administrado. En realidad, este es otro impedimento que reduce las posibilidades de
que cualquiera que desee asumir la tarea de hacer y coordinación NATing tal cambio.
En segundo lugar, hemos limitado las opciones en cuanto a cómo la base de datos
puede ser optimizado para el uso ya sea de casos y el respaldo del sistema en vivo o
el sistema de información. Algunas bases de datos nos permiten hacer optimizaciones
sobre réplicas de lectura para permitir más rápido, más eficiente de informes; por
ejemplo, MySQL nos permitiría correr un motor diferente que no tiene la sobrecarga
de gestión de transacciones. Sin embargo, no podemos estructurar los datos de
manera diferente a la notificación sea más rápido si ese cambio en la estructura de
datos tiene un impacto negativo en el sistema en funcionamiento. Lo que suele
ocurrir es que el esquema sea termina siendo grande para un caso de uso y pésimo
para el otro, o de lo contrario se convierte en el denominador común más bajo, ideal
informes | 95
para ni propósito.
Por último, las opciones de base de datos disponibles nos han explotado
recientemente. Mientras que las bases de datos relacionales estándar exponen
interfaces de consulta SQL que trabajan con muchas herramientas de información,
que no siempre son la mejor opción para el almacenamiento de datos para nuestros
servicios en ejecución.
96| Capítulo 5: La división de la
Monolith
¿Qué pasaría si nuestros datos de aplicación es mejor modelar como un gráfico,
como en Neo4j? ¿O si preferimos utilizar un almacén de documentos como
MongoDB? Del mismo modo, si lo que queríamos explorar el uso de una base de
datos orientada a columnas como Cassandra para nuestro sistema de información, lo
que hace que sea mucho más fácil de escalar para volúmenes mayores? Verse
limitados en la necesidad de tener una base de datos para ambos propósitos
resultados en nosotros a menudo no ser capaz de tomar estas decisiones y explorar
nuevas opciones.
Así que no es perfecto, pero funciona (en su mayoría). Ahora bien, si nuestra
información es almacenada en varios sistemas diferentes, ¿qué hacemos? ¿Hay una
manera de traer todos los datos juntos para hacer funcionar nuestros informes? Y
podríamos también, potencialmente, encontrar una manera de eliminar algunos de los
inconvenientes asociados con el modelo de base de datos de informes estándar?
Resulta que tenemos una serie de alternativas viables a este enfoque. ¿Qué solución
tiene más sentido para usted dependerá de varios factores, pero vamos a explorar
algunas opciones diferentes que he visto en la práctica.
Recuperación de datos a través de llamadas de servicio
Hay muchas variantes de este modelo, pero todos se basan en tirar los datos
necesarios de los sistemas de origen a través de llamadas a la API. Para un sistema de
información muy simple, como un tablero de salpicadero que es posible que quieran
mostrar el número de pedidos realizados en los últimos 15 minutos, esto podría estar
bien. Para informar a través de los datos de dos o más sistemas, es necesario realizar
varias llamadas para ensamblar estos datos.
Este enfoque se degrada rápidamente con los casos de uso que requieren grandes
volúmenes de datos, sin embargo. Imaginemos un caso de uso donde queremos
informar sobre el comportamiento de compra de los clientes de nuestra tienda de
música en los últimos 24 meses, mirando a diversas tendencias en el comportamiento
del cliente y cómo esto ha impactado en los ingresos. Tenemos que tirar de grandes
volúmenes de datos de los sistemas, al menos, del cliente y de finanzas. Mantener
una copia local de estos datos en el sistema de información es peligroso, ya que
puede que no sepamos si ha cambiado (datos tóricas incluso his- se pueden cambiar
después de los hechos), de modo de generar un informe preciso que necesitamos toda
la financiación y registros de clientes por los últimos dos años. Con aún modestos
fibras mero de clientes, se puede ver que esto rápidamente se convertirá en una
operación muy lenta.
Informando sistemas también a menudo confían en las herramientas de terceros que
se esperan para recuperar datos de una determinada manera, y aquí proporciona una
interfaz SQL es la forma más rápida de garantizar su cadena de herramienta de
informes es tan fácil de integrar con posible. Todavía podríamos utilizar este método
para extraer datos periódicamente en una base de datos SQL, por supuesto, pero esto
Recuperación de datos a través de las
llamadas al servicio | 95
todavía nos presenta algunos retos.
Uno de los retos principales es que las API expuestas por los diferentes
microservicios pueden no estar diseñados también para informar de casos de uso. Por
ejemplo, un servicio de atención al cliente puede permitir que encontremos un cliente
mediante un ID, o buscar un cliente por varios campos, pero no necesariamente
exponer una API para recuperar todos los clientes. Esto podría dar lugar a muchas
llamadas que se están realizando para recuperar todos los datos, por ejemplo, tener
que recorrer una lista
96| Capítulo 5: La división de la
Monolith
de todos los clientes, hacer una llamada por separado para cada uno. Esto no sólo
podría ser ineficiente para el sistema de información, que podría generar carga para
el servicio en cuestión también.
A pesar de que podría acelerar algunos de los recuperación de datos mediante la
adición de cabeceras de caché de los recursos expuestos por nuestro servicio, y tienen
estos datos en caché en algo así como un proxy inverso, la naturaleza de la
información es a menudo que se accede a la larga cola de datos. Esto significa que
muy bien podemos solicitar recursos que nadie ha solicitado otra cosa antes (o al
menos no por un tiempo suficientemente largo), lo que resulta en una pérdida de
caché potencialmente costosa.
Tú podría resolver este mediante la exposición de las API de lotes para la notificación
sea más fácil. Por ejemplo, nuestro servicio al cliente podría permitir que usted pase
una lista de los ID de cliente a ella para recuperarlos en lotes, o incluso puede
exponer una interfaz que le permite desplazarse por todos los clientes. Una versión
más extrema de este es el modelo de la solicitud por lotes como un recurso por
derecho propio. Por ejemplo, el servicio al cliente podría exponer algo así como un
criterio de valoración de recursos BatchCustomerExport. El sistema de llamada
podría publicar un BatchRequest, tal vez pasando en un lugar donde un archivo se
puede colocar con todos los datos. El servicio al cliente devolverá un código de
respuesta HTTP 202, lo que indica que la solicitud fue aceptada, pero aún no se ha
procesado. El sistema de llamada a continuación, podría sondear el recurso de espera
hasta que se recupera un estado 201 Creado, lo que indica que la solicitud se ha
cumplido, y luego el sistema de llamada podría ir a buscar los datos. Esto permitiría
potencialmente grandes archivos de datos a ser exportados sin el añadido de ser
enviado a través de HTTP; en cambio, el sistema podría simplemente guardar un
archivo CSV en una ubicación compartida.
He visto el enfoque anterior utilizado para la inserción lote de datos, en los que
funcionaba bien. Estoy menos a favor de ella para informar de sistemas, sin embargo,
ya que siento que hay otras soluciones, potencialmente más simples que pueden
escalar de manera más efectiva cuando estás oferta- ing con las necesidades de
información tradicionales.
Bombas de datos
En lugar de que el sistema de información tirar de los datos, en lugar podríamos tener
los datos llevados al sistema de información. Una de las desventajas de la
recuperación de los datos por Stan- dard HTTP llama es la sobrecarga de HTTP
cuando estamos haciendo un gran número de llamadas, junto con la sobrecarga de
tener que crear APIs que puedan existir sólo para fines informativos. Una opción
alternativa es tener un programa independiente que se accede directamente a la base
de datos del servicio que es la fuente de los datos, y la bombea a una base de datos de
informes, como se muestra enFigura 5-13.
Recuperación de datos a través de las
llamadas al servicio | 97
Figura 5-13. Utilizando una bomba de datos para empujar periódicamente datos a una base de
datos central de informes
A este punto se le dice, “Pero Sam, dijo que tener un montón de programas que
integran en la misma base de datos es una mala idea!” Al menos espero que se le dice
que, dada la firmeza con la que he señalado antes! Este enfoque, si se aplica
correctamente, es una notable excepción, donde las desventajas del acoplamiento
están más que mitigado haciendo que la presentación de informes más fácil.
A empezar, el bombeo de datos debe ser construido y gestionado por el mismo
equipo que gestiona el servicio. Esto puede ser algo tan simple como un programa de
línea de comandos activado a través de Cron. Este programa tiene que tener un
profundo conocimiento tanto de la base de datos final inter para el servicio, y
también el esquema de presentación de informes. El trabajo de la bomba es mapear
una de la otra. Tratamos de reducir los problemas de acoplamiento para el esquema
del servicio por tener el mismo equipo que gestiona el servicio también gestionar la
bomba. Yo sugeriría que, de hecho, que la versión de control de estos juntos, y tienen
construye de la bomba de datos creada como un artefacto adicional como parte de la
construcción del propio servicio, con la suposición de que cada vez que se
implementa una de ellas, se implementa los dos. Como hemos manifestado
explícitamente que hacemos uso de estos juntos,
El acoplamiento en el propio esquema de informes que queda, pero hay que tratarlo
como un API cado pu- que es difícil de cambiar. Algunas bases de datos nos dan
técnicas donde se puede mitigar aún más este costo.Figura 5-14 muestra un ejemplo
de esto para ses databa- relacionales, donde podríamos tener un esquema en la base
de datos de informes para cada servicio, utilizando cosas como vistas materializadas
para crear la vista agregada. De esa manera, exponer sólo el esquema de informes
para los datos de los clientes a la bomba de datos de clientes. Si esto es algo que se
puede hacer de una manera performante, sin embargo, dependerá de las capacidades
de la base de datos que eligió para la presentación de informes.
Las bombas de
datos | 97
Figura 5-14. La utilización de vistas materializadas para formar un solo esquema de informes
monolítica
Aquí, por supuesto, la complejidad de la integración es empujado más
profundamente en el esquema, y se apoyará en las capacidades de la base de datos
para hacer una configuración tal performant. Aunque creo que los datos de las
bombas en general son una sugerencia sensata y viable, estoy convencido de menos
confirma que la complejidad de un esquema segmentado es que vale la pena,
especialmente teniendo en cuenta los desafíos en la gestión del cambio en la base de
datos.
destinos alternativos
En un proyecto que estaba involucrada, se utilizó una serie de bombas de datos para
poblar archivos JSON en AWS S3, la utilización eficaz de S3 para hacerse pasar por
un mercado de datos gigante! Este enfoque ha funcionado muy bien hasta que
tuvimos que escalar nuestra solución, y en el momento de la escritura estamos
buscando para cambiar estas bombas para llenar su lugar un cubo que puede ser
integrado con herramientas de informes estándar como Excel y Tableau.
Bomba de datos de eventos
En Capítulo 4, Hemos tocado en la idea de microservicios emisores de eventos
basados en el cambio de estado de las entidades que gestionan. Por ejemplo, nuestro
servicio al cliente puede emitir un evento cuando se crea un cliente dado, o actualiza
o suprime. Para aquellos que exponen microservicios alimenta tal caso, tenemos la
opción de escribir nuestro propio suscriptor de eventos que bombea datos en la base
98| Capítulo 5: La división de la
Monolith
de datos de informes, como se muestra enFigura 5-15.
Las bombas de
datos | 99
Figura 5-15. Un conjunto de datos de eventos de la bomba con los eventos de cambio
de estado para poblar una base de datos de informes
El acoplamiento en la base de datos subyacente de la microService fuente está ahora
evitado. En su lugar, sólo estamos unión a los eventos emitidos por el servicio, que
están diseñados para ser expuesto a los consumidores externos. Dado que los eventos
son temporales en la naturaleza, sino que también hace que sea más fácil para
nosotros ser más inteligentes en lo que los datos que enviamos a nuestro almacén
central de informes; podemos enviar datos al sistema de información como vemos un
evento, lo que permite que los datos fluyan más rápidamente a nuestro sistema de
información, en lugar de confiar en un horario regular al igual que con la bomba de
datos.
Además, si almacenamos los eventos que ya han sido procesados, sólo podemos
procesar los nuevos eventos a medida que llegan, asumiendo las citas antiguas que ya
han sido asignadas en el sistema de información. Esto significa que nuestra inserción
será más eficiente, ya que sólo necesitamos enviar los deltas. Podemos hacer cosas
similares con una bomba de datos, pero tenemos que manejar esto por nosotros
mismos, mientras que la naturaleza fundamentalmente temporal de la corriente de
eventos (bolígrafos x HAP en fecha y hora y) nos ayuda en gran medida.
A medida que nuestra bomba de datos de eventos es menos acoplada a la parte
interna del servicio, sino que también es más fácil considerar esta siendo manejado
por un grupo separado del equipo de cuidado de la propia microService. Mientras la
naturaleza de nuestro flujo de sucesos no abonados excesivamente par a los cambios
en el servicio, este asignador de evento puede evolucionar de forma independiente
del servicio que se haya suscrito.
Las principales desventajas de este método son que toda la información requerida
debe ser transmitido como eventos, y no puede escalar, así como una bomba de datos
para grandes volúmenes de datos que tiene la ventaja de operar directamente en el
nivel de base de datos. No obstante, el acoplamiento flojo y datos más frescos
disponibles a través de un enfoque de este tipo hace que sea muy vale la pena
considerar si ya está exponiendo a los eventos apropiados.
Bomba de los datos de copia de seguridad
Esta opción se basa en un enfoque utilizado en Netflix, que se aprovecha de las
soluciones de copia de seguridad existen- tes y también resuelve algunos problemas
de escala que Netflix tiene que tratar. En cierto modo, se puede considerar esto como
un
dedeuna
bomba de datos, pero que pareció una solución muy
100| caso
Capítuloespecial
5: La división
la
interesante que merece la inclusión.
Monolith
Netflix ha decidido estandarizar Cassandra como el almacén de respaldo de sus
servicios, de los cuales hay muchos. Netflix ha invertido mucho tiempo en la
construcción de herramientas para
Bomba de los datos de copia de seguridad | 99
Cassandra hacer fácil trabajar con él, gran parte del cual la compañía ha compartido
con el resto del mundo a través de numerosos proyectos de código abierto.
Obviamente, es muy importante que las tiendas de Netflix datos se copian
correctamente. Para realizar una copia de seguridad de datos Cassandra, el enfoque
estándar es hacer una copia de los archivos de datos que respaldan y guardarlo en un
lugar seguro. tiendas de Netflix estos archivos, conocidos como SSTables, en el
almacén de objetos S3 de Amazon, que ofrece importantes garantías de durabilidad
de datos.
Netflix tiene que informar a través de todos estos datos, pero teniendo en cuenta la
escala involucrada esto es un desafío no trivial. Su enfoque es utilizar Hadoop que
utiliza copia de seguridad SSTable como la fuente de sus puestos de trabajo. Al final,
Netflix terminó la implementación de una tubería capaz de proceso- grandes
cantidades ing de datos utilizando este enfoque, que luego de código abierto como
elproyecto Egisto. Al igual que las bombas de datos, sin embargo, con este patrón
aún tenemos un acoplamiento a la presentación de informes de destino del esquema
(o sistema de destino).
Es concebible que el uso de un enfoque semejante, es decir, el uso de creadores de
mapas que trabajan fuera de las copias de seguridad funcionaría en otros contextos. Y
si usted ya está usando Cassan- dra, Netflix ya ha hecho gran parte del trabajo para
usted!
Hacia Tiempo real
Muchos de los patrones anteriormente descritos son diferentes maneras de conseguir
una gran cantidad de datos de muchos lugares diferentes para un mismo lugar. Pero
lo hace la idea de que todo nuestro será completado de un lugar realmente apilar
hasta más? Tenemos cuadros de mando, alertas, informes financieros, análisis -todos
los usuarios de estos casos de uso tienen diferentes niveles de tolerancia de precisión
y puntualidad, que pueden dar lugar a diferentes opciones técnicas que se apoya. A
medida que detallaremos enCapítulo 8, Nos estamos moviendo cada vez más hacia
los sistemas de concurso completo genéricos capaz de encaminar nuestros datos a
múltiples lugares diferentes dependiendo de la necesidad.
Costo de Cambio
Hay muchas razones por las que, a lo largo del libro, promover la necesidad de hacer
cambios pequeños y graduales, pero uno de los factores clave es comprender el
impacto de cada alteración que hacemos y cambiar de rumbo si es necesario. Esto
nos permite una mejor puerta mitiga el costo de los errores, pero no elimina la
posibilidad de errores en su totalidad. Podemos-y-a cometer errores, y que debemos
abrazar. Lo que también hay que hacer, sin embargo, es entender la mejor manera de
mitigar los costos de esos errores.
Como hemos visto, los costos involucrados en el movimiento de código por todas
100| Capítulo 5: La división de la
Monolith
partes dentro de una base de código es bastante pequeña. Tenemos un montón de
herramientas que nos apoyan, y si hacemos que un problema, la solución es generalmente rápida. Dividir además una base de datos, sin embargo, es mucho más
trabajo, y hacer retroceder un cambio de base de datos es tan compleja. Del mismo
modo, desenredar una inte- gración excesivamente acoplado entre servicios, o tener
que reescribir completamente un API que es utilizado por múltiples consumidores,
puede ser una tarea considerable. La gran coste de cambio significa que éstos
La comprensión de Causas | 101
las operaciones son cada vez más arriesgado. ¿Cómo podemos gestionar este riesgo?
Mi enfoque es tratar de cometer errores, donde el impacto será más bajo.
Que tienden a hacer la mayor parte de mi forma de pensar en el lugar donde el coste
del cambio y el costo de los errores es tan baja como puede ser: la pizarra. Esbozar el
diseño propuesto. Vea lo que sucede cuando se ejecuta casos de uso a través de lo
que usted piensa aries su servicio obligados- serán. Para nuestra tienda de música,
por ejemplo, imaginar lo que sucede cuando una al cliente central busca de un
registro, se registra en el sitio web, o compra un álbum. Lo que se envían las
llamadas? Qué se empiezan a ver las referencias circulares impares? ¿Ves dos
servicios que son demasiado hablador, lo que podría indicar que debería ser una
cosa?
Una gran técnica aquí es adaptar un enfoque más típicamente enseñado para el diseño
de sistemas orientados a objetos: Clase-responsabilidad-colaboración (CRC) tarjetas.
Con las tarjetas CRC, se escribe en una tarjeta de índice el nombre de la clase, lo que
sus responsabilidades son, y que colabora con. Cuando se trabaja a través de un
diseño propuesto, para cada ser- vicio enumero sus responsabilidades en cuanto a las
capacidades que ofrece, con los rators colabo- especificados en el diagrama. A
medida que trabaja a través de más casos de uso, se empieza a tener una idea de si
todo esto va unido correctamente.
Causas comprensión
Hemos hablado de cómo dividir los servicios aparte más grandes en otros más
pequeños, pero ¿por qué estos servicios crecer tanto en el primer lugar? Lo primero
que debe entender es que el crecimiento de un servicio hasta el punto que hay que
dividir es completamente bien. Queremos que la arquitectura de nuestro sistema
cambie con el tiempo en forma incremental. La clave es saber que necesita dividirse
antes de la división se vuelve demasiado caro.
Pero en la práctica muchos de nosotros hemos visto los servicios crecen mucho más
allá del punto de san- dad. A pesar de saber que un conjunto más pequeño de los
servicios sería más fácil de tratar que la enorme monstruosidad que tenemos
actualmente, todavía arar con el crecimiento de la bestia. ¿Por qué?
Parte del problema es saber por dónde empezar, y espero este capítulo tiene ped Hel-.
Sin embargo, otro reto es el costo asociado con la división a cabo los servicios.
Encontrar un lugar para ejecutar el servicio, haciendo girar una nueva pila de
servicio, etc., son tareas no triviales. Entonces, ¿cómo podemos abordar esto? Bueno,
si haciendo algo está bien, pero difícil, debemos esforzamos para facilitar las cosas.
La inversión en las bibliotecas y los marcos de servicios ligeros puede reducir el
costo asociado con la creación del nuevo servicio. Dando perso- PLE acceso a
máquinas virtuales de provisión de autoservicio o incluso hacer una plataforma como
servicio (PaaS) disponible, será más fácil a los sistemas de previsión y probarlos. A
lo largo del resto del libro, vamos a estar discutiendo una serie de maneras de ayudar
102| Capítulo 5: La división de la
Monolith
a mantener este costo.
La comprensión de Causas | 101
Resumen
Descomponemos nuestro sistema mediante la búsqueda de costuras a lo largo de la
cual los límites del servicio pueden surgir, y esto puede ser un enfoque incremental.
Al obtener buenos para encontrar estas costuras y trabajando para reducir el costo de
la división de servicios a cabo, en primer lugar, podemos continuar creciendo y
evolucionando nuestros sistemas para cumplir con lo requisitos vienen en el camino.
Como se puede ver, algunos de estos trabajos puede ser laborioso. Pero el mismo
hecho de que se puede hacer de forma incremental significa que no hay necesidad de
temer a este trabajo.
Así que ahora podemos dividir nuestros servicios, pero hemos introducido algunos
nuevos problemas también. Tenemos muchos más partes móviles que puedan entrar
en producción ahora! Así que la próxima arriba vamos a bucear en el mundo de la
implementación.
104| Capítulo 5: La división de la
Monolith
CAPÍTULO 6
Despliegue
La implementación de una aplicación monolítica es un proceso bastante sencillo.
Microservicios, con su interdependencia, son harina de otro costal por completo. Si
no se acercan a la derecha del despliegue, que es una de esas áreas en las que la
complejidad puede hacer de su vida una miseria. En este capítulo, vamos a ver
algunas técnicas y tecnologıa que nos puede ayudar a la hora de desplegar
microservicios en arquitecturas de grano fino.
Fueron va a comenzar, sin embargo, echando un vistazo a la integración continua
y la entrega continua. Estos conceptos relacionados, pero diferentes ayudarán a
dar forma a los otros las decisiones que va a hacer cuando se piensa en lo que
construir, cómo construirlo, y cómo implementarlo.
Una breve introducción a la integración continua
La integración continua (CI) ha existido durante varios años en este punto. Vale la
pena pasar un poco de tiempo a repasar los conceptos básicos, sin embargo, como
sobre todo cuando pensamos en el mapeo entre microservicios, construye y control
de versiones torios reposi-, hay algunas opciones diferentes a considerar.
Con CI, el objetivo principal es mantener a todos en sincronía con los demás, lo que
logramos, asegurándose de que recientemente revisado en código integra
adecuadamente con el código existente. Para ello, un servidor CI detecta que el
código ha sido cometido, comprueba hacia fuera, y car- Ries fuera algún tipo de
verificación como asegurarse de que el código se compila y que pasa las pruebas.
Como parte de este proceso, a menudo creamos artefacto (s) que se utilizan para su
posterior validación, tales como la implementación de un servicio en ejecución para
ejecutar las pruebas en contra de ella. Lo ideal es que queremos construir estos
artefactos una vez y sólo una vez, y utilizarlos para todas las implementaciones de
esa versión del código. Esto es con el fin de evitar hacer la misma cosa una y otra
vez, y así que podemos confirmar que el artefacto desplegamos es el que hemos
103
probado. Para habilitar estos
104 | Capítulo 6: Despliegue
artefactos para ser reutilizados, les colocamos en un repositorio de algún tipo, ya sea
proporcionado por la herramienta propia CI o en un sistema independiente.
Vamos a estar buscando en qué tipo de artefactos que podemos utilizar para
microservicios poco, y vamos a ver en profundidad en las pruebas de Capítulo 7.
CI tiene una serie de beneficios. Obtenemos un cierto nivel de respuesta rápida en
cuanto a la calidad de nuestro código. Que nos permite automatizar la creación de
nuestros artefactos binarios. Todo el código necesario para construir el artefacto es en
sí mismo el control de versiones, por lo que puede volver a crear el artefacto si es
necesario. También conseguimos un cierto nivel de trazabilidad de un artefacto
desplegado volver al código, y en función de las capacidades de la herramienta
propia CI, podemos ver qué pruebas se realizaron en el código y los artefactos
también. Es por estas razones que CI ha sido tan cessful Suc.
¿Usted está haciendo realmente?
Sospecho que probablemente está utilizando la integración continua en su propia
organización. Si no es así, usted debe comenzar. Es una práctica clave que nos
permite realizar cambios de forma rápida y sencilla, y sin el cual el viaje en
microservicios va a ser doloroso. Dicho esto, he trabajado con muchos equipos que, a
pesar de decir que hacen CI, son en realidad no hacerlo en absoluto. Ellos confunden
el uso de una herramienta de CI con la adopción de la práctica de la IC. La
herramienta es sólo algo que permite el enfoque.
Me gusta mucho Jez de Humble tres preguntas que hace la gente para poner a prueba
si realmente sub soporte lo CI es acerca de:
Cómo se comprueba en la línea principal de una vez al día?
Tú necesita asegurarse de que su código se integra. Si usted no marca su código
junto con los cambios de todos los demás con frecuencia, se termina haciendo
más difícil el futuro inte- gración. Incluso si está utilizando ramas de corta
duración para gestionar los cambios, integrar con tanta frecuencia como sea
posible en una sola rama de la línea principal.
¿Tiene una serie de pruebas para validar los cambios?
Sin pruebas, solo sabemos que sintácticamente nuestra integración ha
funcionado, pero no sabemos si hemos roto el comportamiento del sistema. CI
sin algún cación verificables que nuestro código se comporta como se esperaba,
no es CI.
Cuando la acumulación se rompe, es que la prioridad # 1 del equipo para solucionarlo?
Una acumulación verde que pasa significa que nuestros cambios se han integrado
de manera segura. Una acumulación rojo significa que el último cambio
posiblemente no integró. Tiene que dejar todo más check-ins que no están
involucrados en la fijación de las compilaciones conseguirlo pasa de nuevo. Si
deja que más cambios se acumulan, el tiempo que toma para fijar la acumulación
103
aumentará drásticamente. He trabajado con equipos en los que la acumulación se
ha roto durante días, dando lugar a un importante esfuerzo para obtener
finalmente una acumulación de paso.
104 | Capítulo 6: Despliegue
Mapeo de integración continua a microservicios
Al pensar en microservicios y la integración continua, tenemos que pensar en cómo
nuestra CI construye mapa para microservicios individuales. Como ya he dicho
muchas veces, queremos asegurarnos de que podemos hacer un cambio a un único
servicio y desplegarlo de forma independiente del resto. Con esto en mente, ¿cómo
debemos mapear ces microservi- individuales a CI construye y código fuente?
Si partimos de la opción más sencilla, podríamos agrupar todo en conjunto. Tenemos
un único repositorio, gigante almacenar todo nuestro código, y tienen una sola
estructura, como vemos enFigura 6-1. Los registros de entrada a este repositorio de
código fuente hará que nuestra estructura para desencadenar, donde vamos a ejecutar
todos los pasos de verificación asociados con todos nuestros microservicios, y
producir múltiples artefactos, todo ello vinculado de nuevo a la misma constitución.
La Figura 6-1. El uso de un único repositorio de código fuente y la acumulación de CI para todos
los microservicios
Esto parece mucho más simple en la superficie que otros enfoques: un menor número
de repositorios de qué preocuparse, y una estructura conceptualmente más simple.
Desde el punto de vista del desarrollador, las cosas son bastante sencillo también.
Acabo de comprobar el código. Si tengo que trabajar en varios servi- cios a la vez,
sólo tiene que preocuparse de una confirmación.
Este modelo puede funcionar perfectamente si se compra en la idea de comunicados
de bloqueo de paso, en la que no le importa la implementación de varios servicios a
la vez. En general, se trata de que sea absolutamente un patrón de evitar, pero muy
pronto en un proyecto, especialmente si sólo un equipo está trabajando en todo, esto
podría tener sentido para períodos cortos de tiempo.
Sin embargo, hay algunas desventajas importantes. Si hago un cambio de una línea
para un servicio de GLE pecado ejemplo, cambiar el comportamiento en el servicio
de usuario enFigura 6-1-todos los otros servicios Verifícate y construidos. Esto
podría tomar más tiempo de lo necesario-estoy esperando que las cosas que
probablemente no necesitan ser probados. Esto afecta nuestro tiempo de ciclo, la
velocidad a la que nos podemos mover un solo cambio del desarrollo para vivir. Más
Mapeo de integración continua a microservicios | 105
preocupante, sin embargo, es saber qué artefactos debe o no debe ser desplegada.
¿Busco ahora necesidad de desplegar todos los servicios de construcción para
empujar mi pequeño cambio en la producción? Puede ser difícil saber; tratar de
adivinar qué servicios realmente cambiaron la sola lectura de la
106 | Capítulo 6: Despliegue
los mensajes de confirmación es difícil. Las organizaciones que utilizan este enfoque
a menudo caen de nuevo a sólo distribuir todo junto, lo que realmente queremos
evitar.
Por otra parte, si mi cambio de una línea para el servicio de usuario rompe la
compilación, no hay otros cambios se pueden hacer a los otros servicios hasta que se
rompen es fijo. Y pensar en un escenario en el que tiene varios equipos de todos
compartir esta acumulación gigante. ¿Quién está a cargo?
Una variación de este enfoque es tener un árbol de origen individual con todo el
código en él, con múltiples CI construye mapeo de las partes de este árbol de origen,
como vemos en Figura 6-2. Con una estructura bien definida, se puede asignar
fácilmente las compilaciones a ciertas partes del árbol de fuentes. En general, yo no
soy un fan de este enfoque, ya que este modelo puede ser un arma de doble filo. Por
un lado, mi proceso de registro de entrada / salida puede ser más fácil ya que tengo
sólo un repositorio de qué preocuparse. Por otro lado, se hace muy fácil de conseguir
en el hábito de revisar en el código fuente para varios servicios a la vez, lo que puede
hacer que sea igual de fácil caer en hacer cambios que los servicios pareja juntos. Yo
preferiría en gran medida este enfoque, sin embargo, por tener una única
acumulación de múltiples servicios.
La Figura 6-2. Un repo fuente individual con subdirectorios asignada a independiente construye
Entonces, ¿hay otra alternativa? El enfoque que prefiero es tener una única
acumulación CI por microService, que nos permitirá realizar y validar un cambio
antes de su despliegue en producción rápidamente, como se muestra enFigura 6-3.
Aquí cada microService tiene su propio repositorio de código fuente, asignada a su
propio IC de construcción. Al hacer un cambio, corro solamente la construcción y las
pruebas que necesito. Me sale un solo artefacto de desplegar. La alineación al equipo
propietario-barco es más clara también. Si es el propietario del servicio, es el
propietario del repositorio y la construcción. Hacer cambios a través de los
repositorios pueden ser más difíciles en este mundo, pero me man- tener esto es más
fácil de resolver (por ejemplo, mediante el uso de secuencias de comandos de línea
de comandos) que el lado negativo de la fuente de control monolítico y construir
proceso.
Mapeo de integración continua a microservicios | 105
La Figura 6-3. Utilizando el código fuente de un depósito de acumulación y CI por microService
Las pruebas para un microService determinado deben vivir en el control de código
fuente con el código fuente de la microService también, para garantizar siempre
sabemos qué pruebas se deben ejecutar en contra de un determinado servicio.
Entonces, cada microService vivirá en su propio repositorio de código fuente, y su
propio proceso de acumulación de CI. Vamos a utilizar el proceso de construcción de
CI para crear nuestros artefactos desplegables también de una forma totalmente
automatizada. Ahora vamos a mirar más allá de CI para ver cómo continua la entrega
encaja.
Construir oleoductos y Entrega Continua
Muy desde el principio en el uso de la integración continua, nos dimos cuenta el valor
de veces tener múltiples etapas dentro de una generación. Las pruebas son un caso
muy común donde esto entra en juego. Puede que tenga una gran cantidad de pruebas
rápidas, con ámbito de pequeño, y un pequeño número de a gran con ámbito, las
pruebas lentas. Si corremos todas las pruebas juntas, es posible que no será capaz de
obtener rápidamente las tarifas reguladas atrás cuando nuestras pruebas rápidas fallan
si estamos a la espera de nuestras pruebas lentas-largas con ámbito para terminar
finalmente. Y si las pruebas rápidas fallan, probablemente no hay mucho sentido en
el funcionamiento de las pruebas más lento de todos modos! Una solución a este
problema es tener diferentes etapas de nuestra construcción, creat- ing lo que se
conoce como una tubería de construcción. Una etapa de las pruebas más rápidas, una
de las pruebas más lentas.
Este concepto de tuberías de construcción nos da una buena manera de rastrear el
progreso de nuestro software, ya que borra cada etapa, nos ayuda a dar una idea de la
calidad de nuestro software. Construimos nuestra artefacto, y que el artefacto se
utiliza en toda la tubería. A medida que nuestro artefacto se mueve a través de estas
etapas, nos sentimos cada vez más seguro de que el software funcionará en la
producción.
El suministro continuo (CD) se basa en este concepto, y algo más. Como se indica
en Jez Humble y Dave Farley del libro del mismo nombre, la administración
108 | Capítulo 6: Despliegue
continua es el método mediante el cual obtenemos una retroalimentación constante
sobre la disponibilidad de la producción de todas y cada registro de entrada, y
además tratar todos y cada registro de entrada como una versión candidata.
Construir oleoductos y entrega continua | 107
Para adoptar plenamente este concepto, tenemos que modelar todos los procesos
implicados en conseguir nuestro software desde la llegada hasta la producción, y
saber dónde cualquier versión del software es en términos de ser limpiado para su
liberación. En el CD, lo hacemos mediante la extensión de la idea de la tubería de
acumulación de varias etapas para modelar cada etapa de nuestro software tiene que
ir a través, tanto manuales como automatizados. EnFigura 6-4, Vemos una tubería de
muestra que puede ser familiar.
Figura 6-4. Un proceso estándar de liberación de modelado como una tubería de acumulación
Aquí queremos realmente una herramienta que abarca CD como un concepto de
primera clase. He visto a muchas personas tratan de cortar y extender herramientas
de CI para que lo hagan de CD, resultando a menudo en sistemas com- plejos que son
nada tan fácil de usar como herramientas que se acumulan en el CD de la
COMIENZO Ning. Herramientas que apoyan totalmente CD le permiten definir y
visualizar estas tuberías, modelando todo el camino a la producción para su software.
Como una versión de nuestro código se mueve a través de la tubería, si pasa una de
estas etapas de verificación automatizados que se mueve a la siguiente etapa. Otras
etapas pueden ser manuales. Por ejemplo, si tenemos un proceso de hombre-UAL
pruebas de aceptación del usuario (UAT) que debería ser capaz de utilizar una
herramienta de CD para modelarlo. Puedo ver la próxima construcción disponibles
listo para ser desplegado en nuestro entorno UAT, desplegarlo, y si pasa nuestras
comprobaciones manuales,
Al modelar todo el camino a la producción de nuestro software, mejoramos
enormemente La visibilidad de la calidad de nuestro software, y también puede
reducir en gran medida el tiempo necesario entre los comunicados, ya que tenemos
un lugar a observar nuestro proceso de acumulación y liberación, y una punto focal
evidente para introducir mejoras.
En un mundo microservicios, donde queremos asegurarnos de que podemos liberar
nuestros servicios de forma independiente el uno del otro, se deduce que al igual que
con IC, vamos a querer una tubería por servicio. En nuestras tuberías, es un artefacto
que queremos crear y moverse a través de nuestro camino hacia la producción. Como
siempre, resulta que nuestros artefactos pueden venir en muchos tamaños y formas.
Vamos a ver algunas de las opciones más comunes disponibles para nosotros en un
momento.
Y las excepciones inevitables
Al igual que con todas las buenas reglas, hay excepciones debemos tener en cuenta
también. El enfoque de “un servicio de micro por acumulación” es absolutamente
108 | Capítulo 6: Despliegue
algo que se debe apuntar para, pero hay momentos en los que algo más tiene sentido?
Cuando un equipo está empezando a cabo con un nuevo proyecto, especialmente un
Greenfield aquel en el que están trabajando con una hoja de papel en blanco, es muy
probable que habrá una gran cantidad de rotación en términos de trabajar a cabo en
los límites del servicio se encuentran. Esta es una buena razón, de hecho, para
mantener sus servicios iniciales en el lado más grande hasta su comprensión del
dominio estabiliza.
Construir oleoductos y entrega continua | 107
Durante este tiempo de rotación, cambios a través de los límites del servicio es más
probable, y lo que está o no en un determinado servicio puede cambiar con
frecuencia. Durante este período, tener todos los servicios en una sola estructura para
reducir el coste de los cambios cruzada de servicios puede tener sentido.
Que se sigue, sin embargo, que en este caso es necesario para comprar en la
liberación de todos los servicios como un paquete. También tiene absoluta necesidad
de ser un paso transitorio. Como API del servicio Estabilizante lize, que comenzará a
moverse hacia construye su propia cuenta. Si después de unas semanas (o un número
muy pequeño de meses) que no puede conseguir la estabilidad en los límites del
servicio con el fin de separar adecuadamente, fusionarlos de nuevo en un servicio
más monolítica (aunque conservando la separación modular dentro de los límites) y
dése tiempo para poder familiarizarse con el dominio. Esto refleja las experiencias de
nuestro propio equipo SnapCI, como hemos comentado enCapítulo 3.
Los artefactos Específicos de la Plataforma
La mayoría de las pilas de tecnología tienen algún tipo de artefacto de primera clase,
junto con herramientas para crear y SUP- puerto de instalarlos. Ruby tiene gemas,
Java tiene archivos JAR y los archivos WAR, y Python tiene huevos. Los
desarrolladores con experiencia en una de estas pilas estarán bien versados en el
trabajo con (y es de esperar la creación de) estos artefactos.
Desde el punto de vista de un microService, sin embargo, dependiendo de la
tecnología de pila, este artefacto puede no ser suficiente por sí mismo. Mientras que
un archivo JAR de Java puede ser hecho para ser ejecutable y ejecutar un proceso de
HTTP integrado, para cosas como las aplicaciones Ruby y Python, que se puede
esperar de utilizar un gestor de procesos se ejecuta dentro de Apache o Nginx. Así
que es posible que tengamos alguna forma de instalar y configurar otro software que
necesitamos con el fin de implementar y poner en marcha nuestros artefactos. Aquí
es donde las herramientas automatizadas de gestión de configuración, como la
marioneta y el chef puede ayudar.
Otra pega aquí es que estos artefactos son específicas para un determinado conjunto
de tecnología, lo que puede hacer el despliegue más difícil cuando tenemos una
combinación de tecnologías en el juego. Piense en ello desde el punto de vista de
alguien que trata de implementar varios servicios juntos. Podrían ser un desarrollador
o un probador con ganas de probar algunas funciones, o podría ser alguien
administrar una implementación de producción. Ahora imagina que esos servi- cios
utilizan tres mecanismos de despliegue completamente diferentes. Tal vez tenemos
una gema de rubíes, un archivo JAR, y un paquete nodejs NGP. Iban a darle las
gracias?
La automatización puede recorrer un largo camino para ocultar las diferencias en los
mecanismos de despliegue de los artefactos subyacentes. Cocinero, de marionetas, y
Ansible todo el apoyo múl- tiples diferentes comunes específicos de tecnología de
110 | Capítulo 6: Despliegue
construcción artefactos también. Pero hay diferentes tipos de artefactos que podrían
ser aún más fácil trabajar con ellos.
Específicos de la Plataforma
Artefactos | 109
Los artefactos del sistema operativo
Una forma de evitar los problemas asociados con artefactos específicos de tecnología
consiste en CRE comió artefactos que son nativas del sistema operativo subyacente.
Por ejemplo, para un sistema basado en CentOS o RedHat-, podría construir RPM;
para Ubuntu, podría construir un paquete deb; o para Windows, un MSI.
La ventaja de usar artefactos específicos de OS es que desde el punto de vista de
implementación no nos importa lo que la tecnología subyacente es. Sólo tiene que
utilizar el nativo de herramientas para el sistema operativo para instalar el paquete.
Las herramientas del sistema operativo también nos puede ayudar a desinstalar y
obtener información sobre los paquetes también, e incluso pueden proporcionar
depósitos de paquetes que nuestras herramientas de CI puede empujar a. Gran parte
del trabajo realizado por el gestor de paquetes de sistema operativo también podrá
utilizarse para compensar el trabajo que de otro modo podrían hacer en una
herramienta como la marioneta o cocinero. En todas las plataformas Linux que he
utilizado, por ejemplo, se pueden definir las dependencias de los paquetes a otros
paquetes en las que confía, y las herramientas del sistema operativo se instalará
automáticamente para usted también.
La desventaja puede ser la dificultad en la creación de los paquetes en el primer
lugar. Para Linux, elherramienta de gestor de paquetes FPM da una abstracción más
agradable para la creación de paquetes del sistema operativo Linux, y la conversión
de una implementación basada en archivo comprimido a una implementación basada
en sistema operativo puede ser bastante sencillo. El espacio de Windows es algo más
complicado. El sistema de envasado nativa en forma de instaladores MSI y similares
dejan mucho que desear en comparación con las capacidades en el espacio Linux. El
sistema de paquetes NuGet ha comenzado a ayudar a resolver esto, al menos en
términos de ayudar a gestionar las librerías de desa- rrollo. Más recientemente, se ha
extendido Chocolatey NuGet estas ideas, que proporciona un gestor de paquetes para
Windows diseñado para la implementación de herramientas y servicios, lo cual es
mucho más parecido a los gestores de paquetes en el espacio Linux. Este es sin duda
un paso en la dirección correcta,
Otra desventaja, por supuesto, podría ser si va a implementar en múltiples sistemas
operativos diferentes. La sobrecarga de administración de artefactos para diferentes
sistemas operativos podría ser bastante elevado. Si va a crear software para otras
personas para su instalación, puede que no tenga una opción. Si va a instalar software
en las máquinas que controles, sin embargo, sugeriría nos fijamos en unificadora o al
menos reducir el número de diferentes sistemas operativos que utilice. Se puede
reducir en gran medida las variaciones en el comportamiento de una máquina a la
siguiente, y simplificar las tareas de implementación y mantenimiento.
En general, aquellos equipos que he visto que se han trasladado a la gestión de
paquetes basada en sistema operativo han simplificado su enfoque de
implementación, y tienden a evitar la trampa de grandes com- plejo guiones,
110 | Capítulo 6: Despliegue
despliegue. Especialmente si estás en Linux, esto puede ser una buena manera de
sim- plificar el despliegue de microservicios utilizando pilas de tecnología dispares.
Específicos de la Plataforma
Artefactos | 109
Imágenes personalizadas
Uno de los retos con los sistemas de gestión de la configuración automatizados como
Pup- mascota, cocinero, y Ansible puede ser el tiempo necesario para ejecutar las
secuencias de comandos en una máquina. Vamos a dar un ejemplo simple de un
servidor que se está aprovisionado y configurado para permitir el despliegue de una
aplicación Java. Asumamos que estoy usando AWS para aprovisionar el servidor,
usando la imagen de Ubuntu estándar. Lo primero que tengo que hacer es instalar el
Oracle JVM para ejecutar mi aplicación Java. He visto este sencillo proceso de toma
alrededor de cinco minutos, con un par de minutos tomadas por la máquina que está
siendo aprovisionado, y algunos más para instalar la JVM. Entonces podemos pensar
en tener que poner nuestro software en él.
Esto es en realidad un ejemplo bastante trivial. A menudo nos querremos instalar
otros bits comunes de software. Por ejemplo, es posible que desee utilizar para la
recopilación de estadísticas collectd OS, utilice logstash para la agregación de
registro, y tal vez instalar los bits apropiados de Nagios para monitorear (hablaremos
más sobre este software enCapítulo 8). Con el tiempo, más cosas puede ser que
consiga añadido, lo que lleva a cantidades cada vez más largos de tiempo necesario
para la visión pro de estas dependencias.
Marioneta, Chef, Ansible, y sus semejantes pueden ser inteligentes y evitarán
software que ya está presente la instalación. Esto no significa que la ejecución de las
secuencias de comandos en las máquinas existentes será siempre rápida, por
desgracia, como ejecutar todos los controles lleva tiempo. También queremos evitar
mantener nuestras máquinas existido por mucho tiempo, ya que no queremos para
permitir demasiada cambios de configuración (que vamos a explorar en mayor
profundidad en breve). Y si estamos usando una plataforma de computación bajo
demanda que podríamos estar constantemente cerrando y girando nuevos casos sobre
una base diaria (o con mayor frecuencia), por lo que la naturaleza declarativa de estas
herramientas de gestión de configuración puede ser de uso limitado.
Con el tiempo, viendo las mismas herramientas se instalan una y otra vez puede
convertirse en una verdadera molestia. Si usted está tratando de hacer esto varias
veces al día, tal vez como parte del desarrollo o CI-esto se convierte en un verdadero
problema en términos de proporcionar retroalimentación rápida. También puede
conducir a un mayor tiempo de inactividad cuando se despliega en la producción si
los sistemas no permiten la implementación sin tiempo de inactividad, ya que usted
está esperando para instalar todos los requisitos previos en sus máquinas, incluso
antes de llegar a la instalación del software. Modelos como el despliegue azul / verde
(que discutiremos enCapítulo 7) Pueden ayudar a mitigar esto, ya que nos permiten
desplegar una nueva versión de nuestro servicio sin tomar el viejo fuera de línea.
Un enfoque para reducir este tiempo spin-up es crear una imagen de máquina virtual
que hornea en algunas de las dependencias comunes que usamos, como se muestra en
Figura 6-5. Todas las plataformas lización virtualmente que he usado le permiten
Imágenes personalizadas
| 111
construir sus propias imágenes, y las herramientas para hacerlo son mucho más
avanzados de lo que eran hace unos años. Esto cambia las cosas un poco. Ahora
podríamos hornear las herramientas comunes en nuestra propia imagen. Cuando
nosotros
112| Capítulo 6: Despliegue
desee implementar nuestro software, hacemos girar una instancia de esta imagen
personalizada, y todo lo que tenemos que hacer es instalar la versión más reciente de
nuestro servicio.
Figura 6-5. La creación de una imagen de máquina virtual personalizada
Por supuesto, porque se genera la imagen sólo una vez, cuando se inicie
posteriormente copias de esta imagen que no es necesario pasar el tiempo la
instalación de sus dependencias, ya que ya están allí. Esto puede resultar en un
ahorro significativo de tiempo. Si sus dependencias centrales no cambian, las nuevas
versiones de su servicio pueden continuar utilizando la misma imagen base.
Hay algunos inconvenientes con este enfoque, sin embargo. Construyendo las
imágenes pueden tardar mucho tiempo. Esto significa que para los desarrolladores es
posible que desee apoyar otras formas de implementación de servicios para
asegurarse de que no tienen que esperar media hora sólo para crear una expansión
binaria. En segundo lugar, algunas de las imágenes resultantes pueden ser grandes.
Esto podría ser un problema real si va a crear sus propias imágenes de VMWare, por
ejemplo, como una imagen de 20 GB en torno a una red móvil no es siempre una
actividad sencilla. Vamos a estar buscando en la tecnología tainer con- poco, y en
concreto del estibador, que puede evitar algunos de estos inconvenientes.
Históricamente, uno de los retos es que la cadena de herramientas necesario para
construir una imagen tan variada de plataforma en plataforma. La construcción de
una imagen de VMWare es diferente de la construcción de una imagen de una
imagen Rackspace un vagabundo AWS IAM, o. Esto puede no haber sido un
problema si tuviera la misma plataforma todas partes, pero no todas las
organizaciones fueron tan afortunados. E incluso si lo fueran, las herramientas de
este espacio eran a menudo difíciles de trabajar con ellos, y se llevan bien con otras
herramientas que podría estar usando para la configuración de la máquina.
Envasador es una herramienta diseñada para hacer de la creación de imágenes mucho
Imágenes personalizadas
| 113
más fácil. El uso de scripts de configuración de su elección (Chef, Ansible, de
marionetas, y más son compatibles), que nos permite
114| Capítulo 6: Despliegue
crear imágenes para diferentes plataformas de la misma configuración. En el
momento de la escritura, que tiene soporte para VMware, AWS, Rackspace Cloud,
Océano Digital, y vagabundo, y he visto equipos lo utilizan con éxito para la creación
de imágenes de Linux y Windows. Esto significa que podría crear una imagen para la
implementación en su entorno de producción de AWS y una imagen Vagrant a juego
para el desarrollo local y la prueba, todos de la misma configuración.
Imágenes como artefactos
Así podemos crear imágenes de máquinas virtuales que cocer en las dependencias de
acelerar Feed- atrás, pero ¿por qué detenerse ahí? Podríamos ir más lejos, hornear
nuestro servicio en la propia imagen, y adoptar el modelo de ser nuestro artefacto
servicio de una imagen. Ahora, cuando lancemos nuestra imagen, nuestro servicio
está allí listo para funcionar. Esta vez muy rápido spin-up es la razón por la que
Netflix ha adoptado el modelo de hornear sus propios servicios como AWS IAM.
Al igual que con los paquetes específicos de OS, estas imágenes de VM se convierten
en una buena manera de abstraer las diferencias en las pilas de tecnología utilizados
para crear los servicios. ¿Nos importa si el servicio que se ejecuta en la imagen está
escrito en Ruby o Java, y utiliza un archivo JAR joya? Todo lo que importa es que
funciona. Nos podemos centrar nuestros esfuerzos, a continuación, en la
automatización de la creación y despliegue de estas imágenes. Esto también se
convierte en una forma muy bien para poner en práctica otro concepto de despliegue,
el servidor inmutable.
Servidores inmutables
Al almacenar toda nuestra configuración de control de código fuente, que estamos
tratando de asegurar que podemos reproducir automáticamente los servicios y
entornos de esperar enteras a voluntad. Pero una vez que corremos nuestro proceso
de despliegue, lo que pasa si alguien viene, se registra en la caja, y cambia las cosas,
independientemente de lo que está en control de código fuente? Este problema se
llama a menudo deriva de configuración: el código de control de código fuente ya no
refleja la configuración del host que ejecuta.
Para evitar esto, podemos asegurar que no se realizan cambios nunca a un servidor
que ejecuta. En cambio, cualquier cambio, por pequeño que sea, tiene que ir a través
de una tubería de construcción con el fin de crear una nueva máquina. Puede
implementar este patrón sin necesidad de utilizar las implementaciones basadas en
imágenes, sino que también es una extensión lógica de la utilización de imágenes
como artefactos. Durante nuestra creación de la imagen, por ejemplo, que podríamos
desactivar SSH, asegurando que nadie podía siquiera iniciar sesión en el cuadro para
hacer un cambio!
Las mismas advertencias que hemos discutido sobre el tiempo de ciclo se siguen
aplicando, por supuesto. Y también tenemos que garantizar que todos los datos que
nos importa que se almacena en el cuadro se almacena en otro lugar. Estas
Imágenes personalizadas
| 115
complejidades un lado, he visto la adopción de este patrón de plomo a los
despliegues mucho más sencillo y más fácil de la razón, sobre los entornos. Y como
ya he dicho, todo lo que podemos hacer para simplificar las cosas debe llevarse a
cabo!
116| Capítulo 6: Despliegue
entornos
A medida que nuestro software se mueve a través de nuestras etapas de canalización
de CD, también se desplegará en diferentes tipos de entornos. Si pensamos en el
ejemplo construir oleoducto enFigura 6-4, Es probable que considerar al menos
cuatro ambientes distintos: uno entorno en el que manejamos nuestras pruebas lentas,
otra para la UAT, otra para el rendimiento, y una última para la producción. Nuestra
microService debe ser el mismo en todas partes, pero el ambiente será diferente. Por
lo menos, van a estar ciones recogida diferenciada de residuos, distintos de
configuración y anfitriones. Pero a menudo pueden variar mucho más que eso. Por
ejemplo, nuestro entorno de producción para nuestro servicio podría consistir en
varios hosts equilibradas carga-repartidos en dos centros de datos, mientras que
nuestro entorno de prueba sólo podría tener todo lo que se ejecuta en un único host.
Estas diferencias en los entornos pueden introducir algunos problemas.
Me picaron por esto hace personalmente muchos años. Nos despliegue de un servicio
web Java en un contenedor de aplicaciones WebLogic agrupado en la producción.
Este cluster WebLogic replicado estado de sesión entre múltiples nodos, que nos da
un cierto nivel de capacidad de recuperación si un solo nodo que ha fallado. Sin
embargo, las licencias WebLogic eran caros, al igual que las máquinas de nuestro
software se desplegó en. Esto significaba que en nuestro entorno de prueba, nuestro
software se implementa en una sola máquina, en una configuración no agrupado.
Esto nos herido gravemente durante un lanzamiento. Para WebLogic para poder
copiar el estado de sesión entre nodos, los datos de sesión tiene que ser
adecuadamente serializable. Por desgracia, una de nuestras confirmaciones
rompieron esto, así que cuando nos implementarse en producción de nuestra ción
replicativa sesión fallida. Terminamos la resolución de esta empujando duro para
replicar una configuración agrupada en nuestro entorno de prueba.
El servicio que desea implementar es el mismo en todos estos entornos diferentes,
pero cada uno de los ambientes tiene un propósito diferente. En mi portátil
desarrollador Quiero desplegar rápidamente el servicio, potencialmente contra
colaboradores tropezados, para ejecutar pruebas o llevar a cabo algún validación
manual de comportamiento, mientras que cuando puedo implementar en un entorno
de pro- ducción es posible que quiera instalar múltiples copias de mi servicio en de
manera equilibrada load-, quizás divide en uno o más centros de datos por razones de
durabilidad.
A medida que avanza desde su ordenador portátil para construir servidor al entorno
UAT todo el camino a la producción, tendrá que asegurarse de que sus entornos son
cada vez más la producción como para atrapar cualquier problema asociado con estas
diferencias ambientales más pronto. Este será un equilibrio constante. A veces, el
tiempo y el coste de repro- entornos de producción como Duce pueden ser
prohibitivos, por lo que tiene que hacer concesiones. Además, a veces utilizando un
entorno de producción-como puede ralentizar bucles de retroalimentación; a la espera
Imágenes personalizadas
| 117
de 25 máquinas para instalar el software en AWS podría ser mucho más lento que el
simple despliegue de su servicio en una instancia de Vagrant local, por ejemplo.
118| Capítulo 6: Despliegue
Este equilibrio entre los entornos de producción similar y respuesta rápida, no será
estática. Mantenga un ojo en el error que encuentre más abajo y sus tiempos de
retroalimentación, y ajustar este equilibrio tan necesario.
Gestión de entornos de sistemas monolíticos de un solo Artfact puede ser un reto,
especialmente si usted no tiene acceso a los sistemas que son fácilmente
automatizables. Cuando se piensa en múltiples entornos por microService, esto puede
ser aún más desalentador. Vamos a ver en breve en algunas plataformas de
despliegue diferentes que pueden hacer esto mucho más fácil para nosotros.
Configuración de servicio
Nuestros servicios tienen alguna configuración. Idealmente, esto debería ser una
cantidad pequeña, y solamente en aquellas características que cambian de un entorno
a otro, tal como lo nombre de usuario y contraseña debo utilizar para conectar a mi
base de datos? Configuración que cambia de un entorno a otro debe mantenerse a un
mínimo absoluto. Cuanto más su configuración cambia el comportamiento de
servicio fundamental, y cuanto más que la configuración varía de un entorno a otro,
más se va a encontrar problemas sólo en ciertos ambientes, lo cual es doloroso en
extremo.
Así que si tenemos alguna configuración para nuestro servicio que cambiar de una a
otra ENTORNO, ¿cómo debemos manejar esto como parte de nuestro proceso de
implementación? Una opción es construir un artefacto por el medio ambiente, con la
configuración interior del propio artefacto. Inicialmente esto parece sensato. La
configuración está construido justo en; simplemente desplegarlo y todo debería
funcionar bien, ¿verdad? Esto es problemático. Recuerde que el concepto de la
entrega continua. Queremos crear un artefacto que representa la fecha nuestro
comunicado candi-, y moverlo a través de nuestra línea, confirmando que es lo
suficientemente bueno para entrar en producción. Imaginemos construyo un cliente
por servicio de Prueba y artefactos Prod Service- el cliente. Si mi artefacto cliente
por servicio de prueba pasa las pruebas, pero es el artefacto cliente-servicio-Prod que
en realidad implementar,
Hay otros retos. En primer lugar, está el tiempo adicional necesario para construir
estos artefactos. A continuación, el hecho de que lo que necesita saber en tiempo de
compilación lo que existen ambientes. Y, ¿cómo manejar los datos de configuración
sensibles? No quiero que la información acerca de las contraseñas de producción
registramos con mi código fuente, pero si es necesario en tiempo de compilación para
crear todos esos artefactos, esto es a menudo difícil de evitar.
Un mejor enfoque es crear un solo artefacto, y administrar la configuración por
separado. Esto podría ser un archivo de propiedades que existe para cada entorno o
diferentes parámetros pasados a un proceso de instalación. Otra opción popular,
especialmente cuando se trata de un número mayor de microservicios, es utilizar un
sistema dedicado para la configuración Viding pro, que vamos a explorar más
Configuración del servicio |
115
enCapítulo 11.
116| Capítulo 6: Despliegue
Servicio-a-Host Mapping
Una de las preguntas que surge muy pronto en la discusión en torno microser- vicios
es “¿Cómo muchos servicios por máquina?” Antes de continuar, debemos escoger un
término mejor que la máquina, o incluso la caja más genérico que he utilizado
anteriormente . En esta era de tualization vir-, la asignación entre un único host que
ejecuta un sistema operativo y la infraestructura física subyacente puede variar en
gran medida. Por lo tanto, tiendo a hablar de los ejércitos, usándolos como una
unidad genérica de aislamiento, a saber, un sistema operativo en el que puedo instalar
y ejecutar mis servicios. Si va a implementar directamente en máquinas físicas, a
continuación, un servidor físico se asigna a un host (que tal vez no se comterminología totalmente correctas en este contexto, pero en ausencia de mejores
condiciones puede tener que ser suficiente). Si está utilizando la virtualización,
Así que cuando se piensa en diferentes modelos de implementación, hablaremos de
los ejércitos. Así, pues, el número de servicios por host deberíamos tener?
Tengo una visión clara en cuanto a qué modelo es preferible, pero hay una serie de
fac- tores a considerar cuando se trabaja con el modelo que será el adecuado para
usted. También es impor- tante entender que algunas decisiones que tomamos en este
sentido limitarán algunas de las opciones de implementación disponibles para
nosotros.
Servicios Múltiples por host
Tener varios servicios por host, como se muestra en Figura 6-6, Es atractivo por
varias razones. En primer lugar, sólo a partir de un punto de administración de
acogida de vista, es más simple. En un mundo en el que un equipo gestiona la
infraestructura y otro equipo gestiona el software, la carga de trabajo del equipo de
infraestructura es a menudo una función del número de hosts que tiene que gestionar.
Si más servicios se empaquetan en un único host, éste hombre-carga de trabajo
agement no aumenta el número de servicios aumenta. En segundo lugar es el costo.
Incluso si usted tiene acceso a una plataforma de virtualización que le permite
cambiar el tamaño de prestación y los hosts virtuales, la virtualización puede añadir
una sobrecarga que reduce los recursos disponibles subyacentes a sus servicios. En
mi opinión, estos dos problemas se pueden abordar con nuevas prácticas de trabajo y
la tecnología, y vamos a explorar que en breve.
Este modelo también es familiar para aquellos que desplegar en alguna forma de un
con- tainer aplicación. En cierto modo, el uso de un contenedor de aplicaciones es un
caso especial del modelo de múltiples servicios-por-anfitrión, por lo que tendremos
que mirar en forma separada. Este modelo también puede simplificar la vida del
desarrollador. La implementación de servicios múltiples a un solo host en la
producción es sinónimo de desplegar múltiples servicios a un dev ción estaciones de
trabajo local o portátil. Si queremos mirar a un modelo alternativo, queremos
encontrar una manera de mantener esta conceptualmente simple para los
desarrolladores.
Configuración del servicio |
117
Figura 6-6. Múltiples microservicios por host
Hay algunos problemas con este modelo, sin embargo. En primer lugar, puede hacer
seguimiento a más difícil. Por ejemplo, cuando el seguimiento de la CPU, lo que
necesito para hacer un seguimiento de la CPU de un servicio independiente de los
demás? ¿O es que se preocupan por la CPU de la caja en su conjunto? Los efectos
secundarios también pueden ser difíciles de evitar. Si un servicio está bajo carga
significativa, que puede terminar reduciendo los recursos disponibles para otras
partes del sistema. Dorada, cuando scal- ing a cabo el número de servicios que corría,
golpear a este problema. Inicialmente coexistido muchos servicios en una sola caja,
pero la carga desigual en uno de los servicios tendría un impacto negativo en todo lo
demás que se ejecutan en ese anfitrión. Esto hace que el análisis del impacto de
errores de host más compleja, así la asunción de un único host fuera de servicio,
puede tener un efecto dominó.
El despliegue de servicios puede ser algo más compleja también, como asegurar un
des- pliegue no afecta a otro conduce a dolores de cabeza adicionales. Por ejemplo, si
uso Pup- mascota para preparar una gran cantidad, pero cada servicio tiene diferentes
(y potencialmente contradictorias) dependencias, ¿cómo puedo hacer eso? En el peor
de los casos, he visto per- sonas atan múltiples implementaciones de servicios en
conjunto, el despliegue de múltiples servicios diferentes a un único host en un solo
paso, para tratar de simplificar el despliegue de múltiples servicios a un host. En mi
opinión, el pequeño revés en la mejora de la simplicidad es más de OUT- ponderado
por el hecho de que hemos renunciado a una de las principales ventajas de
microservicios: La lucha por la liberación independiente de nuestro software. Si
adopta el modelo de servicios múltiple-per-anfitrión,
Este modelo también puede inhibir la autonomía de los equipos. Si los servicios para
los diferentes equipos se instalan en el mismo host remate para configurar el host por
sus servicios? Con toda probabilidad, esto termina siendo manejado por un equipo
centralizado, lo que significa que se necesita una mayor coordinación para obtener
los servicios desplegados.
Otra cuestión es que esta opción puede limitar nuestras opciones de despliegue de
artefactos. implementaciones basadas Image- están fuera, al igual que los servidores
inmutables menos que se ata múltiples servicios diferentes en un solo artefacto, lo
que realmente queremos evitar.
Servicio-a-Host Mapping | 117
El hecho de tener múltiples servicios en un único host significa que los esfuerzos se
dirigen a escala para el servicio con mayor necesidad de que puede ser complicado.
Del mismo modo, si uno
118| Capítulo 6: Despliegue
microService maneja los datos y operaciones que son especialmente sensibles, lo que
se quiere configurar el host subyacente de manera diferente, o tal vez incluso colocar
el anfitrión en un segmento de red Separando. Tener todo en un host significa que
podría terminar hav- ing para el tratamiento de todos los servicios de la misma
manera, incluso si sus necesidades son diferentes.
Como mi colega Neal Ford pone, muchas de nuestras prácticas de trabajo alrededor
de des- pliegue y la gestión de acogida son un intento de optimizar la escasez de
recursos. En el pasado, la única opción si queríamos otra anfitrión era para comprar o
alquilar otra máquina físi- cas. A menudo, esto tuvo un gran tiempo de espera a la
misma y dio lugar a un largo plazo finan- compromiso oficial. No era raro que los
clientes que he trabajado realiza la provisión de nuevos servidores sólo cada dos o
tres años, y tratando de conseguir máquinas adicionales OUT- lado de estas líneas de
tiempo era difícil. Pero bajo demanda plataformas de computación han drásticamente reducido los costos de los recursos informáticos, y mejoras en la tecnología
de virtualización significar incluso para internamente infraestructura alojada hay más
flexibilidad.
contenedores de aplicaciones
Si está familiarizado con el despliegue de aplicaciones .NET detrás de las
aplicaciones de IIS o Java en un contenedor de servlets, usted estará bien
familiarizado con el modelo en el que múltiples servicios o aplicaciones distintas
sientan dentro de un único contenedor de aplicaciones, que a su vez se encuentra en
un solo host, como vemos en Figura 6-7. La idea es que el contenedor de
aplicaciones sus servicios en vivo en le da beneficios en términos de mejora de
gestión, como el soporte de clustering para manejar la agrupación de varias instancias
juntos, herramientas de monitorización, y similares.
Figura 6-7. Múltiples microservicios por host
Esta configuración también puede producir beneficios en términos de reducir los
gastos generales de los tiempos de lenguaje de ejecución. Considere correr cinco
servicios Java en un único contenedor de servlets Java. Sólo tengo la sobrecarga de
una única JVM. Compare esto con el funcionamiento de cinco JVM independientes
en el mismo host al utilizar contenedores enterrados. Dicho esto, todavía me siento
Servicio-a-Host Mapping | 119
que estos contenedores de aplicaciones tienen bastantes desventajas que usted debe
desafiar auto tu- para ver si son realmente necesarios.
120| Capítulo 6: Despliegue
El primer lugar entre las desventajas es que inevitablemente limitan la elección de la
tecnología. Usted tiene que comprar en una pila de tecnología. Esto puede limitar no
sólo las opciones tecnológicas para la implementación del servicio en sí, sino
también las opciones que tiene en términos de automatización y gestión de sus
sistemas. Como veremos en breve, una de las maneras en que podemos hacer frente a
la sobrecarga de la gestión de múltiples hosts es de alrededor de automatización, y así
limitar nuestras opciones para resolver este bien puede ser doblemente perjudicial.
También me gustaría cuestionar algunos de los valores de las características del
envase. Muchos de ellos tout la capacidad de gestionar grupos de apoyo compartido
estado de sesión en la memoria, algo que queremos evitar absolutamente en cualquier
caso, debido a las dificultades que esto crea al escalar nuestros servicios. Y la
capacidad de vigilancia que proporcionan no será suficiente si tenemos en cuenta el
tipo de monitoreo se unió a punto que queremos hacer en un mundo microservicios,
como veremos enCapítulo 8. Muchos de ellos también tienen tiempos muy lentos
volver a acelerarse, lo que afecta los ciclos de retroalimentación desarrollador.
Hay otros tipos de problemas también. El intento de hacer la gestión del ciclo de vida
adecuado de las aplicaciones en la parte superior de las plataformas como la JVM
puede ser problemático, y más com- plejo que simplemente reiniciar una JVM. El
análisis de uso de recursos y las discusiones también es mucho más compleja, ya que
tiene varias aplicaciones que comparten el mismo proceso. Y recuerde, incluso si lo
hace obtener el valor de un contenedor específico de la tecnología, que no son libres.
Aparte del hecho de que muchos de ellos son comerciales y así tener un catión
implica- costo, añaden una sobrecarga de recursos en sí mismos.
En última instancia, este enfoque es de nuevo un intento de optimizar la escasez de
recursos que simplemente no puede albergar hasta más. Tanto si decide tener
múltiples servicios al huésped como un modelo de implementación, sugeriría
fuertemente mirando microservicios desplegables autónomos como artefactos. Para
.NET, esto es posible con cosas como Nancy, y Java ha apoyado este modelo desde
hace años. Por ejemplo, el recipiente embarcadero incrustado venerable hace para un
servidor HTTP autónomo muy ligero, que es el núcleo de la pila Dropwizard. Google
ha sido conocido por usar felizmente contenedores Jetty incrustados para servir
contenido estático directamente, por lo que sabemos estas cosas pueden funcionar a
escala.
Servicio individual por sistema
Con un modelo de un solo servicio-per-anfitrión se muestra en la Figura 6-8,
Evitamos los efectos secundarios de varios hosts que viven en una misma máquina,
haciendo el seguimiento y la recuperación mucho más simple. Hemos reducido
potencialmente nuestros puntos únicos de fallo. Un corte de luz a un host debe
impactar un solo servicio, a pesar de que no siempre es clara cuando se está
utilizando una plataforma virtualizada. Vamos a cubrir el diseño de la escala y el
fracaso más enCap- 11 ter. También podemos escalar más fácilmente un servicio
Servicio-a-Host Mapping | 121
independiente de los demás, y hacer frente a los problemas de seguridad más
fácilmente enfocando nuestra atención sólo en el servicio y el anfitrión que lo
requiera.
122| Capítulo 6: Despliegue
Figura 6-8. Un único microService por host
Igual de importante es que hemos abierto la posibilidad de utilizar técnicas de despliegue alternativos tales como despliegues basados en imágenes o el patrón del
servidor inmutable, que hemos comentado anteriormente.
hemos añadido una gran complejidad en la adopción de una arquitectura
microService. La última cosa que queremos hacer es ir en busca de más fuentes de
complejidad. En mi opinión, si usted no tiene un PaaS viables disponibles, a
continuación, este modelo hace un muy buen trabajo de reducción ing complejidad
global de un sistema. Tener un modelo de un solo servicio-per-host es
significativamente más fácil de razonar acerca y puede ayudar a reducir la
complejidad. Si no puede abrazar a este modelo, sin embargo, no voy a decir
microservicios no son para usted. Pero yo sugeriría que se mira a avanzar hacia este
modelo con el tiempo como una forma de reducir la complejidad que una
arquitectura microService puede traer.
Tener un mayor número de hosts tiene desventajas potenciales, sin embargo.
Tenemos más servidores para gestionar, y también puede haber una implicación
costo de funcionamiento de los ejércitos más dis- tinct. A pesar de estos problemas,
este sigue siendo el modelo prefiero para arquitecturas MICROSERVICE. Y
hablaremos de algunas cosas que podemos hacer para reducir la sobrecarga de
manejar grandes cantidades de hosts en breve.
Plataforma como servicio
Cuando se utiliza una plataforma como servicio (PaaS), que está trabajando en una
abstracción de nivel más alto que en un solo host. La mayoría de estas plataformas se
basan en la consideración de un artefacto específico de la tecnología, como por
ejemplo un archivo Java guerra o gema Ruby, y automáticamente aprovisionamiento
y ejecutarlo para usted. Algunas de estas plataformas se forma transparente intentar
manejar scal- ing el sistema de arriba a abajo para que, a pesar de una forma (menos
propenso a errores y en mi expe- riencia) más común que permitirá cierto control
sobre el número de nodos podría ejecutar su servicio en adelante, pero se encarga del
resto.
automatización | 121
A el momento de la escritura, la mayor parte de las mejores soluciones PaaS más
pulidas están alojados. Heroku viene a la mente como siendo probablemente la clase
de oro de PaaS. No se encarga solamente de funcionamiento de su servicio, que
también es compatible con servicios como bases de datos de una manera muy simple.
120 | Capítulo 6: Despliegue
soluciones de auto-organizada existen en este espacio, aunque son más inmaduro que
las soluciones alojadas.
Cuando las soluciones PaaS funcionan bien, trabajan muy bien. Sin embargo, cuando
no llegan a trabajar para usted, que a menudo no tiene mucho control en términos de
conseguir bajo el capó para arreglar las cosas. Esto es parte de la compensación que
realice. Yo diría que en mi experiencia, la más inteligente de las soluciones PaaS
tratar de ser, más que ir mal. He usado más de un PaaS que intenta AutoScale basado
en el uso de aplicaciones, pero lo hace mal. Invariablemente, la heurística que
impulsan estos inteligencia tienden a ser adaptado para la aplicación edad promedios
en lugar de su caso de uso específico. Cuanto más estándar que su aplica- ción, lo
más probable es que no podría jugar muy bien con una PaaS.
Como las buenas soluciones PaaS manejan tanto por ti, pueden ser una excelente
manera de manejar la mayor sobrecarga que obtenemos con tener muchas más piezas
móviles. Dicho esto, todavía no estoy seguro de que tenemos todos los modelos de la
derecha en este espacio todavía, y el LIMITA- TED opciones de auto-organizada
significan que este enfoque podría no funcionar para usted. En la década ing comaunque espero que estaremos apuntando PaaS para el despliegue de más de tener que
autogestionar anfitriones y las implementaciones de servicios individuales.
Automatización
La respuesta a tantos problemas que hemos planteado hasta ahora se reduce a la
automatización. Con un pequeño número de máquinas, es posible gestionar todo
manualmente. Solía hacer esto. Recuerdo la ejecución de un pequeño conjunto de
máquinas de producción, y me recopilar registros, implementar el software, y
comprobar los procesos ingresando manualmente en la caja. Mi productividad
parecía estar limitada por el número de ventanas de terminal que pudiera tener
abiertos a la vez, un segundo monitor fue un gran paso adelante. Esto se descompone
muy rápido, sin embargo.
Una de las expulsiones en contra de la instalación de un solo servicio-per-host es la
percepción de que la cantidad de sobrecarga para gestionar estos anfitriones se
incrementarán. Esto es especialmente cierto si usted está haciendo todo
manualmente. El doble de los servidores, el doble de trabajo! Pero si nos automatizar
el control de nuestros anfitriones, y el despliegue de los servicios, entonces no hay
razón por la rea- hijo añadiendo más hosts deben aumentar nuestra carga de trabajo
de una forma lineal.
Pero incluso si mantenemos el número de hosts pequeña, todavía vamos a tener un
montón de servi- cios. Eso significa que múltiples implementaciones de manejar,
servicios para monitorear, troncos para recoger. La automatización es esencial.
La automatización es también cómo podemos asegurarnos de que nuestros
desarrolladores todavía permanecen tivo productividad. Dándoles la capacidad de
auto-servicio de provisión de servicios individuales o grupos de servicios es clave
automatización | 121
para hacer más fácil la vida de los desarrolladores. Idealmente, los desarrolladores
deben tener acceso a exactamente la misma cadena de herramientas que se utiliza
para el despliegue de nuestros servicios de producción a fin de garantizar que
podemos detectar problemas a tiempo. Vamos a estar buscando en una gran cantidad
de tecnología en este capítulo que abarca este punto de vista.
120 | Capítulo 6: Despliegue
Recogiendo tecnología que permite la automatización es muy importante. Esto
comienza con las herramientas utilizadas para administrar hosts. Se puede escribir
una línea de código para poner en marcha una máquina virtual, o apagar uno abajo?
Se puede implementar el software que ha escrito de forma automática? Se puede
implementar cambios de bases de datos sin intervención manual? Adoptar una
cultura de la automatización es clave si desea mantener la complejidad de las
arquitecturas MICROSERVICE bajo control.
Dos estudios de casos sobre el poder de la automatización
Es probable que sea útil para darle un par de ejemplos concretos que explican el
poder del bien automatización. Uno de nuestros clientes en Australia es
RealEstate.com.au (REA). Entre otras cosas, la empresa ofrece listados de bienes
raíces para clientes minoristas y comerciales en Australia y en la región de Asia y el
Pacífico en otros lugares. Durante varios años, se ha estado moviendo su plataforma
hacia un diseño distribuido, microservicios. Cuando se inició en este viaje que tuvo
que pasar mucho tiempo para llegar al ing herramienta- en torno a los servicios sólo
haga lo que facilita a los desarrolladores a máquinas de provisión, para desplegar su
código, o supervisarlos. Esto causó una carga frontal del trabajo tome la iniciativa.
En los tres primeros meses de este ejercicio, REA fue capaz de mover sólo dos
nuevos servicios de micro en la producción, con el equipo de desarrollo de una
responsabilidad plena en toda la construcción, implementación y apoyo de los
servicios. En los próximos tres meses, entre 10-15 se pusieron en marcha los
servicios de una manera similar. Al final del período de 18 meses, REA tenía más de
60-70 servicios.
Este tipo de patrón también se ve confirmado por las experiencias de Dorado, Un
minorista en línea de la manera que se inició en 2007. aplicación Rails monolítica de
la cerda joven estaba empezando a llegar a ser difícil de escalar, y la compañía
decidió en 2009 iniciar la descomposición del sistema en microservicios.
automatización de nuevo, sobre todo herramientas para ayudar a los desarrolladores,
se dio como una razón clave para impulsar la explosión de la cerda joven en el uso de
microservicios. Un año más tarde, dorado tenía alrededor de 10 microservicios viven;
para el año 2012, más de 100; y en 2014, más de 450 microservicios por propia
cuenta, en otras palabras, alrededor de tres servicios de Gilt para todos los
desarrolladores en dorado.
De físico a virtual
Una de las herramientas clave disponibles para nosotros en la gestión de un gran
número de hosts es encontrar formas de fragmentación de seguridad de máquinas
físicas existentes en partes más pequeñas. lización virtualmente tradicional como
VMWare o la utilizada por AWS ha dado enormes beneficios en la reducción de los
gastos generales de gestión de acogida. Sin embargo, ha habido algunos nuevos
avances en este espacio que merece la pena explorar, ya que pueden abrirse aún más
122| Capítulo 6: Despliegue
interesantes posibili- dades para hacer frente a nuestra arquitectura microService.
De físico a virtual | 123
La virtualización tradicional
¿Por qué tener un montón de anfitriones caro? Bueno, si usted necesita un servidor
físico por host, la respuesta es bastante obvia. Si este es el mundo se está operando
en, entonces el modelo múltiple de servicios-per-host es probablemente adecuado
para usted, a pesar de que no se sorprenda si esto se convierte en una restricción cada
vez más desafiante. Sospecho, sin embargo, que la mayoría de ustedes están
utilizando la virtualización de algún tipo. La virtualización permite que rebanemos
un servidor físico en hosts separados, cada uno de los cuales se pueden ejecutar
diferentes cosas. Así que si queremos un servicio por host, no podemos simplemente
el tramo hasta nuestra infraestructura física en trozos cada vez más pequeños?
Bien, para algunas personas, se puede. Sin embargo, cortando la máquina cada vez
mayor en las máquinas virtuales no es libre. Pensar en nuestra máquina física como
un cajón de los calcetines. Si ponemos un montón de separadores de madera en
nuestro cajón, podemos almacenar más calcetines o menos? La respuesta es menos:
los divisores propios ocupan espacio también! Nuestro cajón podría ser más fácil de
tratar y organizar, y tal vez nos podría decidir poner camisetas en uno de los espacios
ahora en lugar de sólo calcetines, pero más divisores significa menos espacio en
general.
En el mundo de la virtualización, tenemos una cabeza similar a nuestros divisores
calcetín cajón. Para entender de dónde proviene de esta sobrecarga, vamos a ver
cómo se realiza la mayoría de virtualización.Figura 6-9 muestra una comparación de
dos tipos de virtualización. A la izquierda, vemos las distintas capas que participan
en lo que se llama el tipo 2 de virtualización, que es el tipo aplicado por AWS,
VMware, vSphere, Xen y KVM. (Tipo 1 virtualización se refiere a la tecnología,
donde las máquinas virtuales se ejecutan directamente en el hardware, no encima de
otro sistema operativo.) En nuestra infraestructura física tenemos un sistema
operativo anfitrión. En este sistema operativo se corre algo que se llama un
hipervisor, que tiene dos puestos clave. En primer lugar, los mapas de recursos como
CPU y la memoria de la máquina virtual en el host físico. Segundo, que actúa como
una capa de control, lo que nos permite manipular las máquinas virtuales mismos.
124| Capítulo 6: Despliegue
Figura 6-9. Una comparación de estándar Tipo 2 virtualización y envases ligeros
De físico a virtual | 125
Dentro de las máquinas virtuales, obtenemos lo que parece ser completamente
diferentes hosts. Pueden ejecutar sus propios sistemas operativos, con sus propios
núcleos. Pueden considerarse máquinas casi ella- metically sellados, mantienen
aislado del host físico subyacente y las otras máquinas virtuales por el hipervisor.
El problema es que el hipervisor aquí tiene que reservar recursos para hacer su
trabajo. Esto quita CPU, I / O, y la memoria que podría ser utilizado en otro lugar.
Los más hosts gestiona el hipervisor, más recursos que necesita. En un momento
determinado, esta sobrecarga se convierte en una restricción de corte de su
infraestructura física más allá. En la práctica, esto significa que a menudo hay
rendimientos decrecientes en corte de una caja física en partes cada vez más
pequeñas, ya que proporcionalmente cada vez más recursos van a la cabeza del
hipervisor.
Vagabundo
Vagabundo es una plataforma de despliegue de gran utilidad, que normalmente se
utiliza para el dev y prueba en lugar de la producción. Vagabundo le proporciona una
nube virtual en su computadora portátil. Debajo, se utiliza un sistema de
virtualización estándar (típicamente VirtualBox, aunque puede utilizar otras
plataformas). Se le permite definir un conjunto de máquinas virtuales en un archivo
de texto, junto con la forma de las máquinas virtuales están conectados en red entre sí
y que las imágenes de las máquinas virtuales debe basarse en. Este archivo de texto
se puede comprobar en y compartida entre los miembros del equipo.
Esto hace que sea más fácil para usted para crear entornos de producción como en su
máquina local. Puede girar múltiples máquinas virtuales a la vez, cierra los
individuales para probar los modos de fallo, y tienen las máquinas virtuales asignada
a través de los directorios locales para que pueda hacer cambios y verlos reflejados
inmediatamente. Incluso para los equipos que utilizan plataformas en la nube bajo
demanda como AWS, la respuesta más rápido de utilizar vagabundo puede ser de
gran ayuda para los equipos de desarrollo.
Una de las desventajas, sin embargo, es que una gran cantidad de máquinas virtuales
que se ejecutan pueden gravar la máquina de desa- rrollo de la media. Si tenemos un
servicio a una máquina virtual, puede que no sea capaz de llevar seguridad de todo el
sistema en su máquina local. Esto puede resultar en la necesidad de apagar algunas
dependencias de hacer las cosas manejables, que es una cosa más que tendrá que
manejar para asegurar que la experiencia de desarrollo y prueba es una buena.
Linux Contenedores
Para los usuarios de Linux, hay una alternativa a la virtualización. En lugar de tener
una visera hiper para segmentar y control de máquinas virtuales separados, los
contenedores de Linux en vez crean un espacio separado proceso en el que viven
otros procesos.
126| Capítulo 6: Despliegue
En Linux, el proceso se ejecute por un usuario dado, y tienen ciertas capacidades en
función de cómo se establecen los permisos. Los procesos pueden generar otros
procesos. Por ejemplo, si pongo en marcha un proceso en un terminal, que el proceso
hijo se considera generalmente un hijo del proceso terminal. El trabajo del núcleo de
Linux es el mantenimiento de este árbol de procesos.
De físico a virtual | 127
contenedores Linux extienden esta idea. Cada contenedor es efectivamente un subárbol del árbol del proceso global del sistema. Estos contenedores pueden tener
recursos físicos asignados a ellos, algo que el kernel maneja para nosotros. Este
enfoque general ha existido en muchas formas, tales como las zonas y OpenVZ
Solaris, pero es LXC que se ha convertido lar más pobla-. LXC ya está disponible
fuera de la caja en cualquier moderna núcleo de Linux.
Si nos fijamos en un diagrama de pila para un host que ejecuta en LXC Figura 6-9,
Vemos unas cuantas diferencias. En primer lugar, no necesitamos un hipervisor. En
segundo lugar, aunque cada contenedor puede ejecutar su propia distribución del
sistema operativo, tiene que compartir el mismo núcleo (porque el núcleo es donde
vive el árbol de procesos). Esto significa que nuestro sistema operativo anfitrión
podría ejecutar Ubuntu, y nuestros contenedores de CentOS, siempre y cuando
ambos podrían compartir el mismo núcleo.
Nosotros no hacemos acaba de beneficiarse de los recursos que se ahorran al no tener
un hipervisor. También ganamos en términos de retroalimentación. contenedores de
Linux son mucho más rápidos a la provisión de máquinas virtuales con toda la grasa.
No es raro que una máquina virtual para tomar muchos minutos para empezar, pero
con los contenedores de Linux, el arranque puede tardar unos segundos. También
tiene un control más preciso sobre los propios contenedores en términos de
asignación de recursos para ellos, lo que hace que sea mucho más fácil de ajustar los
ajustes para obtener el máximo rendimiento del hardware subyacente.
Debido a la naturaleza del ligero-peso de los contenedores, podemos tener muchos
más de ellos escorrentías Ning en el mismo hardware que sería posible con las
máquinas virtuales. Mediante el despliegue de un ser- vicio por contenedor, como
enFigura 6-10, Se obtiene un grado de aislamiento de otros contenedores (aunque
esto no es perfecto), y podemos hacer mucho más rentable de lo que sería posible si
queríamos ejecutar cada servicio en su propia máquina virtual.
La figura 6-10. Servicios en ejecución en recipientes separados
128| Capítulo 6: Despliegue
Los contenedores pueden ser utilizados también con la virtualización de grasa natural
también. He visto más de una disposición del proyecto un gran ejemplo de ejecución
y LXC contenedores AWS EC2 en él para obtener la
De físico a virtual | 129
mejor de ambos mundos: una plataforma de computación efímero en la demanda en
forma de EC2, junto con contenedores altamente flexibles y rápidas que se ejecuta en
la parte superior de la misma.
contenedores de Linux no dejan de tener algunos problemas, sin embargo. Imagínese
que tengo un montón de microservicios que se ejecutan en sus propios contenedores
en un host. ¿Cómo funciona el mundo exterior ha de ver? Usted necesita alguna
manera de encaminar el mundo exterior a través de los contenedores subyacentes,
algo que muchos de los hipervisores hacer por usted con la virtualización normal. He
visto a muchos una persona se hunden enormes cantidades de tiempo en la
configuración de puerto de lucro alejar el uso de iptables para exponer directamente a
los contenedores. Otro punto a tener en cuenta es que estos recipientes no pueden
considerarse completamente sellados el uno del otro. Hay muchas maneras
documentados y conocidos en los que un proceso de un recipiente puede reventar
hacia fuera e interactuar con otros recipientes o el huésped subyacente. Algunos de
estos problemas son por diseño y algunos son insectos que se están abordando, pero
de cualquier manera, si usted no confía en el código que está ejecutando, no
esperamos que se puede ejecutar en un con- tainer y estar seguro. Si necesita ese tipo
de aislamiento, tendrá que considerar el uso de máquinas vir- tuales en su lugar.
Estibador
Docker es una plataforma construida en la parte superior de envases ligeros. Se
ocupa gran parte del trabajo en torno a la manipulación de contenedores para usted.
En estibador, crear y desplegar aplicaciones, que son sinónimo de imágenes en el
mundo VM, si bien por una plataforma basada en contenedores. Acoplable gestiona
el aprovisionamiento de contenedores, se ocupa de algunos de los problemas que el
trabajo en red para usted, e incluso ofrece su propio concepto de registro que le
permite almacenar y aplicaciones de la versión acoplables.
La aplicación de la abstracción del estibador es un útil para nosotros, ya que al igual
que con imágenes de VM la tecnología subyacente que se utiliza para implementar el
servicio se nos oculta. Tenemos nuestra construye para nuestros servicios crean
aplicaciones acoplables, y los almacenan en el REG-terio del estibador, y allá vamos.
Acoplable también puede aliviar algunas de las desventajas de correr una gran
cantidad de servicios a nivel local para fines de pruebas y desarrollo. En lugar de
utilizar Vagrant para albergar varias máquinas virtuales independientes, cada uno con
su propio servicio, podemos albergar una única máquina virtual que se ejecuta en
Vagrant una instancia del estibador. A continuación, utilizamos Vagrant de
configurar y derribar la plataforma acoplable en sí, y el uso del estibador para el
aprovisionamiento rápido de los servicios individuales.
Se están desarrollando una serie de diferentes tecnologías para aprovechar estibador.
CoreOS es un sistema operativo muy interesante diseñado con estibador en mente. Es
un sistema operativo Linux reducidos al mínimo, que ofrece sólo los servicios
esenciales para permitir acoplable a ejecutar. Esto significa que consume menos
130| Capítulo 6: Despliegue
recursos que otros sistemas operativos, por lo que es posible dedicar más recursos de
la máquina subyacente a nuestros ERS contención. En lugar de utilizar un gestor de
paquetes como Debs o RPM, todo el software se instala como aplicaciones
independientes acoplables, cada una ejecutando en su propio contenedor.
De físico a virtual | 131
misma ventana acoplable no resuelve todos los problemas para nosotros. Piense en
ello como un simple PaaS que trabaja en una sola máquina. Si quieres herramientas
para ayudarle a gestionar servicios a través de varias instancias acoplables a través de
múltiples máquinas, usted tiene que mirar a otro software que añade estas
capacidades. Hay una necesidad clave para una capa de programación que le deja
solicitar un recipiente y luego encuentra un recipiente acoplable que puede funcionar
para usted. En este espacio, recientemente, de código abierto y de Kubernetes
CoreOS tecnología de clúster de Google puede ayudar, y parece que cada mes hay un
nuevo participante en este espacio.Deis es otra herramienta intere- sante basado en
acoplable, que se intenta proporcionar un Heroku-como PaaS en la parte superior de
acoplable.
He hablado anteriormente acerca de soluciones PaaS. Mi lucha con ellos siempre ha
sido que a menudo obtienen el nivel de abstracción mal, y que las soluciones de autoorganizado un importante retraso soluciones alojadas como Heroku. Docker se hace
mucho más de este derecho, y la explosión de interés en este espacio significa que
sospecho que se convertirá en una plataforma mucho más viable para todo tipo de
despliegues en los próximos años para todo tipo de diferentes casos de uso. En
muchos sentidos, acoplable con una capa de programación adecuado se encuentra
entre IaaS y soluciones de los PAA contenedores plazo como un servicio (CaaS) ya
está siendo utilizado para describirlo.
Acoplable está siendo utilizado en la producción de múltiples empresas. Se
proporciona muchos de los beneficios de envases ligeros en términos de eficiencia y
velocidad de aprovisionamiento, junto con las herramientas para evitar muchas de las
desventajas. Si usted está interesado en ing Look-a plataformas de despliegue
alternativos, me gustaría sugerir fuertemente a dar una mirada del estibador.
Una interfaz de despliegue
Lo que subyace a la plataforma o artefactos que utiliza, que tiene una interfaz
uniforme para desplegar un servicio dado es vital. Vamos a querer desencadenar el
despliegue de un microService en la demanda en una variedad de situaciones
diferentes, desde las implementaciones a nivel local para dev y prueba para los
despliegues de producción. También vamos a querer mantener los mecanismos de
despliegue lo más similar posible a partir dev para la producción, como el último que
queremos es encontrar a nosotros mismos golpear problemas en la producción a
causa de despliegue utiliza un proceso completamente diferente!
Después de muchos años de trabajo en este espacio, estoy convencido de que la
manera más sensata para activar cualquier despliegue es a través de una simple
llamada de línea de comandos, parametrizable. Esto puede ser provocado por
guiones, puesto en marcha por su herramienta de CI, o ha escrito a mano. He
construido guiones envoltura en una variedad de tecnología de pilas para hacer este
trabajo, a partir de Windows por lotes, para golpear, a scripts de Python tela, y
mucho más, pero todas las líneas de comandos comparten el mismo formato básico.
Una interfaz de despliegue |
127
Necesitamos saber lo que estamos desplegando, por lo que necesitamos para
proporcionar el nombre de una entidad conocida, o en nuestro caso un microService.
También necesitamos saber qué versión de la entidad que queremos. La respuesta a
qué versión tiende a ser una de las tres posibilidades. Cuando
128| Capítulo 6: Despliegue
estás trabajando a nivel local, que va a ser cualquier versión está en su máquina local.
Cuando Exámenes, querrá la versión más reciente verde, que solo podría ser el más
reciente artefacto bendita en nuestro repositorio de artefactos. O cuando se prueba /
diagnóstico de problemas, es posible que desee implementar una acumulación exacta.
La tercera y última cosa que necesitamos saber es qué ambiente queremos que el
servicio de micro desplegado dentro. Como hemos comentado anteriormente, la
topología de nuestra microService puede diferir de un ambiente a otro, pero que debe
ser escondido de nosotros aquí.
Así que, imaginamos, creamos un script de despliegue simple que toma estos tres
parámetros. Decimos que estamos desarrollando a nivel local y desee implementar
nuestro servicio de catálogo en nuestro medio local. Yo podría escribir:
$ Desplegar artefacto = entorno de catálogos = versión local = local
Una vez que me he registrado, nuestro servicio de acumulación IC recoge el cambio
y crea un nuevo artefacto de construcción, lo que le da el número de compilación
B456. Como es habitual en la mayoría de las herramientas de CI, este valor se pasa a
lo largo de la tubería. Cuando nuestra fase de prueba se desencadena, la etapa de CI
se ejecutará:
$ Desplegar artefacto = Catálogo de entorno = ci = versión B456
Mientras tanto, nuestro control de calidad quiere tirar de la última versión del
servicio de catálogo en un entorno de prueba inte- grado para hacer algunas pruebas
exploratorias, y para ayudar con un escaparate. Que corre del equipo:
$ Desplegar artefacto = entorno de catálogos = versión más reciente integrated_qa =
La herramienta que he utilizado la mayor parte de esto es la tela, una biblioteca de
Python diseñada para mapear la línea de comandos llamadas a funciones, junto con
un buen apoyo para el manejo de tareas como SSH a máquinas remotas.
Sincronizarlo con una biblioteca de cliente de AWS como Boto, y usted tiene todo lo
necesario para automatizar totalmente los grandes entornos de AWS. Para Ruby,
capi- strano es similar en algunos aspectos a la tela, y en Windows que podría hacer
mucho uso de PowerShell.
Definición de Medio Ambiente
Es evidente que, para que esto funcione, tenemos que tener alguna manera de definir
lo que nuestros ambientes parecen, y lo que nuestro servicio se ve como en un
entorno determinado. Se puede pensar en una definición de entorno como una
asignación de un microService para calcular, la red y los recursos de
almacenamiento. He hecho esto con los archivos YAML antes, y utilicé mis scripts
para extraer estos datos en.Ejemplo 6-1 es una versión simplificada de un trabajo que
hice hace un par de años para un proyecto que utiliza AWS.
Una interfaz de despliegue |
129
Ejemplo 6-1. Un ejemplo de definición de entorno
desarrollo:
nodos:
- ami_id: ami-e1e1234
Tamaño: t1.micro
credentials_name: eu-oeste-ssh
servicios: [Catálogo de
servicios] Región: eu-oeste-1
producción:
nodos:
- ami_id: Tamaño amie1e1234: m3.xlarge
credentials_name: Prod-credenciales
servicios: [Catálogo de servicios]
número 5
Hemos variado el tamaño de las instancias que utilizamos para ser más rentable.
Usted no necesita una caja de 16 núcleos con 64 GB de RAM para pruebas
exploratorias!
Ser capaz de especificar credenciales diferentes para diferentes entornos es la
clave. dentials CRE para entornos sensibles se almacenan en diferentes
repositorios de código fuente que sólo seleccionar las personas tendrían acceso a.
Decidimos que, por defecto, si un servicio tenía más de un nodo configurado,
queremos crear automáticamente un equilibrador de carga para él.
He eliminado algunos detalles en aras de la brevedad.
La información del catálogo de servicio se almacena en otro lugar. No difieren de un
ambiente a otro, como se puede ver enEjemplo 6-2.
Ejemplo 6-2. Un ejemplo de definición de entorno
Catálogo de servicios:
puppet_manifest: catalog.pp
conectividad:
- Protocolo: TCP
[puertos: 8080, 8081 ]
permitido: [ MUNDO ]
Este era el nombre del archivo de marionetas de gestión pasamos a utilizar la
marioneta en solitario en esta situación, pero en teoría podría haber apoyado los
sistemas alternativos de configuración.
130| Capítulo 6: Despliegue
Obviamente, una gran parte del comportamiento que aquí se basó convención. Por
ejemplo, decidimos normalizar los puertos que utilizan los servicios dondequiera que
corrían, y equilibradores de carga de forma automática ured CONFIG- si un servicio
tenía más de una instancia (algo que ELB de AWS hacen bastante fácil).
La construcción de un sistema como este requiere una cantidad significativa de
trabajo. El esfuerzo es a menudo delante carga-, pero puede ser fundamental para
gestionar la complejidad de la instalación que tiene. Espero que en el futuro no tendrá
que hacerlo usted mismo. Terraform es una nueva herramienta de Hashicorp, que
trabaja en este espacio. Me había generalmente asusto de mencionar una nueva
herramienta de este tipo en un libro que es más acerca de las ideas que la tecnología,
pero es ing Si se intenta crear una herramienta de código abierto a lo largo de estas
líneas. Es pronto todavía, pero ya sus capacidades parece muy interesante. Con la
capacidad de dirigirse a los despliegues en un nú- mero de diferentes plataformas, en
el futuro podría ser sólo la herramienta para el trabajo.
Resumen
Hemos cubierto mucho terreno aquí, así que una recapitulación está en orden. En
primer lugar, se centran en el mantenimiento de la capacidad de liberar un servicio
independiente de los otros, y asegurarse de que cualquier tecnología que admite esta
opción. Yo prefiero mucho tener un solo toria reposi- por microService, pero todavía
estoy más firme que necesita una acumulación de CI por microService si desea
implementar por separado.
A continuación, si es posible, mover a un solo servicio por host / contenedor. Mira
tecnolo- gías alternativas como LXC o acoplable a hacer la gestión de las partes
móviles más barato y más fácil, pero entender que cualquier tecnología que se
adopta, una cultura de la automatización es clave para manejar todo. Automatizar
todo, y si la tecnología que tiene no lo permite, obtener una nueva tecnología! Ser
capaz de utilizar una plataforma como AWS le dará enormes beneficios en lo que
respecta a la automatización.
Asegúrese de entender el impacto de sus opciones de implementación tienen en los
desarrolladores, y asegúrese de que sienten el amor también. La creación de
herramientas que le permiten auto-servicio-implementar un servicio determinado en
un número de diferentes entornos es muy importante, y ayudará a los desarrolladores,
probadores, y personal de operaciones por igual.
Por último, si quieres profundizar más en este tema, yo bien recomiendo que lea Jez
Humble y entrega continua de David Farley (Addison-Wesley), que entra en muchos
más detalles sobre temas como diseño de la tubería y la gestión artefacto.
En el siguiente capítulo, vamos a ir más profundo en un tema hemos tocado
brevemente aquí. Es decir, ¿cómo podemos probar nuestros microservicios para
asegurarse de que funcionan realmente?
Una interfaz de despliegue |
131
CAPÍTULO
7
Prueba
s
El mundo de las pruebas automatizadas ha avanzado significativamente desde que
empecé a escribir código, y cada mes parece que hay una nueva herramienta o
técnica para que sea aún mejor. Pero sigue habiendo problemas como la forma de
probar con eficacia y eficiencia de nuestro funcional- idad cuando se extiende por un
sistema distribuido. En este capítulo se rompe los problemas asocia- dos con los
sistemas de pruebas de grano más fino y presenta algunas soluciones para ayudar a
asegurarse de que puede liberar su nueva funcionalidad con confianza.
Pruebas cubre mucho terreno. Incluso cuando estamos hablando de pruebas
automatizadas, hay un gran número de considerar. Con microservicios, hemos
añadido otro nivel de complejidad. La comprensión de lo que los diferentes tipos de
pruebas que pueden correr es impor- tante para ayudar a equilibrar las fuerzas
opuestas a veces de conseguir nuestro software en producción lo más rápido posible
frente asegurándose de nuestro software es de suficiente calidad.
Tipos de pruebas
Como consultor, me gusta sacar el cuadrante extraño como una forma de categorizar
el mundo, y yo estaba empezando a preocuparse por este libro no tendría uno. Por
suerte, Brian Marick subió con un sistema de categorización fantástica para las
pruebas que encaja a la perfección.Figura 7-1 muestra una variación del cuadrante de
Marick de Lisa Crispin y el libro de Janet Gregory Agile Testing (Addison-Wesley)
que ayuda a clasificar los diferentes tipos de pruebas.
131
Figura 7-1. cuadrante prueba de Brian Marick. Crispin, Lisa; Gregory, Janet,
pruebas ágil: Una guía práctica para los probadores y equipos ágiles, 1ª edición, ©
2009. Adaptado por per- miso de Pearson Education, Inc., Upper Saddle River,
Nueva Jersey.
En la parte inferior, tenemos pruebas de que son la tecnología orientada, es decir,
pruebas que ayudan a los desarrolladores en la creación del sistema en el primer
lugar. Las pruebas de rendimiento y las pequeñas pruebas de unidad de ámbito entran
en esta categoría, todo normalmente automatizado. Esto se compara con la mitad
superior del cuadrante, donde las pruebas ayudan a las partes interesadas no técnicos
entienden cómo funciona el sistema. Estos podrían ser de gran restringidos, pruebas
de extremo a extremo, como se muestra en la plaza Prueba de Aceptación parte
superior izquierda, o pruebas manuales como tipificado por las pruebas de usuario
hecho en contra de un sistema de UAT, como se muestra en la plaza pruebas
exploratorias.
Cada tipo de prueba que se muestra en este cuadrante tiene un lugar. Exactamente
qué cantidad de cada prueba que desea hacer dependerá de la naturaleza de su
sistema, pero el punto clave de soporte inferior es que tiene múltiples opciones en
cuanto a la forma de probar su sistema. La tendencia reciente ha estado lejos de
cualquier prueba manual a gran escala, a favor de automatizar tanto como sea
posible, y desde luego de acuerdo con este enfoque. Si lleva a cabo actualmente una
gran cantidad de pruebas manuales, sugeriría a abordar que antes de proceder
demasiado lejos por el camino de microservicios, ya que no se obtiene muchos de sus
beneficios si no puede validar su software de forma rápida y eficiente.
A los efectos de este capítulo, vamos a hacer caso omiso de las pruebas manuales.
Aunque este tipo de pruebas puede ser muy útil y sin duda tiene un papel que
desempeñar, las diferencias con la prueba de una arquitectura microService su
mayoría se manifiestan en el contexto de diversos tipos de automatización pone a
prueba ted, así que es donde nos vamos a centrar nuestro tiempo.
Pero cuando se trata de pruebas automatizadas, ¿cuántos de cada prueba es lo que
queremos? Otro modelo vendrá en muy práctico para ayudar a responder a esta
pregunta, y entender cuáles podrían ser las diferentes ventajas y desventajas.
132| Capítulo 7: Prueba
Alcance de la prueba
En su libro El tener éxito con Agile (Addison-Wesley), Mike Cohn esboza un
modelo llamado la Pirámide de prueba para ayudar a explicar qué tipos de pruebas
automatizadas que necesita. los
Alcance de prueba |
133
pirámide nos ayuda a pensar acerca de los alcances de las pruebas deben cubrir, sino
también las proporciones de los diferentes tipos de pruebas que debemos aspirar. El
modelo original de Cohn divide automatización ted pone a prueba a la Unidad,
Servicio, y la interfaz de usuario, que se puede ver enFigura 7-2.
Figura 7-2. Pirámide de prueba de Mike Cohn. Cohn, Mike, teniendo éxito con ágil:
desarrollo de software utilizando Scrum, 1ª Edición, © 2010. Adaptado con permiso
de Pearson Edu- cación, Inc., Upper Saddle River, Nueva Jersey.
El problema con este modelo es que todos estos términos significan cosas diferentes
para diferentes personas. “Servicio” es especialmente sobrecargado, y hay muchas
definiciones de una prueba de unidad que hay. Es una prueba de una prueba de
unidad si sólo prueba de una línea de código? Yo diría que sí. ¿Sigue siendo una
prueba de unidad si el test múltiples funciones o clases? Yo diría que no, pero
muchos no estaría de acuerdo! Tiendo a seguir con la unidad y nombres de servicios
a pesar de su ambigüedad, pero prefiero llamar a las pruebas de interfaz de usuario de
extremo a extremo pruebas, que vamos a hacer a partir de ahora.
Dada la confusión, vale la pena mirar a nosotros lo que significan estas diferentes
capas.
Veamos un ejemplo práctico. EnFigura 7-3, Tenemos nuestra aplicación de servicio
de ayuda y nuestro principal sitio web, ambos de los cuales están interactuando con
nuestro servicio al cliente para recuperar, revisar y editar los datos del cliente.
Nuestro servicio al cliente a su vez está hablando con nuestro banco loy- puntos Alty,
donde nuestros clientes acumulan puntos por la compra de Justin Bieber CDs.
Probablemente. Esto es obviamente una astilla de nuestro sistema global tienda de
música, pero es una buena tajada suficiente para nosotros para sumergirse en una
serie de escenarios diferentes es posible que desee probar.
134| Capítulo 7: Prueba
Figura 7-3. Parte de nuestra tienda de música que se está probando
Alcance de prueba |
135
Las pruebas unitarias
Estas son pruebas que típicamente ensayan una función o método sola llamada. Las
pruebas generados como un efecto secundario de guiado por pruebas de diseño
(TDD) caerán dentro de esta categoría, como lo hacen los tipos de pruebas generados
por técnicas tales como la prueba basada en la propiedad. No estamos lanzamiento de
servicios de aquí, y está limitando el uso de archivos externos o conexiones de red.
En general, usted quiere un gran número de este tipo de pruebas. Si se hace bien, son
muy, muy rápido, y en el hardware moderno que se puede esperar para ejecutar
muchos miles de estos en menos de un minuto.
Estas son pruebas que nos ayudan a los desarrolladores y así sería la tecnología
orientada, no orientada hacia el negocio, en la terminología de Marick. Son también
donde esperamos captar la mayor parte de nuestros errores. Así, en nuestro ejemplo,
cuando pensamos en el servicio al cliente, las pruebas unitarias cubrirían pequeñas
partes del código de forma aislada, como se muestra enFigura 7-4.
Figura 7-4. Ámbito de aplicación de las pruebas de unidad en nuestro sistema de
ejemplo
El principal objetivo de estas pruebas es para darnos una respuesta muy rápida acerca
de si nuestro funcio- nalidad es buena. Las pruebas pueden ser importantes para
apoyar a la refactorización de código, lo que nos permite reestructurar nuestro código
a medida que avanzamos, sabiendo que nuestras pruebas pequeñas de ámbito nos
cogerán si hacemos un error.
pruebas de servicio
pruebas de servicio están diseñados para pasar por alto los servicios de interfaz de
usuario y una prueba directa. En una aplicación monolítica, que sólo podría estar
probando una colección de clases que proporcionan un servicio a la interfaz de
usuario. Para un sistema que comprende una serie de servicios, una prueba de
servicio pondría a prueba las capacidades de un servicio individual.
La razón por la que queremos probar un único servicio por sí mismo es mejorar el
aislamiento de la prueba para encontrar y corregir problemas con mayor rapidez. Para
lograr este aislamiento, tenemos que apagar todos los colaboradores externos de
modo que sólo el servicio en sí es en su alcance, comoFigura 7-5 muestra.
136| Capítulo 7: Prueba
Figura 7-5. Ámbito de aplicación de pruebas de servicio en nuestro sistema de ejemplo
Algunas de estas pruebas podrían ser tan rápido como pequeñas pruebas, pero si
usted decide poner a prueba contra una base de datos real, o ir a través de redes de
colaboradores aguas abajo tropezados, los tiempos de prueba puede aumentar.
También cubren más amplio que una simple prueba de unidad, de manera que
cuando no puede ser más difícil de detectar lo que está roto que con una prueba de
unidad. Sin embargo, tienen mucho menos partes móviles y por lo tanto son menos
frágiles que las pruebas más grande con ámbito.
Las pruebas de extremo a extremo
pruebas de extremo a extremo son las pruebas realizadas en contra de todo el sistema.
A menudo se conduce una interfaz gráfica de usuario a través de un navegador, pero
podrían ser fácilmente imitando a otros tipos de interacción con el usuario, al igual
que la posibilidad de subir un archivo.
Estas pruebas abarcan una gran cantidad de código de producción, como vemos en
Figura 7-6 . Así que cuando pasan, que se siente bien: usted tiene un alto grado de
confianza de que el código está probando trabajará en la producción. Pero este
aumento de alcance viene con desventajas, y como veremos en breve, que puede ser
muy difícil de hacer bien en un contexto microservicios.
Figura 7-6. Ámbito de aplicación de pruebas de extremo a extremo en nuestro sistema
de ejemplo
Las compensaciones
Cuando estás leyendo la pirámide, la clave para llevar es que a medida que suben la
Alcance de prueba |
137
pirámide, el alcance aumenta de prueba, al igual que nuestra confianza en que la
funcionalidad está probando obras. Por otro lado, el tiempo de ciclo de
retroalimentación aumenta a medida que las pruebas tardan más en ejecutarse, y
cuando falla una prueba que puede ser más difícil de determinar qué funcionalidad
138| Capítulo 7: Prueba
ha roto. Al bajar la pirámide, en general, las pruebas se hacen mucho más rápido, por
lo que consiguen ciclos de retroalimentación mucho más rápido. Nos encontramos
con funcionalidad rota más rápido, nuestra integración ous continua- construye son
más rápidos, y es menos probable de pasar a una nueva tarea antes de descubrir algo
que han roto. Cuando esas pruebas más pequeñas de ámbito fallan, también tienden a
saber lo que se rompió, a menudo exactamente qué línea de código. En el otro lado,
no obtenemos mucha confianza de que nuestro sistema en su conjunto funciona si
sólo hemos probado una línea de código!
Cuando los ensayos más amplios de ámbito como nuestro servicio o pruebas de
extremo a extremo fallan, vamos a tratar de escribir una prueba unitaria rápido para
alcanzar ese problema en el futuro. De esta manera, estamos constantemente tratando
de mejorar nuestros ciclos de retroalimentación.
Prácticamente cada equipo que he trabajado ha utilizado diferentes nombres que los
que Cohn utiliza en la pirámide. Lo que usted le llama, el punto clave es que tendrá
que pruebas de alcance diferente para diferentes propósitos.
¿Cuántos?
Así que si todas estas pruebas tienen ventajas y desventajas, ¿cuántos de cada tipo lo
que quiere? Una buena regla general es que es probable que desee un orden de
magnitud más pruebas a medida que desciende la pirámide, pero lo importante es
saber que tienen diferentes tipos de pruebas automatizadas y comprensión si su saldo
actual le da un problema!
Trabajé en un sistema monolítico, por ejemplo, donde tuvimos 4.000 pruebas de
unidad, 1.000 pruebas de servicio, y 60 pruebas de extremo a extremo. Hemos
decidido que desde el punto de vista de retroalimentación que teníamos demasiados
servicio y pruebas de extremo a extremo (el último de los cuales eran los peores
delincuentes en impactando bucles de retroalimentación), por lo que hemos trabajado
duro para sustituir la prueba con la cubierta bajo más pequeña pruebas -scoped.
Un anti-patrón común es lo que se refiere a menudo como un cono de nieve de
prueba, o de pirámide invertida. Aquí, hay poco que no hay pruebas pequeñas de
ámbito, con toda la cobertura de las pruebas a gran con ámbito. Estos proyectos
suelen tener pruebas de funcionamiento sumamente lento, y muy largo Feed- volver
ciclos. Si estas pruebas se ejecutan como parte de la integración continua, no
obtendrá muchas construcciones, y la naturaleza de los tiempos de construcción
significa que la construcción puede permanecer roto por un largo período cuando
algo se rompe.
La implementación de pruebas de servicio
La implementación de pruebas de unidad es un asunto bastante simple en el gran
esquema de las cosas, y hay un montón de documentación por ahí explicando cómo
escribirlas. Las pruebas de servicio y de extremo a extremo son los que son más
Alcance de prueba |
139
interesantes.
Nuestras pruebas de servicio quieren probar una rebanada de funcionalidad a través
de todo el servicio, pero a aislarnos de otros servicios que tenemos que encontrar la
manera de apagar todos nuestros colaboradores. Por lo tanto, si queríamos escribir
una prueba de este tipo para el servicio al cliente de
140| Capítulo 7: Prueba
Figura 7-3, Queremos implementar una instancia del servicio al cliente, y como se
explicó anteriormente nos gustaría apagar cualquier servicio de aguas abajo.
Una de las primeras cosas que nuestra acumulación continua integración hará es
crear un hecho arti- binario para nuestro servicio, por lo desplegando es bastante
sencillo. Pero ¿cómo lo manejamos falsificar los colaboradores aguas abajo?
Nuestra serie de pruebas de servicio necesita para poner en marcha los servicios de
derivación para cualquier colaboradores aguas abajo (o garantizar que se ejecuta), y
configurar el servicio que se está probando para conectarse a los servicios de código
auxiliar. entonces tenemos que configurar los talones para enviar respuestas de nuevo
a imitar los servicios del mundo real. Por ejemplo, podríamos configurar el código
auxiliar para el banco puntos de fidelidad para volver conocidos saldos puntos para
ciertos clientes.
Burlándose o Stubbing
Cuando hablo de stubbing colaboradores aguas abajo, quiero decir que nosotros
creamos un servicio de código auxiliar que responde con respuestas enlatadas a las
solicitudes conocidos del servicio, utilizando la prueba. Por ejemplo, podría decirle a
mi banco de puntos de código auxiliar que cuando se le preguntó por el Ance equilide cliente 123, debe devolver 15.000. La prueba no le importa si el talón se llama 0,
1, o 100 veces. Una variante de esto es utilizar una maqueta en lugar de un trozo.
Cuando se utiliza una maqueta, en realidad van más allá y aseguro se realizó la
llamada. Si no se realiza la llamada esperada, la prueba falla. La implementación de
este enfoque requiere más inteligencia en los colaboradores falsos que creamos, y si
se abusa puede provocar que las pruebas se vuelvan frágiles. Como se ha señalado,
sin embargo, un talón no le importa si se llama 0, 1, o muchas veces.
A veces, sin embargo, se burla puede ser muy útil para asegurar que los efectos
secundarios esperados ocurren. Por ejemplo, puede ser que desee comprobar que
cuando se crea un cliente, un equilibrio nuevos puntos está configurado para ese
cliente. El equilibrio entre tropezar y llamadas ING maqueta es delicado, y es tan
plagado de pruebas de servicio como en las pruebas unitarias. En ge- neral, sin
embargo, yo uso mucho más que los trozos se burla de pruebas de servicio. Para una
discusión más a fondo de esta disyuntiva, echar un vistazo a crecer de software
orientado a objetos, guiada por pruebas, por Steve Freeman y Nat Pryce (AddisonWesley).
En general, rara vez usar burla para este tipo de pruebas. Sin embargo, tener una
herramienta que puede hacer ambas cosas es útil.
Aunque siento que los trozos y se burla de hecho son bastante bien diferenciada, sé
que la distinción puede ser confuso para algunos, especialmente cuando algunas
personas tiran en otros términos como falsificaciones, espías y maniquíes. Martin
Fowler llama a todas estas cosas, incluyendo talones y se burla,dobles de prueba.
Implementar el servicio de
exámenes | 137
Un servicio más inteligente del trozo
Normalmente, para los servicios del trozo Los he rodé. He usado todo de Apache o
Nginx a los contenedores Jetty incrustados o servidores web de Python, incluso la
línea de comandos lanzados utilizados para poner en marcha los servidores de código
auxiliar para tales casos de prueba. Probablemente he reproducido el mismo tiempo
de trabajo una y otra vez en la creación de estos talones. Mi colega ThoughtWorks
Brandon Bryars ha salvado potencialmente muchos de nosotros un trozo de trabajo
con su talón / servidor maqueta llamadaSaltimbanqui.
Se puede pensar en charlatán como un pequeño dispositivo de software que se puede
programar a través de HTTP. El hecho de que pasa a ser escrito en NodeJS es
completamente opaca a cualquier servicio de llamadas. Cuando se pone en marcha,
lo envía comandos le dice qué puerto al código auxiliar, qué protocolo para manejar
(actualmente TCP, HTTP, HTTPS y son compatibles, con más planificado), y qué
respuestas se debe enviar cuando se envían las solicitudes. También SUP- puertos de
ajuste expectativas si desea utilizarlo como una maqueta. Puede añadir o eliminar
estos criterios de valoración del trozo a voluntad, por lo que es posible que una sola
instancia charlatán de código auxiliar más de una dependencia de aguas abajo.
Entonces, si queremos ejecutar nuestras pruebas de servicio por sólo nuestro servicio
al cliente se puede poner en marcha el servicio al cliente, y una instancia de charlatán
que actúa como nuestro banco puntos de fidelidad. Y si pasan estas pruebas, puedo
desplegar la recta servicio al cliente! O ¿verdad? ¿Qué pasa con los servicios que
requieren el servicio al cliente servicio de asistencia y la tienda web? ¿Sabemos si
hemos hecho un cambio que puede romper? Por supuesto, nos hemos olvidado de las
pruebas importantes en la parte superior de la pirámide: las pruebas de extremo a
extremo.
Esos Tricky pruebas de extremo a extremo
En un sistema microService, las capacidades que se exponen a través de nuestras
interfaces de usuario se emitirá según una serie de servicios. El punto de las pruebas
de extremo a extremo como se indica en la pirámide de Mike Cohn es conducir
funcionalidad a través de estas interfaces de usuario contra every- cosa debajo para
darnos una visión general de una gran cantidad de nuestro sistema.
Así, para implementar una prueba de extremo a extremo que necesitamos para
desplegar múltiples servicios juntos, a continuación, ejecutar una prueba contra todos
ellos. Obviamente, esta prueba tiene mucho más alcance, ing result- en más
confianza de que nuestro sistema funciona! Por otra parte, estas pruebas se LIA- ble
que sea más lento y que sea más difícil de diagnosticar la insuficiencia. Vamos a
profundizar en ellos un poco más con el ejemplo anterior para ver cómo estas
pruebas pueden encajar.
Imaginemos que queremos empujar a cabo una nueva versión del servicio al cliente.
138| Capítulo 7: Prueba
Queremos desplegar nuestros cambios en la producción tan pronto como sea posible,
pero preocupa que hayamos introducido un cambio que podría romper o bien el
servicio de asistencia o la tienda web. No hay problema, vamos a desplegar todos
nuestros servicios juntos, y hacer algunas pruebas en contra de la asistencia y site de
la tienda para ver si hemos introducido un error. Ahora, un enfoque ingenuo sería
sólo tiene que añadir estas pruebas en el extremo de nuestra línea de servicio al
cliente, al igual que enFigura 7-7.
Implementar el servicio de
exámenes | 139
Figura 7-7. La adición de nuestra etapa de pruebas de extremo a extremo: el enfoque
correcto?
Hasta aquí todo bien. Pero la primera pregunta que tenemos que hacernos es qué
versión de los otros servicios deberíamos usar? ¿Hay que manejamos nuestras
pruebas en contra de las versiones de escritorio y ayuda- site de la tienda que están en
producción? Es una suposición razonable, pero lo que si hay una nueva versión de
cualquiera de los servicio de asistencia o site de la tienda en cola para ir a vivir; ¿Qué
debemos hacer entonces?
Otro problema: si tenemos un conjunto de pruebas de servicio al cliente que
despliegan una gran cantidad de servicios y ejecutar pruebas contra ellos, ¿qué pasa
con las pruebas de extremo a extremo que los otros servicios se ejecutan? Si ellos
están probando lo mismo, nos podemos encontrar que cubre porciones de la misma
planta, y puede duplicar una gran cantidad de esfuerzo para desplegar todos aquellos
servicios en el primer lugar.
Nosotros puede hacer frente a estos dos problemas elegantemente por tener ventilador
de múltiples tuberías a una sola etapa de prueba, de extremo a extremo. En este caso,
cada vez que se activa una nueva versión de uno de nuestros servicios, en que
manejamos nuestras pruebas de extremo a extremo, un ejemplo de lo que podemos
ver enFigura 7-8. Algunas herramientas de CI con un mejor soporte de tuberías de
construcción permitirán a los modelos de abanico de entrada de este tipo fuera de la
caja.
Figura 7-8. Una forma estándar para manejar pruebas de extremo a extremo a través
de los servicios
Así cualquier momento cualquiera de nuestros cambios de servicios, que ejecutan las
Esos Tricky pruebas de extremo a
extremo | 139
pruebas locales a ese servicio. Si se superan estas pruebas, provocamos nuestras
pruebas de integración. Grande, ¿eh? Bueno, hay algunos problemas.
140 | Capítulo 7: Prueba
Los inconvenientes de extremo a extremo de
análisis
Hay, por desgracia, muchas desventajas a extremo a extremo de análisis.
Las pruebas de hojaldre y quebradizo
A medida que aumenta el alcance de prueba, también lo hacen el número de partes
móviles. Estas partes móviles pueden introducir fallos de las pruebas que no
muestran que la funcionalidad que se está probando es Bro-ken, pero que se ha
producido algún otro problema. A modo de ejemplo, si tenemos una prueba para
comprobar que podemos realizar un pedido de un solo CD, pero estamos corriendo
esa prueba en contra de cuatro o cinco servicios, si alguno de ellos es abajo
podríamos obtener un fallo que no tiene nada que ver con la naturaleza de la prueba
en sí. Del mismo modo, un fallo temporal de la red podría causar un error de la
prueba sin decir nada acerca de la funcionalidad que se está probando.
Los más partes móviles, el más frágil nuestras pruebas pueden ser, y al menos
determinista que son. Si usted tiene pruebas de que a veces fallan, pero cada uno sólo
de ellos re-corre, ya que pueden pasar de nuevo más tarde, entonces usted tiene
pruebas de hojaldre. No son sólo pruebas que cubren una gran cantidad de diferentes
procesos que son el culpable aquí. Los exámenes que cubren siendo funcionalidad
cio CISED en varios subprocesos son a menudo problemático, donde una falla podría
significar una condición de carrera, un tiempo de espera, o que la funcionalidad es
realmente roto. pruebas escamosas son el enemigo. Al no conseguirlo, no nos dicen
mucho. Nos re-ejecutar nuestro CI se basa en la esperanza de que van a pasar de
nuevo más tarde, sólo para ver registros de entrada se acumulan, y de repente nos
encontramos a nosotros mismos con una carga de funcionalidad roto.
Cuando detectamos pruebas de hojaldre, es esencial que hacemos todo lo posible
para eliminarlos. De otro modo, empezamos a perder la fe en un conjunto de pruebas
que “siempre falla de esa manera.” Un conjunto de pruebas con las pruebas de
hojaldre puede convertirse en una víctima de lo que Diane Vaughan llama a la
normalización de la desviación: la idea de que con el tiempo podemos llegar a ser tan
acostumbrados a las cosas a equivocarse que se empieza a aceptarlas como normal y
no un problema.1 Esta tendencia muy humana significa que tenemos que encontrar y
eliminar estas pruebas tan pronto como sea posible antes de empezar a asumir que las
pruebas en su defecto están bien.
En “Erradicación del no determinismo en las pruebas”, Martin Fowler defiende el
criterio de que si tiene pruebas de hojaldre, debe rastrearlos y si no se puede arreglar
de inmediato ellos, sacarlos de la suite para que pueda tratarlos. Ver si se puede
volver a escribir para evitar código de prueba que se ejecuta en varios subprocesos.
Ver si se puede hacer el ambiente más estable subyacente. Mejor aún, ver si se puede
sustituir la prueba escamosa con una prueba de menor con ámbito que es menos
Esos Tricky pruebas de extremo a
extremo | 141
propensos a mostrar problemas. En algunos casos, Chang-ing el software bajo prueba
para que sea más fácil para poner a prueba también puede ser el camino correcto a
seguir.
1 Diane Vaughan, el Challenger Lanzamiento Decisión: Tecnología arriesgado, Cultura, y la desviación de la
NASA (Chicago: University of Chicago Press, 1996).
140 | Capítulo 7: Prueba
Quién escribe estas pruebas?
Con las pruebas que se ejecutan como parte de la tubería para un servicio
determinado, el punto de arranque ing sensato es que el equipo que es dueño de ese
servicio debe escribir esas pruebas (hablaremos más sobre el servicio en la propiedad
Capítulo 10). Pero si tenemos en cuenta que podríamos tener varios equipos
implicados, y el paso de extremo a extremo pruebas es ahora compartido con eficacia
entre los equipos, que escribe y se ocupa de estas pruebas?
He visto una serie de anti-patrones causadas aquí. Estas pruebas se convierten en
un libre acceso para todos, con todos los equipos otorgados a añadir pruebas sin
ninguna comprensión de la salud de toda la suite. A menudo, esto puede dar
lugar a una explosión de casos de prueba, a veces RESULTEN en el cono de
nieve prueba de que hemos hablado antes. He visto situaciones en las que, debido
a que no había verdadera propiedad evidente de estas pruebas, sus resultados son
ignorados. Cuando se rompen, todo el mundo asume que es un problema de otra
persona, por lo que no importa si las pruebas están pasando.
A veces las organizaciones reaccionan por tener un equipo dedicado escribir estas
pruebas. Esto puede ser desastroso. El equipo de desarrollo del software se vuelve
cada vez más distante de las pruebas de su código. aumentan los tiempos de ciclo,
como los propietarios de servicios terminan esperando el equipo de pruebas para
escribir pruebas de extremo a extremo para la funcionalidad que acaba de escribir.
Porque otro equipo escribe estas pruebas, el equipo redactor del servicio es menos
involucrados con, y por lo tanto menos probabilidades de saber, cómo ejecutar y
corregir estas pruebas. A pesar de que es, por desgracia sigue siendo un modelo de
organización común, veo un daño significativo a cabo cada vez que un equipo está
distanciado de escribir pruebas para el código que escribió en el primer lugar.
Conseguir este aspecto correcto es realmente difícil. No queremos duplicar esfuerzos,
ni queremos centralizar completo este en la medida en que los equipos de
construcción de servicios están demasiado alejados de las cosas. El mejor balance
que he encontrado es para tratar el conjunto de pruebas de extremo a extremo como
una base de código compartido, pero con la propiedad conjunta. Los equipos son
libres de confirmar a esta suite, pero la propiedad de la salud de la suite tiene que ser
compartida entre los equipos de desarrollo de los servicios mismos. Si desea hacer un
uso extensivo de las pruebas finales a extremo con múltiples equipos Creo que este
enfoque es esencial, y sin embargo he visto hacer muy raramente, y nunca sin la
edición.
¿Cuánto tiempo?
Estas pruebas de extremo a extremo puede tomar un tiempo. Los he visto tardar hasta
un día para correr, si no más, y en un proyecto que trabajé, una suite de regresión
completa llevó seis semanas! Rara vez veo equipos realmente cura sus conjuntos de
pruebas de extremo a extremo para reducir la superposición en la cobertura de la
142 | Capítulo 7: Prueba
prueba, o pasar bastante tiempo en hacerlos rápido.
Esta lentitud, combinado con el hecho de que estos ensayos a menudo puede ser en
forma de escamas, puede ser un problema importante. Un conjunto de pruebas que se
lleva todo el día y, a menudo tiene roturas que se han noth- ing que ver con la
funcionalidad rotos son un desastre. Incluso si su funcionalidad se Bro-ken, que le
podría tomar muchas horas para averiguarlo momento en el que muchos de nosotros
lo haría
Las pruebas de hojaldre y
quebradizo | 141
ya han pasado a otras actividades, y el cambio de contexto en el cambio de nuestro
cerebro de nuevo a solucionar el problema es doloroso.
Nosotros puede mejorar algunos de esto mediante la ejecución de pruebas en el
ejemplo paralelo-para, haciendo uso de herramientas como selenio cuadrícula. Sin
embargo, este enfoque no es un sustituto para comprender realmente lo que necesita
ser probado y eliminar activamente pruebas que ya no son necesarios.
La eliminación de las pruebas es a veces un ejercicio lleno, y sospecho que comparte
gran parte de com- mon con las personas que quieren eliminar ciertas medidas de
seguridad del aeropuerto. No importa qué tan ineficaces podrían ser las medidas de
seguridad, cualquier conversación sobre la eliminación de ellos es a menudo
respondió con reacciones reflejas de no preocuparse por la seguridad de las personas
o el deseo de ganar terroristas. Es difícil tener una conversación equilibrada sobre el
valor de algo añade frente a la carga que conlleva. También puede ser una tarea
difícil de riesgo / recompensa disyuntiva. ¿Usted consigue agradeció si se quita una
prueba? Tal vez. Pero vas a cierta- mente ser culpados si una prueba de que ha
extraído permite un error a través. Cuando se trata de los bancos de pruebas de
ámbito-grande, sin embargo, esto es exactamente lo que tenemos que ser capaces de
hacer. Si la misma característica se cubre en 20 pruebas diferentes, tal vez podemos
deshacernos de la mitad de ellos, como esas 20 pruebas tardan 10 minutos para
correr! Lo que esto requiere una mejor comprensión del riesgo, que algo que los
humanos son famosos malo en. Como resultado, este cura- ción inteligente y gestión
de las pruebas, mayor de ámbito de alta carga pasa muy poca frecuencia. las personas
que deseen hicieron más no es lo mismo que hacer que suceda.
El Gran Pile-up
Los largos ciclos de retroalimentación asociados con pruebas de extremo a extremo
no son sólo un problema cuando se trata de la productividad del desarrollador. Un
banco de pruebas de largo, los saltos de tomar un tiempo para arreglar, lo que reduce
la cantidad de tiempo que las pruebas de extremo a extremo se puede esperar que se
pasa. Si hacemos uso único software que ha pasado por todas nuestras pruebas con
éxito (que debería!), Esto significa menos de nuestros servicios de llegar hasta el
punto de ser despliegue en producción.
Esto puede conducir a un choque en cadena. Mientras rota una etapa de pruebas de
integración se fija, más cambios de los equipos aguas arriba pueden acumularse en.
Aparte del hecho de que esto puede hacer FIX-ing la acumulación más difícil,
significa que el alcance de los cambios que se desplegarán aumenta. Una forma de
resolver este es no dejar que la gente comprobar en si las pruebas de extremo a
extremo están fallando, pero dado mucho tiempo conjunto de pruebas a menudo es
poco práctico. Trate de decir, “Ustedes los 30 desarrolladores: no hay registros de
entrada hasta que nos solucionar este problema de siete horas de duración de
construcción!”
Cuanto mayor sea el alcance de un despliegue y mayor es el riesgo de un
142 | Capítulo 7: Prueba
comunicado, la más probable es que romper algo. Un factor clave para asegurar que
podemos liberar nuestro soft- ware con frecuencia se basa en la idea de que
liberamos pequeños cambios tan pronto como estén listos.
Las pruebas de hojaldre y
quebradizo | 141
el Metaversion
Con la etapa de prueba de extremo a extremo, es fácil empezar a pensar, tanto, sé
todos estos servicios en estas versiones trabajan juntos, así que por qué no se
despliegan todos juntos? Esto se convierte muy rápidamente una conversación a lo
largo de las líneas de, ¿Por qué no usar un número de versión para el sistema entero?
CitarBrandon Bryars“Ahora usted tiene problemas 2.1.0.”
Por versiones juntos los cambios realizados en múltiples servicios, abrazamos con
eficacia la idea de que el cambio y la implementación de varios servicios a la vez es
aceptable. Se convierte en la norma, se convierte en Aceptar. De este modo, cedemos
una de las principales ventajas de micro servicios: la capacidad de desplegar un
servicio por sí mismo, independientemente de otros servicios.
Con demasiada frecuencia, el enfoque de aceptar múltiples servicios que se activa
junto deriva en una situación en Servicios convertirse acoplados. En poco tiempo, los
servicios muy bien separadas se vuelven cada vez se enredaron con los demás, y
nunca se dan cuenta, ya que nunca intenta implementar por sí mismos. Se termina
con una maraña donde hay que organizar el despliegue de servicios múltiples a la
vez, y como hemos comentado previa- mente, este tipo de acoplamiento nos puede
dejar en un lugar peor de lo que sería con un pecado gle, monolítica solicitud.
Esto es malo.
Journeys prueba, No Historias
A pesar de los inconvenientes que acabamos de esbozar, para muchos usuarios de
extremo a extremo pruebas todavía puede ser manejable con uno o dos servicios, y en
estas situaciones todavía hacer un montón de sentido. ¿Pero qué sucede con 3, 4, 10,
20 o servicios? Muy rápidamente estos bancos de pruebas se vuelven enormemente
hinchado, y en el peor de los casos puede producirse una explosión cartesiana-como
en los esce- narios bajo prueba.
Esta situación se agrava si caemos en la trampa de la adición de una nueva prueba de
extremo a extremo para cada pieza de funcionalidad añadimos. Muéstrame un código
base donde todos los nuevos resultados de la historia en una nueva prueba de
extremo a extremo, y yo voy a mostrar un conjunto de pruebas hinchada que tiene
ciclos de retroalimentación pobres y hay grandes coincidencias en la cobertura de la
prueba.
La mejor manera de contrarrestar esto es centrarse en un pequeño número de
desplazamientos básicos para probar todo el sistema. Cualquier funcionalidad no
cubierto en estos viajes de núcleo necesita ser cubierto en las pruebas que analizan
Servicios de aislamiento entre sí. Estos viajes tienen que ser mutuamente acordado, y
de propiedad conjunta. Para nuestra tienda de música, es posible que se centran en
acciones como pedir un CD, de devolver un producto, o tal vez la creación de un
nuevo interacciones con los clientes de alto valor y muy pocos en número.
Al centrarse en un pequeño número (y me refiero pequeña: muy bajas cifras de dos
144 | Capítulo 7: Prueba
dígitos, incluso para sistemas complejos) de pruebas que pueden reducir las
desventajas de las pruebas de integración, pero no podemos evitar todos ellos. ¿Hay
una mejor manera?
Journeys prueba, No Historias |
143
Las pruebas dirigidos por el consumidor al Rescate
¿Cuál es uno de los principales problemas que estamos tratando de hacer frente a
cuando utilizamos las pruebas de integración descritas anteriormente? Estamos
tratando de asegurar que cuando hacemos uso de un nuevo servicio para la
producción, nuestros cambios no se romperán los consumidores. Una forma de hacer
esto sin necesidad de realizar ensayos contra el consumidor real es mediante el uso
de un contrato impulsada por el consumidor (CDC).
Con CDC, estamos definiendo las expectativas de un consumidor de un servicio (o
pro-ductor). Las expectativas de los consumidores son capturados en forma de
código como las pruebas, que luego se ejecutan en el productor. Si se hace bien, estas
CDC se deben ejecutar como parte de la construcción CI del productor, asegurando
que nunca se despliega si se rompe uno de estos contratos. Muy importante desde el
punto de vista de retroalimentación de prueba, estas pruebas deben ejecutarse sólo en
contra de un solo productor de manera aislada, por lo que puede ser más rápido y más
fia- ble que las pruebas de extremo a extremo que podrían reemplazar.
A modo de ejemplo, vamos a revisar nuestro escenario de atención al cliente. El
servicio al cliente tiene dos consumidores distintos: el servicio de asistencia y de la
tela de la tienda. Tanto estos servicios que consumen tienen expectativas de cómo se
comportará el servicio al cliente. En este ejemplo, Cre comió dos series de pruebas:
una para cada consumidor que representa el uso de la tienda web de servicio de
asistencia y de la atención al cliente. Una buena práctica aquí es tener a alguien de
los equipos productores y consumidores colaboran en la creación de las pruebas, así
que quizás la gente de los equipos de tienda web y servicio de asistencia se
emparejan con las personas del equipo de servicio al cliente.
Debido a que estos CDC son las expectativas sobre cómo el servicio al cliente debe
comportarse, que se pueden ejecutar en contra de la atención al cliente por sí mismo
con cualquiera de sus dependencias aguas abajo apagó, como Figura 7-9 muestra.
Desde un punto de vista alcance, se sientan en el mismo nivel en la pirámide de
prueba como pruebas de servicio, aunque con un enfoque muy diferente, como se
muestra enFigura 7-10. Estas pruebas se centran en cómo un consumidor va a utilizar
el servicio, y el gatillo si se rompen es muy diferente en comparación con las pruebas
de servicio. Si uno de estos CDC rompe durante una acumulación de la atención al
cliente, se hace evidente, que se verían afectados los consumidores. En este punto,
puede solucionar el problema o bien iniciar la discusión sobre la introducción de un
cambio importante en la forma que dis- cussed enCapítulo 4. Así que con los CDC,
podemos identificar un cambio de última hora antes de nuestro software de entrar en
producción sin tener que utilizar una prueba de extremo a extremo potencialmente
costosa.
144 | Capítulo 7: Prueba
Figura 7-9. prueba impulsada por el consumidor en el contexto de nuestro ejemplo de
servicio al cliente
La figura 7-10. La integración de pruebas dirigido a los consumidores en la pirámide
de la prueba
Pacto
Pacto es una herramienta de prueba impulsada por el consumidor que fue
desarrollado originalmente en el local en Real-Estate.com.au, pero ahora es de
código abierto, con Beth Skurrie conducir la mayor parte del desa- rrollo.
Originalmente sólo para Ruby, pacto ahora incluye puertos de JVM y .NET.
Pacto funciona de una manera muy interesante, como se resume en Figura 7-11. El
consumidor comienza por definir las expectativas del productor por medio de DSL
Ruby. A continuación, se lanza un servidor simulacro local y ejecutar esta
expectativa en contra de ella para crear el archivo ficación del Pacto speci-. El
archivo pacto es sólo una especificación formal JSON; Naturalmente, también puede
handcode estos, pero el uso de la API de lenguaje es mucho más fácil. Esto también
le da un Run-Ning servidor maqueta que se puede utilizar para realizar pruebas
complementarias aisladas del consumidor.
Las pruebas dirigidos por el consumidor al
Rescate | 145
Figura 7-11. Un resumen de cómo Pacto realiza pruebas impulsada por el consumidor
En el lado del productor, que a continuación, compruebe que esta especificación de
los consumidores se cumple mediante el uso de la especificación JSON Pacto para
conducir llamadas en contra de su API y comprobar las respuestas. Para que esto
funcione, el código base productor necesita acceso al archivo Pacto. Como ya
comentamos en Lier oído:Capítulo 6, Esperamos que tanto el consumidor y el
productor de estar en diferentes formaciones. El uso de una especificación JSON
independiente del idioma es un toque especialmente agradable. Esto significa que
usted puede generar las especificaciones del consumidor, utilizando un cliente Ruby,
sino que lo utiliza para verificar un productor de Java utilizando el puerto JVM del
Pacto.
Como la especificación Pacto JSON es creado por el consumidor, éste debe
convertirse en un artefacto que la acumulación productor tiene acceso. Se podría
almacenar este artefacto en el repositorio de su CI de herramienta / CD, o bien
utilizar el Pacto Broker, lo que le permite almacenar versiones múl- tiples de sus
especificaciones del Pacto. Esto podría permitirle ejecutar sus pruebas de contrato
dirigido a los consumidores contra múltiples versiones diferentes de los
consumidores, si se quería comprobar con respecto a, por ejemplo, la versión del
consumidor en la producción y la versión del consumidor que fue recientemente
construido.
Confusamente, hay un proyecto de código abierto llamado ThoughtWorks pacto, Que
es también una herramienta de rubíes usado para la prueba impulsada por el
consumidor. Tiene la capacidad de grabar las interacciones entre el cliente y el
servidor para generar las expectativas. Esto hace que la redacción de contratos
consumidor-conducidos por los servicios existentes sin gran dificultad. Con Pacto,
una vez que generan estas expectativas son más o menos estática, mientras que con el
Pacto de regenerar las expectativas en el consumidor con cada generación. El hecho
de que se puede definir expectativas para las capacidades de los productores ni
siquiera puede tener sin embargo también mejor encaja en un flujo de trabajo en el
146 | Capítulo 7: Prueba
que el servicio de la producción todavía se está (o aún no se ha) desarrollado.
Las pruebas dirigidos por el consumidor al
Rescate | 145
Es Acerca de las conversaciones
En ágiles, las historias se refieren a menudo como un marcador de posición para una
conversación. CDC son sólo de esa manera. Se convierten en la codificación de un
conjunto de discusiones acerca de lo que es un vicio API ser- debe ser similar, y
cuando se rompen, se convierten en un punto de activación a tener conversaciones
acerca de la forma en que la API debe evolucionar.
Es importante entender que CDC requieren una buena comunicación y confianza
entre el servicio de consumo y producción. Si ambas partes están en el mismo equipo
(o la misma persona!), Entonces esto no debería ser difícil. Sin embargo, si usted está
consumiendo un ser- vicio provisto de un tercero, puede que no tenga la frecuencia
de comunicación, o de confianza, para hacer el trabajo CDC. En estas situaciones, es
posible que tenga que conformarse con LIMITA- TED pruebas de integración más
amplio de ámbito de la vuelta de la componente no es de confianza. Alternativamente, si va a crear una API para miles de consumidores potenciales, como con
un API de servicios web a disposición del público, puede que tenga que jugar el
papel del consumidor a sí mismo (o tal vez trabajar con un subconjunto de los
consumidores) en la definición estas pruebas. Rompiendo un gran número de
consumidores externos es una muy mala idea, por lo que en todo caso la importancia
de los CDC se incrementa!
Así que hay que usar pruebas de extremo a
extremo?
Como se describe en detalle en el capítulo anterior, pruebas de extremo a extremo
tienen un gran número de desventajas que crecen de manera significativa a medida
que añada más piezas móviles que se está probando. De hablar con personas que han
estado aplicando a escala microservicios desde hace un tiempo, he aprendido que la
mayoría de ellos con el tiempo eliminar por completo la necesidad de pruebas de
extremo a extremo en favor de herramientas como CDC y un mejor seguimiento.
Pero no nece- sariamente arrojan las pruebas de distancia. Ellos terminan usando
muchas de esas pruebas viaje de extremo a extremo para controlar el sistema de
producción mediante una técnica denominada monitoreo semántica, del que
hablaremos más enCapítulo 8.
Tú puede ver la ejecución de pruebas de extremo a extremo antes de la
implementación de producción como las ruedas de entrenamiento. Mientras que
usted está aprendiendo cómo funcionan las CDC, y mejorar su control de la
producción y las técnicas de implementación, estas pruebas de extremo a extremo
pueden formar una red de seguridad útil, en el que está operando fuera de tiempo de
ciclo para la disminución del riesgo. Pero a medida que mejora esas otras áreas, se
puede empezar a reducir su dependencia de las pruebas de extremo a extremo hasta
el punto en que ya no son necesarios.
Del mismo modo, es posible trabajar en un ambiente donde el apetito de aprender en
148 | Capítulo 7: Prueba
la producción es baja, y la gente prefiere trabajar tan duro como sea posible para
eliminar cualquier defecto antes de la producción, incluso si eso significa que el
software tarda más en enviar. Siempre y cuando se entienda que no se puede estar
seguro de que se han eliminado todas las fuentes de defectos, y que todavía se
necesita tener un control eficaz y remediación en su lugar en la producción, esto
puede ser una decisión sensata.
Así que hay que usar pruebas de extremo a
extremo? | 147
Obviamente, usted tendrá una mejor comprensión del perfil de riesgo de su propia
organización que yo, pero yo desafío a pensar largo y tendido sobre la cantidad de
pruebas de extremo a extremo que realmente necesita hacer.
Después de las pruebas de Producción
La mayoría de las pruebas se realizan antes de que el sistema está en producción.
Con nuestras pruebas, estamos defin- ing una serie de modelos con los que
esperamos probar si nuestro sistema funciona y se comporta como nos gustaría, tanto
funcional como nonfunctionally. Pero si nuestros modelos no son perfectos, entonces
vamos a encontrar problemas cuando se utilizan nuestros sistemas de rabia. Insectos
caen en la producción, los nuevos modos de fallo se descubren, y nuestros usuarios
utilizan el sistema de una manera que nunca podría esperar.
Una reacción a esto es a menudo para definir más y más pruebas, y perfeccionar
nuestros modelos, para coger más problemas en forma temprana y reducir el número
de problemas que nos encontramos con nuestro sistema de producción en marcha.
Sin embargo, en cierto punto, tenemos que aceptar que llegamos a rendimientos
decrecientes con este enfoque. Con la prueba antes del despliegue, no podemos
reducir la probabilidad de fallo a cero.
La separación de despliegue desde Release
Una forma en que podemos coger más problemas antes de que ocurran es extender en
que manejamos nuestras pruebas más allá de las medidas tradicionales antes del
despliegue. En cambio, si podemos implementar nuestro software, y probarlo in situ
antes de dirigir las cargas de producción en contra de ella, podemos detectar
problemas específicos de un entorno determinado. Un ejemplo común de esto es el
conjunto de pruebas de humo, una colección de pruebas diseñadas para ejecutarse
contra el software recién implementado para confirmar que el despliegue trabajó.
Estas pruebas ayudan a recoger todas las cuestiones ambientales locales. Si está
utilizando un solo comando de línea de comandos para desplegar cualquier
microService dada (y debe), este comando se debe ejecutar las pruebas de humo de
forma automática.
Otro ejemplo de esto es lo que se llama el despliegue azul / verde. Con el azul /
verde, tenemos dos copias de nuestro software implementado en un momento, pero
sólo una versión de la misma está recibiendo peticiones reales.
Vamos considerar un ejemplo sencillo, visto en Figura 7-12. En la producción,
tenemos v123 de la atención al cliente directa. Queremos desplegar una nueva
versión, v456. Hacemos uso de este lado v123, pero no dirigir cualquier tráfico a
la misma. En lugar de ello, llevamos a cabo algunas pruebas in situ con la
versión recién desplegada. Una vez que las pruebas han trabajado, dirigimos la
carga de producción a la nueva versión v456 del servicio al cliente. Es común
para mantener la versión antigua de alrededor de un corto período de tiempo, lo
148 | Capítulo 7: Prueba
que permite un repliegue rápido si detecta algún error.
Así que hay que usar pruebas de extremo a
extremo? | 147
La figura 7-12. El uso de los despliegues / verde azul para separar el despliegue de la
liberación
La implementación de despliegue azul / verde requiere un par de cosas. En primer
lugar, tiene que ser capaz de dirigir el tráfico a la producción de los diferentes
huéspedes (o colecciones de hosts). Se podría hacer esto cambiando las entradas de
DNS, o actualizar la configuración de equilibrio de carga. También es necesario ser
capaz de provisión de suficientes hosts para tener las dos versiones de la
microService funcionando a la vez. Si está utilizando un proveedor de la nube
elástica, esto podría ser la sala straightfor-. El uso de los despliegues / verde azul le
permite reducir el riesgo de despliegue, así como le da la oportunidad de volver Si
surge algún problema. Si obtiene buenos en esto, todo el proceso puede ser
completamente automatizado, ya sea con el roll-completo hacia fuera o revertir
ocurriendo sin ninguna intervención humana.
Dejando de lado la ventaja de que nos permite probar nuestros servicios in situ antes
de enviarlos tráfico de producción, manteniendo la versión antigua en
funcionamiento mientras realizamos nuestra liberación reducimos considerablemente
el tiempo de inactividad asociado con la liberación de nuestro software. Dependiendo
de qué mecanismo se utiliza para implementar el redireccionamiento del tráfico, la
conmutación entre versiones puede ser completamente invisible para el cliente, que
nos da las implementaciones sin tiempo de inactividad.
Existe otra técnica vale la pena discutir brevemente aquí también, que a veces se
confunde con despliegues azul / verde, ya que puede utilizar algunas de las mismas
implementaciones técnicas. Se conoce como la liberación de canario.
La liberación de Canarias
Con canario liberación, estamos verificando nuestro software recién implementado
por la dirección de cantidades de tráfico de producción contra el sistema para ver si
funciona como se esperaba. “Funciona como se esperaba” puede cubrir un número de
cosas, a la vez funcional y no funcional. Por ejemplo, podríamos comprobar que un
servicio recién desplegada está respondiendo a las solicitudes dentro de 500 ms, o
que vemos las mismas tasas de error proporcional a partir de lo nuevo y lo antiguo
servicio. Pero se puede ir más allá de eso. Imaginemos que hemos lanzado una nueva
versión del servicio de recomendación. Podríamos correr a ambos lado de la otra,
150 | Capítulo 7: Prueba
sino ver si las recomendaciones generadas por la nueva versión del resultado del
servicio en el mayor número de ventas esperadas, asegurándose de que no hemos
lanzado un algoritmo óptimo.
Después de las pruebas de
producción | 149
Si la nueva versión es malo, se llega a revertir rápidamente. Si es buena, se puede
empujar increas- cantidades ing de tráfico a través de la nueva versión. Canarias
difiere de la liberación de azul / verde en la que se puede esperar a versiones
coexisten durante más tiempo, y que a menudo van a variar las cantidades de tráfico.
Netflix utiliza este enfoque ampliamente. Antes de la liberación, las nuevas versiones
de servicio se despliegan junto con un grupo de referencia que representa la misma
versión que la producción. Netflix continuación, se ejecuta un subconjunto de la
carga de producción durante un número de horas contra tanto la nueva versión y la
línea de base, anotando ambos. Si el canario pasa, la empresa procede a un pleno
despliegue en producción.
Al considerar la liberación de canario, tiene que decidir si se va a desviar una parte
de las solicitudes de producción hasta el canario o simplemente copiar carga de
producción. Algunos equipos son capaces de sombra tráfico de producción y dirigirla
a su canario. De esta manera, las versiones de producción y canario existentes pueden
ver exactamente las mismas peticiones, pero sólo los resultados de las solicitudes de
producción se ve externamente. Esto le permite hacer una comparación lado a lado al
tiempo que elimina la posibilidad de que un fallo en el canario puede ser visto por un
pedido del cliente. El trabajo a la sombra de tráfico de producción puede ser compleja, sin embargo, especialmente si los eventos / solicitudes está reproduciendo no
son idempotente.
la liberación de Canarias es una técnica de gran alcance, y pueden ayudarle a
verificar las nuevas versiones de su software con tráfico real, mientras que le da las
herramientas para gestionar el riesgo de empujar a cabo un mal lanzamiento. Se
requiere una configuración más compleja, sin embargo, que el despliegue azul /
verde, y un poco más pensado. Se podría esperar que coexistan diferentes versiones
de sus servicios durante más tiempo que con el azul / verde, por lo que se le puede
atar más hardware durante más tiempo que antes. También tendrá más sofisticada de
enrutamiento del tráfico, ya que es posible que desee a la rampa hacia arriba o hacia
abajo los porcentajes del tráfico para conseguir más confianza en que funciona su
liberación. Si ya manejar despliegues / verde azul, es posible que algunos de los
bloques de construcción ya.
Tiempo para reparar lo largo del tiempo medio entre fallos
significa?
Así examinado técnicas como / despliegue o canario verde, azul, liberar,
encontramos una manera de probar más cerca de la producción (o incluso en), y
también construimos herramientas para ayudarnos edad hombre- un fracaso si se
produce. El uso de estos enfoques es un reconocimiento tácito de que no podemos
detectar y atrapar todos los problemas antes de que realmente liberamos nuestro
software.
A veces gastando el mismo esfuerzo en conseguir mejor en la remediación de un
150 | Capítulo 7: Prueba
comunicado puede ser significativamente más beneficiosa que la adición de más
pruebas funcionales automatizadas. En el mundo de las operaciones de web, esto se
refiere a menudo como el equilibrio entre la optimización de tiempo medio entre
fallos (MTBF) y el tiempo medio de reparación (MTTR).
técnicas para reducir el tiempo de recuperación puede ser tan simple como
reversiones muy rápidos aco- se declararon con un buen seguimiento (del que
hablaremos en Capítulo 8), Como tos despliegues azul / verde. Si podemos detectar
un problema en la producción temprana, y hacer retroceder temprano, reducimos
Después de las pruebas de
producción | 149
el impacto a nuestros clientes. También podemos utilizar técnicas como el despliegue
azul / verde, en el que desplegar una nueva versión de nuestro software y probarlo en
situ antes de dirigir nuestros usuarios a la nueva versión.
Para diferentes organizaciones, esta disyuntiva entre MTBF y MTTR variará, y
mucho de esto recae en la comprensión del verdadero impacto del fracaso en una
producción ronment bientes. Sin embargo, la mayoría de las organizaciones que veo
pasar el tiempo la creación de conjuntos de pruebas funcionales a menudo gastan
poco o ningún esfuerzo en absoluto en la mejora del control o de recuperación tras el
fallo. Así, mientras que éstos pueden reducir el número de defectos que se producen
en el primer lugar, no pueden eliminar todos ellos, y están preparados para tratar con
ellos si surgen en la producción.
Existen ventajas y desventajas distintas de MTBF y MTTR. Por ejemplo, si usted
está tratando de averiguar si alguien va a utilizar realmente su software, puede tener
mucho más sentido de sacar algo ahora, para probar la idea o el modelo de negocio
antes de construir software robusto. En un entorno donde este es el caso, la prueba
puede ser excesiva, ya que el impacto de no saber si su idea funciona es mucho
mayor que tener un defecto en la pro- ducción. En estas situaciones, puede ser
bastante sensata para evitar ensayos antes de la pro- ducción por completo.
Prueba de funciones cruzadas
La mayor parte de este capítulo se ha centrado en las pruebas de piezas específicas de
funcionalidad, y en qué se diferencia cuando se está probando un sistema basado en
microService. Sin embargo, existe otra categoría de las pruebas de que es importante
discutir. Los requisitos no funcionales es un término general usado para describir las
características de sus exposiciones del sistema que no puede simplemente ser
implementadas como una característica normal. Incluyen aspectos como la latencia
aceptable de una página web, el número de usuarios de un sistema debe apoyar,
cómo acceder a su interfaz de usuario debe ser a las personas con discapacidades, o
cómo proteger sus datos del cliente deben ser.
El término no funcional nunca se sentó bien conmigo. Algunas de las cosas que son
cubiertas por este término parece muy funcional en la naturaleza! Uno de mis
colegas, Sarah Taraporewalla, acuñaron los requisitos frase multi-funcionales (CFR),
en cambio, que yo prefiero en gran medida. Se habla más al hecho de que estos
comportamientos del sistema en realidad sólo surgen como resultado de un montón
de trabajo intersectorial.
Muchos, si no la mayor parte, las tasas de letalidad realmente sólo se reunieron en la
producción. Dicho esto, podemos definir las estrategias de prueba para ayudarnos a
ver si nos movemos al menos hacia el cumplimiento de estos objetivos. Este tipo de
pruebas se dividen en el cuadrante Prueba propiedad. Un gran ejemplo de esto es la
prueba de rendimiento, del que hablaremos con más profundidad en breve.
Para algunos las tasas de letalidad, es posible que desee realizar un seguimiento de
152 | Capítulo 7: Prueba
ellos en un nivel de servicio individual. Por ejem- plo, puede decidir que la
durabilidad de servicio que necesita de su servicio de pago es significativamente
mayor, pero que está satisfecho con más tiempo de inactividad para su música
Prueba de funciones cruzadas |
151
servicio de recomendación, sabiendo que su negocio puede sobrevivir si no puede
recomendar artistas similares a Metallica durante 10 minutos más o menos. Estas
compensaciones terminarán por tener un gran impacto en la forma de diseñar y
evolucionar su sistema, y una vez más la naturaleza de grano fino de un sistema
basado en microService le da muchas más posibilidades para hacer que estas
compensaciones.
pruebas alrededor de las tasas de letalidad debe seguir la pirámide también. Algunas
pruebas tendrán que ser de extremo a extremo, como pruebas de carga, pero otros no.
Por ejemplo, una vez que haya encontrado un cuello de botella de rendimiento en una
prueba de carga de extremo a extremo, escribir una prueba de ámbito de menor a
ayudarle a coger el problema en el futuro. Otras tasas de letalidad encajan pruebas
más rápidas con bastante facilidad. Recuerdo trabajando en un proyecto donde
habíamos insistido en asegurar nuestra marcado HTML fue el uso de características
adecuadas de accesibilidad para ayudar a las personas con discapacidad utilizan
nuestra página web. Comprobación del marcado generado para asegurarse de que los
controles adecuados se podría haber hecho muy rápidamente sin la necesidad de
ninguna de ida y vuelta de redes.
Con demasiada frecuencia, las consideraciones acerca de las tasas de letalidad llegan
demasiado tarde. Me sugieren fuertemente mirar sus tasas de letalidad tan pronto
como sea posible, y revisar con regularidad.
Pruebas de rendimiento
Las pruebas de rendimiento son vale la pena llamar explícitamente como una manera
de asegurar que algunos de nuestros requerimientos multi-funcionales pueden ser
satisfechas. Al descomponer sistemas en microservicios más pequeños, aumentamos
el número de llamadas que se harán a través de límites de trabajo Net-. Mientras que
antes de una operación podría haber implicado una llamada base de datos, ahora
puede implicar tres o cuatro llamadas a través de límites de la red a otros servi- cios,
con un número correspondiente de las llamadas bases de datos. Todo esto puede
disminuir la velocidad a la que operan nuestros sistemas. La localización de las
fuentes de latencia es especialmente importante. Cuando se tiene una cadena de
llamadas de múltiples llamadas síncronas, si alguna parte de la cadena comienza a
actuar lentamente, todo está afectada, que podría dar lugar a un impacto significativo.
Esto hace que tenga alguna forma de prueba de rendimiento de sus aplicaciones aún
más importante de lo que podría ser con un sistema más monolítico. A menudo, la
razón de este tipo de pruebas se retrasa se debe a que inicialmente no hay suficiente
del sistema hay que probar. Entiendo este problema, pero con demasiada frecuencia
se lleva a patear la lata en el camino, con las pruebas de rendimiento a menudo sólo
está haciendo justo antes de ir en vivo por primera vez, en todo caso! No caiga en
esta trampa.
Al igual que con las pruebas de funcionamiento, es posible que desee una mezcla.
Usted puede decidir que desea pruebas Mance perfor- que aíslan los servicios
152 | Capítulo 7: Prueba
individuales, pero comenzar con las pruebas que evalúan Neys distas básicos en su
sistema. Usted puede ser capaz de tomar las pruebas viaje de extremo a extremo y
sólo tiene que ejecutar estos en volumen.
A generar resultados que valgan la pena, a menudo se necesita para ejecutar
escenarios dados con el aliado gradu- número de clientes simulados en aumento. Esto
le permite ver cómo la latencia de las llamadas varía con el aumento de la carga. Esto
significa que las pruebas de rendimiento puede tomar un tiempo para funcionar.
Además, usted quiere que el sistema de producción coincide con la mayor exactitud
posible,
Prueba de funciones cruzadas |
151
para asegurar que los resultados que se ven serán indicativos del rendimiento que
puede esperar en los sistemas de producción. Esto puede significar que tendrá que
adquirir un volumen mayor de producción como de los datos, y puede necesitar más
máquinas para que coincida con la estructura tareas infraestructuras que pueden ser
un reto. Incluso si se lucha para que el entorno Mance perfor- verdaderamente
producción similar, las pruebas todavía pueden tener valor en la búsqueda de los
cuellos de botella. Sólo ten en cuenta que usted puede obtener falsos negativos, o
peor aún, los falsos positivos.
Debido al tiempo que se tarda en ejecutar las pruebas de rendimiento, no siempre es
factible ejecutar en cada registro de entrada. Es una práctica común para ejecutar un
subconjunto cada día, y un conjunto más grande cada semana. Independientemente
del enfoque que elija, asegúrese de ejecutar ellos con tanta regularidad como sea
posible. Cuanto más tiempo pase sin ejecutar las pruebas de rendimiento, más difícil
puede ser para localizar al culpable. Los problemas de rendimiento son
especialmente difíciles de resolver, por lo que si se puede reducir el número de
confirmaciones que hay que buscar en el fin de ver un problema de reciente
introducción, su vida será mucho más fácil.
Y asegúrese de que también mira los resultados! He estado muy sorprendido por el
número de equipos que he encontrado que han pasado una gran cantidad de pruebas
de aplicación de trabajo y Run-Ning ellos, y nunca comprobar los números. A
menudo esto se debe a que la gente no sabe lo que es un buen resultado se parece.
Usted realmente necesita tener metas. De esta manera, se puede hacer que la
construcción vaya rojo o verde basada en los resultados, con un rojo (no) construir
siendo un claro llamado a la acción.
tesing rendimiento que hay que hacer en conjunto con el seguimiento del sistema real
per- formance (del que hablaremos más en Capítulo 8), Y lo ideal sería utilizar las
mismas herramientas en su entorno de prueba de rendimiento para visualizar el
comportamiento del sistema que aquéllas usadas en la producción. Esto puede hacer
que sea mucho más fácil de comparar cosas similares.
Resumen
Con lo que todo esto junto, lo que he descrito aquí es un enfoque holístico a las
pruebas que se espera le da algunas orientaciones generales sobre cómo proceder al
probar sus propios sistemas. Reiterar los conceptos básicos:
• Optimizar para respuesta rápida, y distintos tipos de pruebas en consecuencia.
• Evitar la necesidad de pruebas de extremo a extremo siempre que sea posible
mediante el uso de contratos orientados al consumidor.
• Utilizar contratos orientados al consumidor para proporcionar puntos de enfoque
para las conversaciones entre los equipos.
• Tratar para entender el trade-off entre poner más esfuerzos en las pruebas y la
154 | Capítulo 7: Prueba
detección de problemas en la producción más rápido (tiempo medio entre fallos
para optimizar frente MTTR).
resumen | 153
Si usted está interesado en leer más acerca de las pruebas, recomiendo Agile Testing
por Lisa Crispin y Janet Gregory (Addison-Wesley), que entre otras cosas incluye el
uso del cuadrante de pruebas con más detalle.
En este capítulo se centró principalmente en asegurar que nuestro código funciona
antes de que llegue pro- ducción, pero también necesitamos saber cómo hacer que
nuestro código funciona una vez que se desplegó. En el siguiente capítulo, vamos a
echar un vistazo a la manera de supervisar nuestros sistemas basados en
MICROSERVICE.
154 | Capítulo 7: Prueba
CAPÍTULO 8
Vigilancia
Como es de esperar que he mostrado hasta ahora, rompiendo nuestro sistema para
arriba en pequeños, microservicios resultados de grano fino en múltiples beneficios.
También, sin embargo, añade complejidad a la hora de vigilar el sistema de
producción. En este capítulo, vamos a ver los retos asociados con el seguimiento y la
identificación de problemas en nuestros siste- mas de grano fino, y voy a esbozar
algunas de las cosas que puede hacer para tener su pastel y comérselo también!
Imagínese la escena. Es un tranquilo viernes por la tarde, y el equipo está a la espera
pendiente antes de tiempo al pub como una manera de empezar un fin de semana
fuera del trabajo. Luego forma repentina los correos electrónicos llegan. El sitio web
está portando mal! Twitter se llena de faltas de su com- pañía, su jefe está
masticando su oreja, y las perspectivas de un fin de semana tranquilo desaparecer.
¿Cuál es la primera cosa que hay que saber? ¿Qué demonios ha salido mal?
En el mundo de la aplicación monolítica, al menos tenemos un lugar muy obvio para
comenzar nuestras investigaciones. Sitio web lento? Es el monolito. Sitio web
impares produce errores? Es el monolito. CPU al 100%? Monolito. Olor a quemado?
Bueno, ya captas la idea. Tener un único punto de fallo también hace investigación
de falla algo más simple!
Ahora vamos a pensar en nuestro propio sistema, basado en microService. Las
capacidades que ofrecemos a nuestros usuarios se sirven de múltiples servicios
pequeños, algunos de los cuales se comunican con aún más servicios para llevar a
cabo sus tareas. Hay un montón de ventajas a este tipo de enfoque (lo cual es bueno,
ya que de lo contrario este libro sería una pérdida de tiempo), pero en el mundo de la
vigilancia, tenemos un problema más complejo en nuestras manos.
Nosotros ahora tienen varios servidores para monitorear, múltiples archivos de
registro para tamizar a través, y múltiples lugares donde la latencia de red podría
causar problemas. Entonces, ¿cómo nos acercamos a esto? Tenemos que dar sentido
a lo que podría ser un caos, desorden, la enmarañada último que cualquiera de
155
nosotros quiere hacer frente a viernes por la tarde (o en cualquier momento, llegar a
eso!).
156 | Capítulo 8: Seguimiento
La respuesta en este caso es bastante sencillo: el seguimiento de las cosas pequeñas,
y el uso de agregación ción para ver la imagen más grande. Para ver cómo, vamos a
empezar con el sistema más simple podemos: un solo nodo.
Servicio individual, Single Server
Figura 8-1 presenta una configuración muy sencilla: un host, se ejecuta un servicio.
Ahora tenemos que vigilar que el fin de saber cuando algo va mal, así que podemos
solucionarlo. ¿Qué debemos tener en cuenta?
Figura 8-1. Un único servicio en un único host
En primer lugar, vamos a querer controlar el host en sí. CPU, memoria de todas estas
cosas se uso-ful. Vamos a querer saber lo que deberían ser las cosas cuando están
sanos, por lo que podemos avisar cuando van fuera de los límites. Si queremos
ejecutar nuestro propio software de monitoreo, podríamos usar algo como Nagios
para hacerlo, o bien utilizar un servicio alojado como Nueva Relic.
A continuación, vamos a querer tener acceso a los registros desde el propio servidor.
Si un usuario informa de un error, estos registros deben recogerlo y es de esperar
nosotros cuando y donde el error es decir. En este punto, con nuestro único host
probablemente podemos llegar a funcionar con sólo iniciar sesión en el host y el uso
de herramientas de línea de comando para escanear el registro. Podemos incluso
llegar avanzada y usar logrotate para mover los registros antiguos, fuera del camino y
evitar dichas prácticas ocupando todo nuestro espacio en disco.
Por último, lo que se quiere controlar la aplicación en sí. Como mínimo, moniToring el tiempo de respuesta del servicio es una buena idea. Es probable que sea
capaz de hacer esto mirando los registros procedentes ya sea desde un servidor web
al frente de su servicio, o tal vez desde el propio servicio. Si conseguimos muy
avanzada, lo que se quiere realizar el seguimiento del número de errores estamos
informando.
El tiempo pasa, las cargas aumentan, y nos encontramos necesidad de escalar ...
Servicio individual, varios servidores
Ahora tenemos varias copias del servicio que se ejecuta en máquinas separadas,
como se muestra en Figura 8-2, Con las solicitudes a las diferentes instancias de
155
servicio distribuidos a través de un ancer equili- carga. Las cosas empiezan a ponerse
un poco ahora más complicado. Todavía queremos monitorear todas las mismas
cosas que antes, pero hay que hacerlo de tal manera que podamos aislar el problema.
156 | Capítulo 8: Seguimiento
Cuando la CPU es alta, es un problema que estamos viendo en todos los hosts, lo que
apuntaría a un problema con el servicio en sí, o se trata de aislar a un único host, lo
que implica que el propio anfitrión tiene el un sistema operativo pícaro quizá la
solución de ¿proceso?
Figura 8-2. Un único servicio distribuido a través de múltiples hosts
Así que en este punto, todavía queremos realizar un seguimiento de las métricas de
nivel de host, y alerta sobre ellos. Pero ahora queremos ver lo que son en todos los
anfitriones, así como los hosts individuales. En otras palabras, queremos agregar a
ellos, y aún así ser capaz de perforar hacia abajo. Nagios nos permite grupo de
nuestros anfitriones como este, tan lejos, tan bueno. Un enfoque similar,
probablemente será suficiente para nuestra aplicación.
Entonces tenemos nuestros registros. Con nuestro servicio que se ejecuta en más de
un servidor, probablemente vamos a cansamos de iniciar sesión en cada caja de
mirarlo. Con sólo unos pocos hosts, sin embargo, podemos utilizar herramientas
como ssh-multiplexores, lo que nos permitirá ejecutar los mismos comandos en
varios hosts. Un monitor grande y una grep "error" app.log más tarde, y podemos
encontrar nuestro culpable.
Para tareas como el seguimiento de tiempo de respuesta, podemos conseguir algo de
la agregación de forma gratuita mediante el seguimiento en el propio equilibrador de
carga. Pero tenemos que seguir el equilibrador de carga, así, por supuesto; si eso se
porta mal, tenemos un problema. En este punto, también, probablemente, importa
mucho más de lo que un servicio de salud se parece, como lo configuraremos nuestra
equilibrador de carga para eliminar nodos no saludables de nuestra aplicación.
Esperamos que para cuando llegamos aquí tenemos al menos una idea de que ...
Servicios Múltiples, múltiples servidores
En Figura 8-3, Las cosas se ponen mucho más interesante. Múltiples servicios están
colaborando para proporcionar capacidades de nuestros usuarios, y dichos servicios
se están ejecutando en anfitriones múltiples ya sean físicos o virtuales. ¿Cómo
encontrar el error que está buscando en miles de líneas de registros en varios hosts?
Servicios Múltiples, múltiples servidores |
157
¿Cómo se determina si un servidor es el Ing misbehav-, o si se trata de una cuestión
sistemática? Y cómo realizar el seguimiento de vuelta un error encontrado en el
fondo de una cadena llamada entre varios hosts y el trabajo lo causó?
158 | Capítulo 8: Seguimiento
Figura 8-3. servicios múltiples colaboradores distribuidos en varios hosts
La respuesta es recogida y agregación central de todo lo que podemos tener en
nuestras manos, a partir de los registros de las métricas de aplicación.
Troncos, troncos, y sin embargo ... Más registros
Ahora el número de hosts que se están ejecutando en se está convirtiendo en un reto.
multiplexación SSH- para recuperar registros probablemente no se va a cortar ahora,
y no hay una pantalla lo suficientemente grande como para que tenga abiertas en
todos los terminales de acogida. En su lugar, estamos buscando a utilizar subsistemas
especializados para agarrar nuestros registros y ponerlos a disposición de forma
centralizada. Un ejemplo de esto eslogstash, Que puede analizar múltiples formatos
de archivo de registro y les puede enviar a los sistemas de aguas abajo para una
mayor investigación.
Kibana es un sistema de Elasticsearch respaldados para los registros de visualización,
ilustradas en las Figura 8-4. Puede utilizar una sintaxis de consulta para buscar a
través de los registros, lo que le permite hacer cosas como restringir los rangos de
fecha y hora o utilizar expresiones regulares para buscar cadenas coincidentes.
Kibana puede incluso generar gráficos a partir de los registros de enviarlo, lo que le
permite ver de un vistazo cómo se han generado muchos errores con el tiempo, por
ejemplo.
Servicios Múltiples, múltiples servidores |
157
Figura 8-4. Usando Kibana para ver registros agregados
Seguimiento métrica Al otro lado de Servicios
Múltiples
Al igual que con el reto de mirar los registros de diferentes anfitriones, tenemos que
mirar a mejores maneras de reunir y ver nuestras métricas. Puede ser difícil saber lo
que se ve bien como cuando estamos mirando métricas para un sistema más
complejo. Nuestra página web está viendo casi 50 4XX códigos de error HTTP por
segundo. ¿Es tan malo? La carga de la CPU en el servicio de registro de cata- ha
aumentado en un 20% desde el almuerzo; ha ido algo mal? El secreto para saber
cuándo entrar en pánico y cuando para relajarse es recopilar métricas sobre cómo su
sis- tema se comporta en un período de tiempo suficientemente largo que emergen
patrones claros.
En un entorno más complejo, vamos a estar aprovisionamiento nuevas instancias de
nuestros servicios con bastante frecuencia, por lo que queremos que el sistema
elegimos para que sea muy fácil de recoger RICS Met de nuevos huéspedes. Vamos a
querer ser capaz de mirar a una métrica agregada para todo el sistema, por ejemplo,
la carga de la CPU, pero avergage que también querrá agregar esa métrica para todas
las instancias de un servicio determinado, o incluso para un solo instancia de ese servicio. Eso significa que tendremos que ser capaz de asociar metadatos con la métrica
que nos permita inferir esta estructura.
El grafito es un tal sistema que hace esto muy fácil. Se expone una API muy simple y
le permite enviar métricas en tiempo real. A continuación, le permite consultar las
métricas para producir gráficos y otras pantallas para ver lo que está sucediendo. La
forma en que maneja volumen también es interesante. Efectivamente, se configura de
tal manera que se reduce la reso- lución de las métricas de más edad para asegurar los
volúmenes no demasiado grande. Así, por ejemplo, podría registrar la CPU para mis
anfitriones una vez cada 10 segundos durante los últimos 10 minutos, a continuación,
una muestra agregada cada minuto para el último día, hasta quizás una muestra cada
30 minutos durante los últimos años. De esta manera, se puede almacenar
160 | Capítulo 8: Seguimiento
información acerca de cómo su sistema se ha comportado durante un largo periodo
de tiempo sin necesidad de grandes cantidades de almacenamiento.
Seguimiento métrica Al otro lado de Servicios
Múltiples | 159
El grafito también le permite agregarse a través de muestras, o acceda a una sola
serie, por lo que se puede ver el tiempo de respuesta de todo el sistema, un conjunto
de servicios, o de una sola instancia. Si grafito no funciona para usted por cualquier
motivo, asegúrese de obtener capacidades similares en cualquier otra herramienta que
seleccione. Y, desde luego asegurarse de que puede obtener acceso a los datos en
bruto para proporcionar a su propia presentación de informes o cuadros de mando si
es necesario.
Otro beneficio clave de la comprensión de sus tendencias es cuando se trata de la
capacidad de la Planificación. ¿Estamos llegando a nuestro límite? ¿Cuánto tiempo
hasta que necesitamos más hosts? En el pasado, cuando trajimos hosts físicos, esto
era a menudo un trabajo anual. En la nueva era de la informática bajo demanda
proporcionado por la infraestructura como servicio (IaaS) vendedores, ahora
podemos escalar hacia arriba o hacia abajo en cuestión de minutos, si no segundos.
Esto significa que si entendemos nuestros patrones de uso, podemos asegurarnos de
que tenemos suficiente infraestructura para servir a nuestras necesidades. El más
inteligente que estamos en el seguimiento de nuestras tendencias y saber qué hacer
con ellos, los más rentables y que responden nuestros sistemas pueden ser.
Las métricas de servicio
Los sistemas operativos que se ejecutan en generar un gran número de métricas para
nosotros, ya que encontrará el momento de instalar collectd en una máquina Linux y
lo señala en grafito. Como- sabia, apoyando subsistemas como Nginx o barniz
expone información útil, como los tiempos de respuesta o las tasas de aciertos de
caché. Pero ¿qué pasa con su propio servicio?
Me gustaría sugerir fuertemente con sus servicios básicos exponen las métricas de sí
mismos. Como mínimo, para un servicio web que probablemente debería exponer
métricas como los tiempos de respuesta y las tasas vitales de error si el servidor no es
liderada por un servidor web que está haciendo esto para usted. Pero realmente
debería ir más allá. Por ejemplo, nuestro servicio de cuentas puede querer exponer el
número de veces que los clientes ver sus pedidos anteriores, o su tienda web puede
ser que desee para capturar la cantidad de dinero que se ha hecho durante el último
día.
¿Por qué nos importa esto? Bueno, por una serie de razones. En primer lugar, hay un
viejo dicho de que el 80% de las características del software no se utilizan nunca.
Ahora no puedo comentar sobre la forma precisa esa cifra es, sino como alguien que
ha sido el desarrollo de software desde hace casi 20 años, sé que he pasado mucho
tiempo en las características que en realidad nunca se acostumbra. ¿No sería bueno
saber cuáles son?
En segundo lugar, nos estamos mejor que nunca en reaccionar a cómo nuestros
usuarios utilizan nuestro sis- tema de encontrar la manera de mejorarlo. Métricas que
nos informan de cómo se comportan nuestros sistemas sólo puede ayudarnos aquí.
160 | Capítulo 8: Seguimiento
Empujamos a cabo una nueva versión de la página web, y encontramos que el
número de búsquedas por géneros se ha incrementado significativamente en el
servicio de catálogo. Es que un problema, o esperar?
Por último, nunca podemos saber qué datos serán útiles! Más veces de las que puedo
contar que he querido capturar datos para ayudar a entender algo que sólo después de
la oportunidad de hacerlo ha pasado mucho tiempo. Tiendo a errar hacia la
exposición de todo y confiar en mi sistema RICS Met para manejar esto más
adelante.
Seguimiento métrica Al otro lado de Servicios
Múltiples | 159
Existen bibliotecas para un número de diferentes plataformas que permiten a nuestros
servicios para enviar métricas para los sistemas estándar. Codahale debiblioteca
métricas es uno de tales biblioteca de ejemplo para la JVM. Se le permite almacenar
métricas como contadores, temporizadores, o calibres; soporta métricas en tiempo
boxeo (para que pueda especificar las métricas como “número de pedidos en los
últimos cinco minutos”); y también viene de la caja con soporte para el envío de
datos a grafito y otra agregación y sistemas de información.
Monitorización sintética
Podemos tratar de averiguar si un servicio es saludable, por ejemplo, decidir lo que
un buen nivel de CPU es, o lo que lo convierte en un tiempo de respuesta aceptable.
Si tem nuestro monitoreo sis- detecta que los valores reales se encuentran fuera de
este nivel seguro, podemos desencadenar una Alert-algo que una herramienta como
Nagios es más que capaz de hacer.
Sin embargo, en muchos sentidos, estos valores se retiran a un paso de lo que
realmente queremos hacer un seguimiento, a saber, es el sistema de trabajo? Cuanto
más compleja es la interacción entre los servicios, se eliminó el más estamos
realmente de responder a esta cues- ción. ¿Y qué si se programan nuestros sistemas
de monitoreo para actuar un poco como nuestros usuarios, y podrían informar si algo
va mal?
Primero lo hice en 2005. Yo era parte de un pequeño equipo ThoughtWorks que era
Building Pro- un sistema para un banco de inversión. A lo largo de la jornada, un
montón de acontecimientos vinieron en la representación de los cambios en el
mercado. Nuestro trabajo consistía en reaccionar a estos cambios, y mirar el impacto
en la cartera del banco. Estábamos trabajando en algunas fechas límites bastante
estrechos, ya que el objetivo era haber hecho todos nuestros cálculos en menos de 10
segundos después del evento llegó. El sistema en sí consistía en alrededor de cinco
servicios discretos, al menos uno de los cuales se ejecutan en una red de computación
que, entre otras cosas, se chatarreros ciclos de CPU no utilizados en alrededor de 250
hosts de escritorio en el centro de recuperación de desastres del banco.
El número de piezas móviles en el sistema significaba mucho ruido estaba siendo
generada a partir de muchas de las métricas de nivel inferior que se reunían. No
teníamos el beneficio de la ampliación gradual o que tengan el sistema funcione
durante unos meses para entender lo que parecía buena para las métricas como
nuestra tasa CPU o incluso las latencias de algunos de los componentes individual y
específico. Nuestro enfoque fue generar eventos falsos a Precio parte del lio portfoque no estaba reservado a los sistemas de aguas abajo. Cada minuto o así, tuvimos
Nagios ejecutar un trabajo de línea de comandos que inserta un evento falso en una
de nuestras colas. Nuestro sistema lo recogió y corrió todos los diversos cálculos al
igual que cualquier otro trabajo, a excepción de los resultados aparecieron en el libro
deseado, que fue utilizado sólo para la prueba. Si una re-fijación de precios no fue
visto en un tiempo determinado, Nagios informó esto como un problema.
162 | Capítulo 8: Seguimiento
Este evento falso que hemos creado es un ejemplo de transacción sintética.
Utilizamos esta transacción tético sin- para asegurar que el sistema se comporta de
vista semántico, por lo que esta técnica se llama a menudo la vigilancia semántica.
Monitoreo sintéticas | 161
En la práctica, he encontrado el uso de transacciones sintéticas para realizar ing
Monitor-semántica, como se trata de un indicador mucho mejor de los problemas en
los sistemas de alerta en las métricas de nivel inferior. No reemplazan la necesidad de
que las métricas de nivel inferior, aunque-nosotros todavía quiere ese detalle cuando
tenemos que averiguar por qué nuestro monitoreo semántica está reportando un
problema.
La implementación de Monitoreo Semántica
Ahora bien, en el pasado, la aplicación de monitoreo semántica era una tarea bastante
desalentadora. Pero el mundo ha cambiado, y los medios de hacer esto es a nuestro
alcance! Estás pruebas Ning RUN para sus sistemas, ¿verdad? Si no, ve a
leerCapítulo 7 y vuelve. ¿Todo listo? ¡Bueno!
Si nos fijamos en las pruebas que tenemos que prueba un servicio dado extremo a
extremo, o incluso todo nuestro sistema de extremo a extremo, tenemos mucho
de lo que necesitamos para implementar ing Monitor-semántica. Nuestro sistema
ya expone los ganchos necesarios para iniciar la prueba y comprobar el resultado.
¿Por qué no basta con ejecutar un subconjunto de estas pruebas, de manera
continua, como una forma de controlar nuestro sistema?
Hay algunas cosas que tenemos que hacer, por supuesto. En primer lugar, tenemos
que tener cuidado con los requerimientos de información de nuestras pruebas. Es
posible que tengamos que encontrar una manera para nuestras pruebas para adaptarse
a diferentes datos en tiempo real si esto cambia con el tiempo, o bien establece una
fuente diferente de datos. Por ejemplo, podríamos tener un conjunto de usuarios
falsos que utilizamos en la producción con un conjunto conocido de datos.
Del mismo modo, tenemos que asegurarnos de que no activan accidentalmente
efectos secundarios imprevistos. Un amigo me contó una historia sobre una
compañía de comercio electrónico que accidentalmente corrió sus pruebas en contra
de sus sistemas de pedidos de producción. No se dio cuenta de su error hasta que un
gran nú- mero de lavadoras llegó a la oficina central.
ID de correlación
Con un gran número de servicios que interactúan para proporcionar cualquier
capacidad del usuario final dado, una sola llamada de iniciación puede terminar la
generación de múltiples llamadas de servicio más aguas abajo. Por ejemplo,
considere el ejemplo de un cliente que está siendo registrada. El cliente rellena todos
sus detalles en un formulario y hace clic en Enviar. Detrás de las escenas,
comprobamos validez de los datos de la tarjeta de crédito con nuestro servicio de
pago, hablamos con nuestro servicio postal para enviar un paquete de bienvenida en
el puesto, y enviar un mensaje de bienvenida con nuestro servicio de correo
electrónico. Ahora lo que sucede si la llamada al servicio de pago termina generando
un error extraño? Hablaremos largo y tendido sobre el manejo de la insuficiencia
162 | Capítulo 8: Seguimiento
deCapítulo 11, Pero tenga en cuenta la dificultad de diagnosticar lo que pasó.
Si nos fijamos en los registros, el único servicio de registro de un error es nuestro
servicio de pago. Si tenemos suerte, podemos trabajar a cabo lo pedido causó el
problema, y podemos incluso ser capaz de mirar a los parámetros de la llamada.
Ahora considera que este es un ejemplo sencillo,
Monitoreo sintéticas | 161
y que una solicitud de iniciación podría generar una cadena de llamadas aguas abajo
y tal vez los eventos que se disparó que se manejan de manera asíncrona. ¿Cómo
podemos reconstruir el flujo de llamadas con el fin de reproducir y solucionar el
problema? A menudo, lo que necesitamos es ver que el error en el contexto más
amplio de la llamada de iniciación; en otras palabras, nos gustaría seguir la cadena de
llamadas aguas arriba, al igual que hacemos con un seguimiento de la pila.
Un enfoque que puede ser útil en este caso es el uso de identificadores de
correlación. Cuando se hizo la primera llamada, se genera un GUID para la llamada.
Esto se hace pasar a continuación a lo largo de todas las llamadas posteriores, como
se ve enFigura 8-5Y se pueden poner en sus registros de una manera estructurada,
todo lo que ya se va a hacer con componentes como el nivel de registro o fecha. Con
el registro de derecho de herramientas gación agregada, a continuación, será capaz de
rastrear ese evento todo el camino a través de su sistema:
15-02-2014
15-02-2014
15-02-2014
15-02-2014
15-02-2014
16:01:01
16:01:02
16:01:03
16:01:03
16:01:03
Web-Frontend INFO [abc-123] Registro
RegisterService INFO [abc-123] RegisterCustomer ...
PostalSystem INFO [abc-123] SendWelcomePack ...
EmailSystem INFO [abc-123] SendWelcomeEmail ...
Pasarela de pago ERROR [abc-123] ValidatePayment ...
Figura 8-5. El uso de identificadores de correlación para realizar un seguimiento de
cadenas de llamadas a través de múltiples servicios
Usted, por supuesto, necesitará asegurarse de que cada servicio sabe transmitir el
identificador de correlación. Aquí es donde usted necesita para estandarizar y ser más
fuertes en la aplicación de esto a través de su sistema. Pero una vez que haya hecho
esto, en realidad se puede crear herramientas para realizar un seguimiento de todo
tipo de interacciones. Tales herramientas puede ser útil en la búsqueda de las
tormentas de eventos, casos de esquina impares, o incluso la identificación de
transacciones especialmente costosos, como se puede imaginar a toda la cascada de
llamadas.
Software como Zipkin También puede rastrear las llamadas a través de múltiples
162
| Capítulo
8: Seguimiento
límites
del sistema.
Sobre la base de las ideas de sistema de rastreo de Google propia,
apuesto, Zipkin puede proporcionar el seguimiento muy detallado de llamadas entre
servicios, junto con una interfaz de usuario para ayudar a presentar los datos.
sonalmente, me he encontrado con los requisitos de Zipkin a ser un poco pesado,
requiriendo clientes personalizados y apoyo a los sistemas de recogida. Teniendo en
cuenta que ya se querrá conectarse
ID de correlación | 163
agregación para otros fines, se siente mucho más simple en lugar de hacer uso de los
datos que ya está recogiendo de tener que sondear en otras fuentes de datos. Dicho
esto, si usted encuentra que necesita una herramienta más avanzada para realizar un
seguimiento de las llamadas entre servicios de este tipo, es posible que desee darles
un vistazo.
Uno de los problemas reales con los ID de correlación es que a menudo no sabe lo
necesita hasta después de que ya tiene un problema que podría ser diagnosticado sólo
si tenías la identificación al principio! Esto es especialmente problemático, como
reequipamiento IDs de correlación en es muy difícil; que necesita para manejarlos de
una manera estandarizada para poder cadenas de llamadas fácilmente reconsititute.
Aunque podría parecer como un trabajo adicional por adelantado, yo fuertemente
sugeriría que los considere el establecimiento de tan pronto como sea posible,
especialmente si su sistema hará uso de patrones de arquitectura evento de
accionamiento, que puede conducir a un comportamiento emergente impar.
Necesidad de manejar tareas como pasar constantemente a través de los ID de
correlación puede ser un fuerte argumento para el uso de las bibliotecas de
derivadores de clientes compartidos delgadas. En una escala determinada, se hace
difícil garantizar que todo el mundo está llamando servicios derivados de la manera
correcta y la recolección de la clase correcta de los datos. Sólo se necesita un servicio
de punto intermedio de la cadena que se olvide de hacer esto para que perder
información crítica. Si decide crear una biblioteca de cliente de la casa para hacer
cosas como esta obra fuera de la caja, no asegurarse de que mantener muy delgada y
no vinculada a ningún ser- vicio producción particular. Por ejemplo, si está utilizando
HTTP como protocolo subyacente para la comu- nicación, simplemente envolver una
biblioteca de cliente HTTP estándar, añadiendo en el código para asegurarse de que
propagan los ID de correlación en las cabeceras.
la Cascade
En cascada fallos puede ser especialmente peligroso. Imagine una situación en la que
la conexión de red entre nuestra página web tienda de música y el servicio de
catálogo se pone. Los propios servicios parecen sanos, pero no pueden hablar entre
sí. Si que acabamos de ver la salud del servicio individual, no sabríamos que hay un
problema. El uso de monitoreo para sintética ejemplo, para imitar a un cliente en
busca de una canción- recogería el problema. Pero también tendríamos que informar
sobre el hecho de que un servicio no puede ver a otro con el fin de determinar la
causa del problema.
Por lo tanto, el seguimiento de los puntos de integración entre los sistemas es la
clave. Cada instancia de servicio debe realizar un seguimiento y exponer la salud de
sus dependencias aguas abajo, desde la base de datos a otros servicios que colaboran.
También debe permitir que esta información se agrega para darle una imagen
enrollada. Usted querrá ver el tiempo de respuesta de las llamadas aguas abajo, y
también detectan si se erroring.
164| Capítulo 8: Seguimiento
Como veremos más en Capítulo 11, Puede utilizar las bibliotecas para implementar
un interruptor de circuito en torno a la red llama para ayudarle a manejar los fallos en
cascada de una manera más elegante, lo que le permite a degradarse con más gracia
su sistema. Algunos de estos libra-
Normalización | 165
Ries, como Hystrix para la JVM, también hacen un buen trabajo de proporcionar
estas capacidades de monitoreo para usted.
Estandarización
Como ya hemos dicho anteriormente, uno de los actos de equilibrio en curso que
necesita para arrancar es donde para permitir que se tomen decisiones estrecho
margen para un solo servicio frente a donde necesita estandarizar a través de su
sistema. En mi opinión, el monitoreo es un área donde la estandarización es
increíblemente importante. Con los servicios de colaboración en un montón de
diferentes maneras de proporcionar capacidades de los usuarios que utilizan
múltiples interfaces, es necesario ver el sistema de una manera holística.
Tú debe tratar de escribir sus registros en un formato estándar. Que debe de tener
todas sus métricas en un solo lugar, y es posible que desee tener una lista de nombres
estándar para sus métricas también; sería muy molesto para un servicio a tener una
métrica llamada ResponseTime, y otra tener uno llamado RspTimeSecs, cuando
quieren decir lo mismo.
Como siempre con la estandarización, las herramientas pueden ayudar. Como he
dicho antes, la clave es hacer que sea fácil de hacer la cosa tan a la derecha por qué
no proporcionar imágenes de máquinas virtuales preconfiguradas con logstash y
collectd listo para salir, junto con las bibliotecas de aplicaciones que le permiten
hablar al grafito con mucha facilidad?
Considere la audiencia
Todos estos datos que estamos reuniendo es para un propósito. Más específicamente,
estamos reuniendo todos estos datos para diferentes personas para ayudar a hacer su
trabajo; estos datos se convierte en una llamada a la acción. Algunos de estos datos
tiene que desencadenar una llamada inmediata a la acción de nuestro apoyo ejemplo
de equipo para, en el caso de una de nuestras pruebas de monitoreo sintéticos que
fallan. Otros datos, como el hecho de que nuestra carga de la CPU se ha
incrementado en un 2% en la última semana, es poten- cialmente sólo de interés
cuando estamos haciendo la planificación de capacidad. Del mismo modo, su jefe es
probablemente va a querer saber de inmediato que los ingresos bajó un 25% después
de la última autorización, pero probablemente no necesita ser despertado, porque las
búsquedas de “Justin Bieber” han subido un 5% en la última hora.
Lo que nuestra gente quiere ver y reaccionar a este momento es diferente de lo que
necesitan cuando la perforación hacia abajo. Por lo tanto, para el tipo de persona que
se busca en estos datos, con- Sider lo siguiente:
• Lo que necesitan saber en este momento
• Lo que tal vez quiera tarde
166| Capítulo 8: Seguimiento
• Cómo les gusta consumir datos
Normalización | 165
Alertar sobre las cosas que necesitan saber en este momento. Crear grandes pantallas
visibles con esta información que se sientan en un rincón de la habitación. darles
acceso fácil a los datos que necesitan conocer más adelante. Y pasar tiempo con ellos
para saber cómo quieren consumir datos. Una discusión acerca de todos los matices
que intervienen en la representación gráfica de la información cuantitativa es, sin
duda fuera del alcance de este libro, pero un gran lugar para comenzar es de Stephen
Few excelente libro de Información Dashboard Design: Visualización de datos de Ata-Glance Monitoreo ( Analítica Prensa).
El futuro
He visto a muchas organizaciones en las métricas están en silos en diferentes
sistemas. métricas de nivel de aplicación, al igual que el número de pedidos
realizados, terminan en un sistema de análisis de propiedad como Omniture, que a
menudo es disponible solamente para seleccionar partes de la empresa, o de lo
contrario termina en el almacén de datos temida, alias donde los datos se va a morir .
Informes de tales sistemas a menudo no está disponible en tiempo real, a pesar de
que es el Ing puesta en cambiar. Mientras tanto, las medidas del sistema, como los
tiempos de respuesta, tasas de error y carga de la CPU se almacenan en los sistemas
que los equipos de operaciones pueden tener acceso. Estos sistemas permiten
normalmente, un camente para la presentación de informes en tiempo real, ya que
normalmente el punto de ellos es provocar una llamada a la acción inmediata.
Históricamente, la idea de que podemos saber acerca de las métricas clave del
negocio de un día o dos más tarde estaba bien, ya que por lo general no fuimos
capaces de reaccionar lo suficientemente rápido como para estos datos para hacer
Any-nada al respecto de todos modos. Ahora, sin embargo, nos movemos en un
mundo en el que muchos de nosotros pueden y empujar a cabo múltiples
comunicados por día. Los equipos ahora se miden no en términos de la cantidad de
puntos que completan, pero en lugar de optimizar el tiempo que toma para el código
de obtener de ordenador portátil para vivir. En tal ambiente, necesitamos todas
nuestras métricas a nuestro alcance para tomar la acción correcta. Irónicamente, los
mismos sistemas que almacenan las métricas de negocio a menudo no están
sintonizados para el acceso inmediato a los datos, pero nuestros sistemas operativos
son.
Entonces, ¿por manejar métricas operativas y de negocio de la misma manera? En
última instancia, ambos tipos de cosas se descomponen a eventos que decir algo que
sucedió en X. Por lo tanto, si podemos unificar los sistemas que utilizamos para
reunir, agregar y almacenar estos eventos, y ponerlos a disposición para la
presentación de informes, nos encontramos con un gran arquitectura más simple.
Riemann es un servidor de eventos que permite la agregación bastante avanzada y el
encaminamiento de eventos y puede formar parte de una solución de este tipo. Suro
es tubería de datos de Netflix y ates oper- en un espacio similar. Suro se utiliza
explícitamente para manejar tanto las métricas asociadas con el comportamiento del
168| Capítulo 8: Seguimiento
usuario, y los datos más operativos como registros de la aplicación. Estos datos
pueden ser enviados a una variedad de sistemas, como tormenta para el análisis en
tiempo real, Hadoop para el procesamiento por lotes fuera de línea, o Kibana para el
análisis de registro.
Muchas organizaciones se están moviendo en una dirección fundamentalmente
diferente: lejos de haberse especializado cadenas de herramientas para diferentes
tipos de métricas y hacia más genérico
Normalización | 165
sistemas de eventos de encaminamiento capaces de escala significativa. Estos
sistemas logran proporcionar mucha más flexibilidad, mientras que al mismo tiempo
realmente simplifica nuestra arquitectura.
Resumen
Por lo tanto, hemos cubierto mucho aquí! Voy a tratar de resumir en este capítulo
algunos consejos de fácil seguimiento.
Para cada servicio:
• Pista tiempo de respuesta de entrada en un mínimo. Una vez que hayas hecho
esto, siga con tasas de error y empezar a trabajar en los indicadores de nivel de
aplicación.
• Pista la salud de todas las respuestas aguas abajo, en un mínimo incluyendo el
tiempo de respuesta de las llamadas aguas abajo, y en el mejor de los índices de
error de seguimiento. Bibliotecas como Hystrix pueden ayudar aquí.
• Estandarizar de cómo y dónde se recogen las métricas.
• Entrar en una ubicación estándar, en un formato estándar, si es posible. La
agregación es un dolor si cada servicio utiliza un diseño diferente!
• Supervisar el sistema operativo subyacente para que pueda localizar a los
procesos autorizados y planificación de capacidad.
Para el sistema:
• métricas de nivel de host agregados como CPU, junto con las métricas de nivel de
aplicación.
• Asegúrese de que su herramienta de almacenamiento métrica permite la
agregación a nivel de sistema o servicio, y profundizar en los hosts individuales.
• Asegúrese de que su herramienta de almacenamiento métrica le permite
mantener los datos de tiempo suficiente para comprender las tendencias en su
sistema.
• Tener una sola herramienta, consultable para agregar y almacenar registros.
• Totalmente de considerar la estandarización en el uso de identificadores de
correlación.
• Entender lo que requiere una llamada a la acción, y alerta estructura y cuadros de
mando en consecuencia.
• Investigar la posibilidad de unificar cómo agregada todas sus diversas RICS Met
viendo si una herramienta como Suro o Riemann tiene sentido para usted.
También he tratado de esbozar la dirección en que se mueve el monitoreo: lejos de
los sistemas especializados para hacer una sola cosa, y hacia sistemas de
resumen | 167
procesamiento de eventos genéricos que le permiten mirar a su sistema de una
manera más integral. Se trata de un ing excit- y el espacio emergente, y al mismo
tiempo una investigación completa está fuera del alcance de este libro, es de esperar
que he dado lo suficiente como para empezar a trabajar con. Si quieres saber más,
168 | Capítulo 8: Seguimiento
Entro en algunas de estas ideas y más en mi publicación anterior Sistemas ligeros
Monitoreo en tiempo real de (O'Reilly).
En el siguiente capítulo, vamos a tener una visión de conjunto diferente de nuestros
sistemas a considerar algunas de las ventajas únicas y desafíos que las arquitecturas
de grano fino pueden proporcionar en el ámbito de la seguridad.
resumen | 167
CAPÍTULO
9
Segurid
ad
hemos familiarizarse con historias sobre violaciones de la seguridad de sistemas a
gran escala resultantes en nuestros datos están expuestos a todo tipo de personajes
poco fiables. Sin embargo, más recientemente, eventos como las revelaciones
Edward Snowden nos han hecho aún más consciente del valor de los datos que las
empresas tienen sobre nosotros, y el valor de los datos que nos son para nuestros
clientes en los sistemas que construimos. En este capítulo se dará una breve
descripción de algunos aspectos de la seguridad que debe considerar en el diseño de
sistemas. Si bien no pretende ser exhaustiva, que despedirá a cabo algunas de las
principales opciones disponibles para usted y le dará un punto de partida para su
propia investigación ulterior.
Nosotros que pensar en lo que la protección de nuestros datos necesita mientras está
en tránsito de un punto a otro, y qué protección que necesita en reposo. Tenemos que
pensar en la seguridad de nuestros sistemas operativos subyacentes, y nuestras redes
también. Hay mucho que pensar, y por lo mucho que podía hacer! Entonces, ¿cuánto
de seguridad necesitamos? ¿Cómo podemos trabajar lo que es suficiente seguridad?
Pero también tenemos que pensar en el elemento humano. ¿Cómo sabemos que es
una persona, y lo que podemos hacer? Y cómo esto se relaciona con la forma en
nuestros servidores se comunican entre sí? Vamos a empezar por ahí.
Autenticacion y autorizacion
Autenticación y autorización son conceptos fundamentales cuando se trata de
personas y cosas que interactúan con nuestro sistema. En el contexto de la seguridad,
la autenticación es el proceso mediante el cual se confirma que una de las partes es
170 | Capítulo 9: Seguridad
quien dice ser. Para un ser humano, por lo general autenticar a un usuario por tener
su tipo en su nombre de usuario y contraseña. Suponemos que sólo ella tiene acceso a
esta información, y por lo tanto que la persona que entra en esta información debe ser
ella. también existen otros sistemas más complejos, por supuesto. Mi teléfono ahora
me permite usar mi huella digital para confirmar que soy quien digo
169
a.m. En general, cuando estamos hablando de manera abstracta acerca de quién o qué
está siendo authentica- Ted, nos referimos a esa parte como el principal.
Autorización es el mecanismo por el cual hacemos un mapa de un director para la
acción estamos permitiendo que haga. A menudo, cuando un director es autenticado,
se nos dará información sobre ella que le ayudará a decidir lo que debemos dejar que
lo haga. Podríamos, por ejemplo, se les diga qué departamento u oficina que trabaja
en piezas de información que nuestros sistemas se pueden utilizar para decidir lo que
puede y no puede hacer.
Para aplicaciones individuales, monolíticos, es común que la propia aplicación para
manejar la autenticación y la autorización para usted. Django, el framework web
Python, sale de la caja con la gestión de usuarios, por ejemplo. Cuando se trata de
siste- mas distribuidos, sin embargo, tenemos que pensar en esquemas más
avanzados. Nosotros no queremos que todos tengan que entrar por separado para los
diferentes sistemas, utilizando un nombre de usuario diferente y la palabra de
Transmisión para cada uno. El objetivo es tener una identidad única que podemos
autenticar una vez.
Común de sesión único Implementaciones
Un enfoque común para la autenticación y autorización es utilizar algún tipo de
solución de inicio de sesión único (SSO). SAML, que es la aplicación que reina en el
espacio empresarial, y OpenID Conectar ambos proporcionan capacidades en esta
área. Más o menos se utilizan los mismos conceptos básicos, aunque la terminología
difiere ligeramente. Los términos utilizados aquí son de SAML.
Cuando un director intenta acceder a un recurso (como una interfaz basada en la
web), que es direc- ted para autenticarse con un proveedor de identidad. Esto puede
preguntarle a proporcionar un nombre de usuario y contraseña, o podría utilizar algo
más avanzada, como la autenticación de dos factores. Una vez que el proveedor de
identidad está convencido de que el director haya sido autenticada, que da
información al proveedor de servicios, que le permita decidir si conceder su acceso al
recurso.
Este proveedor de identidad podría ser un sistema alojado externamente, o algo
dentro de su propia organización. Google, por ejemplo, proporciona una vider pro
OpenID Connect. Para las empresas, sin embargo, es común tener su propio
proveedor de identidad, que puede estar relacionado con el servicio de directorio de
su empresa. Un servicio de directorio podría ser algo así como el Lightweight
Directory Access Protocol (LDAP) o Active Directory. Estos sistemas permiten
almacenar información acerca de las entidades, tales como qué papeles que
desempeñan en la organización. A menudo, el servicio de directorio y el pro veedor
de identidad son una y la misma, mientras que a veces son separados pero
vinculados. Okta, por ejemplo, es un proveedor de identidad SAML alojado que se
encarga de tareas como la autenticación de dos factores, pero puede enlazar a los
servicios de directorio de su empresa como la fuente de la verdad.
170 | Capítulo 9: Seguridad
SAML es un estándar basado en SOAP, y es conocido por ser bastante compleja a
pesar de trabajar con las bibliotecas y herramientas disponibles para apoyarlo.
OpenID Connect es una norma
169
que ha surgido como una implementación específica de OAuth 2.0, basado en la
forma en que Google y otros manejan SSO. Utiliza llamadas REST más simples, y en
mi opinión es probable que hacer incursiones en las empresas debido a su mayor
facilidad de uso. Su mayor obstáculo en este momento es la falta de proveedores de
identidad que lo soportan. Para un sitio web de cara al público, es posible que estar
bien usando Google como su proveedor, pero para los sistemas internos o sistemas en
los que desea más control sobre y visibilidad sobre cómo y dónde se instala sus
datos, usted quiere que su propia identidad en la casa proveedor. En el momento de
ING ESCRITO, OpenAM y Gluu son dos de las pocas opciones disponibles en este
espacio, compararse a una gran cantidad de opciones para SAML (incluyendo Active
Directory, que parece estar en todas partes). Hasta ya menos que los proveedores de
identidad existente empezar a apoyar a OpenID Connect,
Así, mientras pienso OpenID Connect es el futuro, es muy posible que va a tomar un
tiempo para llegar a la adopción generalizada.
Single Sign-On de puerta de enlace
Dentro de una configuración microService, cada servicio podría decidir manejar la
redirección a, y la toma de contacto con el proveedor de identidad. Obviamente, esto
podría significar un montón de trabajo duplicado. Una biblioteca compartida podría
ayudar, pero que tendríamos que tener cuidado para evitar el acoplamiento que puede
venir de código compartido. Esto tampoco sería de ayuda si usted tenía múltiples
diferentes pilas de tecnología.
En lugar de tener cada servicio gestionar apretón de manos con su proveedor de
identidad, se puede utilizar una puerta de entrada a actuar como un proxy, sentado
entre sus servicios y el mundo exterior (como se muestra en Figura 9-1). La idea es
que podemos centralizar el comportamiento para redireccionar al usuario y realizar el
apretón de manos en un solo lugar.
La Figura 9-1. El uso de una puerta de enlace para manejar SSO
170 | Capítulo 9: Seguridad
Autenticación y Autorización | 171
Sin embargo, todavía tenemos que resolver el problema de cómo el servicio de aguas
abajo recibe información acerca de las entidades, como su nombre de usuario o qué
papeles que desempeñan. Si está utilizando HTTP, podría llenar los encabezados con
esta información. Shibboleth es una herramienta que puede hacer esto para usted, y
he visto que se usa con Apache con gran efecto para manejar la integración con
proveedores de identidad basados en SAML.
Otro problema es que si hemos decidido remitir la responsabilidad de authenticación a una pasarela, puede ser más difícil de razonar acerca de cómo se comporta un
microService al mirarlo de forma aislada. Recuerde que enCapítulo 7 donde hemos
explorado algunos de los desafíos en la reproducción de los entornos de producción
similar? Si vas a la ruta de puerta de enlace, asegúrese de que los desarrolladores
pueden lanzar sus servicios, unos tras otros, sin demasiado trabajo.
Un último problema con este enfoque es que se le puede adormecer en una falsa
sensación de seguri- dad. Me gusta la idea de defensa en profundidad, desde el
perímetro de la red, a la subred, a pruebas de inflamabilidad de la pared, a máquina, a
sistema operativo, el hardware subyacente. Usted tiene la capacidad de poner en
práctica medidas de seguridad en todos estos puntos, algunos de los cuales vamos a
entrar en breve. He visto algunas personas ponen todos sus huevos en una canasta,
apoyándose en la puerta de entrada para manejar cada paso para ellos. Y todos
sabemos lo que ocurre cuando tenemos un único punto de fallo ...
Obviamente, usted podría utilizar esta puerta de enlace para hacer otras cosas. Si se
utiliza una capa de instancias de Apache corriendo Shibboleth, por ejemplo, puede
también decidir terminar HTTPS a este nivel, detección de intrusos ejecutar, y así
sucesivamente. Hay que tener cuidado, sin embargo. forma en capas Gate- tienden a
asumir más y más funcionalidad, que en sí mismo puede llegar a ser un punto de
acoplamiento gigante. Y cuanto más funcionalidad algo tiene, mayor es la superficie
de ataque.
Autorización de grano fino
Una puerta de entrada puede ser capaz de proporcionar autenticación bastante eficaz
de grano grueso. Por ejemplo, podría impedir el acceso a cualquier usuario que no ha
iniciado la sesión en el servicio de ayuda a la aplica- ción. Asumiendo nuestra
pasarela puede extraer atributos acerca del principal como resultado de la
autenticación, puede ser capaz de tomar decisiones más matizadas. Por ejemplo, es
común colocar a las personas en grupos, o asignarlos a los roles. Podemos utilizar
esta informa- ción para entender lo que pueden hacer. Así que para la aplicación de
servicio de ayuda, podríamos permitir el acceso sólo a los directores con una función
específica (por ejemplo, personal). Más allá de lo que permite (o mugido disal-) el
acceso a los recursos o puntos finales específicos, sin embargo, tenemos que dejar el
resto a la propia microService; se tendrá que hacer más decisiones acerca de lo que
las operaciones para permitir.
Volver a nuestra solicitud de asistencia: qué permitimos que cualquier miembro del
172| Capítulo 9: Seguridad
personal a ver cualquiera y todos los detalles? Lo más probable es que tendremos
diferentes roles en el trabajo. Por ejemplo, un director en el grupo call_center podría
permitirse para ver cualquier tipo de información sobre un cliente, excepto sus datos
de pago. El director también podría ser capaz de emitir
Servicio-al-servicio de autenticación y autorización | 173
reembolsos, pero esa cantidad podría estar tapados. Alguien que tiene el papel
TER_TEAM_LEADER CALL_CEN-, sin embargo, podría ser capaz de emitir un
reembolso mayor.
Estas decisiones tienen que ser local en el microService en cuestión. He visto
personas utilizan los diversos atributos suministrados por proveedores de identidad
en formas horribles, utilizando papeles muy de grano fino como
CALL_CENTER_50_DOLLAR_REFUND, en el que terminan poniendo la
información específica de una parte de una de comportamiento de nuestro sistema en
sus servicios de directorio. Esto es una pesadilla para mantener y da muy poco
margen para nuestros servicios tengan su propio ciclo de vida independiente, como
de repente un trozo de información sobre cómo se comporta un servicio vidas en otro
lugar, tal vez en un sistema gestionado por una parte dife- rentes de la organización.
En su lugar, favorecer papeles de grano grueso, modelada en torno a cómo funciona
su organización. Va todo el camino de regreso a los primeros capítulos, recordamos
que estamos construyendo el software para que coincida con el funcionamiento de
nuestro organismo. Así que utilice sus papeles de esta manera también.
Servicio-al-servicio de autenticación y autorización
Hasta este punto hemos estado usando el término principal para describir cualquier
cosa que pueda autenticar y estar autorizado para hacer las cosas, pero nuestros
ejemplos se han hecho acerca de los humanos que usan computadoras. Pero ¿qué
pasa con los programas, u otros servicios, autenti- ticating uno con el otro?
Permitir que todo el interior del perímetro
Nuestra primera opción podría ser simplemente asumir que cualquier llamada a un
servicio realizado desde el interior de nuestro perímetro son de confianza implícita.
Dependiendo de la sensibilidad de los datos, esto podría estar bien. Algunas
organizaciones tratan de garantizar la seguridad en el perímetro de sus redes, y por lo
tanto asumen que no es necesario hacer nada más que dos servicios están hablando
juntos. Sin embargo, un atacante debe penetrar en su red, tendrá poca protección
contra un típico ataque man-in-the-middle. Si el atacante decide interceptar y leer los
datos que se envían, cambiar los datos sin conocimiento del usuario, o incluso en
algunas circunstancias pre tienden a ser lo que está hablando, usted no puede saber
mucho al respecto.
Esto es, con mucho, la forma más común de confianza dentro de perímetro que veo
en las organizaciones. Pueden decidir ejecutar este tráfico a través de HTTPS, pero
no hacer mucho más. No estoy diciendo que es una buena cosa! Para la mayoría de
las organizaciones que veo que utilizan este modelo, me preocupa que el modelo de
confianza implícita no es una decisión consciente, pero más que las personas no son
conscientes de los riesgos en el primer lugar.
174| Capítulo 9: Seguridad
HTTP (S) de autenticación básica
La autenticación básica HTTP permite que un cliente envía un nombre de usuario y
contraseña en un encabezado HTTP estándar. El servidor puede comprobar estos
detalles y confirmar que el cliente está autorizado para acceder al servicio. La ventaja
aquí es que este es un protocolo extremadamente bien entendido y bien soportado. El
problema es que hacer esto a través de HTTP es muy problemático, ya que el nombre
de usuario y la contraseña no se envían de forma segura. Cualquier parte intermedia
puede ver la información en la cabecera y ver los datos. Por lo tanto, la autenticación
básica HTTP normalmente se debe utilizar a través de HTTPS.
Cuando se utiliza HTTPS, el cliente obtiene garantías firmes de que el servidor se
está hablando con quién es el cliente piensa que es. También nos da una protección
adicional contra las personas escuchas ilegales en el tráfico entre el cliente y el
servidor o jugar con la carga de PAY.
El servidor necesita para gestionar sus propios certificados SSL, que pueden llegar a
ser problemático cuando se está gestionando múltiples máquinas. Algunas
organizaciones adquieren su propio proceso de emisión cado certifi-, que es una
carga administrativa y operativa adicional. Herramientas alrededor de la gestión de
esta forma automatizada son ni mucho menos tan madura como podrían ser, y no es
sólo el proceso de emisión que tiene que manejar. certifica- dos auto-firmados no son
fácilmente revocable, y por lo tanto requiere de mucho más pensamiento en torno
escenarios de desastre. Ver si se puede esquivar todo este trabajo, evitando
autofirmar por completo.
Otra desventaja es que el tráfico enviado a través de SSL no puede ser almacenado en
caché por los proxies inversos como barniz o calamar. Esto significa que si usted
necesita para almacenar en caché el tráfico, tendrá que ser hecho ya sea dentro del
servidor o en el interior del cliente. Puedes solucionar este problema por tener un
equilibrador de carga por terminado el tráfico SSL, y tener la sentada detrás de la
caché equilibrador de carga.
Nosotros También hay que pensar en lo que sucede si estamos utilizando una solución
SSO existente, como SAML, que ya tiene acceso a los nombres de usuario y
contraseñas. ¿Queremos que nuestro servicio básico de autenticación a utilizar el
mismo conjunto de credenciales, lo que nos permite un proceso para ing issu- y
revocación de ellos? Podríamos hacer esto a través de la charla de servicios al mismo
servicio toria direc- que respalda nuestra solución SSO. Alternativamente, podríamos
almacenar los usuarios y contraseñas a nosotros mismos dentro del servicio, pero
corremos el riesgo de duplicar el comportamiento.
Una nota: en este enfoque, todo el servidor sabe es que el cliente tiene el nombre de
usuario y contraseña. No tenemos idea de si esta información proviene de una
máquina que esperamos; que puede provenir de cualquier persona en nuestra red.
El uso de SAML o OpenID Conectar
Servicio-al-servicio de autenticación y autorización | 175
Si ya está utilizando SAML o OpenID Conectar como su esquema de autenticación y
autorización, es posible que utilices para que las interacciones de servicio a servicio
también. Si está utilizando una puerta de entrada, deberá encaminar el tráfico de todo
dentro de la red a través de la puerta de entrada también, pero si cada servicio se
encarga de la integración en sí, este enfoque sólo debe
176| Capítulo 9: Seguridad
trabajar fuera de la caja. La ventaja aquí es que usted está haciendo uso de la
infraestructura existente, y llegar a centralizar todos sus controles de acceso al
servicio en un servidor de directorio central. Todavía había necesidad de ruta de este
a través de HTTPS si queríamos evitar man-in-the-middle.
Los clientes tienen un conjunto de credenciales que utilizan para autenticarse con el
proveedor de identidad, y el servicio obtiene la información que necesita para decidir
sobre cualquier autentificación de grano fino.
Esto significa que necesitará una cuenta para sus clientes, a veces referido como una
cuenta de servicio. Muchas organizaciones utilizan este enfoque con bastante
frecuencia. Una palabra de advertencia, sin embargo: si se va a crear cuentas de
servicio, trate de mantener su uso nar- fila. Así que considerar cada microService
tiene su propio conjunto de credenciales. Esto hace revocación / cambiar un acceso
más fácil si las credenciales verse en peligro, ya que sólo necesita revocar el conjunto
de credenciales que se han visto afectados.
Hay un par de otras desventajas, sin embargo. En primer lugar, al igual que con
autenticación básica, tenemos que almacenar de forma segura nuestras credenciales:
¿de dónde el nombre de usuario y contraseña viven? El ent CLI- tendrá que encontrar
alguna forma segura de almacenar estos datos. El otro problema es que algunas de las
tecnologías en este espacio para hacer la autenticación es bastante tedioso para
codificar. SAML, en particular, hace que la implementación de un cliente en un
asunto doloroso. OpenID Con- Nect tiene un flujo de trabajo más sencillo, pero como
hemos comentado anteriormente no es así que todavía compatible.
certificados de cliente
Otro enfoque para confirmar la identidad de un cliente es hacer uso de las
capacidades de seguridad de la capa de transporte (TLS), el sucesor de SSL, en forma
de certificados de cliente. En este caso, cada cliente tiene instalado un certificado
X.509 que se utiliza para establecer un vínculo entre el cliente y el servidor. El
servidor puede verificar la autenticidad de cado el cliente certifi-, proporcionando
garantías firmes de que el cliente es válida.
Los retos operativos aquí en la gestión de certificados son aún más onerosa que con
sólo el uso de certificados de servidor. No es sólo algunas de las cuestiones básicas
de la crea- ating y gestionar un mayor número de certificados; más bien, es que con
todas las complejidades alrededor de los propios certificados, se puede esperar a
pasar mucho tiempo tratando de diagnosticar por qué un servicio no aceptará lo que
creemos que es un certificado de cliente completamente válido. Y entonces tenemos
que considerar la dificultad de revocar y reexpedir los certificados si sucede lo peor.
El uso de certificados comodín puede ayudar, pero no va a resolver todos los
problemas. Esta carga adicional significa que va a estar buscando a utilizar esta
técnica cuando usted está especialmente preocupado por la sensibilidad de los datos
que se envían, o si va a enviar datos a través de redes no lo hace totalmente de
control.
Servicio-al-servicio de autenticación y autorización | 177
HMAC a través de HTTP
Como hemos comentado anteriormente, el uso de la autenticación básica sobre HTTP
plano no se torios Bly razonable si nos preocupa el nombre de usuario y la contraseña
sean comprometidos. La alternativa es tradicional ruta de tráfico HTTPS, pero hay
algunas desventajas. Aparte de la gestión de los certificados, la sobrecarga de tráfico
HTTPS puede colocar adi- cional tensión en los servidores (aunque, para ser honesto,
esto tiene un impacto menor de lo que hizo hace varios años), y el tráfico no puede
ser fácilmente almacenado en caché.
Un enfoque alternativo, tal como se utiliza ampliamente por APIs S3 de Amazon
para AWS y en partes de la especificación OAuth, es utilizar un código de mensajería
basado en hash (HMAC) para firmar la solicitud.
Con HMAC la solicitud cuerpo junto con una clave privada es ordenado, y el hash
resultante se envía junto con la solicitud. El servidor utiliza su propia copia de la
clave privada y el cuerpo de la petición para volver a crear el hash. Si coincide,
permite la solicitud. Lo bueno aquí es que si un hombre en el medio se mete con la
solicitud, entonces el hash no coincidirá y el servidor sabe que la solicitud haya sido
manipulado. Y la clave pri- vado nunca se envía en la solicitud, por lo que no puede
verse comprometida durante el transporte! El beneficio añadido es que este tráfico
puede entonces más fácilmente ser almacenado en caché, y la sobrecarga de la
generación de los valores hash bien puede ser inferior a manejar el tráfico de HTTPS
(aunque su kilometraje puede variar).
Hay tres desventajas de este enfoque. En primer lugar, tanto el cliente como el
servidor necesitan un secreto compartido que debe ser comunicada de alguna manera.
¿Cómo lo comparten? Se podría hardcoded en ambos extremos, pero entonces usted
tiene el problema de revocar el acceso si el secreto se convierte en peligro. Si se
comunica esta clave sobre algún protocolo alternativo, entonces usted necesita para
asegurarse de que ese protocolo también es muy seguro!
En segundo lugar, se trata de un patrón, no una norma, y por lo tanto hay formas
divergentes de imple- Menting ella. Como resultado, hay una escasez de buenas
implementaciones, abiertos y utilizables de este enfoque. En general, si este enfoque
le interesa, a continuación, hacer un poco más lectura para entender las diferentes
formas en que se hace. Me gustaría ir tan lejos como para decir que basta con ver
cómo Amazon hace esto para S3 y copiar su enfoque, sobre todo utilizando una
función hash sensible con una forma adecuada a largo clave como SHA-256.JSON
fichas web (JWT) son también vale la pena mirar, a medida que implementan un
enfoque muy similar y parecen estar ganando impulso. Pero ser consciente de la
dificultad de conseguir esta materia derecha. Mi compañero estaba trabajando con un
equipo que estaba llevando a cabo su propia implementación JWT, omite un solo
cheque de Boole, e invalidó toda su código de identificación! Esperemos que con el
tiempo veremos más implementaciones de bibliotecas reutilizables.
178| Capítulo 9: Seguridad
Por último, entiende que este enfoque sólo se asegura que ningún tercero tiene
mani- RELAClONADAS la solicitud y que la clave privada en sí sigue siendo
privada. El resto de los datos en la solicitud seguirá siendo visible para los
partidos espionaje en la red.
Claves API
Todas las API públicas de servicios como Twitter, Google, Flickr, y AWS hacen uso
de claves de la API. claves de la API permiten un servicio para identificar que está
haciendo una llamada, y poner límites a lo que pueden hacer. A menudo, los límites
van más allá de simplemente dar acceso a un recurso, y pueden extenderse a acciones
como personas específicas que limitan la velocidad para proteger la calidad del
servicio para otras personas.
Cuando se trata de usar claves de la API para manejar su propio enfoquemicroService a microService, los mecanismos exactos de cómo funciona dependerán
de la tecnología que utiliza. Algunos sistemas utilizan una única clave de API que se
comparte, y utilizan un enfoque similar al HMAC como se acaba de describir. Un
enfoque más común es utilizar un par de claves pública y privada. Por lo general,
podrás gestionar claves en el centro, al igual que nos administrar identidades de las
personas en el centro. El modelo de pasarela es muy popular en este espacio.
Parte de su popularidad se debe al hecho de que las claves de la API se centran en la
facilidad de uso para los programas. En comparación con el manejo de un apretón de
manos SAML, authentica- ción basada en la clave de API es mucho más simple y
directo.
Las capacidades exactas de los sistemas varían, y hay múltiples opciones, tanto en el
espacio comercial y de código abierto. Algunos de los productos que se encarga
solamente el intercambio de claves de API y un poco de gestión de claves básica.
Otras herramientas ofrecen de todo, hasta e incluyendo la limitación de velocidad,
monetización, catálogos API y sistemas de descubrimiento.
Algunos sistemas API permiten al puente de claves de la API a los servicios de
directorio existentes. Esto le permitiría a emitir claves de la API a los directores (que
representan a personas o sistemas) en su organización, y controlar el ciclo de vida de
las claves de la misma manera en que se mane- jan sus credenciales normales. Esto
abre la posibilidad de permitir el acceso a sus servicios en diferentes formas, pero
manteniendo la misma fuente de la verdad, por ejemplo, mediante SAML para
autenticar a los seres humanos para SSO, y el uso de claves de la API para la
comunicación de servicio a servicio, como se muestra enFigura 9-2.
Servicio-al-servicio de autenticación y autorización | 179
Figura 9-2. Utilizando los servicios de directorio para sincronizar la información
principal entre un SSO y una puerta de enlace API
El problema Adjunto
Tener un director autenticar con un microserservice dado es bastante simple. ¿Pero
qué sucede si ese servicio, entonces tiene que hacer llamadas adicionales para
completar un fun- cionamiento? Echa un vistazo aFigura 9-3, Que ilustra sitio de
compras en línea de MusicCorp. Nuestra tienda en línea es un navegador basado en
JavaScript interfaz de usuario. Se realiza llamadas a una aplicación de tienda del lado
del servidor, utilizando el patrón backends-para-interfaces describimos enCapítulo 4.
Las llamadas realizadas entre el navegador y el servidor de llamadas pueden ser
autenticados mediante SAML o OpenID Connect o similar. Hasta aquí todo bien.
Cuando estoy conectado, puedo hacer clic en un enlace para ver detalles de un
pedido. Para mostrar la información, hay que tirar de la orden original del servicio de
orden, pero también queremos buscar información de la orden de envío. Así clic en el
enlace a / OrderStatus / 12345 hace que la tienda en línea para iniciar una llamada
desde el servicio de tienda online tanto para el servicio de servicio de pedidos y el
envío preguntando por esos detalles. Pero si estos servicios derivados aceptar las
llamadas de la tienda en línea? Podríamos adoptar una postura de confianza implícita
que debido a que la llamada es de origen dentro de nuestro ter perime-, que está bien.
Podríamos incluso utilizar los certificados o claves API para confirmar que sí, lo que
realmente es la tienda en línea solicitando esta información. Pero es esto suficiente?
180| Capítulo 9: Seguridad
Figura 9-3. Un ejemplo en el que un diputado confusa podría entrar en juego
Hay un tipo de vulnerabilidad, denominada el problema adjunto confusa, que en el
con- texto de la comunicación de servicio a servicio se refiere a una situación en la
que un usuario malintencionado puede engañar a un servicio adjunto en la realización
de llamadas a un servicio de aguas abajo en su nombre que él no debería ser capaz de
hacerlo. Por ejemplo, como cliente, al iniciar sesión en el sistema de compras en
línea, puedo ver más detalles de la cuenta. ¿Y si pudiera engañar a la interfaz de
usuario de ping tienda- en línea en la fabricación de una solicitud de alguien más
detalles, tal vez haciendo una llamada con el que ha iniciado sesión en credenciales?
En este ejemplo, ¿cuál es para que dejara de pedir órdenes que no son mías? Una vez
iniciada la sesión, pude empezar a enviar solicitudes de otras órdenes que no son
mías para ver si podía obtener información útil. Podríamos tratar de proteger contra
esta dentro de la misma tienda en línea, comprobando que la orden es para rechazarla
y si alguien está pidiendo cosas que no debería. Si tenemos un montón de diferentes
aplicaciones que salen a la superficie esta informa- ción, sin embargo, que podría ser
potencialmente duplicar esta lógica en muchos lugares.
Nosotros podría encaminar peticiones directamente desde la interfaz de usuario para el
servicio de pedidos y deje que se validen fecha de la solicitud, pero luego llegamos a
los diversos inconvenientes que discutimos en Capítulo 4. Por otra parte, cuando la
tienda en línea envía la solicitud al servicio de orden, que podría indicar no sólo lo
que quiere el fin, sino también en nombre del cual está pidiendo. Algunos esquemas
nológica autenti- nos permiten pasar las credenciales del principal original, aguas
abajo, aunque con SAML esto es un poco de una pesadilla, con la participación
aserciones SAML anidadas que son técnicamente posible, pero tan difícil que nadie
lo hace. Esto puede llegar a ser aún más complejo, por supuesto. Imagínese si los
servicios de la tienda en línea charlas a su vez hacen más llamadas aguas abajo.
¿Hasta dónde tenemos que ir en la validación de la confianza de todos los diputados?
Este problema, por desgracia, no tiene una respuesta sencilla, ya que no es un
problema sencillo. Tenga en cuenta que existe, sin embargo. Dependiendo de la
Servicio-al-servicio de autenticación y autorización | 181
sensibilidad de la operación en
182| Capítulo 9: Seguridad
pregunta, usted podría tener que elegir entre una confianza implícita, la verificación
de la identidad de la persona que llama, o pidiendo a la persona que llama para
proporcionar las credenciales del capital original.
Asegurar los datos en reposo
Datos mentir acerca es un pasivo, especialmente si es sensible. Con suerte que hemos
hecho cuanto esté en nuestra para asegurar los atacantes no puedan romper nuestra
red, y también que no podemos romper nuestras aplicaciones o sistemas operativos
para obtener acceso a la estrecha subyacente arriba. Sin embargo, tenemos que estar
preparados en caso de que lo hacen-defensa en profundidad es la clave.
Muchos del alto perfil de las brechas de seguridad implican datos en reposo siendo
adquiridas por un atacante, y que los datos sistema legible por el atacante. Esto se
debe a que los datos se almacenan en una forma no cifrada, o porque el mecanismo
que se utiliza para proteger los datos tenía un defecto fundamental.
Los mecanismos por los cuales la información segura pueden ser protegidos son
muchas y variadas, pero lo que se aproximan a elegir, hay algunas cosas generales a
tener en cuenta.
Ir a la bien conocida
La forma más sencilla que puede estropear el cifrado de datos es tratar de poner en
práctica sus propios algoritmos de cifrado, o incluso tratar de poner en práctica de
otra persona. Cualquiera que sea el lenguaje programa- ming que utilice, tendrá
acceso a las implementaciones revisados regularmente, parcheadas de algoritmos de
cifrado bien considerados. Utilizar esos! Y suscribirse a las listas de correo / listas de
referencia para la tecnología que elija para asegurarse de que son conscientes de las
vulnerabilidades ya que se encuentran para que pueda mantenerlos parcheado y hasta
la fecha.
Para el cifrado en reposo, a menos que tenga una muy buena razón para escoger otra
cosa, elegir una aplicación bien conocida de AES-128 o AES-256 para su platform.1
Tanto los tiempos de ejecución de Java y .NET incluyen implementaciones de AES
que son altamente probable que sea bien probada (y bien parcheado), pero existen
bibliotecas separadas para la mayoría de las plataformas también- por ejemplo, el
bibliotecas castillo hinchable para Java y C #.
Para las contraseñas, se debe considerar el uso de una técnica llamada salada hash de
la clave.
Mal implementado cifrado podría ser peor que no tener ninguno, como la falsa
sensación de seguridad (perdón por el juego de palabras) que puede llevar a tomar su
ojo de la pelota.
180 | Capítulo 9: Seguridad
1 En general, longitud de la clave aumenta la cantidad de trabajo necesario para la fuerza bruta-romper una
llave. Por lo tanto se puede asumir el la clave más larga, más segura sus datos. Sin embargo, algunos
problemas de menor importancia se han planteado acerca de la implementación de AES-256 para ciertos tipos
de llaves por el experto en seguridad respetadoBruce Schneier. Esta es una de las áreas en las que hay que
hacer más investigación sobre lo que el consejo actual es en el momento de la lectura!
Asegurar los datos en reposo
| 181
Sólo se trata de los Cayos
Como se ha cubierto hasta el momento, el cifrado se basa en un algoritmo de tomar
los datos a ser cifrados y una clave y luego producir los datos cifrados. Por lo tanto,
donde se almacena su clave? Ahora bien, si estoy cifrando los datos de mi porque
estoy preocupado por que alguien le robe toda mi base de datos, y almacenar la clave
que utilizo en la misma base de datos, entonces realmente no he logrado mucho! Por
lo tanto, tenemos que almacenar las claves en otro lugar. ¿Pero donde?
Una solución es utilizar un dispositivo de seguridad separado para cifrar y descifrar
datos. Otra es utilizar una bóveda llave separada que su servicio puede acceder
cuando se necesita una llave. La gestión del ciclo de vida de las teclas (y el acceso a
cambiarlos) puede ser una operación importante, y estos sistemas puede manejar esto
para usted.
Algunas bases de datos, incluso incluyen soporte integrado para el cifrado, como el
cifrado de datos transparente de SQL Server, que tienen como objetivo manejar esto
de una manera transparente. Incluso si su base de datos de elección no, la
investigación de cómo se manejan las claves y entender si la amenaza está
protegiendo contra la realidad está siendo mitigada.
Una vez más, esto es complejo. Evitar la aplicación de su cuenta, y hacer algo de una
buena investigación!
Recoger sus objetivos
Suponiendo que todo debe ser encriptada puede simplificar un poco las cosas. No
hay conjeturas sobre lo que debe o no debe ser protegida. Sin embargo, usted todavía
necesita pensar acerca de qué datos se pueden poner en los archivos de registro para
ayudar a la identificación de problemas, y la sobrecarga de cálculo de cifrar todo
puede llegar a ser bastante onerosa, necesidad- ing hardware más potente como
resultado. Esto es aún más difícil cuando se está aplicando migraciones de bases de
datos como parte de los esquemas de refactorización. Dependiendo de que se realicen
los cambios, los datos pueden necesitar ser descifrado, emigrado, y vuelve a cifrar.
Al subdividir el sistema en más servicios de grano fino, es posible identificar todo un
almacén de datos que pueden ser encriptados al por mayor, pero incluso entonces es
poco probable. LIMIT- ing este cifrado a un conjunto conocido de tablas es un
enfoque sensato.
Descifrar bajo demanda
Cifrar los datos cuando se ve por primera vez. Sólo descifrar en la demanda, y
asegurarse de que los datos nunca se almacena en cualquier lugar.
Las copias de seguridad Cifrar
Las copias de seguridad son buenas. Queremos copia de seguridad de nuestros datos
180 | Capítulo 9: Seguridad
importantes, y casi por definición, los datos nos preocupa lo suficiente acerca de que
queremos cifrar es suficientemente importante como para realizar copias de
seguridad! Por lo que puede parecer un punto obvio, pero tenemos que asegurarnos
de que nuestras copias de seguridad también están cifradas. Esto también significa
que necesitamos saber qué teclas son
Asegurar los datos en reposo
| 181
necesaria para manejar la versión de datos, especialmente si cambian las claves.
Tener clara la gestión de claves se vuelve bastante importante.
Defensa en profundidad
Como he mencionado antes, me gusta poner todos los huevos en una sola canasta. Es
todo acerca de la defensa en profundidad. Hemos hablado ya sobre la seguridad de
los datos en tránsito, y asegurar los datos en reposo. Pero hay otras protecciones que
podría poner en marcha para ayudar?
Los cortafuegos
Tiene uno o más servidores de seguridad es una medida muy sensible a tomar.
Algunos son muy sim- ple, capaces sólo para restringir el acceso a ciertos tipos de
tráfico en algunos puertos. Otros son más sofisticados. ModSecurity, por ejemplo, es
un tipo de firewall de aplicaciones que pueden ayudar a las conexiones de la válvula
reguladora de ciertos rangos de IP y detectar otros tipos de ataques preciosos Malí-.
No hay valor en tener más de un firewall. Por ejemplo, puede decidir utilizar
IPTables localmente en un host para asegurar ese host, la configuración de la entrada
y la salida permitida. Estas reglas pueden ser adaptados a los servicios que se
ejecutan a nivel local, con un servidor de seguridad en el perímetro para controlar el
acceso general.
Inicio sesión
Buen registro, y en concreto la capacidad de agregar registros a partir de múltiples
sistemas, no se trata de la prevención, pero pueden ayudar con la detección y
recuperación de las cosas malas que suceden. Por ejemplo, después de aplicar los
parches de seguridad se puede ver a menudo en los registros si la gente ha estado
explotando ciertas vulnerabilidades. Parches se asegura de que no se HAP pluma de
nuevo, pero si ya ha sucedido, puede que tenga que entrar en modo de recuperación.
Tener registros disponibles le permite ver si algo malo sucedió después de los
hechos.
Sin embargo, observamos que tenemos que tener cuidado con lo que la información
que almacenamos en nuestros registros! información sensible tiene que ser
sacrificadas para garantizar que no tengan fugas de datos importantes en nuestros
registros, lo que podría llegar a ser un gran destino para los atacantes.
Detección de Intrusos (y prevención) Sistema
Intrusión sistemas de detección (IDS) puede supervisar redes o sistemas principales
para el comporta- miento sospechoso, informar de los problemas cuando se los ve.
Los sistemas de prevención de intrusiones (IPS), así como el monitoreo de actividad
sospechosa, puede intervenir para evitar que suceda. A diferencia de un servidor de
182| Capítulo 9: Seguridad
seguridad, que busca principalmente hacia el exterior para evitar que las cosas malas
de entrar, IDS e IPS están buscando activamente dentro del perímetro de un
comportamiento sospechoso. Cuando estás empezando desde cero, IDS puede tener
más sentido. Estos sistemas están basados en la heurística (al igual que muchos
cortafuegos de aplicación), y es posible que el conjunto de partida genérica de reglas
o será demasiado indulgente o no indulgente suficiente para que el comportamiento
de su servicio.
Defensa en profundidad |
183
El uso de un IDS más pasivos para avisarle de problemas es una buena manera de
ajustar sus reglas antes de utilizarlo en una capacidad más activo.
La segregación de la red
Con un sistema monolítico, tenemos límites a cómo podemos estructurar nuestras
redes para proporcionar protecciones adicionales. Con microservicios, sin embargo,
usted puede ponerlos en distintos segmentos de red para controlar mejor cómo los
servicios se comuniquen entre sí. AWS, por ejemplo, proporciona la capacidad de
prestación de forma automática una nube privada virtual (VPC), que permiten a los
anfitriones viven en subredes separadas. A continuación, puede especificar qué VPC
puede verse entre sí mediante la definición de reglas de peering, e incluso enrutar el
tráfico a través de pasarelas de acceso de proxy, que le da, en efecto, varios
perímetros en los que las medidas de seguridad adicionales se pueden poner en su
lugar.
Esto le podría permitir a las redes de segmento basado en la propiedad del equipo, o
tal vez por nivel de riesgo.
Sistema operativo
Nuestros sistemas se basan en una gran cantidad de software que no escribimos, y
pueden tener vulnerabilidades de seguridad que podrían exponer nuestra aplicación,
es decir, nuestros sistemas operativos y las otras herramientas de apoyo que se
ejecutan en ellos. Aquí, consejos básicos puede obtener un largo camino. Comience
con sólo el funcionamiento de los servicios como usuarios de sistemas operativos que
tienen el menor número de permisos como sea posible, para asegurar que si se ve
comprometida tal cuenta que va a hacer el mínimo daño.
A continuación, parchear el software. Regularmente. Esto necesita ser automatizado,
y lo que necesita saber si sus máquinas están fuera de sincronía con los últimos
niveles de parches. Herramientas como SCCM de Micro suave o caminata espacial
de RedHat puede ser beneficioso aquí, ya que pueden ayudar a ver si las máquinas
están al día con los últimos parches e iniciar cambios si es necesario. Si está
utilizando herramientas como Ansible, de marionetas, o el chef, es probable que ya
está bastante contento con empujar a cabo cambios automática-estas herramientas
puede obtener un largo camino también, pero no lo harán todo para usted.
Esto realmente es lo básico, pero es sorprendente la frecuencia con que veo correr
software crítico en los sistemas operativos sin parches, viejos. Puede tener la
seguridad a nivel de aplicación tegido más bien definida y pro en el mundo, pero si
tienes una versión antigua de un servidor web que se ejecuta en el equipo como raíz
que tiene un desbordamiento de búfer vulnerabilidad sin parche, entonces su sistema
todavía podría ser extremadamente vulnerables.
Otra cosa a mirar si está utilizando Linux es la aparición de los módulos de seguridad
para el propio sistema operativo. AppArmour, por ejemplo, le permite definir cómo
184| Capítulo 9: Seguridad
se espera que su aplicación se comporte, con el kernel de mantener un ojo sobre él. Si
comienza a hacer algo que no debe, los pasos del núcleo en. AppArmour ha existido
durante un tiempo, ya que cuenta con SELinux. Aunque técnicamente cualquiera de
ellos debería funcionar en cualquier sistema Linux moderna, en la práctica algunas
distribuciones apoyan uno mejor que el
Defensa en profundidad |
183
otro. AppArmour se utiliza por defecto en Ubuntu y SuSE, por ejemplo, mientras
SELinux tradicionalmente ha sido bien apoyada por RedHat. Una nueva opción es
GrSSecurity, que pretende ser más fácil de usar que sea AppArmour o Grsecurity al
mismo tiempo tratando de ampliar sus capacidades, pero requiere un kernel
personalizado para trabajar. Te sugiero echar un vistazo a los tres para ver cuál se
ajusta mejor a sus casos de uso, pero me gusta la idea de tener otra capa de
protección y prevención en el trabajo.
A Ejemplo resuelto
Tener una arquitectura de sistema de grano más fino nos da mucha más libertad en la
forma en que implementamos nuestra seguridad. Para aquellas partes que tienen que
ver con la información más sensible o exponen las capacidades más valiosas,
podemos adoptar las disposi- ciones más estrictas de seguridad. Sin embargo, para
otras partes del sistema, podemos darnos el lujo de ser mucho más laxos en lo que
nos preocupa.
Vamos MusicCorp considerar una vez más, y tirar de algunos de los conceptos
anteriores juntos para ver dónde y cómo se puede utilizar algunas de estas técnicas de
seguridad. Estamos buscando principalmente a las preocupaciones de seguridad de
los datos en tránsito y en reposo.Figura 9-4 muestra un subconjunto de todo el
sistema que vamos a estar analizando, que en la actualidad muestra una falta de
consideración de trituración por motivos de seguridad. Todo se envía a través de
HTTP plano de edad.
Figura 9-4. Un subconjunto de la arquitectura lamentablemente insegura de
MusicCorp
Aquí tenemos los navegadores web estándar que son utilizados por nuestros clientes
para hacer compras en el sitio. También se introduce el concepto de una puerta de
entrada libre de terceros: hemos comenzado a trabajar con una compañía de terceros
que se encargará de los pagos de regalías para nuestro nuevo servicio de streaming.
186| Capítulo 9: Seguridad
Nos contactos de vez en cuando para tirar hacia abajo registros de lo que la música se
ha transmitido al-información que protegemos celosamente como nos preocupa
compe- tencia de las compañías rivales. Por último, exponemos nuestros datos del
catálogo a otros terceros par- vínculos, por ejemplo, permitiendo que los metadatos
acerca artista o canción que se incrusta en
Defensa en profundidad |
183
sitios de la revisión de la música. Dentro de nuestro perímetro de la red, tenemos
algunos servi- cios colaboradoras, que sólo alguna vez se utilizan internamente.
Para el navegador, vamos a utilizar una mezcla de tráfico HTTP estándar para el
contenido no seguro, para permitir que se almacene en caché. Por seguro, que ha
iniciado sesión en las páginas, todo el contenido seguro se enviará a través de
HTTPS, dando a nuestros clientes una protección adicional si están haciendo las
cosas como Run-Ning en redes WiFi públicas.
Cuando se trata del sistema de pago de derechos de terceros, nos preocupa no sólo
sobre la naturaleza de los datos que estamos exponiendo, sino que también trata de
asegurarse de las solicitudes que estamos recibiendo son legítimas. Aquí, insistimos
en que nuestra tercero utiliza certificados de cliente. Todos los datos se envían a
través de un canal seguro, cifrado, el aumento de nuestra capacidad de asegurar que
está pidiendo para estos datos por la persona correcta. Nosotros, por supuesto, tiene
que pensar en lo que sucede cuando los datos sale de nuestro control. Lo hará nuestro
cuidado pareja acerca de los datos tanto como lo hará?
Para los feeds de datos del catálogo, queremos que esta información se comparta lo
más ampliamente posible para permitir a la gente a comprar fácilmente la música de
nosotros! Sin embargo, no queremos que este abuso, y nos gustaría una idea de quién
está utilizando nuestros datos. Aquí, claves de la API tienen perfecto sentido.
En el interior del perímetro de la red, las cosas son un poco más matizada. Lo
preocupados que estamos por la gente comprometer nuestras redes internas?
Idealmente, nos gustaría utilizar HTTPS en un mínimo, pero la gestión de TI es algo
doloroso. Decidimos en vez de poner la obra (en un principio, al menos) en el
endurecimiento de nuestro perímetro de la red, incluyendo el tener un cortafuegos
bien configurado y la selección de un hardware apropiado o software de seguridad
apli- Ance a observar el tráfico malicioso (por ejemplo, el escaneo de puertos o de
denegación de -Servicio de ataques).
Dicho esto, nos preocupa que algunos de nuestros datos y en el que vive. No estamos
wor- Ried acerca del servicio de catálogo; Después de todo, queremos que los datos
compartidos y han proporcionado una API para él! Pero estamos muy preocupados
por los datos de nuestros clientes. Aquí, decidimos para cifrar los datos en poder de
la atención al cliente, y descifrar datos de lectura. Si ers ATTACK- hacen penetrar en
nuestra red, que aún podrían funcionar peticiones contra el cliente ser- API de hielo,
pero la implementación actual no permite la recuperación mayor parte de los datos
del cliente. Si así fuera, tendríamos probablemente considerar el uso de certificados
de cliente a fin de protegerlo contra esta información. Incluso si los atacantes
comprometer la máquina de la base de datos esté en funcionamiento, encendido y se
las arreglan para descargar todo el contenido, que necesitarían acceso a la clave
utilizada para cifrar y descifrar los datos para hacer uso si.
Figura 9-5 Muestra la imagen final. Como se puede ver, las elecciones que hicimos
acerca de lo que la tecnología para su uso se basan en una comprensión de la
Un ejemplo práctico | 185
naturaleza de la información que se fijan. preocupaciones por la seguridad de su
propia arquitectura es probable que sean muy diferentes, y por lo que puede terminar
con una solución de aspecto diferente.
186 | Capítulo 9: Seguridad
Figura 9-5. sistema más seguro de MusicCorp
ser frugal
Dado que el espacio de disco se hace más barata y las capacidades de las bases de
datos a mejorar, la facilidad con que cantidades masivas de información pueden ser
capturadas y almacenadas está mejorando rápidamente. Estos datos son valiosos, no
sólo para las propias empresas, que cada vez ven los datos como un activo valioso,
pero igualmente a los usuarios que valoran su propia intimidad. Los datos que
pertenece a un individuo, o podría ser utilizada para obtener información sobre una
persona, debe ser los datos que estamos máximo cuidado.
Sin embargo, ¿y si hemos hecho nuestras vidas un poco más fácil? ¿Por qué no fregar
mayor cantidad de información posible que puede ser de identificación personal, y
hacerlo tan pronto como sea posible? Al iniciar la sesión una petición de un usuario,
lo que necesitamos para almacenar la dirección IP completa para siempre, o
podríamos sustituir a los últimos dígitos con x? Qué necesitamos para almacenar el
nombre de alguien, la edad, el género, y la fecha de nacimiento con el fin de
proporcionarle ofertas de productos, o es su rango de edad y el código postal
suficiente información?
Las ventajas aquí son múltiples. En primer lugar, si no lo almacena, nadie puede
robarlo. Segundo, si no lo almacena, nadie (por ejemplo, una agencia gubernamental)
puede pedir que sea!
La frase en alemán Datensparsamkeit representa este concepto. Derivados de la
legislación hombre privacidad germanio, que encapsula el concepto de sólo el
Un ejemplo práctico | 185
almacenamiento de informa- ción tanto como sea absolutamente necesario para
cumplir con las operaciones de negocios o satisfacer las leyes locales.
186 | Capítulo 9: Seguridad
Esto es, obviamente, en la tensión directa con el movimiento hacia almacenar cada
vez más información, pero es un comienzo para darse cuenta de que aún existe esta
tensión!
El factor humano
Gran parte de lo que hemos tratado aquí es lo básico de la forma de aplicar
salvaguardias tecnológicas para proteger sus sistemas y datos de los atacantes
externos y malintencionados. SIN EMBARGO, es posible que tenga procesos y
políticas para hacer frente a la ele- mento humano en su organización. ¿Cómo se
revoca el acceso a las credenciales cuando alguien deja la organización? ¿Cómo
puede protegerse contra la ingeniería social? Como un buen ejercicio mental, tenga
en cuenta el daño que un ex empleado descontento podría hacer para sus sistemas si
ella quería. Ponerse en la mentalidad de un usuario malintencionado es a menudo una
buena manera de razonar acerca de las protecciones que usted pueda necesitar, y
algunas partes maliciosos tener tanta información privilegiada como empleado
reciente!
La regla de oro
Si no hay nada más que se lleva de este capítulo, que sea esto: no escriba su propia
criptografía. No invente sus propios protocolos de seguridad. A menos que seas un
experto en criptografía con años de experiencia, si se intenta inventar su propia
codificación o elaborado protecciones criptográficas, usted se equivoca. E incluso si
usted es un experto en criptografía, es posible que aún se equivocan.
Muchos de las herramientas anteriormente descritas, como AES, son tecnologías de
la industria endurecido cuyos algoritmos subyacentes han sido revisados por pares, y
cuyo software Implementation ha sido rigurosamente probado y parcheado lo largo
de muchos años. Son lo suficientemente bueno! Reinventar la rueda en muchos casos
es a menudo sólo una pérdida de tiempo, pero cuando se trata de seguridad que puede
ser francamente peligroso.
En bicarbonato de Seguridad
Al igual que con las pruebas funcionales automatizadas, no queremos la seguridad de
dejarse a un conjunto dife- rentes de las personas, ni queremos dejar todo para el
último minuto. Ayudar a los desarrolladores cate edu- sobre las preocupaciones de
seguridad es clave, ya aumentar la concienciación general de todos los problemas de
seguridad puede ayudar a reducir en el primer lugar. Hacer que la gente
familiarizados con la lista de lista y se Framework de Pruebas de Seguridad de
OWASP puede ser un gran lugar para comenzar. Especialistas absolutamente tienen
su lugar, sin embargo, y si tiene acceso a ellos, los utilizan para ayudarle.
Hay herramientas automatizadas que pueden sondear nuestros sistemas de
El factor humano | 187
vulnerabilidades, como mediante la búsqueda de los ataques de cross-site scripting.
El Ataque Zed Proxy (también conocido como ZAP) es un buen ejemplo. Informada
por el trabajo de OWASP, ZAP intenta recrear ataques maliciosos en su sitio web.
Existen otras herramientas que el uso de análisis estático para buscar común
188 | Capítulo 9: Seguridad
errores de codificación que pueden abrir agujeros de seguridad, tales como
Guardafrenos para Ruby. Cuando estas herramientas se pueden integrar fácilmente en
CI normal, construye, integrarlos en sus registros de entrada estándar. Otros tipos de
pruebas automatizadas están más involucrados. Por ejemplo, usando algo como
Nessus para escanear en busca de vulnerabilidades es un poco más complicado y
puede requerir un ser humano para interpretar los resultados. Dicho esto, estas
pruebas siguen automata- ble, y puede tener sentido para funcionar con el mismo tipo
de cadencia como pruebas de carga.
microsoft de Ciclo de Vida de Desarrollo de Seguridad También tiene algunos buenos
modelos de cómo los equipos de ery deliv- pueden hornear de seguridad. Algunos
aspectos de la misma se sienten excesivamente cascada, pero echar un vistazo y ver
qué aspectos se pueden encajar en su flujo de trabajo actual.
Verificación externa
Con seguridad, creo que hay un gran valor en tener una evaluación externa realizada.
Los ejercicios como pruebas de penetración, cuando es realizada por un tercero,
realmente hacen intentos del mundo real imitan. También eludir la cuestión de que
los equipos no siempre son capaces de ver los errores que han cometido ellos
mismos, ya que son demasiado cerca del problema. Si usted es una empresa lo
suficientemente grande, es posible que tenga un equipo infosec dedicada que puede
ayudarle. Si no es así, encontrar una parte externa que pueda hacerlo. Llegar a ellos
temprano, entienden cómo les gusta trabajar, y averiguar cuánto tiempo de aviso que
necesitan para hacer una prueba.
Usted también debe tener en cuenta la cantidad de verificación que necesite antes de
cada lanzamiento. En general, hacer una prueba de penetración completa, por
ejemplo, no es necesario para los pequeños comunicados Tal incremen-, pero puede
ser para los cambios más grandes. Lo que se necesita depende de su propio perfil de
riesgo.
Resumen
Así que de nuevo volvemos a un tema central del libro-que tener un sistema
descompuesto en los servicios de grano más fino nos da muchas más opciones en
cuanto a la forma de resolver un problema. No sólo se tienen microservicios
potencialmente reducir el impacto de cualquier incumplimiento dado, sino que
también nos da más capacidad de operar fuera de la sobrecarga de los enfoques más
complejos y seguros donde los datos son sensibles, y un enfoque más ligero cuando
los riesgos son más bajos.
Una vez que entienda los niveles de amenaza de las diferentes partes de su sistema,
usted debe comenzar a tener una idea de cuándo considerar la seguridad durante el
transporte, en reposo, o nada en absoluto.
El factor humano | 187
Por último, comprender la importancia de la defensa en profundidad, asegúrese de
aplicar un parche sus sistemas operativos, e incluso si usted se considera una estrella
de rock, no trate de las aplicará su propia criptografía!
Si desea una descripción general de seguridad para las aplicaciones basadas en el
navegador, un gran lugar para comenzar es la excelente Abrir Web Application
Security Project (OWASP) no lucro, Cuyo documento se actualiza regularmente para
los principales riesgos de seguridad 10 se debe considerar
188 | Capítulo 9: Seguridad
una lectura esencial para cualquier desarrollador. Por último, si quieres una discusión
más general de la criptografía, echa un vistazo al libro Criptografía Ingeniería de
Niels Ferguson, Bruce Schneier, y Tadayoshi Kohno (Wiley).
Tener el control de la seguridad es a menudo acerca de la comprensión de la gente y
cómo trabajan con nuestros sistemas. Uno de los aspectos relacionados con los
humanos aún no hemos discutido en términos de microservicios es la interacción
entre las estructuras organizativas y las propias arquitecturas. Pero como con la
seguridad, vamos a ver que haciendo caso omiso del elemento humano puede un
grave error.
resumen | 189
CAPÍTULO 10
Conway La ley y el sistema de
diseño
Gran parte del libro hasta ahora se ha centrado en los desafíos técnicos en el avance
hacia una arquitectura de grano fino. Pero hay otras cuestiones de organización, a
considerar también. Como vamos a aprender en este capítulo, se ignora el
organigrama de su empresa a su propio riesgo!
Nuestra industria es joven, y parece estar constantemente reinventándose a sí misma.
Y sin embargo, algunas leyes fundamentales han resistido la prueba del tiempo. La
ley de Moore, por ejemplo, que establece que la densidad de transistores en circuitos
integrados se duplica cada dos años, ha demostrado ser sorprendentemente precisa
(aunque algunas personas predicen que esta tendencia ya se está desacelerando). Una
ley que he encontrado para ser casi universalmente cierto, y mucho más útil en mi
trabajo del día a día, es la ley de Conway.
El artículo de Melvin Conway Cómo Inventar Comités Do, publicado en revista
Datamation Maga- en abril de 1968, observó que:
Cualquier organización que diseña un sistema (que se define más ampliamente aquí
que los sistemas de informa- ción sólo) inevitablemente producir un diseño cuya
estructura es una copia de la estructura de comunicación de la organización.
Esta declaración es citado a menudo, en diversas formas, como la ley de Conway.
Eric S. Raymond resume este fenómeno en el diccionario The New Hacker (MIT
Press) diciendo “Si tiene cuatro grupos de trabajo sobre un compilador, podrás
conseguir un compilador de 4 pasadas.”
Evidencia
La historia cuenta que cuando Melvin Conway presentó su documento sobre este
tema para la Harvard Business Review, la rechazaron, alegando que no había
probado su tesis. He visto esta teoría confirmada en muchas situaciones diferentes
191
que lo he aceptado como verdadero. Pero usted no tiene que tomar mi palabra para
ella: desde la presentación original del Conway, una gran cantidad de
192 | Capítulo 10: Conway de Derecho y Diseño de
Sistemas
Se ha trabajado en esta área. Un número de estudios se han llevado a cabo para
explorar la interrelación de la estructura organizativa y de los sistemas que crean.
Organizaciones sueltos y de estructura rígida
En la exploración de la dualidad entre el producto y la organización Arquitecturas
(Harvard Business School), los autores Alan MacCormack, John Rusnak, y Carliss
Baldwin vistazo a una serie de diferentes sistemas de software, vagamente
categorizados como un ser creado ya sea por organizaciones débilmente acoplados u
organizaciones fuertemente acoplados. Para las organizaciones fuertemente
acoplados, piense empresas de productos comerciales que se suelen colocarse con
visiones y objetivos fuertemente alineados, mientras que las organizaciones
débilmente acoplados son bien representada por las comunidades de código abierto
distribuido.
En su estudio, en el que coincidían pares de productos similares de cada tipo de
organización, los autores encontraron que las organizaciones acoplada de manera
más flexible en realidad crearon sistemas modulares más, menos acoplados, mientras
que el software de la organización más fuerte orientación era menos modular.
Windows Vista
Microsoft llevó a cabo Un Estudio Empírico donde se examinó la forma en su propia
estructura organizativa afectada la calidad del software de un producto específico,
Windows Vista. En concreto, los investigadores analizaron varios factores para
determinar qué tan propenso a errores de un componente en el sistema sería ser.1
Después de mirar varias métricas, incluidas las métricas de calidad de software de
uso común como la complejidad del código, se encontraron con que las métricas
asociadas con las estructuras organizativas demostraron ser las medidas más
relevantes estadísticamente.
Así que aquí tenemos otro ejemplo de la estructura organizativa que afecta la
naturaleza del sistema que crea la organización.
Netflix y Amazon
Es probable que los dos niños del cartel de la idea de que las organizaciones y la
arquitectura deben estar alineados son Amazon y Netflix. Desde el principio,
Amazon comenzó a entender los beneficios de equipos con todo el ciclo de vida de
los sistemas que gestionan. Se quería equipos para poseer y operar los sistemas que
parecían después, la gestión de todo el ciclo de vida. Sin embargo, Amazon también
sabía que los equipos pequeños pueden trabajar más rápido que los equipos grandes.
Esto llevó famoso a sus equipos de dos pizzas, donde ningún equipo debe ser tan
grande que no podía ser alimentado con dos pizzas. Este controlador para pequeños
equipos con todo el ciclo de vida de
191
1 Y todos sabemos que Windows Vista fue muy propenso a errores!
192 | Capítulo 10: Conway de Derecho y Diseño de
Sistemas
sus servicios es una razón importante por Amazon desarrolló Amazon Web Services.
Es necesario crear las herramientas para permitir que sus equipos sean
autosuficientes.
Netflix aprender de este ejemplo, y aseguró que desde el principio se estructuró en
torno a equipos pequeños e independientes, por lo que los servicios que crearon
también serían independientes entre sí. Esto aseguró que la arquitectura del sistema
se ha optimizado para la velocidad de cambio. Efectivamente, Netflix diseñó la
estruc- tura organizativa de la arquitectura del sistema que quería.
¿Qué podemos hacer con esto?
Así que la evidencia anecdótica y empírica, apunta a nuestra estructura organizativa
siendo una fuerte influencia en la naturaleza (y calidad) de los sistemas que
proporcionamos. Entonces, ¿cómo esta comprensión nos ayuda? Veamos algunas
situaciones organizativas diferentes y comprender el impacto que cada uno puede
tener en nuestro diseño del sistema.
La adaptación a las rutas de comunicación
Consideremos primero un simple solo equipo,. Es responsable de todos los aspectos
del diseño y la implementación del sistema. Puede tener, la comunicación de grano
fino frecuente. Ima- INE que este equipo está a cargo de un único servicio, por
ejemplo, servicio de catálogo de nuestra tienda de música. Consideremos ahora el
interior de un servicio: un montón de llamadas de método o función de grano fino.
Como hemos dicho antes, nuestro objetivo es asegurar que nuestros servicios se
descomponen de manera que el ritmo de cambio dentro de un servicio es mucho más
alto que el ritmo de cambio entre los servicios. Esto solo equipo, con su capacidad
para la comunicación de grano fino, coincide muy bien con las vías de comunicación
del código dentro del servicio.
Esto solo equipo le resulta fácil de comunicar acerca de los cambios propuestos y los
Ings refactor-, y por lo general tiene un buen sentido de la propiedad.
Ahora imaginemos un escenario diferente. En lugar de un solo equipo,
geolocalizados ser dueño de nuestro servicio de catálogo, supongamos que los
equipos en el Reino Unido y la India están involucrados activamente en el cambio de
una propiedad conjunta con el servicio de manera efectiva del servicio. límites de la
zona geográfica y el tiempo aquí hacen que la comunicación de grano fino entre esos
equipos difícil. En su lugar, se basan en una comunicación más grano grueso a través
de videoconferencia y correo electrónico. ¿Qué tan fácil es para un miembro del
equipo en el Reino Unido para hacer un PLE sim- refactorización con confianza? El
costo de las comunicaciones en un equipo buido geográficamente dis- es mayor, y
por lo tanto el costo de los cambios de coordinación es mayor.
Cuando el costo de la coordinación de cambio aumenta, una de dos cosas sucederá.
¿Qué podemos hacer con esto? |
193
Cualquiera de las personas a encontrar maneras de reducir los costes de coordinación
/ comunicación, o que dejan de cambios de ING MAK-. Este último es exactamente
cómo nos encontramos con grandes, difíciles de mantener bases de código.
194 | Capítulo 10: Conway de Derecho y Diseño de
Sistemas
Recuerdo un proyecto de cliente que trabajé en los que la propiedad de un único
servicio se comparte entre dos ubicaciones geográficas. Con el tiempo, cada sitio
comienza a especializarse qué tipo de trabajo que maneja. Esto le permitió tomar
posesión de parte de la base de código, dentro de la cual podría tener un costo más
fácil del cambio. Los equipos tuvieron entonces la comunicación de grano más
coarse- sobre cómo interrelacionan las dos partes; efectivamente, las vías de comunicación hecho posible dentro de la estructura organizativa se correspondía con el
API de grano grueso que se formó el límite entre las dos mitades de la base de
código.
Entonces, ¿dónde nos deja esto al considerar la evolución de nuestro propio diseño
de servicios? Bueno, yo sugeriría que las fronteras geográficas entre las personas
involucradas con el desarrollo de un sistema pueden ser una gran manera de conducir
cuando los servicios se deben plantear, descomposición, y que, en general, usted
debe buscar para asignar la propiedad de un servicio a un sin- gle, equipo que puede
mantener el coste del cambio bajo colocated.
Tal vez su organización decide que quiere aumentar el número de personas que
trabajan en su proyecto mediante la apertura de una oficina en otro país. En este
punto, pensar activamente sobre qué partes de su sistema se pueden mover más. Tal
vez esto es lo que impulsa sus decisiones acerca de lo que las costuras de dividir el
próximo.
Eso Es también digno de mención en este punto que, al menos sobre la base de las
observaciones de los autores de la exploración de la dualidad entre el producto y la
organización Arquitecturas informe que se menciona anteriormente, si la
organización de la construcción del sistema se acopla de manera más flexible (por
ejemplo, que consiste en equipos distribuidos geográficamente ), los sistemas se
construyen tienden hacia el más modular, y por lo tanto es de esperar menos
acoplados. La tendencia de un solo equipo que posee muchos servicios a inclinarse
hacia una integración más estrecha es muy difícil de mantener en una organización
más distribuida.
Propietario de servicio
¿Qué quiero decir por la propiedad de servicio? En general, esto significa que el
equipo de ser dueño de un servicio se encarga de hacer cambios a ese servicio. El
equipo debe sentirse libre para reestructurar el código sin embargo, quiere, siempre y
cuando que el cambio no se rompe servicios de ING consum-. Para muchos equipos,
la propiedad se extiende a todos los aspectos del servicio, a partir de necesidades de
abastecimiento a la construcción, implementación y mantenimiento de la aplicación.
Este modelo es especialmente frecuente con microservicios, donde es más fácil para
un pequeño equipo de poseer un pequeño servicio. Este aumento de nivel de
propiedad conduce a una mayor autonomía y velocidad de entrega. Tener un equipo
responsable de la implementación y el mantenimiento de la aplicación significa que
tiene un incentivo para crear servicios que son fáciles de implementar; es decir,
¿Qué podemos hacer con esto? |
193
Este modelo es sin duda uno estoy a favor. Empuja las decisiones a las personas más
capaces de hacerlos, dando al equipo tanto en potencia y autonomía, sino también por
lo que es
194 | Capítulo 10: Conway de Derecho y Diseño de
Sistemas
cuentas de su trabajo. He visto demasiados desarrolladores entregan su sistema a
través de fases de prueba o de despliegue y piensan que su trabajo se realiza en ese
punto.
Controladores para servicios compartidos
He visto a muchos equipos adoptan un modelo de propiedad de servicios
compartidos. Me parece que este enfoque subóptimo, por las razones ya discutidas.
Sin embargo, los conductores que hacen que las personas a elegir los servicios
compartidos son importantes para entender, especialmente en lo que puede ser capaz
de encontrar algunos modelos alternativos convincentes que puedan abordar las
preocupaciones subyacentes de las personas.
Demasiado duro a Split
Obviamente, una de las razones por las que puede encontrarse con un único servicio
propiedad de más de un equipo es que el costo de dividir el servicio es demasiado
alta, o tal vez su organización podría no ver el punto de la misma. Esto es una
ocurrencia común con grandes sistemas monolíticos. Si este es el principal desafío
que se presente, entonces espero que algunos de los consejos dados enCapítulo 5 será
de utilidad. También podría considerar la fusión de los equipos juntos, para alinear
más estrechamente con la propia arquitectura.
equipos de características
La idea de los equipos de características (también conocidos como equipos basados
en características) es que un pequeño equipo impulsa el desarrollo de un conjunto de
características, implementar toda la funcionalidad requerida incluso si se corta a
través de componente (o incluso servicio) límites. Los objetivos de los equipos de
características son lo suficientemente sensible. Esta estructura permite al equipo
mantener un enfoque en el resultado final y asegura que el trabajo se unió, evitando
algunos de los desafíos de tratar de coordinar los cambios a través de múltiples
equipos diferentes.
En muchas situaciones, el equipo de trabajo es una reacción a las organizaciones de
TI tradicionales, donde la estructura del equipo está alineado alrededor de los límites
técnicos. Por ejemplo, es posible que tenga un equipo que se encarga de la interfaz de
usuario, otro que se encarga de la lógica de apli- cación, y una tercera manejo de la
base de datos. En este entorno, un equipo de la característica es un paso significativo,
ya que funciona a través de todas estas capas para ofrecer la funcionalidad.
Con adopción por mayor de equipos de características, todos los servicios se pueden
considerar compartida. Todo el mundo puede cambiar cada servicio, cada pieza de
código. El papel de los servicios dians custo- aquí se hace mucho más compleja, si la
función existe en absoluto. Desafortunadamente, rara vez ver que funciona custodios
en absoluto en el que se adoptó este patrón, lo que lleva a los tipos de cuestiones que
discutimos anteriormente.
Pero vamos a volver a considerar lo microservicios son: Servicios de modelo de un
dominio de negocio, no técnico. Y si nuestro equipo que posee un determinado
servicio está alineado de manera similar a lo largo del dominio de negocio, es mucho
más probable que el equipo será capaz de mantener un enfoque en el cliente, y ver
más de la característica desarrollada a través, porque
Controladores para servicios compartidos | 195
194 | Capítulo 10: Conway de Derecho y Diseño de
Sistemas
tiene una comprensión holística y la propiedad de toda la tecnología asociada a un
servicio.
cambios transversales pueden ocurrir, por supuesto, pero su probabilidad se reduce
significativamente por nuestros equipos de tecnología orientada a evitar.
en la entrega
Una de las razones clave de la gente se mueve hacia los servicios compartidos es
evitar en la entrega. ¿Qué pasa si hay una gran acumulación de cambios que deben
hacerse en un mismo servicio? Imaginemos que estamos desplegando la capacidad de
un cliente para ver el género de una pista a través de nuestros productos, así como la
adición de marca aa nuevo tipo de stock: virtuales musi- cal tonos de llamada para el
teléfono móvil. El equipo del sitio web tiene que realizar un cambio en superfi- cie la
información de género, con el equipo de trabajo de aplicaciones móviles para
permitir a los usuarios navegar, previsualizar y comprar los tonos de llamada. Ambos
cambios deben hacerse al servicio de catálogo, pero desafortunadamente la mitad del
equipo está fuera de la gripe, y la otra mitad se ha quedado atascado el diagnóstico de
un fallo de producción.
Tenemos un par de opciones que no implican servicios compartidos para evitar esta
situación. La primera es simplemente esperar. Los equipos de sitios web y
aplicaciones móviles pasan a algu- cosa. En función de la importancia de la función
es, o cuánto tiempo es probable que sea el retraso, esto puede estar bien o puede ser
un problema importante.
En su lugar podría agregar personas al equipo de catálogo para ayudarles a moverse a
través de su trabajo más rápido. Cuanto más estandarizado la tecnología de pila y
modismos de programación en uso a través de su sistema, más fácil es para otras
personas para hacer cambios en sus servi- cios. La otra cara, por supuesto, como
hemos comentado anteriormente, es que la normalización tiende a reducir la
capacidad de un equipo para adoptar la solución adecuada para el trabajo, y puede
dar lugar a diferentes tipos de ineficiencias. Si el equipo está en el otro lado del
planeta, esto podría ser imposible, sin embargo.
Otra opción podría ser la de dividir el catálogo en un catálogo general de música
independiente y un catálogo de tono. Si el cambio que se realizan para apoyar tonos
es bastante pequeño, y la probabilidad de que esto sea un área en la que vamos a
desarrollar en gran medida en el futuro también es bastante baja, esto bien puede ser
prematuro. Por otro lado, si hay 10 semanas de características relacionadas con
Tono-apilados, dividiendo a cabo el servicio podría tener sentido, con el equipo
móvil de la toma de posesión.
Hay otro modelo que podría funcionar bien para nosotros, sin embargo.
Interna Open Source
196| Capítulo 10: Conway de Derecho y Diseño de
Sistemas
¿Y qué si hemos intentado con todas nuestras fuerzas, pero simplemente no puede
encontrar un camino más allá de tener unos servicios compartidos? En este punto,
adecuadamente abrazar el modelo de código abierto interno puede hacer mucho
sentido.
Abrir interna Fuente | 197
Con de código abierto normal, un pequeño grupo de personas se consideran
committers centrales. Son los guardianes del código. Si quieres un cambio a un
proyecto de código abierto, o bien pedir a uno de los committers para hacer el
cambio para usted, o bien realizar el cambio a ti mismo y les envía una solicitud de
extracción. Los committers núcleo son todavía a cargo de la base de código; ellos son
los dueños.
Dentro de la organización, este patrón puede funcionar bien también. Tal vez las
personas que trabajaron en el servicio originalmente ya no están en un equipo en
conjunto; quizá ahora están dispersos en toda la organización. Bueno, si todavía
tienen permiso de commit, puede encontrarlos y pedir su ayuda, tal vez
emparejamiento con ellos, o si usted tiene la herramienta correcta usted puede enviar
una solicitud de extracción.
Papel de los Custodios
Nosotros Todavía queremos que nuestros servicios sean sensibles. Queremos que el
código sea de buena calidad, y el servicio en sí para exhibir algún tipo de
consistencia en la forma en que está organizado. También queremos para asegurarse
de que los cambios se hacen ahora no realizar futuros cambios planeado mucho más
difícil de lo que necesitan ser. Esto significa que tenemos que adoptar los mismos
patrones utilizados en la normalidad de código abierto también internamente, lo que
significa la separación de un grupo de committers confianza (el equipo central), y
committers no son de confianza (gente de un lado OUT- el equipo de la presentación
de los cambios).
El núcleo del equipo tiene que tener algún medio para controlar y aprobar los
cambios. Tiene que asegurarse de que los cambios son consistentes idiomático, es
decir, que sigan las directrices de codificación generales del resto de la base de
código. Las personas que realizan la investigación de antecedentes, por lo tanto se
van a tener que pasar tiempo trabajando con los peticionarios para asegurarse de que
el cambio sea de suficiente calidad.
Buenos porteros ponen mucho trabajo en esto, la comunicación clara con los tros
submit- y fomentar el buen comportamiento. Malos porteros pueden utilizar esto
como una excusa para ejercer poder sobre otros o tener guerras religiosas sobre las
decisiones técnicas arbitrarias. Después de haber visto los dos conjuntos de
comportamiento, te puedo decir una cosa está clara: en cualquier caso se necesita
tiempo. Al considerar lo que permite committers no confiables para enviar los
cambios a la base de código, usted tiene que decidir si la sobrecarga de ser un
guardián vale la pena el trou- ble: el equipo central podría estar haciendo mejor las
cosas con el tiempo que pasa parches de investigación y evaluación?
Madurez
El menos estable o madurar un servicio es, más difícil será para permitir que la gente
198| Capítulo 10: Conway de Derecho y Diseño de
Sistemas
fuera del equipo central para enviar parches. Antes de que el lomo de la llave de un
servicio está en su lugar, el equipo no puede saber qué se parecen las buenas, y por lo
tanto pueden tener dificultades para saber lo que una buena presentación se parece.
Durante esta etapa, el servicio en sí está experimentando un alto grado de cambio.
Abrir interna Fuente | 197
La mayoría de los proyectos de código abierto tienden a no tener presentaciones de
un grupo más amplio de committers no son de confianza hasta que se haga el núcleo
de la primera versión. Siguiendo un modelo similar para sus propias organizaciones
tiene sentido. Si un servicio es bastante madura, y rara vez se cambia, por ejemplo,
nuestro servicio, entonces tal vez que la compra es el momento de abrirlo para otras
contribuciones.
Estampación
A mejor soporte de un modelo de código abierto interno, usted necesitará un poco de
herramientas en su lugar. El uso de una herramienta de control de versiones
distribuido con la capacidad de las personas pueden presentar solicitudes de
extracción (o algo similar) es importante. Dependiendo del tamaño de la organización, es posible que tenga herramientas para permitir una discusión y la evolución de
las solicitudes de parche; esto puede o no quiere decir un sistema de revisión de
código en toda regla, pero la capacidad de los comentarios en línea sobre los parches
es muy útil. Por último, tendrá que hacer que sea muy fácil para un confirmador para
construir y desplegar su software, y hacer que esté disponible para otros.
Generalmente, esto implica tener tuberías de construcción y despliegue bien
definidos y repositorios de artefactos tralized cen-.
Los contextos y estructuras de equipo acotada
Como se mencionó antes, miramos a sacar nuestras fronteras de servicios de todo
contextos delimitadas. Por lo tanto, se deduce que nos gustaría que nuestros equipos
alineados a lo largo contextos delimitadas también. Esto tiene múltiples ventajas. En
primer lugar, un equipo será más fácil de comprender conceptos de dominio dentro
de un contexto limitado, ya que están relacionadas entre sí. En segundo lugar, los
servicios dentro de un contexto acotado son más propensos a ser servicios que se
comunican entre sí, haciendo el diseño del sistema y liberar la coordinación más
fácil. Por último, en cuanto a la forma en que el equipo de entrega interactúa con los
accionistas de la empresa, se hace más fácil para el equipo para crear buenas
relaciones con los uno o dos expertos en la materia.
El Servicio huérfano?
Entonces, ¿qué acerca de los servicios que ya no están siendo mantenido
activamente? A medida que avanzamos hacia arquitecturas de grano más fino, los
servicios mismos se hacen más pequeños. Una de las metas de los servicios más
pequeños, como hemos discutido, es el hecho de que son más simples. los servicios
más simples con menos funcionalidad que no sea necesario cambiar por un tiempo.
Considere el servicio de carro humilde, que proporciona algunas capacidades
bastante modestas: Añadir a la cesta, Sacar de la cesta, y así sucesivamente. Es
perfectamente concebible que este servicio puede no tener que cambiar durante
meses tras haber sido escrita, incluso si el desarrollo activo está todavía en curso.
200| Capítulo 10: Conway de Derecho y Diseño de
Sistemas
¿Qué pasa aquí? Quien es este servicio?
Abrir interna Fuente | 197
Si sus estructuras de equipo están alineados a lo largo de los contextos acotado de su
organización, incluso los servicios que no se cambian con frecuencia todavía tienen
un dueño de facto. Imagínese un equipo que está alineado con el contexto web de
venta al consumidor. Podría manejar los servicios del sitio, la compra y la
Recomendación en web. Incluso si el servicio de carro no se ha cambiado en meses,
que sería, naturalmente, caer a este equipo para realizar el cambio. Uno de los
beneficios de microservicios, por supuesto, es que si el equipo tiene que cambiar el
servicio para añadir una nueva característica y lo encuentra a su gusto, la reescritura
no debería tomar mucho tiempo en absoluto.
Dicho esto, si usted ha adoptado un enfoque verdaderamente políglota, haciendo uso
de múltiples pilas logía gías, entonces los retos de hacer cambios en un servicio de
huérfanos podrían agravarse si su equipo no sabe la pila de tecnología por más
tiempo.
Estudio de caso: RealEstate.com.au
REA de negocio principal son los bienes raíces. Pero esto abarca múltiples facetas
diferentes, cada uno de los cuales funciona como una sola línea de negocio (LOB).
Por ejemplo, una línea de negocio se ocupa de la propiedad residencial en Australia,
otro comercial, mientras que otro puede referirse a uno de los negocios en el
extranjero de la REA. Estas líneas de negocio ya lo tienen equipos de entrega (o
escuadrones) asociados con ellos; algunos pueden tener sólo un único equipo,
mientras que el mayor tiene cuatro. Así que para la propiedad residencial, hay varios
equipos que participan en la creación de la página web y la lista de servicios para
permitir a la gente a navegar por la propiedad. Las personas rotan entre estos equipos
de vez en cuando, pero tienden a permanecer dentro de esa línea de negocio durante
largos períodos de tiempo, asegurando que los miembros del equipo pueden construir
una fuerte conciencia de que parte del dominio.
Se espera que cada equipo dentro de una línea de negocio de poseer todo el ciclo de
vida de los servi- cios que crea, incluyendo la construcción, pruebas y liberación,
apoyo, e incluso misionar descomposición. Un equipo central proporciona servicios
de entrega de asesoramiento y orientación a estos equipos, así como herramientas
para ayudar a hacer el trabajo. Una fuerte cultura de la automatización es clave, y
REA hace uso intensivo de AWS como una parte clave de permitir a los equipos a
ser más autónomo.Figura 10-1 ilustra cómo funciona todo esto.
Estudio de caso: RealEstate.com.au |
199
Figura 10-1. Una visión general de la estructura organizativa y el equipo de
Realestate.com.au, y la alineación con la arquitectura
No es sólo la organización de prestación que está alineado con el funcionamiento del
negocio. Se extiende a la arquitectura también. Un ejemplo de esto es métodos de
integración. Dentro de un LOB, todos los servicios son gratuitos para hablar unos con
otros en cualquier forma que estimen conveniente, por decisión de los escuadrones
que actúan como sus guardianes. Sin embargo, entre los LOB, toda la comunicación
tiene el mandato de ser lotes asincrónico, una de las pocas reglas de hierro fundido de
lo muy pequeño equipo de arquitectura. Esta comunicación de grano grueso coincide
con la comunicación de grano grueso que existe entre las diferentes partes de la
empresa también. Por ing insistir- con que sea por lotes, cada LOB tiene una gran
cantidad de libertad en la forma en que actúa y gestiona sí. Podría darse el lujo de
tener sus servicios hacia abajo cada vez que quería,
Esta estructura ha permitido una autonomía significativa no sólo de los equipos, sino
también a las diferentes partes de la empresa. A partir de un puñado de servicios de
hace unos años, ahora tiene cientos REA, con más servicios que las personas, y está
creciendo a un ritmo rápido. La capacidad de entregar cambio ha ayudado a la
compañía a alcanzar un éxito significativo en el mercado local hasta el punto en que
se está expandiendo en el extranjero. Y, lo más alentador de todo, de hablar con la
gente de allí me da la impresión de que tanto la arquitectura y la estructura de la
organización tal y como están ahora son sólo la última iteración en lugar del destino.
Me atrevería a decir que en otros cinco años REA será muy diferente de nuevo.
Aquellas organizaciones que son lo suficientemente adaptable para cambiar no sólo
su sistema de arqui- tectura, sino también su estructura organizativa puede producir
200 | Capítulo 10: Conway de Derecho y Diseño de
Sistemas
enormes beneficios en términos de
Estudio de caso: RealEstate.com.au |
199
mejora de la autonomía de los equipos y el tiempo de lanzamiento al mercado de
nuevas características y funcio- nalidad. REA es sólo uno de una serie de
organizaciones que se están dando cuenta de que la arquitectura del sistema no existe
en un vacío.
Ley de Conway en reversa
Hasta ahora, hemos hablado sobre cómo los impactos de la organización del diseño
del sistema. Pero ¿qué pasa con la inversa? Es decir, se puede cambiar un diseño de
sistema de la organización? Aunque no he sido capaz de encontrar la misma calidad
de evidencia para apoyar la idea de que la ley de Con- forma en que funciona a la
inversa, lo he visto de manera anecdótica.
Probablemente el mejor ejemplo era un cliente que trabajé hace muchos años. De
vuelta en los días en que la web era bastante incipiente, y la Internet se ve como algo
que llegó en un disquete de AOL a través de la puerta, esta empresa era una empresa
de impresión de gran tamaño que tenía una pequeña, modesta página web. Tenía un
sitio web, ya que era lo que hacer, pero en el gran esquema de las cosas que era de
poca importancia a cómo opera el negocio. Cuando se creó el sistema original, por
decisión técnica bastante arbitraria se hizo en cuanto a cómo funcionaría el sistema.
El contenido de este sistema era originario de múltiples maneras, pero la mayor parte
provino de terceros que fueron la colocación de anuncios para ser vistos por el
público en general. Había un sistema de entrada que permitió que el contenido sea
creado por los terceros pagadores, un sistema central que se llevó a que los datos y se
enriquece de varias maneras, y un sistema de salida que creó el sitio web final que el
público en general podría navegar.
Si las decisiones de diseño originales estaban en lo correcto en el momento es una
conversación para los historia- dores, pero muchos años en la compañía había
cambiado un poco y yo y muchos de mis colegas estaban comenzando a preguntarse
si el diseño del sistema era apto para el presente de la empresa estado. Su negocio de
la impresión física había disminuido significativamente, y los nues reve- y por lo
tanto las operaciones de negocio de la organización ahora se dominada por su
presencia en línea.
Lo que vimos en ese momento era una organización estrechamente alineado a este
sis- tema de tres partes. Tres canales o divisiones en el lado de IT de la empresa
alineados con cada una de las partes de entrada, de núcleo, y de salida de la empresa.
Dentro de esos canales, había equipos de entrega separadas. Lo que no me di cuenta
en ese momento era que estas estructuras organizativas no son anteriores al diseño
del sistema, pero en realidad creció a su alrededor. Como la cara de impresión de la
empresa disminuido, y el lado digital de la empresa crecieron, el diseño del sistema
sin querer abrir el paso al cómo la organización creció.
Al final nos dimos cuenta de que todo lo que las deficiencias del diseño del sistema
eran, tendríamos que hacer cambios en la estructura organizativa de hacer un cambio.
202 | Capítulo 10: Conway de Derecho y Diseño de
Sistemas
Muchos años después, ese proceso sigue siendo un trabajo en progreso!
Ley de Conway en marcha atrás |
201
Personas
No importa cómo se ve en un primer momento, siempre es un
problema de personas.
-Gerry Weinberg,
La segunda ley de la Consultoría
Nosotros tener que aceptar que en un entorno microService, es más difícil para un
desarrollador que sólo piensa en la escritura de código en su propio pequeño mundo.
Tiene que ser más conscientes de las implicaciones de cosas como las llamadas a
través de límites de red, o las implicaciones de Ure fail. También hemos hablado
sobre la capacidad de microservicios para que sea más fácil para probar nuevas
tecnologías, desde los almacenes de datos de idiomas. Pero si se está moviendo desde
un mundo en el que usted tiene un sistema monolítico, donde la mayoría de los
desarrolladores simplemente han tenido que utilizar un idioma y permanece
completamente ajeno a las preocupaciones con- operacionales, a continuación,
echarlos en el mundo de la microservicios puede ser una sorpresa muy desagradable
para ellos.
Del mismo modo, empujando alimentación a los equipos de desarrollo para aumentar
la autonomía puede estar lleno. Las personas que en el pasado han arrojado trabajo a
lo largo de la pared a otra persona están acostumbrados a tener a alguien más a quien
culpar, y no se sienten cómodos siendo plenamente responsables de su trabajo. Usted
puede incluso encontrar barreras contractuales a tener sus desarrolladores llevar
localizadores de apoyo para los sistemas que apoyan!
Aunque este libro ha sido sobre todo acerca de la tecnología, las personas no son sólo
una cuestión secundaria para ser considerado; que son las personas que construyeron
lo que tenemos ahora, y va a construir lo que sucede a continuación. El subir con una
visión de cómo deben hacerse las cosas sin tener en cuenta cómo su personal actual
se sentirá sobre esto o sin tener en cuenta qué capacidades que tienen es probable que
conduzca a un mal lugar.
Cada organización tiene su propio conjunto de dinámicas en torno a este tema.
Entender su personal 's apetito para cambiar. No empuje demasiado rápido! Tal vez
usted todavía tiene un equipo independiente manejar el soporte de primera línea o de
despliegue para un corto período de tiempo, dando a su vez a los desarrolladores a
adaptarse a otras nuevas prácticas. Es posible, sin embargo, tener que aceptar que se
necesitan diferentes tipos de personas en su organización para hacer todo este trabajo.
Sea cual sea su enfoque, entiende que usted necesita estar claro en la articulación de
las responsabilidades de su gente en un mundo microservicios, y también estar claro
por qué esas responsabilidades son importantes para usted. Esto puede ayudarle a ver
cuáles podrían ser sus lagunas en la formación, y pensar en cómo cerrarlas. Para
muchas personas, esto va a ser un viaje bastante miedo. Sólo recuerde que sin
personas a bordo,
202 | Capítulo 10: Conway de Derecho y Diseño de
Sistemas
Resumen
Conway la ley pone de relieve los peligros de tratar de hacer cumplir un diseño de
sistema que no coincide con la organización. Esto nos lleva a tratar de alinear la
propiedad de servicio a equipos coloca- ted, que a su vez están alineados en torno a
los mismos contextos acotadas de la organización. Cuando los dos no están en
alineación, obtenemos puntos de tensión como se describe en este capítulo. Al
reconocer el vínculo entre los dos, nos aseguraremos de que el sistema que estamos
tratando de construir tiene sentido para la organización que estamos construyendo
para.
Algo de lo que cubre aquí tocado los desafíos de trabajar con organiza- ciones a
escala. Sin embargo, hay otras consideraciones técnicas que tenemos que
preocuparse cuando nuestros sistemas comienzan a crecer más allá de unos pocos
servicios discretos. Vamos a abordar los siguiente.
resumen | 203
CAPÍTULO 11
Microservicios a
escala
Cuando usted está tratando con ejemplos bonito, pequeño, tamaño de un libro, todo
parece sencillo. Pero el mundo real es un espacio más complejo. ¿Qué pasa cuando
nuestras arquitecturas MICROSERVICE crecen a partir de inicios más simples, más
humildes a algo más com- plejo? Lo que sucede cuando tenemos que manejar el
fracaso de múltiples servicios separados o es propietario de cientos de servicios?
¿Cuáles son algunos de los patrones de afrontamiento cuando se tiene más
microservicios que las personas? Vamos a averiguar.
El no está por todas partes
Nosotros entienden que las cosas pueden ir mal. Los discos duros pueden fallar.
Nuestro software puede fallar. Y como cualquier persona que ha leído elfalacias de
computación distribuida le puede decir, sabemos que la red no es confiable. Podemos
hacer nuestro mejor esfuerzo para tratar de limitar las causas del fracaso, pero a una
escala determinada, el fracaso se convierte en inevitable. Los discos duros, por
ejemplo, son más fiables que nunca antes, pero que va a romper con el tiempo. Las
unidades de disco duro más se tiene, mayor es la probabilidad de fallo de una unidad
individual; el fracaso se convierte en una certeza estadística a escala.
Incluso para aquellos de nosotros no pensar a escala extrema, si podemos aceptar la
posibilidad de fallo estaremos en mejores condiciones. Por ejemplo, si podemos
manejar el fallo de un servicio con gracia, entonces se deduce que también podemos
hacer actualizaciones in situ de un servicio, como un corte de Ned plan- es mucho
más fácil de tratar que uno no planificado.
Nosotros También puede pasar un poco menos de nuestro tiempo tratando de detener
lo inevitable, y un poco más de nuestro tiempo a tratar con él con gracia. Estoy
sorprendido por el número de organizaciones poner cesos y controles pro en el lugar
205
para tratar de detener el fracaso ocurra, pero puse poco o ningún pensamiento en
realidad lo que es más fácil recuperarse de un error en el primer lugar.
La cocción en el supuesto de que todo lo puede y se producirá un error te lleva a
pensar de manera diferente acerca de cómo solucionar problemas.
206 | Capítulo 11: microservicios a escala
Vi un ejemplo de esta forma de pensar, mientras que pasar algún tiempo en el
campus de Google hace muchos años. En la zona de recepción de uno de los edificios
en Mountain View era un viejo bastidor de las máquinas, hay como una especie de
exposiciones. Me di cuenta de un par de cosas. En primer lugar, estos servidores no
estaban en gabinetes de servidores, no eran más que las placas ranuradas desnudas en
el bastidor. Lo principal me di cuenta, sin embargo, fue que las unidades de disco
duro se sujeta con velcro. Pregunté a uno de los empleados de Google por qué. “Oh”,
dijo, “los discos duros fallan tanto que no quiere que ellos atornillados. Acabamos de
arrancarlas, tirar a la basura, y velcro en una nueva.”
Así que repito: a gran escala, incluso si usted compra el mejor equipo, el hardware
más caro, no se puede evitar el hecho de que las cosas pueden y van a fallar. Por lo
tanto, es necesario asumir el fracaso puede suceder. Si se construye esta forma de
pensar en todo lo que haces, y un plan para el fracaso, se pueden hacer diferentes
ventajas y desventajas. Si sabe que su sistema puede manejar el hecho de que un
servidor puede y va a fracasar, ¿por qué molestarse gastar mucho en él en absoluto?
¿Por qué no usar una placa base desnudo con componentes más baratos (y algunos de
velcro) como hizo Google, en lugar de tener que preocuparse demasiado acerca de la
capacidad de recuperación de un solo nodo?
¿Cuánto es demasiado?
Hemos tocado el tema de los requisitos de funciones cruzadas en Capítulo 7. ING
requisitos comprensión multi-funcionales es todo sobre teniendo en cuenta aspectos
como la durabilidad de los datos, disponibilidad de servicios, el rendimiento y la
latencia aceptable de servicios. Muchas de las técnicas tratadas en este capítulo y en
otros lugares a hablar de enfoques a las aplicará estos requisitos, pero sólo usted sabe
exactamente lo que podrían ser los requisitos de sí mismos.
Tener un sistema de cambio automático de escala capaz de reaccionar a un aumento
de la carga o el fracaso de los nodos indivi- indi- podría ser fantástico, pero podría
ser excesiva para un sistema de información que sólo tiene que ejecutar dos veces al
mes, en el que ser por un día o dos no es tan grande de un acuerdo. Del mismo modo,
encontrar la manera de hacer despliegues / verde azul para eliminar el tiempo de
inactividad de un servicio podría tener sentido para su sistema de comercio
electrónico en línea, pero para su base de conocimientos intranet corporativa es
probable que sea un paso demasiado lejos.
Sabiendo lo mucho que falta que puede tolerar, o la velocidad de su sistema tiene que
ser, es impulsada por los usuarios de su sistema. Que a su vez le ayudará a entender
lo que técni- cas harán más sentido para usted. Dicho esto, los usuarios no siempre
serán capaces de articular lo que son las necesidades exactas. Así que hay que hacer
preguntas para ayudar a extraer la información correcta, y ayudarles a entender los
costos relativos de proporcio- nando diferentes niveles de servicio.
Como ya he mencionado anteriormente, estos requisitos multifuncionales pueden
205
variar de un servicio a otro, pero sugeriría que define algunas cruzadas funcionales
generales, a continuación, anulando ellos por casos de uso particulares. Cuando se
trata de considerar si y cómo
206 | Capítulo 11: microservicios a escala
escalar el sistema para una mejor carga de mango o el fracaso, empezar por tratar de
comprender los siguientes requisitos:
El tiempo de respuesta / latencia
¿Cuánto debe durar varias operaciones? Puede ser útil para medir esto con
diferente número de usuarios a entender cómo el aumento de carga tendrá un
impacto en el tiempo de respuesta. Dada la naturaleza de las redes, que siempre
tenga los valores extremos, por lo que la fijación de objetivos para un percentil
determinado de las respuestas monitorizados pueden ser útiles. El objetivo
también debe incluir el número de conexiones / usuarios al mismo tiempo que se
espera que su software para manejar. Así que se podría decir: “Esperamos que el
sitio web para tener un tiempo de respuesta a los 90 percentil de 2 segundos al
manejar 200 conexiones simultáneas por segundo.”
Disponibilidad
Se puede esperar un servicio a estar abajo? ¿Se considera un servicio 24/7?
Algunas personas les gusta mirar a los períodos de tiempo de inactividad
aceptable cuando se miden disponibili- dad, pero lo útil que es esto a alguien que
llame a su servicio? ya sea que debería ser capaz de confiar en su servicio de
responder o no. Períodos de medición de tiempo de inactividad es realmente más
útil desde un ángulo de informes históricos.
La durabilidad de los datos
La cantidad de pérdida de datos es aceptable? ¿Por cuánto tiempo se deben
mantener los datos de? Esto es altamente probable que cambie en una base de
caso por caso. Por ejemplo, es posible optar por mantener registros de sesión de
usuario para un año o menos para ahorrar espacio, pero puede ser que necesite
ser mantenido durante muchos años sus registros ción transac- financiera.
Una vez que tenga estos requisitos en su lugar, usted querrá una forma de medisistemáticamente Ure ellos sobre una base continua. Usted puede decidir hacer uso
de las pruebas de rendimiento, por ejemplo, para asegurar que su sistema cumple con
los objetivos de rendimiento aceptables, pero usted querrá asegurarse de que está
supervisando estas estadísticas en la producción, así!
Funcionalidad degradantes
Una parte esencial de la construcción de un sistema resistente, sobre todo cuando su
funcionalidad se extiende sobre un número de diferentes microservicios que pueden
estar arriba o hacia abajo, es la capacidad de degradar la funcionalidad segura.
Imaginemos una página web estándar en nuestro sitio de comercio electrónico. Para
reunir las distintas partes de ese sitio web, podríamos necesitar varios servicios de
micro a desempeñar un papel. Una microService podría mostrar los detalles acerca
del álbum que se está a la venta. Otro podría mostrar el precio y el nivel de
existencias. Y vamos a proba- blemente mostraremos contenido del carrito de
compras también, que puede ser otro microService. Ahora bien, si uno de esos
Funcionalidad degradantes |
207
servicios se ha reducido, y que los resultados en toda la página web no esté
disponible, entonces hemos hecho podría decirse que un sistema que es menos
resistente de lo que requiere solamente un servicio que esté disponible.
208 | Capítulo 11: microservicios a escala
Lo que tenemos que hacer es entender el impacto de cada interrupción, y averiguar
cómo se degradan correctamente funcionalidad. Si el servicio de carrito de la compra
no está disponible, estamos probable- mente en un montón de problemas, pero aún
pudimos mostrar la página web con el anuncio. Tal vez simplemente ocultar el
carrito de la compra o sustituirla por un icono que dice “vuelvo!”
Con una sola, la aplicación monolítica, que no tienen muchas decisiones que tomar.
El estado del sistema es binario. Pero con una arquitectura microService, debemos
tener en cuenta una situación mucho más matizada. Lo que hay que hacer en
cualquier situación a menudo no es una decisión técnica. Puede ser que sabemos lo
que es técnicamente posible cuando el carrito de la compra está abajo, pero si no
entendemos el contexto empresarial no entenderemos qué medidas debemos tomar.
Por ejemplo, tal vez cerramos todo el sitio, todavía permiten a las personas a navegar
por el catálogo de artículos, o reemplazar partes de la interfaz de usuario que
contiene el control de la compra con un número de teléfono para realizar un pedido.
Pero por cada interfaz de cara al cliente que utiliza múltiples microservicios, o cada
microService que depende de múltiples colaboradores aguas abajo, es necesario
preguntarse, “¿Qué pasa si esto se debe?” Y sabe qué hacer.
Al pensar acerca de la criticidad de cada una de nuestras capacidades en términos de
nuestras necesidades funcionales cruzados, estaremos en mejor posición para saber lo
que podemos hacer. Ahora vamos a considerar algunas cosas que podemos hacer
desde un punto de vista técnico para asegurarse de que cuando se produce un fallo
que podemos manejar con gracia.
Medidas de seguridad de arquitectura
Hay unos cuantos patrones, que en conjunto me refiero como las medidas de
seguridad de arquitectura, que podemos hacer uso para asegurarse de que si algo sale
mal, no causa efectos desagradables de la ondulación de salida. Estos son puntos es
esencial entender, y debe considerar seriamente la estandarización en su sistema para
asegurarse de que uno mal ciudadano no trae todo el mundo derrumbarse alrededor
de sus oídos. En un momento, vamos a echar un vistazo a algunas medidas de
seguridad clave que debe considerar, pero antes de hacerlo, me gustaría compartir
una breve historia para describir el tipo de cosas que pueden ir mal.
Yo era una ventaja técnica sobre un proyecto en el que estábamos construyendo un
sitio web de anuncios clasificados en línea. La propia página web maneja volúmenes
bastante altos, y generó una gran cantidad de ingresos para el negocio. Nuestra
aplicación principal manejado alguna pantalla de sí mismo Tablón de anuncios,
llamadas también proxy a otros servicios que proporcionan diferentes tipos de productos, como se muestra enFigura 11-1. Esto es en realidad un ejemplo de una
aplicación de estrangulador, donde un nuevo sistema intercepta las llamadas
realizadas a las aplicaciones heredadas y repla- gradualmente ces por completo.
Como parte de este proyecto, estábamos a mitad de la de retirarse las aplicaciones
más antiguas. Acabábamos movido sobre el volumen más alto y más grande de
Funcionalidad degradantes |
207
productos de ganancia, pero gran parte del resto de los anuncios aún estaban siendo
atendidos por un número de aplicaciones antiguas. Tanto en términos de la cantidad
de búsquedas y el dinero obtenido por estas aplicaciones, había una cola muy larga.
208 | Capítulo 11: microservicios a escala
Figura 11-1. Un sitio web anuncios clasificados estrangular las aplicaciones heredadas
de más edad
Nuestro sistema había sido vivo por un tiempo y se comporta muy bien, el manejo de
una carga no insignificante. En ese momento debemos estado manejando alrededor
de 6.000-7.000 solicitudes por segundo durante el pico, y aunque la mayor parte de
eso fue muy fuertemente en caché por los proxies inversos que se sienta delante de
nuestros servidores de aplicaciones, las búsquedas de productos (el aspecto más
importante del sitio ) eran en su mayoría no está en caché y requiere un servidor
completo de ida y vuelta.
Una mañana, justo antes de chocar con nuestro pico de la hora de comer todos los
días, el sistema comenzó tamiento ing lentamente, y luego comenzó gradualmente a
fallar. Tuvimos un cierto nivel de supervisión en nuestra nueva aplicación central,
suficiente para decirnos que cada uno de nuestros nodos de aplicación estaba
golpeando un pico de la CPU al 100%, muy por encima de los niveles normales,
incluso en el pico. En un corto período de tiempo, todo el sitio fue abajo.
Nosotros conseguido localizar al culpable y llevar el sitio de copia de seguridad.
Resultó uno de los sistemas de anuncios aguas abajo, uno de los más antiguos y
menos mantenido activamente, había comenzado a responder muy lentamente.
Respondiendo muy lentamente es uno de los peores modos de fallo que puede
experimentar. Si un sistema no está allí, se encuentra con bastante rapidez. Cuando es
sólo lenta, se termina la espera por un tiempo antes de abandonar. Pero Cualquiera
que sea la causa de la falla, que habíamos creado un sistema que era vulnerable a un
fallo de conectar en cascada. Un servicio de aguas abajo, sobre el que teníamos poco
control, era capaz de hacer caer todo nuestro sistema.
Mientras que un equipo analizó los problemas con el sistema de aguas abajo, el resto
de nosotros se puso a mirar lo que había ido mal en nuestra aplicación. Hemos
encontrado algunos problemas. Estábamos usando un conjunto de conexiones HTTP
para manejar nuestras conexiones aguas abajo. Los hilos en la propia piscina habían
configurado los tiempos de espera por cuánto tiempo esperarían al hacer la llamada
HTTP aguas abajo, lo cual es bueno. El problema era que los trabajadores estaban
tomando un tiempo para el tiempo de espera debido al sistema de aguas abajo lento.
Medidas de seguridad de
arquitectura | 209
Mientras esperaban, más solicitudes fueron a la piscina pidiendo subprocesos de
trabajo. Sin trabajadores disponibles, estas solicitudes mismos colgadas. Resultó que
la biblioteca de la piscina ción conexiones que estábamos usando tuvo un tiempo de
espera para la espera de los trabajadores, pero esto
210 | Capítulo 11: microservicios a escala
fue desactivado por defecto! Esto dio lugar a una enorme acumulación de hilos
bloqueados. Nuestra apli- cación normalmente contaba con 40 conexiones
simultáneas en un momento dado. En el espacio de cinco minutos, esta situación nos
causó a pico en alrededor de 800 conexiones, con lo que el sis- tema hacia abajo.
Lo peor fue que el servicio de aguas abajo estábamos hablando con funcionalidad
representado que menos del 5% de nuestra base de clientes utiliza y genera menos
ingresos que eso. Al llegar a fin de cuentas, descubrimos la manera más difícil que
los sistemas que simplemente actúan lenta son mucho más difíciles de tratar que los
sistemas que simplemente fallan rápido. En un sistema distribuido, la latencia mata.
Incluso si hubiéramos tenido los tiempos de espera en la piscina situada
correctamente, sino que también estaban compartiendo una única agrupación de
conexiones HTTP para todas las solicitudes salientes. Esto significaba que un
servicio lento podría agotar el número de trabajadores disponibles por sí mismo,
incluso si todo lo demás estaba sano. Por último, estaba claro que el servicio de aguas
abajo en cuestión no era saludable, pero siguió enviando tráfico de su camino. En
nuestra situación, esto significaba en realidad estábamos haciendo una mala situación
peor, como el servicio de aguas abajo no tenía ninguna posibilidad de recuperarse.
Terminamos la implementación de tres correcciones para evitar que esto suceda otra
vez: conseguir nuestros tiempos de espera de la derecha, la implementación de los
mamparos para separar las diferentes agrupaciones de conexiones, y la
implementación de un disyuntor para evitar el envío de llamadas a un sistema poco
saludable en el primer lugar.
La Organización Antifragile
En su libro Antifragile (Random House), Nassim Taleb habla de cosas que realmente
se benefician de la insuficiencia y desorden. Ariel Tseitlin utiliza este concepto para
acuñar el concepto de laorganización antifragile en lo que respecta a cómo opera
Netflix.
La escala a la que funciona Netflix es bien conocida, como es el hecho de que Netflix
se basa totalmente en la infraestructura de AWS. Estos dos factores significa que
tiene para abrazar así fracaso. Netflix va más allá de que por el fracaso en realidad
incitar a asegurar que sus siste- mas son tolerantes de la misma.
Algunas organizaciones estarían felices con los días de juego, donde el fracaso se
simula mediante sistemas que se están apagados y con los distintos equipos
reaccionan. Durante mi tiempo en Google, se trataba de un fenómeno bastante común
para los diversos sistemas, y ciertamente creo que muchas organizaciones podrían
beneficiarse de tener este tipo de ejercicios con regu- laridad. Google va más allá de
simples pruebas para imitar falla en el servidor, y como parte de su informe anualDe
suciedad (recuperación de desastres de prueba) ejercicios se ha simulado desastres a
gran escala como los terremotos. Netflix también tiene un enfoque más agresivo,
escribiendo pro- gramas que el fracaso causa y ejecutarlos en la producción sobre una
base diaria.
Medidas de seguridad de
arquitectura | 209
El más famoso de estos programas es el mono Caos, que durante ciertas horas del día
se apagará máquinas de azar. Sabiendo que esto puede y va a HAP pluma en la
producción significa que los desarrolladores que crean los sistemas realmente tienen
que estar preparados para ello. El mono caos es sólo una parte del Ejército Simian de
Netflix de los robots de fallo. El Caos gorila se utiliza para sacar todo un centro de
disponibilidad (el equivalente AWS de un centro de datos), mientras que el mono
Latencia simula la conectividad de red lenta entre las máquinas. Netflix ha hecho
estas herramientas disponibles bajo unaabierto licencia de código. Para muchos, la
prueba definitiva de que su sistema es realmente robusta podría ser desatar su propio
ejército de simio en su infraestructura de producción.
Abrazando e incitar al fracaso a través de software y sistemas de construcción que se
manipulan de dle él, es sólo una parte de lo que hace Netflix. También comprende la
importancia de aprender del fracaso cuando se produce, y la adopción de una cultura
libre de culpa cuando los errores ocurren. Los desarrolladores tienen la facultad
adicional de ser parte de este proceso de aprendizaje y evolución, ya que cada
desarrollador es también responsable de la gestión de sus servicios de producción.
Al provocar la falta de suceder, y construyendo para ello, Netflix ha asegurado que
los sistemas tiene escala mejor, y mejor soporte a las necesidades de sus clientes.
No todo el mundo tiene que ir a la clase de extremos que Google o Netflix hacen,
pero es importante entender el cambio de mentalidad que se requiere con los sistemas
distribuidos. Las cosas van a fallar. El hecho de que el sistema está divida en varias
máquinas (que se puede y se producirá un error) a través de una red (que será poco
fiable) en realidad puede hacer que su sistema sea más vulnerable, no menos. Así
que, independientemente de si usted está tratando de ofrecer un servicio a la escala de
Google o Netflix, prepararse para el tipo de fallo que se presentan con más
arquitecturas distribuidas es bastante importante. Entonces, ¿qué tenemos que hacer
para manejar el fracaso en nuestros sistemas?
Tiempos de espera
Los tiempos de espera son algo que es fácil pasar por alto, pero en un sistema de
aguas abajo que son importantes para hacerlo bien. ¿Cuánto tiempo puedo esperar
antes de poder considero un sis- tema de aguas abajo para ser realmente abajo?
Espere demasiado tiempo para decidir que una llamada ha fallado, y se puede retrasar
todo el sistema hacia abajo. Tiempo de espera demasiado rápido, y se le considera
una llamada que podría haber funcionado como fallido. No tienen tiempos de espera
en absoluto, y un sistema de aguas abajo de estar abajo podría pasar todo el sistema.
Ponga los tiempos de espera en todas las llamadas fuera de proceso, y elegir un
tiempo de espera predeterminado para todo. Log cuando se producen tiempos de
espera, mira lo que sucede, y cambiar en consecuencia.
La Organización Antifragile | 211
Rompedores de circuito
En su propia casa, existen disyuntores para proteger sus dispositivos eléctricos de
picos en el poder. Si se produce un pico, el disyuntor se soplado, la protección de sus
electrodomésticos sive expen-. También puede desactivar manualmente un
interruptor para cortar el poder de parte de su casa, lo que le permite trabajar de
forma segura en el sistema eléctrico. El libro de Michael Nygard liberarlo!
(Programadores pragmáticos) muestra cómo la misma idea puede hacer maravillas
como un mecanismo de protección para nuestro software.
Consideremos la historia compartí hace un momento. La apli- cación aguas abajo
legado ad estaba respondiendo muy lentamente, antes de finalmente devolver un
error. Incluso si hubiéramos conseguimos los tiempos de espera de la derecha, que
estaríamos esperando mucho tiempo antes de llegar el error. Y entonces nos gustaría
probar de nuevo la próxima vez que una solicitud entró, y esperar. Ya es bastante
malo que el servicio de aguas abajo está funcionando mal, pero es lo que nos vamos
demasiado lento.
Con un interruptor de circuito, después de un cierto número de solicitudes al recurso
aguas abajo han fracasado, el interruptor de circuito está fundido. Todas las
solicitudes adicionales fallan rápido, mientras que el disyuntor se encuentra en su
estado expandido. Después de un cierto período de tiempo, el cliente envía peticiones
a través de unos pocos para ver si el servicio de aguas abajo se ha recuperado, y si
consigue suficientes respuestas saludables se restablece el interruptor de circuito. Se
puede ver una visión general de este proceso enFigura 11-2.
¿Cómo se implementa un disyuntor depende de lo que significa una solicitud fallado,
pero cuando les he implementado para las conexiones HTTP he tomado falta de
significar un tiempo de espera o un código de retorno HTTP 5XX. De esta manera,
cuando un recurso aguas abajo es hacia abajo, o el tiempo de espera, o devolver
errores, después de un cierto umbral se alcanza automática- mente que deje de enviar
tráfico y empezar a fallar rápidamente. Y podemos empezar de nuevo
automáticamente cuando las cosas son saludables.
Conseguir la configuración correcta puede ser un poco difícil. Usted no quiere que
diera el interruptor de circuito con demasiada facilidad, ni tampoco quiere tomar
demasiado tiempo para hacerlo explotar. Del mismo modo, usted realmente desea
asegurarse de que el servicio de aguas abajo es sano otra vez antes de enviar el
tráfico. Al igual que con los tiempos de espera, me quedaría con unos valores
iniciales adecuados y seguir con ellos en todas partes, a continuación, cambiar ellos
para casos específicos.
Mientras se sopla el disyuntor, usted tiene algunas opciones. Una de ellas es hacer
cola las peticiones y vuelva a intentarlo más adelante. Para algunos casos de uso, esto
podría ser apropiado, especial- mente si usted está llevando a cabo un trabajo como
parte de un trabajo asíncrono. Si esta llamada se está realizando como parte de una
212| Capítulo 11: microservicios a escala
cadena llamada sincrónica, sin embargo, es probablemente mejor fallar rápido. Esto
podría significar la propagación de un error en la cadena de llamada, o una ing
degrad- más sutil de funcionalidad.
Si tenemos este mecanismo en su lugar (como ocurre con los interruptores de circuito
en nuestra casa), podríamos utilizar de forma manual para que sea más seguro para
hacer nuestro trabajo. Por ejemplo, si queríamos tomar un microService abajo como
parte del mantenimiento de rutina, podríamos volar manualmente
La Organización Antifragile | 213
todos los interruptores de circuito de los sistemas dependientes para que fallan
rápido, mientras que el vicio microser- no está en línea. Una vez que está atrás,
podemos restablecer los interruptores de circuito y todo debería volver a la
normalidad.
Figura 11-2. Una visión general de los disyuntores
214| Capítulo 11: microservicios a escala
mamparos
En otro patrón de liberación que !, Nygard introduce el concepto de un mamparo
como una forma de aislarse de fracaso. En el transporte marítimo, un mamparo es
una parte de la nave que puede ser sellada para proteger el resto de la nave. Así que si
el buque surge una fuga, puede cerrar las puertas de los mamparos. Se pierde parte de
la nave, pero el resto de la misma se mantiene intacta.
En términos de arquitectura de software, hay un montón de diferentes mamparos
podemos considerar. Volviendo a mi propia experiencia, que en realidad perdió la
oportunidad de poner en práctica un mamparo. Deberíamos haber utilizado diferentes
agrupaciones de conexiones para cada conexión aguas abajo. De esa manera, si uno
agrupación de conexiones se agota, las otras conexiones no están afectados, como
vemos enFigura 11-3. Esto aseguraría que si un servicio de aguas abajo lentamente
empezó a comportarse en el futuro, sólo eso piscina una conexión sería impac- ted,
permitiendo que otras llamadas para proceder de forma normal.
Figura 11-3. El uso de un conjunto de conexiones por servicio de aguas abajo para
proporcionar los mamparos
La separación de las preocupaciones también puede ser una manera de poner en
práctica los mamparos. Por burlas aparte funcionalidad en microservicios separados,
se reduce la posibilidad de un corte de luz en un área que afecta a otra.
Mira todos los aspectos de su sistema que pueden salir mal, tanto dentro de sus ces
microservi- y entre ellos. ¿Tiene mamparos en su lugar? Yo sugeriría a partir de
grupos de conexión arate SEP para cada conexión aguas abajo al menos. Es posible
que desee ir más lejos, sin embargo, y considerar el uso de interruptores de circuito
también.
Nosotros puede pensar en nuestros interruptores como un mecanismo automático para
sellar un mamparo, no sólo para proteger al consumidor contra el problema aguas
abajo, sino también a potencial- mente proteger el servicio de aguas abajo de más
llamadas que pueden estar teniendo un impacto adverso. Teniendo en cuenta los
peligros de la cascada fracaso, me gustaría recomendar que ordena circuito ERS
La Organización Antifragile | 215
Break para todas sus llamadas aguas abajo síncronos. Usted no tiene que escribir su
propia, ya sea. Netflixbiblioteca hystrix es un interruptor automático de la
abstracción que viene con JVM
216| Capítulo 11: microservicios a escala
un poderoso monitoreo, pero existen otras implementaciones de diferentes pilas de
tecnología, tales como Polly para .NET, o la mixin circuit_breaker para Ruby.
En muchos sentidos, los mamparos son los más importantes de estos tres patrones.
Los tiempos de espera y disyuntores ayudan a liberar recursos cuando se están
limitados, pero los mamparos pueden asegurarse de que no quedan limitados en el
primer lugar. Hystrix le permite, por ejemplo, para poner en práctica los mamparos
que realmente rechazan solicitudes en condiciones determi- nados para garantizar
que los recursos no llegan a ser aún más saturada; esto se conoce como la
desconexión de carga. A veces rechazar una solicitud es la mejor manera de detener
un sistema importante de convertirse en abrumado y ser un cuello de botella para
múltiples servicios de aguas arriba.
Aislamiento
Cuanto más uno de servicio depende de otro ser arriba, más la salud de uno influye
en la capacidad del otro para hacer su trabajo. Si podemos usar técnicas de
integración que permiten a un servidor indirecto a estar fuera de línea, servicios de
aguas arriba tienen menos probabilidades de estar afectados por los cortes, previstas
o imprevistas.
Hay otro beneficio para aumentar el aislamiento entre los servicios. Cuando los
servicios están aislados unos de otros, se necesita mucho menos coordinación entre
los propietarios de servicios. Cuanto menos se necesita la coordinación entre los
equipos, la mayor autonomía esos equipos tienen, ya que son capaces de funcionar y
evolucionar sus servicios con mayor libertad.
idempotencia
En las operaciones idempotente, el resultado no cambia después de la primera
aplicación, incluso si la operación se aplica posteriormente varias veces. Si se
idempotent operaciones, podemos repetir la llamada varias veces sin efectos
adversos. Esto es muy útil cuando queremos reproducir los mensajes que no estamos
seguros han sido procesados, una forma común de recuperación de error.
Vamos considerar una simple llamada a añadir algunos puntos como resultado de uno
de nuestros clientes hacer un pedido. Podríamos hacer una llamada con el tipo de
carga útil se muestra enEjemplo 11-1.
Ejemplo 11-1. Acreditando puntos a una cuenta
<Crédito>
<Cantidad>100</ Cantidad>
<ForAccount>1234</ Cuenta>
</ Crédito>
idempotencia | 215
Si esta llamada es recibida en múltiples ocasiones, que habría que añadir 100 puntos
múltiples veces. Tal como está, por lo tanto, esta llamada no es idempotente. Con un
poco más de información, sin embargo, permitimos que el banco de puntos para
hacer esta llamada idempotente, como se muestra enEjemplo 11-2.
Ejemplo 11-2. La adición de más información al crédito de puntos para que sea
idempotente
<Crédito>
<Cantidad>100</ Cantidad>
<ForAccount>1234</ Cuenta>
<Razón>
<ForPurchase>4567</ ForPurchase>
</ Razón>
</ Crédito>
Ahora sabemos que este crédito se refiere a un orden específico, 4567. Suponiendo
que pudiéramos recibir sólo un crédito para un fin determinado, podríamos aplicar
este crédito nuevo sin aumentar el número total de puntos.
Este mecanismo funciona igual de bien con la colaboración basada en eventos, y
puede ser especial- mente útil si tiene varias instancias del mismo tipo de servicio de
suscripción de eventos. Incluso si almacenamos los eventos que se han procesado,
con algunas formas de entrega de mensajes asíncrona puede haber pequeñas ventanas
donde dos trabajadores pueden ver el mismo mensaje. Al procesar los eventos de una
manera idempotente, nos aseguramos de que esto no nos va a causar ningún
problema.
Algunas personas llegar a ser muy atrapados con este concepto, y asumen que
significa que la subsiguiente llamadas con los mismos parámetros no pueden tener
ningún impacto, que a su vez nos deja en una posición interesante. Realmente todavía
desea grabar el hecho de que una llamada fue recibida en nuestros registros, por
ejemplo. Queremos grabar el tiempo de respuesta de la llamada y recopilar estos
datos para el monitoreo. El punto clave aquí es que es la operación Ness Busisubyacente que estamos considerando idempotente, no todo el estado del sistema.
Algunos de los verbos HTTP, como GET y PUT, se definen en la especificación
HTTP ción para ser idempotente, pero para que eso sea el caso, que se basan en el
manejo de estas llamadas en forma idempotente servicio. Si usted comienza a hacer
estos verbos nonidempotent, pero las personas que llaman piensa que puede ejecutar
con seguridad ellos en varias ocasiones, es posible que te metas en un lío. Recuerde,
sólo porque usted está utilizando HTTP como protocolo subyacente no significa que
usted consigue todo gratis!
Escalada
Nosotros escalar nuestros sistemas, en general, por una de dos razones. En primer
216| Capítulo 11: microservicios a escala
lugar, para ayudar a lidiar con el fracaso: si estamos preocupados de que algo va a
fallar, y luego tener más de lo mismo va a ayudar, ¿verdad? Segundo, se escala para
el rendimiento, ya sea en términos de manejo más carga, reduciendo la latencia, o
ambos. Veamos algunas técnicas de escalamiento comunes que podemos utilizar y
pensar en cómo se aplican a MICROSERVICE arquitecturas.
idempotencia | 217
ir más grande
Algunas operaciones solo pueden beneficiarse de más ronco. Conseguir una caja más
grande con una CPU más rápida y mejor de E / S a menudo puede mejorar la latencia
y rendimiento, lo que le permite pro- ceso más trabajo en menos tiempo. Sin
embargo, esta forma de escala, a menudo llamada la escala vertical, puede ser a veces
un servidor caro grande puede costar más de dos servidores más pequeños con la
misma potencia bruta combinada, especialmente cuando comienza a recibir a
máquinas muy grandes. A veces nuestro software en sí mismo no puede hacer mucho
con los recursos adicionales disponibles a la misma. Las máquinas más grandes a
menudo sólo nos dan más núcleos de CPU, pero no lo suficiente de nuestro software
está escrito para tomar ventaja de ellos. El otro problema es que esta forma de
escalado no puede hacer mucho para mejorar la capacidad de recuperación de nuestro
servidor si sólo tenemos uno de ellos! Sin embargo, esto puede ser una buena victoria
rápida,
Las cargas de trabajo de división
Como se indica en Capítulo 6, Que tiene un único microService por host es
ciertamente preferible a un modelo multiservicio-per-host. Inicialmente, sin embargo,
muchas personas deciden coexistir múltiples microservicios en una caja para
mantener los costos bajos o para simplificar anfitrión manage- ment (aunque eso es
una razón discutible). Como los microservicios son procesos independientes que se
comunican a través de la red, debe ser una tarea fácil para luego moverlos en sus
propios ordenadores para mejorar el rendimiento y escalado. Esto también puede
aumentar la elasticidad del sistema, como un solo corte de anfitrión tendrá un
impacto en un número reducido de microservicios.
Por supuesto, también podríamos utilizar la necesidad de aumentar la escala para
dividir un vicio microser- existente en partes para manejar mejor la carga. Como un
ejemplo simplista, imaginemos que nuestro servicio de cuentas proporciona la
capacidad de crear y administrar las cuentas financieras de los clientes individuales,
pero también expone una API para ejecutar consultas para generar informes. Esta
capacidad de consulta coloca una carga significativa en el sistema. La capacidad de
consulta se considera no crítico, ya que no es necesario para mantener las órdenes
que fluyen durante el día. La capacidad de gestionar los registros financieros para
nuestros clientes es fundamental, sin embargo, y no puede permitirse el lujo de que
sea hacia abajo. Al dividir estas dos capacidades en diversos servicios diferentes, se
reduce la carga en el servicio de cuentas críticas,Capítulo 4, Sino también como un
sistema no crítico no necesita ser desplegado de una manera tan resistentes como las
cuentas del núcleo de servicios.
Difundir su riesgo
Una forma de ampliar la capacidad de recuperación es asegurarse de que usted no
pone todos los huevos en una sola canasta. Un simple ejemplo de esto es asegurarse
escalamiento |
217
de que usted no tiene múltiples servicios en un host, donde una interrupción afectaría
a múltiples servicios. Pero vamos a considerar lo que significa anfitrión. En la
mayoría de las situaciones de hoy en día, una gran cantidad es en realidad un
concepto virtual. Entonces
218| Capítulo 11: microservicios a escala
¿Y si tengo todos mis servicios en diferentes hosts, pero todos esos anfitriones son
realmente anfitriones tuales vir-, que se ejecuta en la misma máquina física? Si este
cuadro no se cae, podría perder los servicios múlti- ples. Algunas plataformas de
virtualización que permiten asegurar que sus anfitriones son distribuidos a través de
múltiples cajas físicas diferentes para reducir esta oportunidad.
Para las plataformas de virtualización internos, es una práctica común tener partición
raíz de la máquina virtual asignado a un solo (red de área de almacenamiento) SAN.
Si eso SAN baja, se puede acabar con todas las máquinas virtuales conectadas. SAN
son grandes, caros, y diseñado para no fallar. Dicho esto, he tenido grandes redes
SAN caros fallan en mí por lo menos dos veces en los últimos 10 años, y cada vez los
resultados fueron bastante grave.
Otra forma común de separación para reducir el fracaso es para asegurarse de que no
todos los servicios se están ejecutando en un solo estante en el centro de datos, o que
sus servicios se dis- tribuyeron en más de un centro de datos. Si está utilizando un
servicio de vider pro subyacente, es importante saber si se ofrece un acuerdo de nivel
de servicio (SLA) y planificar en consecuencia. Si necesita asegurarse de que sus
servicios se han reducido a no más de cuatro horas cada trimestre, pero su proveedor
de alojamiento sólo pueden garantizar un tiempo de inactividad de ocho horas por
trimestre, usted tiene que cambiar ya sea el SLA, o llegar a una solución alter- nativa
.
AWS, por ejemplo, se divide en regiones, que se pueda imaginar nubes distintos.
Cada región está a su vez dividido en dos o más zonas de disponibilidad (AZS). AZS
son equivalentes de un centro de datos de AWS. Es esencial disponer de los servicios
distribuidos a través de múltiples zonas de disponibilidad, como AWS no ofrece
garantías acerca de la disponibilidad de un solo nodo, o incluso toda una zona de
disponibilidad. Por su servicio de computación, que sólo ofrece un tiempo de
actividad del 99,95% durante un período mensual dada de la región en su conjunto,
así que es conveniente para distribuir las cargas de trabajo a través de zonas de
disponibilidad múltiples dentro de una sola región. Para algunas personas, esto no es
lo suficientemente bueno, y en su lugar se ejecuta sus servicios a través de múltiples
regiones también.
Eso Hay que señalar, por supuesto, que debido a que los proveedores le dan una
garantía de SLA, tenderán a limitar su responsabilidad! Si les falta sus objetivos le
cuesta a los clientes y una gran cantidad de dinero, puede que te encuentres buscando
a través de los contratos para ver si se puede arañar nada nuevo de ellos. Por lo tanto,
yo sugerimos que entender el impacto de un proveedor de fallar en sus obligaciones
con usted, y averiguar si es necesario tener un plan B (o C) en el bolsillo. Más de un
cliente que he trabajado ha tenido una recuperación de desastres plataforma de
alojamiento con un proveedor diferente, por ejem- plo, para asegurar que no eran
demasiado vulnerables a los errores de una empresa.
escalamiento |
219
Balanceo de carga
Cuando necesite su servicio para ser resistente, se quiere evitar puntos únicos de
fallo. Para una típica microService que expone un extremo HTTP sincrónico, la
forma más fácil de lograr esto es tener varios hosts funcionando la instancia
microService, sen- tado detrás de un equilibrador de carga, como se muestra
enFigura 11-4. Para los consumidores de la microService, no se sabe si se trata de un
caso microService o cien.
Figura 11-4. Un ejemplo de un enfoque de equilibrio de carga a escala el número de
instancias de servicio al cliente
equilibradores de carga vienen en todas las formas y tamaños, desde ANCES aplihardware grandes y costosos a los equilibradores de carga basados en software como
mod_proxy. Todos ellos comparten algunas funciones clave. Se distribuyen las
llamadas enviadas a ellos para una o más instancias en base a algún algoritmo,
eliminar las instancias cuando ya no son saludables, y es de esperar añadirlos de
nuevo en cuando se encuentran.
Algunos equilibradores de carga proporcionan características útiles. Uno muy
común es la terminación SSL, HTTPS entrantes donde las conexiones con el
equilibrador de carga se transforman en las conexiones HTTP vez que lleguen a
la instancia en sí. Históricamente, la sobrecarga de gestión de SSL fue lo
suficientemente significativo que tener un equilibrador de carga manejar este
proceso para usted era bastante útil. Hoy en día, esto es tanto sobre la
simplificación de la puesta a punto de los anfitriones viduales indi- que ejecuta la
instancia. El punto de usar HTTPS, sin embargo, es asegurarse de que las
solicitudes no son vulnerables a un ataque man-in-the-middle, como hemos
comentado enCapítulo 9, Por lo que si usamos la terminación SSL, estamos
exponiendo potencialmente a nosotros mismos lo que algu-. Uno de mitigación
es tener todas las instancias de la microService dentro de una sola VLAN, como
vemos enFigura 11-5. Una VLAN es una red virtual de área local, es decir
RELAClONADAS iso de una manera tal que solicita desde fuera de ella sólo
puede venir a través de un router, y en este caso nuestro router es también nuestra
220| Capítulo 11: microservicios a escala
equilibrador de carga SSL de terminación. La única comu- nicación a la
microService desde fuera del VLAN viene HTTPS más, pero todo internamente
es HTTP.
escalamiento |
221
Figura 11-5. El uso de la terminación de HTTPS en el equilibrador de carga con una
VLAN para mejorar la seguridad
AWS proporciona HTTPS de terminación de los equilibradores de carga en forma de
ELB (equilibradores de carga elásticas) y puede utilizar sus grupos de seguridad o
nubes privadas virtuales (VPC) para poner en práctica la VLAN. De lo contrario, el
software como mod_proxy puede desempeñar un papel similar al de un equilibrador
de carga de software. Muchas organizaciones tienen equilibradores de carga de
hardware, que pueden ser difíciles de automatizar. En tales circunstancias, me he
encontrado la defensa de los equilibradores de carga de software que se sientan detrás
de los equilibradores de carga de hardware para permitir que los equipos de la
libertad para volver a configurar estos como sea necesario. Usted quiere ver el hecho
de que toda la carga con demasiada frecuencia el hardware balanceadores sí son
puntos únicos de fallo! Independientemente del enfoque que toma, al considerar la
configuración de un equilibrador de carga, lo tratan como tratas a la configuración de
su servicio:
equilibradores de carga nos permite añadir más instancias de nuestra microService de
una manera que sea transparente para los consumidores de servicios. Esto nos da una
mayor capacidad para manejar la carga, y también reducir el impacto de un solo
defecto de acogida. Sin embargo, muchos, si no la mayoría, de sus microservicios
tendrán algún tipo de almacén de datos persistente, probablemente, una base de datos
que se sienta en una máquina diferente. Si tenemos varias instancias
MICROSERVICE en diferentes máquinas, pero sólo un único host que ejecuta la
instancia de base de datos, nuestra base de datos sigue siendo una fuente única de
fracaso. Vamos a hablar acerca de los patrones de manejar esto en breve.
Sistemas del trabajador de base
El balanceo de carga no es la única manera de tener múltiples instancias de su carga
cuota de servicio y reducir la fragilidad. Dependiendo de la naturaleza de las
operaciones, un sistema basado en el trabajador podría ser igual de eficaz. Aquí, una
colección de instancias de todo el trabajo en alguna acumulación de trabajo común.
escalamiento |
221
Esto podría ser una serie de procesos de Hadoop, o tal vez un número de oyentes a
una cola compartida de trabajo. Este tipo de operaciones son también
220 | Capítulo 11: microservicios a escala
adecuado para el trabajo por lotes o asíncronas. Piense en tareas como la imagen en
miniatura cessing pro, el envío de correo electrónico, o la generación de informes.
El modelo también funciona bien para la carga con picos, donde se pueden girar las
instancias adicionales de la demanda para que coincida con la carga que entra.
Mientras la cola de trabajo en sí es resistente, este modelo se puede utilizar para
escalar tanto para mejorar el rendimiento del trabajo, pero también para mejorar la
capacidad de recuperación, el impacto de un trabajador no (o no estar allí) es fácil de
tratar. El trabajo se llevará más tiempo, pero nada se pierde.
He visto que esto funciona bien en organizaciones donde hay una gran cantidad de
capacidad de cómputo no utilizado en determinados momentos del día. Por ejemplo,
durante la noche no puede ser que necesite tantas máquinas para ejecutar su sistema
de comercio electrónico, por lo que puede utilizar de forma temporal para que se
ejecuten los trabajadores para un trabajo de informes en su lugar.
Con los sistemas basados en los trabajadores, aunque los trabajadores mismos no
tiene por qué ser fiable, el sistema que contiene el trabajo que se hará lo hace. Se
podía manejar esto mediante la ejecución de un intermediario de mensajes
persistentes, por ejemplo, o tal vez un sistema como el Zoo-arquero. La ventaja aquí
es que si usamos el software existente para este fin, alguien ha hecho gran parte del
trabajo duro por nosotros. Sin embargo, todavía necesitamos saber cómo configurar y
mantener estos sistemas de una manera flexible.
Empezando de nuevo
La arquitectura que le ayudará a comenzar puede no ser la arquitectura que le
mantiene en marcha cuando el sistema tiene que manejar muy diferentes volúmenes
de carga. Como dijo Jeff Dean en su presentación “Desafíos en la construcción de
información a gran escala sistemas de recuperación” (WSDM conferencia de 2009),
que debería “diseño para ~ 10 × crecimiento, pero el plan de volver a escribir antes
de ~ 100 ×.” En ciertos puntos, es necesario hacer algo bastante radical para apoyar
el siguiente nivel de crecimiento.
Recordemos la historia de la cerda joven, que hemos tocado en Capítulo 6. Una
simple aplicación monolítica rieles hizo así para la cerda joven durante dos años. Su
actividad se convirtió en un éxito creciente, lo que significa más clientes y más carga.
En un determinado punto de inflexión, la compañía tuvo que rediseñar la aplicación
para manejar la carga que estaba viendo.
Un rediseño puede significar una división aparte monolito existente, como lo hizo
para la cerda joven. O puede significar recoger nuevos almacenes de datos que
pueden manejar mejor la carga, lo que vamos a ver en un momento. También podría
significar la adopción de nuevas técnicas, tales como pasar de síncrono de solicitud /
respuesta a los sistemas basados en eventos, la adopción de nuevas plataformas de
despliegue, el cambio de pilas de tecnología enteros, o todo lo demás.
Existe el peligro de que la gente vea la necesidad de rearchitect cuando ciertos
escalamiento |
221
umbrales de escala se alcanzan como una razón para construir de forma masiva desde
el principio. Esto puede ser desastroso. Al inicio de un nuevo proyecto, que a
menudo no sabemos exactamente lo que queremos construir, ni tampoco sabemos si
va a ser un éxito. Necesitamos ser capaces de experimentar rápidamente, y entender
qué capacidades que necesitamos para construir. Si tratamos de construcción
220 | Capítulo 11: microservicios a escala
de forma masiva en la delantera, que acabaríamos de carga frontal una enorme
cantidad de trabajo para pre- parar de carga que puede no llegar nunca, mientras
que el desvío de esfuerzo fuera de las actividades más importantes, como la
comprensión si alguien va a querer utilizar realmente nuestro producto . Eric
Ries cuenta la historia de pasar seis meses en la creación de un producto que
nadie cargado Down-. Pensó que podía haber puesto un enlace en una página
web que 404'd cuando la gente hace clic en él para ver si había alguna demanda,
pasó seis meses en la playa en su lugar, y aprendió igual forma!
La necesidad de cambiar nuestros sistemas para hacer frente a escala no es una señal
de fracaso. Es un signo de éxito.
Bases de datos de escala
Escalamiento microservicios sin estado es bastante sencillo. Pero lo que si estamos
almacenando los datos en una base de datos? Tendremos que saber cómo escalar eso
también. Los diferentes tipos de bases de Data- proporcionan diferentes formas de
escalamiento, y comprender lo que se adapte a su forma de casos de uso mejor se
asegurará de que selecciona la tecnología de base de datos desde el principio.
Disponibilidad de servicio Versus Durabilidad de Datos
Directamente hacia afuera, es importante separar el concepto de disponibilidad del
servicio de la durabilidad de los datos en sí. Es necesario comprender que estos son
dos cosas diferentes, y como tal, tendrá diferentes soluciones.
Por ejemplo, podría almacenar una copia de todos los datos escritos en mi base de
datos en un sistema de Archivo- resistente. Si la base de datos se pone, mis datos no
se pierde, ya que tengo una copia, pero la base de datos en sí no está disponible, lo
que puede hacer mi microService disponible también. Un modelo más com- mon
sería el uso de un modo de espera. Todos los datos escritos en la base de datos
primaria se copia en la base de datos de réplica de espera. Si el principal se
interrumpa, mis datos es segura, pero sin un mecanismo que sea traer una copia de
seguridad o promover la réplica a la primaria, no tenemos una base de datos
disponible, a pesar de que nuestros datos es segura.
Escalamiento de Lee
Muchos los servicios son de lectura en su mayoría. Piense en un servicio de catálogo
que almacena la información de los artículos que tenemos para la venta. Añadimos
los registros de nuevos artículos sobre una base bastante irregular, y no sería en
absoluto sorprendente si tenemos más de 100 lecturas de los datos de nuestro
catálogo para cada escritura. Felizmente, la escala para lecturas es mucho más fácil
de escalar para escrituras. ING Cach- de datos puede desempeñar un papel
importante aquí, y vamos a discutir eso con mayor profundidad en breve. Otro
modelo es hacer uso de réplicas de lectura.
222| Capítulo 11: microservicios a escala
En un sistema de gestión de base de datos relacional (RDBMS) como MySQL o
Postgres, los datos pueden ser copiados desde un nodo primario a uno o más réplicas.
A menudo esto se hace para asegurar que una copia de nuestros datos se mantiene a
salvo, pero también se puede utilizar para distribuir nuestra lecturas. Un servicio
podría dirigir todas las escrituras en el nodo principal y único, pero distribuir lee
Bases de datos de escala |
223
a uno o más réplicas de lectura, como vemos en Figura 11-6. La replicación de la
base de datos mary pri- a las réplicas que sucede en algún momento después de la
escritura. Esto significa que con esta técnica se lee a veces puede ver datos obsoletos
hasta que la replicación tiene com- pletó. Con el tiempo las lecturas se verán los
datos consistentes. Tal configuración se llama eventu- aliado consistente, y si se
puede manejar la inconsistencia temporal es una manera bastante fácil y común para
ayudar a los sistemas de escala. Vamos a ver en esto con más profundidad en breve
cuando nos fijamos en el teorema de CAP.
Figura 11-6. El uso de réplicas de lectura a escala lee
Años Hace, usando réplicas de lectura a escala fue toda la rabia, aunque hoy en día te
sugeriría que mira a la memoria caché en primer lugar, ya que puede ofrecer mejoras
mucho más significativos en el rendimiento, a menudo con menos trabajo.
Escalamiento para escrituras
Lee son comparativamente fácil de escalar. ¿Qué pasa con las escrituras? Un método
consiste en utilizar sharding. Con sharding, tiene varios nodos de bases de datos. Se
toma un trozo de datos a escribir, aplicar una función hash a la clave de los datos, y
en base al resultado de la función aprende dónde enviar los datos. Para recoger un
ejemplo muy simplista (y de hecho mal), imagina que el cliente registra A-M ir a una
instancia de base de datos, y N-Z otra. Usted puede manejar esto por sí mismo en su
aplicación, pero algunas bases de datos, como Mongo, manejar mucho de él para
usted.
La complejidad con sharding para escrituras proviene de consultas de manipulación.
Mirando hacia arriba un registro individual es fácil, ya que sólo puede aplicar la
función hash para encontrar qué instancia los datos deben estar en, y luego
recuperarla desde el fragmento correcto. Pero, ¿qué acerca de las consultas que
abarcan los datos en múltiples nodos, por ejemplo, la búsqueda de todos los tomers
cliente central que tienen más de 18 años? Si desea consultar todos los fragmentos,
ya sea que tenga que mirar cada fragmento individual y unirse en la memoria, o tiene
una tienda de lectura alternativa en la que ambos conjuntos de datos están
224| Capítulo 11: microservicios a escala
disponibles. A menudo, la consulta a través de fragmentos es manejado por un
asynchro-
Bases de datos de escala |
225
mecanismo nous, utilizando los resultados almacenados en caché. Mongo utiliza map
/ reduce puestos de trabajo, por ejemplo, para llevar a cabo estas consultas.
Una de las preguntas que surge con los sistemas fragmentados es, ¿qué ocurre si
desea añadir un nodo de base de datos adicional? En el pasado, esto a menudo
requeriría tiempo, especialmente Down- significativo para grandes grupos, como es
posible que tenga que tomar toda la base de datos de abajo y reequilibrar los datos.
Más recientemente, los sistemas de apoyo más la adición de fragmentos adicionales a
un sistema vivo, en el reequilibrio de datos ocurre en el fondo; Cassandra, por
ejemplo, maneja muy bien. Adición de fragmentos a un clúster existente no es para
los débiles de corazón, sin embargo, así que asegúrese de probar esto a fondo.
Sharding para escrituras puede escalar para el volumen de escritura, pero no puede
mejorar la resistencia. Si el cliente registra A-H siempre van a Instancia X y X
Instancia no está disponible, el acceso a los registros A-H se puede perder. Cassandra
ofrece capacidades adicionales aquí, donde podemos asegurar que los datos se
replican a múltiples nodos en un anillo (plazo de Cassandra para una colección de
nodos de Cassandra).
Como puede haber inferido a partir de este breve resumen, de escala bases de datos
de las escrituras son donde las cosas se ponen muy complicado, y donde las
capacidades de las distintas bases de datos realmente comienzan a diferenciarse. A
menudo veo a la gente evolución de la tecnología de base de datos cuando empiezan
a golpear límites a la facilidad con que se puede ampliar su volumen de escritura
existentes. Si esto le sucede, la compra de una caja más grande es a menudo la
manera más rápida de resolver el proble- ma, pero en el fondo es posible que desee
mirar a sistemas como Cassandra, Mongo, o Riak para ver si sus modelos de escala
alternativos que podrían ofrecer una solución a largo plazo mejor.
Infraestructura base de datos compartida
Algunos tipos de bases de datos, tales como los RDBMS tradicionales, separar el
concepto de la propia base de datos y el esquema. Esto significa una base de datos en
ejecución podría alojar múltiples, esquemas independientes, una para cada
microService. Esto puede ser muy útil en términos de reducir el número de máquinas
que necesitamos para funcionar nuestro sistema, pero estamos introduciendo un
único punto importante de fracaso. Si esta infraestructura de base de datos baja, que
puede afectar múltiples microservicios a la vez, que podrían resultar en una
interrupción catastrófica. Si está ejecutando este tipo de configuración, asegúrese de
considerar los riesgos. Y estar muy seguro de que la base de datos en sí es tan
resistente como lo puede ser.
CQRS
La segregación (CQRS) patrón responsabilidad de mando-Query se refiere a un
modelo nate alter- para almacenar y consultar información. Con bases de datos
normales, utilizamos un sistema para realizar modificaciones a los datos y consulta
226| Capítulo 11: microservicios a escala
de los datos. Con CQRS, parte del sistema se ocupa de comandos, que las solicitudes
de captura para modificar el estado, mientras que otra parte de las ofertas del sistema
con consultas.
Bases de datos de escala |
227
Comandos vienen en solicitar cambios en el estado. Estos comandos son validados, y
si trabajan, van a ser aplicados al modelo. Los comandos debe contener informa- ción
acerca de su intención. Ellos pueden ser procesados manera síncrona o asíncrona,
permitiendo diferentes modelos para manejar escalamiento; Podríamos, por ejemplo,
acaba de poner en cola las peticiones entrantes y procesarlos posteriormente.
La conclusión clave aquí es que los modelos internos utilizados para manejar los
comandos y consultas son en sí mismos completamente separados. Por ejemplo,
podría elegir para manejar y los comandos de proceso como eventos, tal vez sólo el
almacenamiento de la lista de comandos en un almacén de datos (un proceso
conocido como el abastecimiento de eventos). Mi modelo de consulta podría
consultar un almacén de eventos y crear proyecciones de eventos almacenados a
montar el estado de los objetos de dominio, o simplemente podría recoger una
alimentación de la parte de comandos del sistema para actualizar un tipo diferente de
tienda. En muchos sentidos, se obtienen los mismos beneficios de las réplicas de
lectura que dis- cussed antes, sin el requisito de que el almacén de respaldo para las
réplicas ser el mismo que el almacén de datos utiliza para manejar las modificaciones
de datos.
Esta forma de separación permite diferentes tipos de escala. Las partes de mando y
de consulta de nuestro sistema podrían vivir en diferentes servicios, o en otro
hardware, y podrían hacer uso de radicalmente diferentes tipos de almacén de datos.
Esto puede desbloquear un gran nú- mero de maneras de manejar escala. Incluso se
puede soportar diferentes tipos de formatos de lectura al tener múltiples
implementaciones de la pieza de consulta, tal vez el apoyo a una representación
basada graph- de sus datos, o una / formulario de claves basado en el valor de sus
datos.
Se advirtió, sin embargo: este tipo de patrón es bastante un cambio desde un modelo
en un solo almacén de datos se encarga de todas las operaciones CRUD. He visto
más de una experimenté lucha equipo de desarrollo para conseguir este patrón
correcto!
El almacenamiento en caché
El almacenamiento en caché es una optimización del rendimiento de uso común
mediante el cual se almacena el resultado anterior de alguna operación, por lo que las
solicitudes posteriores pueden usar este valor almacenado en lugar de gastar tiempo y
recursos recalcular el valor. Más a menudo que no, el almacenamiento en caché se
trata de eliminar innecesarios de ida y vuelta a las bases de datos u otros servicios a
ofrecer resultados más rápido. Bien utilizada, se puede producir enormes beneficios
en el rendimiento. La razón de que HTTP escalas tan bien en el manejo de un gran
número de peticiones es que el concepto de almacenamiento en caché está integrada.
Incluso con una simple aplicación web monolítica, hay un buen número de opciones
en cuanto a dónde y cómo almacenar en caché. Con una arquitectura microService,
El
almacenamiento
en caché | 225
donde cada servicio es su propia fuente de datos y el comportamiento, tenemos
muchas más opciones para decidir acerca de dónde y cómo almacenar en caché. Con
un sistema distribuido, por lo general pensamos en el almacenamiento en caché, ya
sea en el lado del cliente o en el servidor. Pero que es el mejor?
226| Capítulo 11: microservicios a escala
Del lado del cliente, proxy y almacenamiento en caché del lado
del servidor
En la caché del cliente, el cliente almacena el resultado en caché. El cliente puede
decidir cuando (y si) va y recupera una copia fresca. Idealmente, el servicio de aguas
abajo proporcionará consejos para ayudar al cliente a entender qué hacer con la
respuesta, por lo que sabe cuándo y si para hacer una nueva solicitud. Con el
almacenamiento en caché de proxy, la representación se coloca entre el cliente y el
servidor. Un buen ejemplo de esto es usar una red proxy o entrega de contenido
inversa (CDN). Con el almacenamiento en caché del lado del servidor, el servidor se
encarga de la responsabilidad de almacenamiento en caché, tal vez haciendo uso de
un sistema como Redis o Memcache, o incluso un simple caché en memoria.
¿Cuál tiene más sentido depende de lo que está tratando de optimizar. el
almacenamiento en caché del lado del cliente puede ayudar a reducir drásticamente la
red llama, y puede ser una de las maneras más rápidas de reducir la carga en un
servicio de aguas abajo. En este caso, el cliente es responsable del comportamiento
de caché, y si desea realizar cambios en cómo se realiza el almacenamiento en caché,
roll-ing a cabo cambios en un número de consumidores podría ser difícil. La
invalidación de datos obsoletos también puede ser más complicado, aunque vamos a
discutir algunos mecanismos para lidiar con esto en un momento.
Con proxy caché, todo es opaco tanto para el cliente y el servidor. Esto es a menudo
una forma muy sencilla de añadir almacenamiento en caché a un sistema existente. Si
el proxy está diseñado para almacenar en caché el tráfico genérico, también se puede
almacenar en caché más de un servicio; un ejemplo común es un proxy inverso como
el calamar o el barniz, que se puede almacenar en caché todo el tráfico HTTP. Tener
un proxy entre el cliente y el servidor sí introduce saltos de red adicionales, aunque
en mi experiencia, es muy raro que esto causa problemas, como las optimizaciones
DESEMPEÑO resultantes de la misma almacenamiento en caché superan a los costes
adicionales de la red.
Con el almacenamiento en caché del lado del servidor, todo es opaco a los clientes;
que no es necesario que preocuparse de nada. Con una memoria caché cerca o dentro
de un límite de servicio, puede ser más fácil de razonar acerca de cosas como la
invalidación de los datos, o hacer un seguimiento y optimizar aciertos de caché. En
una situación en la que tiene varios tipos de clientes, una memoria caché del lado del
servidor podría ser la manera más rápida para mejorar el rendimiento.
Para cada sitio web de cara al público que he trabajado, hemos acabado haciendo una
mezcla de los tres enfoques. Pero para más de un sistema distribuido, he salido con
ningún almacenamiento en caché en absoluto. Pero todo se reduce a saber lo que la
carga que necesita para manejar, la frescura de sus datos tiene que ser, y lo que su
sistema puede hacer en este momento. Saber que tiene un número de diferentes
herramientas a su disposición es sólo el principio.
El
almacenamiento
en caché | 227
El almacenamiento en caché de HTTP
HTTP proporciona algunos controles muy útiles para ayudarnos a almacenamos en
caché ya sea en el lado del cliente o del lado del servidor, que son vale la pena
entender, incluso si no está utilizando HTTP en sí.
228| Capítulo 11: microservicios a escala
En primer lugar, con HTTP, podemos utilizar las directivas de control de caché en
nuestras respuestas a los clientes. Indican a los clientes si se debe almacenar en caché
el recurso en absoluto, y si es así cuánto tiempo deben almacenar en caché para que
en cuestión de segundos. También tenemos la opción de establecer un Expira
cabecera, donde en lugar de decir cuánto tiempo una parte del contenido puede ser
almacenado en caché para, especificamos una hora y fecha en la que un recurso debe
considerarse obsoleta y fue a buscar de nuevo. La naturaleza de los recursos que está
compartiendo determina cuál es la más probable para adaptarse. contenido del sitio
web estática estándar como CSS o imágenes menudo encaja bien con un simple
control de tiempo Cache de vida (TTL). Por otro lado, si usted sabe de antemano
cuándo se actualizará una nueva versión de un recurso, el establecimiento de un
Expira cabecera tendrá más sentido.
Aparte de Cache-Control y expira, tenemos otra opción en nuestro arsenal de
golosinas http: Entidad Etiquetas o ETags. Un ETag se utiliza para determinar si el
valor de un recurso ha cambiado. Si puedo actualizar un registro de cliente, el URI
para el recurso es el mismo, pero el valor es diferente, por lo que se puede esperar la
ETag para cambiar. Esto se convierte en poderoso cuando estamos usando lo que se
llama un GET condicional. Al hacer una petición GET, podemos especificar
cabeceras adicionales, contando el servicio para enviar el recurso sólo si se cumplen
ciertos criterios.
Por ejemplo, imaginemos que nos trae un registro de clientes, y su ETag va
recuperando a medida o5t6fkd2sa. Más adelante, tal vez debido a una directiva de
control de caché nos ha dicho el recurso debe considerarse rancio, queremos
asegurarnos de obtener la última versión. Al emitir la solicitud GET posterior,
podemos pasar en un If-None-Match: o5t6fkd2sa. Esto le dice al servidor que
queremos que el recurso en el URI especificado, a menos que ya coincide con este
valor ETag. Si ya tenemos la versión actualizada, el servicio nos envía una respuesta
304 no modificado, que nos dice que tenemos la última versión. Si hay una nueva
versión disponible, se obtiene un 200 OK con el recurso cambiado, y un nuevo ETag
del recurso.
El hecho de que estos controles están integrados en dicha especificación ampliamente
utilizados como medio de llegar a tomar ventaja de una gran cantidad de software
pre-existente que maneja el almacenamiento en caché para nosotros. proxies inversos
como el calamar o el barniz pueden sentarse de forma transparente en la red entre el
cliente y el servidor, almacenamiento y terminaría contenido almacenado en caché
según sea necesario. Estos sistemas están orientados hacia el servicio a un gran
número de solicitudes simultáneas muy rápido, y son una manera de escalar Dard
Están- sitios web de cara al público. CDN como CloudFront de AWS o Akamai
pueden asegurar que las peticiones son redirigidas a cachés cerca del cliente que
llama, asegurándose de que el tráfico no va a mitad de camino alrededor del mundo
cuando se necesita. Y más prosaicamente, bibliotecas de cliente HTTP y cachés
cliente pueden manejar una gran cantidad de este trabajo para nosotros.
El
almacenamiento
en caché | 229
ETags, Expira, y Cache-Control puede solapar un poco, y si no se tiene
cuidado puede llegar a dar información contradictoria si decide utilizar
todos ellos! Para una discusión más a fondo de los varios méritos, echar
un vistazo al libroDescansar en la Práctica
230| Capítulo 11: microservicios a escala
(O'Reilly) o sección de lectura 13 de la HTTP especificación 1.1, Que describe cómo
se supone que tanto los clientes como los servidores para poner en práctica estos
diversos controles.
Ya sea que decida utilizar HTTP como protocolo entre los servicios, el
almacenamiento en caché en el cliente y reducir la necesidad de viajes ida y vuelta al
cliente es bien vale la pena. Si decide elegir un protocolo diferente, comprender
cuándo y cómo se puede proporcionar pistas a la ent CLI- para ayudar a entender
cuánto tiempo se puede almacenar en caché para.
El almacenamiento en caché para escrituras
Aunque se encontrará utilizar la caché para lecturas más a menudo, hay algunos
casos de uso en el almacenamiento en caché de escritura tiene sentido. Por ejemplo,
si hace uso de las rebajas de valor detrás de caché, se puede escribir en una caché
local, y en algún momento más tarde, los datos se vaciarán a una fuente de aguas
abajo, probablemente la fuente canónica de datos. Esto puede ser útil cuando se tiene
estallidos de las escrituras, o cuando hay una buena probabilidad de que los mismos
datos se escribirán en múltiples ocasiones. Cuando se utiliza para amortiguar y
potencialmente lotes escribe, cachés de escritura en segundo puede ser una
optimización del rendimiento más útil.
Con una memoria caché de escritura en segundo, si las escrituras son adecuadamente
tamponadas persistente, incluso si el servicio no está disponible aguas abajo que
podríamos poner en cola las escrituras y enviarlos a través cuando esté disponible de
nuevo.
El almacenamiento en caché de resiliencia
El almacenamiento en caché se puede utilizar para poner en práctica la resistencia en
caso de fallo. Con el lado del cliente ING cach-, si el servicio de aguas abajo no está
disponible, el cliente podría decidir simplemente utilizar los datos en caché, pero
potencialmente obsoletos. También podríamos usar algo como un proxy inverso para
servir datos obsoletos. Para algunos sistemas, estando disponible incluso con datos
obsoletos es mejor que no devolver un resultado en absoluto, sino que es una
cuestión de criterio que tendrá que realizar. Obviamente, si no tenemos los datos
solicitados en la memoria caché, entonces no podemos hacer mucho para ayudar,
pero hay maneras de mitigar esto.
Una técnica que vi utilizado en el Guardian, y posteriormente en otro lugar, era para
rastrear el sitio vivo existente periódicamente para generar una versión estática de la
página web que se podría servir en caso de un corte de luz. Aunque esta versión se
arrastró no era tan fresco como el contenido almacenado en caché sirve desde el
sistema en vivo, en caso de apuro que podría asegurar que una versión del sitio
conseguiría que se muestra.
El
almacenamiento
en caché | 231
Ocultar el origen
Con una caché normal, Si la solicitud se traduce en una pérdida de caché, la solicitud
pasa al origen en busca de los nuevos datos con el bloqueo de llamadas, a la espera
del resultado. En el curso normal de las cosas, esto es de esperar. Pero si sufrimos un
fallo masivo caché, tal vez porque una máquina completa (o grupo de máquinas) que
proporcionan nuestra caché fallan, un gran número de solicitudes golpeará el origen.
232| Capítulo 11: microservicios a escala
Para aquellos servicios que sirven de datos altamente cachable, es común que el
origen en sí a ser escalado para manejar sólo una fracción del total del tráfico, como
la mayoría de las peticiones que nos sirvieran de memoria por los cachés que se
sientan delante del origen. Si de repente tenemos una tormenta Se manada debido a
toda una región de caché de fuga, nuestro origen podría ser golpeado fuera de la
existencia.
Una forma de proteger el origen de esta situación es no permitir nunca que las
solicitudes para ir al origen en el primer lugar. En su lugar, el origen en sí llena el
caché asynchro- nously cuando sea necesario, como se muestra enFigura 11-7. Si se
produce un fallo de caché, lo que desencadena un evento que el origen puede recoger
en, alertando que necesita para repoblar la caché. Así que si todo un fragmento ha
desaparecido, podemos reconstruir la memoria caché en el fondo. Podríamos decidir
bloquear la solicitud original a la espera de la región a ser repoblación ted, pero esto
podría causar la contención en el propio caché, lo que lleva a más problemas. Es más
probable si estamos dando prioridad mantener estable el sistema que queremos fallar
la solicitud original, pero fallaría rápido.
Figura 11-7. Ocultar el origen del cliente y poblar la memoria caché de forma
asíncrona
Este tipo de enfoque puede no tener sentido para algunas situaciones, pero puede ser
una manera de asegurar que el sistema se mantiene cuando partes de ella fallan. Al
no deseos de manera rápida y fin de • asegurar que no tomamos los recursos o
aumentar la latencia, evitamos un fallo en nuestra caché de cascada aguas abajo y nos
damos la oportunidad de recuperarse.
Mantenlo simple
Tenga cuidado con el almacenamiento en caché en demasiados lugares! Las cachés
más entre usted y la fuente de los datos frescos, más rancio los datos pueden ser, y la
más difícil que puede ser para deter- minar la frescura de los datos que un cliente ve
con el tiempo. Esto puede ser especialmente problemático con una arquitectura
microService donde tiene muchos servicios que intervienen en una cadena de
El
almacenamiento
en caché | 233
llamadas. Una vez más, el almacenamiento en caché más tienes, más difícil será
evaluar la frescura de cualquier pedazo de datos. Así que si usted piensa que una
memoria caché es una buena idea, que sea sencillo, se adhieren a uno, y pensar
cuidadosamente antes de añadir más!
234| Capítulo 11: microservicios a escala
El envenenamiento de la caché: un cuento aleccionador
Con almacenamiento en caché a menudo pensamos que si lo hacemos mal lo peor
que puede suceder es que servimos datos antiguos para un poco. ¿Pero qué sucede si
al final sirviendo datos obsoletos para- siempre? Antes he mencionado el proyecto
trabajé en donde estábamos usando una aplicación estrangulador para ayudar a
interceptar llamadas a múltiples sistemas heredados con una vista del recuento
incremen- retirarlos. Nuestra aplicación opera efectivamente como un proxy. El
tráfico a nuestra solicitud se enruta a través de la aplicación heredada. En el camino
de vuelta, hicimos algunas cosas de limpieza; por ejemplo, nos aseguramos de que
los resultados de la aplicación heredada tenían cabeceras de caché HTTP propio
aplicado.
Un día, poco después de la liberación rutina normal, algo extraño comenzó a suceder.
Un error había sido introducida por el que un pequeño subconjunto de páginas
estaban cayendo a través de una condición lógica en nuestro código de inserción de
cabecera caché, lo que resulta en nosotros no cambiar la cabecera en absoluto. Por
desgracia, esta aplicación aguas abajo también había sido cambiado en algún
momento con anterioridad incluir un Expira: Nunca cabecera HTTP. Esto no había
tenido ningún efecto anterior, ya que estábamos preponderantes con esta cabecera.
Ahora no estábamos.
Nuestra aplicación hace un uso intensivo de calamar para almacenar en caché el
tráfico HTTP, y nos dimos cuenta el problema con bastante rapidez, ya que
estábamos viendo más solicitudes sin pasar por sí calamar para golpear nuestros
servidores de aplicaciones. Hemos fijado el código de cabecera caché y empujó un
comunicado, y también borrar manualmente la región correspondiente de la caché de
Squid. Sin embargo, eso no fue suficiente.
Como he mencionado anteriormente, se puede almacenar en caché en múltiples
lugares. Cuando se trata de servir a contenido a los usuarios de una aplicación web
orientada al público, se pueden tener varias cachés entre usted y su cliente. No sólo
puede usted estar al frente de su sitio web con algo así como un CDN, pero algunos
proveedores de Internet hacen uso de almacenamiento en caché. Se puede controlar
esos cachés? E incluso si se pudiera, hay una caché que tiene poco control sobre: la
memoria caché en el navegador del usuario.
Esas páginas con Expira: Nunca atrapados en las cachés de muchos de nuestros
usuarios, y que nunca se invaliden hasta que la caché se ha llenado o el usuario las
limpiado manualmente. Es evidente que no podríamos hacer cualquiera cosa suceda;
nuestra única opción era cambiar las URL de estas páginas para que se re-cargada.
El almacenamiento en caché puede ser muy poderoso, pero hay que entender la ruta
completa de datos que se almacena en caché del origen al destino para apreciar su
complejidad y lo que puede ir mal.
230 | Capítulo 11: microservicios a escala
autoscaling
Si tienes la suerte de tener el aprovisionamiento completamente automatizados de
hosts virtuales, y puede automatizar completamente el despliegue de las instancias
MICROSERVICE, entonces usted tiene los bloques de construcción que permitan
aplicar una escala automática sus microservicios.
autoscaling | 231
Por ejemplo, usted podría también tener la escala provocada por las tendencias
conocidas. Es posible saber que la carga máxima del sistema está entre 9 am y 5 pm,
de modo que aparezca instancias adicionales a las 8:45 am, y apagarlos a las 5:15
pm. Si usted está usando algo como AWS (que tiene muy buen soporte para
AutoScaling incorporada), la desactivación de los casos no es necesario por más
tiempo le ayudará a ahorrar dinero. Que necesita los datos para entender cómo su
carga cambia con el tiempo, de día a día, semana a semana. Algunas empresas tienen
ciclos estacionales obvias también, así que es posible que necesite los datos que se
remontan una manera justa para hacer llamadas de juicio adecuados.
Por otra parte, usted podría ser reactivo, con lo que las instancias adicionales cuando
se ve un aumento en la carga o un fallo de instancia y eliminar instancias cuando ya
no los necesitaba. Sabiendo lo rápido que puede escalar hasta una vez a detectar una
tendencia al alza es la clave. Si sabe que sólo obtendrá un par de minutos de
antelación acerca de un aumento de la carga, pero la ampliación va a tomar por lo
menos 10 minutos, se sabe que necesitará para mantener una capacidad extra en
torno a llenar este vacío. Tener un buen conjunto de pruebas de carga es casi esencial
aquí. Usted las puede utilizar para probar sus reglas AutoScaling. Si usted no tiene
pruebas que pueden reproducir diferentes cargas que activarán escalado, entonces
sólo se va a encontrar en la producción si tienes las reglas equivocadas. Y las
consecuencias del fracaso no son grandes!
Un sitio de noticias es un gran ejemplo de un tipo de negocio donde es posible que
desee una mezcla de escalamiento predictivo y reactivo. En el último sitio de noticias
que trabajé, vimos muy claras tendencias diarias, con vistas a la escalada de la
mañana a la hora del almuerzo y luego comenzar a declinar. Este patrón se repite día
tras día, con un tráfico menos pronunciada en el fin de semana. Que le dio una
tendencia bastante clara que podría conducir escala proactiva hacia arriba (y abajo)
de los recursos. Por otro lado, una gran noticia provocaría un aumento inesperado,
que requiere más capacidad a menudo corto plazo.
en realidad veo AutoScaling utilizado mucho más para el manejo de la insuficiencia
de instancias que para reaccionar a las condiciones de carga. AWS permite
especificar reglas como “Debe haber por lo menos 5 casos de este grupo,” por lo que
si alguien se sumerge uno nuevo se pone en marcha automáticamente. He visto este
enfoque conduce a un divertido juego de golpe-a-mole cuando alguien se olvida de
apagar la regla y luego intenta acabar con los casos de mantenimiento, sólo para
verlos seguir girando arriba!
Tanto la escala reactiva y predictiva son muy útiles, y puede ayudar a ser mucho más
rentable si usted está utilizando una plataforma que le permite pagar sólo por los
recursos informáticos que utiliza. Pero también requieren una cuidadosa observación
de los datos disponibles para usted. Yo sugeriría el uso automático de escala para las
condiciones de falla primero, mientras que recoja los datos. Una vez que desee iniciar
la ampliación de la carga, asegúrese de que está muy cauteloso acerca de la
expansión demasiado rápido. En la mayoría de las situaciones, tener más potencia de
230 | Capítulo 11: microservicios a escala
cálculo en las manos de lo que necesita es mucho mejor que no tener suficiente!
autoscaling | 231
Teorema de la PAC
Nos gustaría tener todo, pero por desgracia sabemos que no se puede. Y cuando se
trata de sistemas distribuidos como los que construimos utilizando arquitecturas
MICROSERVICE, incluso tenemos una prueba matemática que nos dice que no
podemos. Es posible que así haya escuchado sobre el teorema de la PAC, sobre todo
en las discusiones sobre los méritos de varios tipos diferentes de almacenes de datos.
En su corazón se nos dice que en un sistema distribuido, tenemos tres cosas que
podemos comercio se enfrenten entre sí: la consistencia, la disponibilidad y
tolerancia a la partición. En concreto, el teorema nos dice que tiene que mantener dos
en un modo de fallo.
La consistencia es la característica del sistema por el cual voy a tener la misma
respuesta si voy a múltiples nodos. Disponibilidad significa que cada solicitud recibe
una respuesta. la tolerancia de la partición es la capacidad del sistema para manejar el
hecho de que la comunicación entre las partes que a veces es imposible.
Desde Eric Brewer publicó su conjetura original, la idea ha ganado una prueba de cal
matemáticamente. No voy a sumergirse en las matemáticas de la prueba en sí, ya que
no sólo es esto no ese tipo de libro, pero también puedo garantizar que iba a hacerlo
mal. En su lugar, vamos a utilizar algunos ejemplos prácticos que nos ayudarán a
entender que debajo de todo, la PAC teo rem es una destilación de un conjunto muy
lógica de razonamiento.
hemos Ya hablado de algunas técnicas de escalamiento de base de datos simples.
Vamos a usar uno de estos para sondear las ideas detrás del teorema de CAP.
Imaginemos que nuestro servicio de inventario se despliega a través de dos centros
de datos independientes, como se muestra enFigura 11-8. Copia de nuestra instancia
de servicio en cada centro de datos es una base de datos, y estas dos bases de datos se
comuniquen entre sí para tratar de sincronizar los datos entre ellos. Lee y escribe se
realizan a través del nodo de base de datos local, y la replicación se utiliza para
sincronizar los datos entre los nodos.
Ahora vamos a pensar en lo que sucede cuando algo falla. Imagínese que algo tan
simple como el enlace de red entre los dos centros de datos deja de funcionar. De
sincronía en este punto falla. Escrituras realizadas a la base de datos primaria en DC1
no se propagarán a DC2, y viceversa. La mayoría de las bases de datos que soportan
estas configuraciones también soportan una especie de cola técnica para asegurar que
podemos recuperar de esta sala después del horario, pero lo que sucede en el ínterin?
232| Capítulo 11: microservicios a escala
Figura 11-8. Uso de replicación multiprimary para compartir datos entre dos nodos de
base de datos
La consistencia sacrificar
Vamos Suponemos que no cerramos el servicio de inventario por completo. Si hago
un cambio ahora a los datos en DC1, DC2 en la base de datos no lo ve. Esto significa
que todas las solicitudes hechas a nuestro nodo de inventario en DC2 ver los datos
potencialmente obsoletos. En otras palabras, nuestro sistema está disponible en
ambos nodos que son capaces de servir las peticiones, y hemos mantenido el sistema
funcionando a pesar de la partición, pero hemos perdido la consistencia. Esto a
menudo se llama un sistema de AP. No se quedan con los tres.
Durante esta partición, si mantenemos la aceptación de las escrituras a continuación,
aceptamos el hecho de que en algún momento en el futuro que tienen que volver a
sincronizar. Cuanto más larga sea la partición dura, más difícil que puede llegar a ser
de resincronización.
La realidad es que incluso si no tenemos un fallo en la red entre los nodos de bases
de datos, replicación de datos no es instantáneo. Como mencioné antes, se dice que
están en consonancia eventu- aliado sistemas que están dispuestos a ceder
consistencia para mantener la tolerancia de la partición y la disponibilidad; es decir,
se espera que en algún momento en el futuro que todos los nodos verán los datos
actualizados, pero no va a suceder a la vez por lo que tenemos que vivir con la
posibilidad de que los usuarios ven los datos antiguos.
sacrificar la disponibilidad
¿Qué pasa si tenemos que mantener la consistencia y queremos dejar algo más en su
lugar? Pues bien, para mantener la coherencia, cada nodo de base de datos necesita
Teorema CAP | 233
saber la copia de los datos que tiene es el mismo que el otro nodo de base de datos.
Ahora en la partición, si los datos-
234| Capítulo 11: microservicios a escala
los nodos de base no pueden hablar el uno al otro, no pueden coordinar para asegurar
la consistencia. No somos capaces de garantizar la coherencia, por lo que nuestra
única opción es negarse a responder a la solicitud. En otras palabras, hemos
sacrificado disponibilidad. Nuestro sistema es consistente y partición tolerante, o CP.
En este modo nuestro servicio tendría que encontrar la manera de degradar la
funcionalidad hasta que la partición se curó y los nodos de base de datos puede
volver a sincronizarse.
La consistencia a través de múltiples nodos es muy duro. Hay pocas cosas (quizás
noth- ing) más duros en los sistemas distribuidos. Piensa un momento en ello.
Imagino quiero leer un registro desde el nodo de base de datos local. ¿Cómo sé que
es hasta la fecha? Tengo que ir y pedir el otro nodo. Pero también tengo que pedir
que el nodo base de datos para no permitir que se actualiza mientras que la lectura
completa; en otras palabras, lo que necesito para iniciar una transaccional leer a
través de múltiples nodos de base de datos para asegurar la consistencia. Pero, en
general, la gente no lo lee transaccional, ¿verdad? Debido transaccional lee son
lentos. Requieren cerraduras. Una lectura puede bloquear todo un sistema para arriba.
Todos los sistemas consistentes requieren un cierto nivel de bloqueo para hacer su
trabajo.
Como ya hemos comentado, los sistemas distribuidos tienen que esperar el fracaso.
Considere nuestra transaccional leer a través de un conjunto de nodos consistentes.
Les pido un nodo remoto para bloquear un registro dado, mientras se inicia la lectura.
Que complete la lectura, y pedir al nodo remoto para liberar su bloqueo, pero ahora
no puedo hablar con él. ¿Que pasa ahora? Cerraduras son muy duro para hacerlo bien
incluso en un solo sistema de proceso, y son significativamente más difíciles de las
aplicará también en un sistema distribuido.
Recuerde que cuando hablamos de transacciones distribuidas en Capítulo 5? El hijo
rea- núcleo están desafiando es debido a este problema de garantizar la coherencia a
través de múltiples nodos.
Conseguir la consistencia de varios nodos derecha es tan fuerte que me gustaría
firmemente, sugieren fuertemente que, si lo necesita, no trate de inventar por sí
mismo. En su lugar, elegir un almacén de datos o servicio cerradura que ofrece estas
características. Cónsul, por ejemplo, del que hablaremos en breve, implementa una
tienda de clave / valor fuertemente coherente diseñado para compartir con- figuración
entre varios nodos. Junto con “Los amigos no dejan amigos escribir su propio cripto”
debe ir “Los amigos no dejan que los amigos escriban su propio almacén de datos
coherente distribuida.” Si usted piensa que necesita para escribir su propio almacén
de datos CP, leer todos los documentos sobre el sujeto en primer lugar, a
continuación, obtener un doctorado, y luego mirar hacia adelante a pasar unos años
hacerlo mal. Mientras tanto, voy a utilizar algo fuera de la plataforma que lo hace por
mí, o más probablemente tratando muy duro para construir sistemas de AP,
finalmente, consistentes en su lugar.
Teorema CAP | 235
Sacrificar la tolerancia de reparto?
Nosotros dan a elegir dos, ¿verdad? Así que tenemos nuestro sistema de AP
eventualmente consistentes. Tenemos nuestra consistente, pero difícil de construir y
sistema de escala, CP. ¿Por qué no un sistema de CA? Pues bien, ¿cómo podemos
sacrificar la tolerancia partición? Si nuestro sistema no tiene tolerancia partición,
236| Capítulo 11: microservicios a escala
no se puede ejecutar en una red. En otras palabras, tiene que ser un proceso único que
opera localmente. sistemas de CA no existen en los sistemas distribuidos.
AP o CP?
¿Qué es el adecuado, AP o CP? Bueno, la realidad es que depende. A medida que la
gente la construcción del sistema, sabemos que existe la disyuntiva. Sabemos que los
sistemas de AP escalar más fácilmente y son más fáciles de construir, y sabemos que
un sistema CP requerirá más trabajo debido a los desafíos en el apoyo a la
consistencia distribuida. Pero no podemos entender el impacto comercial de esta
disyuntiva. Para nuestro sistema de inventario, si un registro está actualizado por
cinco minutos, es que está bien? Si la respuesta es sí, un sistema de AP podría ser la
respuesta. Pero ¿qué pasa con el saldo a cabo para un cliente en un banco? ¿Puede ser
fuera de fecha? Sin conocer el contexto en el que se utiliza la operación, no podemos
saber lo que hay que hacer. Conocer el teorema CAP simplemente le ayuda a
comprender que existe esta disyuntiva y qué preguntas hacer.
No es todo o nada
Nuestro sistema en su conjunto no tiene por qué ser de AP o CP. Nuestro catálogo
podría ser AP, ya que no importa demasiado acerca de un registro rancio. Sin
embargo, podemos decidir que nuestro servicio de inventario tiene que ser CP, ya
que no queremos vender un cliente algo que no tenemos y luego tener que
disculparse después.
Pero los servicios individuales ni siquiera necesitan ser CP o AP.
Vamos pensar acerca de nuestro servicio de saldo de puntos, ya que guarda un
registro de la cantidad de puntos Alty loy- nuestros clientes han construido.
Podríamos decidir que no nos importa si el saldo se muestra por un cliente está
demasiado cargado, pero que cuando se trata de la actualización de un equilibrio que
necesitamos que sea consistente para asegurar que los clientes no utilizar más puntos
que tienen disponible. Es esta microService CP, o AP, o se trata de ambas cosas? En
realidad, lo que hemos hecho es empujar las compensaciones de todo el teorema de
CAP a las capacidades de servicio individuales.
Otra complicación es que ni la consistencia ni la disponibilidad es todo o nada.
Muchos sistemas de nosotros un cada vez más matizado disyuntiva permiten. Por
ejemplo, con Cassandra puedo hacer diferentes compensaciones para llamadas
individuales. Así que si necesito estricta coherencia, puedo per- formar una lectura
que bloquea hasta que todas las réplicas han respondido confirmando el valor es
Consistente, o hasta que un quórum específico de réplicas han respondido, o incluso
sólo un único nodo. Obviamente, si puedo bloquear la espera de todas las réplicas
que informe y uno de ellos no está disponible, voy a estar bloqueando desde hace
mucho tiempo. Pero si estoy satisfecho con sólo un simple quórum de nodos
informar, puedo aceptar cierta falta de consistencia para ser menos vulnerables a una
única réplica no esté disponible.
Teorema CAP | 237
Vas a menudo ver mensajes acerca de las personas que baten el teorema CAP. Ellos
no tienen. Lo que han hecho es crear un sistema en el que algunas capacidades son
CP, y algunos son AP. los
238| Capítulo 11: microservicios a escala
prueba matemática detrás del teorema de CAP se mantiene. A pesar de muchos
intentos en la escuela, he aprendido que no laten matemáticas.
Y el mundo real
Mucho de lo que hemos hablado es de los bits electrónicos mundiales y bytes
almacenados en la memoria. Hablamos de la consistencia de una manera casi infantil;
nos imaginamos que dentro del alcance del sistema que hemos creado, podemos
detener el mundo y hacer que todo tenga sentido. Y sin embargo, gran parte de lo que
construimos es sólo un reflejo del mundo real, y no conseguimos controlar eso,
¿verdad?
Vamos revisar nuestro sistema de inventario. Se correlaciona con el mundo real, los
elementos físicos. Llevamos una cuenta en nuestro sistema de cuántos discos que
tenemos. Al comienzo del día, tuvimos 100 copias de donar sangre por los frenos.
Hemos vendido uno. Ahora tenemos 99 copias. Fácil, ¿verdad? Por qué ocurre si
cuando la orden estaba siendo enviado, alguien toca una copia del álbum en el suelo
y que se pisó y roto? ¿Que pasa ahora? Nuestros sistemas dicen que 99, pero hay 98
copias en el estante.
¿Y si nos hizo nuestra AP sistema de inventario en su lugar, y de vez en cuando tenía
que ponerse en contacto con un usuario más adelante y decirle que uno de sus
artículos es en realidad fuera de stock? ¿Sería la peor cosa en el mundo? Sin duda,
sería mucho más fácil de construir, escala, y asegurarse de que es correcta.
Nosotros Hay que reconocer que no importa qué tan consistentes nuestros sistemas
podrían ser en sí y por sí mismos, no puede saber todo lo que sucede, especialmente
cuando estamos manteniendo los registros del mundo real. Esta es una de las
principales razones por las cuales los sistemas de AP terminan siendo la decisión
correcta en muchas situaciones. Aparte de la complejidad de la construcción de CP
sis- TEMS, no pueden solucionar todos nuestros problemas de todos modos.
Descubrimiento de servicio
Una vez que tenga más de unos pocos microservicios por ahí, su atención se dirige
inevitablemente a saber dónde está en la tierra está todo. Tal vez usted quiere saber lo
que se está ejecutando en un entorno determinado para que sepa lo que debe haber un
seguimiento. Tal vez es tan simple como saber dónde está su servicio de cuentas es
para que aquellos que lo utilizan microservicios saben dónde encontrarlo. O tal vez lo
que desea es hacer más fácil para los Ircops desa- en su organización para saber qué
opciones están disponibles APIs para que no reinventar la rueda. En términos
generales, todos estos casos de uso abarca los departamentos de servicio de descubrimiento. Y como siempre con microservicios, tenemos bastantes opciones
diferentes a nuestra disposición para tratar con ella.
Todas las soluciones vamos a ver las cosas de mango en dos partes. En primer lugar,
proporcionan un mecanismo para una instancia registrarse a sí mismo y decir, “Estoy
Teorema CAP | 239
aquí!” En segundo lugar, proporcionan una manera de encontrar el servicio una vez
que se ha registrado. descubrimiento de servicios se vuelve más complicado, sin
embargo, cuando estamos considerando un ambiente donde constantemente estamos
destruyendo
240| Capítulo 11: microservicios a escala
y el despliegue de nuevas instancias de servicios. Idealmente, nos gustaría cualquier
solución que elegimos para hacer frente a esto.
Vamos mirar algunas de las soluciones más comunes para la prestación de servicios y
considerar nuestras opciones.
DNS
Sus agradable para empezar de forma sencilla. DNS nos permite asociar un nombre
con la dirección IP de una o más máquinas. Podríamos decidir, por ejemplo, que
nuestro servicio de cuentas siempre se encuentra en accounts.musiccorp.com.
entonces tendríamos ese punto de entrada para la dirección IP del host que ejecuta
ese servicio, o tal vez tenga que resolver a un equilibrador de carga que está
distribuyendo la carga a través de una serie de casos. Esto significa que tendríamos
que manejar la actualización de estas entradas como parte de la implementación de
nuestro servicio.
Cuando se trata de instancias de un servicio en diferentes entornos, he visto un
dominio de trabajo de la plantilla basada en la convención también. Por ejemplo,
podríamos tener una plantilla define como <servicename> - <ambiente>
.musiccorp.com, que nos da entradas como accounts-uat.musiccorp.com o accountsdev.musiccorp.com.
Una forma más avanzada de manejo de diferentes entornos es tener diferentes
servidores de nombres de dominio para diferentes entornos. Por lo que podría
suponer que accounts.musi- ccorp.com es donde siempre encuentro el servicio de
cuentas, pero podría resolver a diferentes hosts dependiendo de donde hago la
búsqueda. Si ya tiene sus entornos sentados en diferentes segmentos de la red y se
siente cómodo con la gestión de sus propios servidores DNS y las entradas, esto
podría ser una buena solución, pero es mucho trabajo si no está recibiendo otros
beneficios de esta configuración.
DNS tiene una serie de ventajas, siendo la principal que es un estándar tales bien
entendido y bien utilizado que casi cualquier pila de tecnología va a apoyar.
Lamentablemente, si bien existe una serie de servicios para la gestión de DNS dentro
de una organización, algunos de ellos parecen diseñados para un entorno en el que se
trata de hosts de alta desechables, por lo que las entradas de actualización de DNS
algo doloroso. Route53 servicio de Amazon hace un muy buen trabajo de esto, pero
no he visto una opción de auto-organizada que es tan bueno, sin embargo, a pesar de
que (como veremos en breve) Cónsul puede ayudarnos aquí. Aparte de los problemas en la actualización de las entradas de DNS, la especificación de DNS en sí nos
puede causar algunos problemas.
entradas de DNS para los nombres de dominio tienen un tiempo de vida (TTL). Este
es el tiempo que un cliente puede tener en cuenta la entrada fresca. Cuando queremos
cambiar el host al que se refiere el nombre de dominio, actualizar esa entrada, pero
tenemos que asumir que los clientes se aferran a la vieja IP de al menos mientras los
estados TTL. entradas de DNS pueden quedar almacenado en caché en múltiples
lugares (incluso la JVM caché entradas DNS a menos que usted
le indique
Teorema
CAP | 241 lo
contrario), y los más lugares que se almacenan en caché en el más rancio de la
entrada puede ser.
Una forma de solucionar este problema es tener la entrada de nombre de dominio
para su punto de servicio a un equilibrador de carga, que a su vez apunta a las
instancias de su servicio,
Descubrimiento de Servicio | 237
como se muestra en Figura 11-9. Al implementar una nueva instancia, se puede
tomar el viejo fuera de la entrada de equilibrador de carga y añadir el nuevo. Algunas
personas utilizan DNS redondas robining, donde las entradas del DNS a sí mismos se
refieren a un grupo de máquinas. Esta técnica es extremadamente problemático, ya
que el cliente no se podrá ver desde el host subyacente, y por lo tanto no puede parar
fácilmente el enrutamiento del tráfico a uno de los anfitriones en caso de ser enfermo.
Figura 11-9. El uso de DNS para resolver a un equilibrador de carga para evitar
entradas de DNS rancios
Como se ha mencionado, DNS se entiende bien y ampliamente compatible. Pero
tiene uno o dos inconvenientes. Yo sugeriría investiga si se trata de una buena opción
para usted antes de recoger algo más complejo. Para una situación en la que sólo
tiene nodos individuales, teniendo DNS se refieren directamente a los ejércitos es
probablemente muy bien. Pero para aquellas situaciones donde se necesita más de
una instancia de un anfitrión, tienen entradas DNS se resuelven a cargar
equilibradores que pueden manejar poner hosts individuales dentro y fuera de
servicio, según corresponda.
Registros de Servicio dinámicos
Las desventajas de DNS como una manera de encontrar nodos en un entorno
altamente dinámico han dado lugar a una serie de sistemas alternativos, la mayoría de
las cuales implican el servicio tering regis- sí con algún registro central, que a su vez
ofrece la posibilidad de buscar estos servicios mas tarde. A menudo, estos sistemas
hacen más que proporcionar un servicio tración REG y el descubrimiento, que puede
o no puede ser una buena cosa. Se trata de un campo lleno de gente, por lo que sólo
tendremos que mirar algunas opciones para darle un sentido de lo que está
disponible.
Zookeeper
Zookeeper fue desarrollado originalmente como parte del proyecto Hadoop. Se
utiliza para una serie casi desconcertante de casos de uso, incluyendo gestión de la
238| Capítulo 11: microservicios a escala
configuración, los datos nizing sincronizada entre los servicios, elección del líder,
colas de mensajes, y (útil para nosotros) como un servicio de nombres.
Al igual que muchos tipos similares de sistemas, Zookeeper se basa en la ejecución
de un número de nodos en un clúster para proporcionar diversas garantías. Esto
significa que usted debe esperar para Run-
Servicio dinámico Registros | 239
Ning al menos tres nodos Zookeeper. La mayor parte de la inteligencia en Zookeeper
son alrededor de asegurar que los datos se replican de forma segura entre estos
nodos, y que las cosas siguen siendo consistentes cuando los nodos fallan.
A su corazón, Zookeeper ofrece un espacio de nombres jerárquico para almacenar
información. Los clientes pueden insertar nuevos nodos en esta jerarquía, cambiarlos
o consultarlos. ULTERIORES más, pueden agregar relojes de los nodos que se les
diga cuando cambian. Esto significa que podríamos almacenar la información acerca
de dónde se encuentran nuestros servicios en esta estructura, y como un cliente se le
indicará cuándo cambian. Zookeeper se utiliza a menudo como un almacén de
configuración general, por lo que también podría configuración específica del
servicio almacena en el mismo, lo que le permite realizar tareas como cambiar
dinámicamente los niveles de registro o apagar características de un sistema en
funcionamiento. Personalmente, tiendo a alejarse de la utilización de sistemas como
Zookeeper como fuente de configuración, ya que creo que puede hacer más difícil
para razonar acerca del comportamiento de un determinado servicio.
Zookeeper en sí es bastante genérico en lo que ofrece, por lo que se utiliza para
tantos casos de uso. Usted puede pensar que es igual que un árbol replicado de
información que puede ser alertado sobre cuando cambia. Esto significa que por lo
general va a construir cosas en la parte superior de la misma para adaptarse a su caso
en particular. Afortunadamente, existen bibliotecas de cliente para la mayoría de los
idiomas que hay.
En el gran esquema de las cosas, Zookeeper podría considerarse vieja por ahora, y no
nos proporciona la funcionalidad que gran parte de la caja para ayudar con el servicio
de des- cubrimiento en comparación con algunas de las alternativas más recientes.
Dicho esto, sin duda es un hecho comprobado, y ampliamente utilizado. Los
implementos de algoritmos subyacentes del guardián son muy difíciles de conseguir
la derecha. Conozco a un proveedor de base de datos, por ejemplo, que utilizaba sólo
para Zookeeper elección del líder con el fin de garantizar que un nodo primario
consiguió promovido adecuadamente durante las condiciones de falla. El cliente
siente que Zookeeper era demasiado pesado y pasó mucho tiempo limar errores en su
propia implementación de la rithm PAXOS algo- para reemplazar lo hizo Zookeeper.
La gente suele decir que no se debe escribir sus propias bibliotecas de criptografía.
Me extiendo que al decir que no se debe escribir sus propios sistemas de
coordinación dis- tribuido tampoco. Hay mucho que decir sobre el uso de material
existente que simplemente funciona.
Cónsul
Al igual que Zookeeper, Cónsul soporta tanto gestión de la configuración y el
servicio descubrimiento. Pero va más allá de lo Zookeeper en proporcionar más
apoyo para estos casos de uso clave. Por ejemplo, se expone una interfaz HTTP para
el descubrimiento de servicios, y una de las características del asesino del Consul es
que realmente proporciona un servidor DNS de la caja; Específicamente, puede
240| Capítulo 11: microservicios a escala
servir registros SRV, que le permite obtener una IP y puerto para un nombre dado.
Esto significa que si una parte de su sistema utiliza DNS ya y puede soportar los
registros SRV, puede simplemente dejar de Cónsul y empezar a usarlo sin ningún
cambio en su sistema existente.
Servicio dinámico Registros | 239
Cónsul también se basa en otras capacidades que le puede resultar útil, tales como la
capacidad de realizar controles de salud en los nodos. Esto significa que Cónsul bien
podría solapar las capacidades proporcionadas por otras herramientas de monitoreo
dedicados, a pesar de que usaría más probable Cónsul como fuente de esta
información y luego tire de ella en un tablero de instrumentos hensive más
Comprehensive o sistema de alerta. diseño y altamente tolerante a fallos del Cónsul
se centran en sistemas que hacen un uso intensivo de los nodos efímeras hace que me
pregunto, sin embargo, si se puede llegar a la sustitución de sistemas como Nagios y
Sensu para algunos casos de uso manipulación.
Cónsul utiliza una interfaz HTTP REST para todo, desde el registro de un servicio,
consultar el almacén de claves / valor, o la inserción de los controles de salud. Esto
hace que la integración con la tecnología de pilas de diferente muy sencillo. Una de
las otras cosas que me gusta de Cónsul es que el equipo detrás de él se ha dividido el
pedazo ción manage- clúster subyacente. Serf, que Consul se sienta encima de, se
ocupa de la detección de nodos en un cluster, gestión de fallo, y alerta. Cónsul luego
añade el descubrimiento de servicios y la gestión de con- figuración. Esta separación
de las preocupaciones que me atrae, que debería ser ninguna sorpresa para usted dado
los temas que se ejecutan a través de este libro!
Cónsul es muy nuevo, y dada la complejidad de los algoritmos que utiliza, esto
normalmente me haría más reacios en recomendarlo para un trabajo tan importante.
Dicho esto, Hashicorp, el equipo detrás de él, sin duda tiene una gran trayectoria en
la creación de la tecnología de código abierto muy uso- ful (en forma de tanto Packer
y el vagabundo), el proyecto está siendo desarrollado activamente, y he hablado con
un algunas personas que están felices para su uso en la producción. Teniendo en
cuenta que, creo que es bien vale la pena un vistazo.
Eureka
de código abierto de Netflix sistema de Eureka se opone a la tendencia de los
sistemas como cónsul y guardián Zoo- en que no tenga también pretende ser un
almacén de configuración de propósito general. En realidad, es muy específica en su
caso de uso.
Eureka también proporciona capacidades básicas de equilibrio de carga en que pueda
soportar las operaciones de búsqueda básica de round-robin de instancias de servicio.
Proporciona un punto final basada en REST para que pueda escribir sus propios
clientes, o puede utilizar su propio cliente de Java. El cliente Java proporciona
capacidades adicionales, tales como la comprobación de estado de instancias.
Obviamente, si se omite propio cliente de Eureka e ir directamente al extremo REST,
que está en su propia allí.
Al tener los clientes tratan con el descubrimiento de servicios directamente, evitamos
la necesidad de un proceso Separando. Sin embargo, no se requiere que todos los
clientes implementar la detección de servicios. Netflix, que estandariza en la JVM,
logra esto haciendo que todos los clientes utilizan Eureka. Si estás en un entorno más
La documentación de Servicios
| 241
políglota, esto puede ser más de un desafío.
240 | Capítulo 11: microservicios a escala
Rodar su propio
Un método que he utilizado yo mismo y visto hecho en otros lugares es rodar su
propio sistema. En un proyecto que estábamos haciendo un uso intensivo de AWS,
que ofrece la posibilidad de añadir etiquetas a los casos. Al poner en marcha
instancias de servicio, me gustaría aplicar etiquetas para ayudar a definir lo que el
caso era y lo que se utilizó para. Estos permitido para algunos ricos metadatos a estar
asociadas con una serie dada, por ejemplo:
• = cuentas de servicios
• ambiente = producción
• version = 154
entonces podría utilizar las API de AWS para consultar todas las instancias asociadas
con una cuenta de AWS dada para encontrar máquinas que me importaba. Aquí, en sí
AWS está manejando el almacenamiento de los metadatos asociados a cada caso, y
que nos proporciona la capacidad de consultar la misma. a continuación, he
construido herramientas de línea de comandos para interactuar con estos casos, y
haciendo cuadros de mando para la supervisión del estado se vuelve bastante fácil,
especialmente si usted adopta la idea de que cada instancia de servicio exponer
detalles de comprobación de estado.
La última vez que hice esto, no fue tan lejos como que tienen servicios utilizan las
API de AWS para encontrar sus dependencias de servicio, pero no hay ninguna razón
por la que no podía. Obviamente, si desea los servicios de aguas arriba para recibir
una alerta cuando la ubicación de un río abajo cambios en el servicio, que está en su
propia.
No se olvide de los seres humanos!
Los sistemas que hemos visto hasta el momento hacen que sea fácil para una
instancia de servicio para registrarse a sí mismo y buscar otros servicios que
necesita para hablar. Pero a medida que los seres humanos que a veces desea que
esta información también. Cualquiera sea el sistema que elija, asegúrese de que
tiene las herramientas disponibles que le permiten crear informes y cuadros de
mando en la parte superior de estos registros para crear pantallas para los seres
humanos, no sólo para las computadoras.
Documentación de Servicios
Al descomponer nuestros sistemas en microservicios de grano más fino, estamos
esperando para exponer una gran cantidad de costuras en forma de API que la gente
puede utilizar para hacer muchas, es de esperar de maravillas ful, las cosas. Si usted
recibe su derecho de descubrimiento, sabemos dónde están las cosas. Pero, ¿cómo
La documentación de Servicios
| 241
sabemos lo que hacen esas cosas, o cómo usarlos? Una opción es obviamente tener
documenta- ción acerca de las API. Por supuesto, la documentación a menudo puede
estar fuera de fecha. Lo ideal aliado, nos aseguramos de que nuestra documentación
está siempre al día con la API microService, y es más fácil ver esta documentación
cuando sabemos que un End-servicio
240 | Capítulo 11: microservicios a escala
punto es. Dos piezas diferentes de la tecnología, Swagger y HAL, tratan de hacer de
esto una realidad, y ambos son vale la pena mirar.
Pavonearse
Swagger le permite describir su API a fin de generar una muy buena interfaz de
usuario web que le permite ver la documentación e interactuar con la API a través de
un navegador web. La capacidad de ejecutar solicitudes es muy agradable: puede
definir plantillas de entrada, por ejem- plo, dejando claro qué tipo de contenido que
el servidor espera.
Para hacer todo esto, Swagger necesita el servicio para exponer un archivo sidecar
que coincida con el formato de Swagger. Swagger tiene una serie de bibliotecas de
diferentes lenguajes que lo hace por usted. Por ejemplo, para Java puede anotar
métodos que responden a las llamadas de la API, y el archivo se genera para usted.
Me gusta la experiencia del usuario final de que Swagger le da, pero hace poco para
el concepto de exploración incrementales en el corazón de hipermedia. Aún así, es
una forma bastante agradable para exponer la documentación sobre sus servicios.
HAL y el navegador HAL
Por sí mismo, el Idioma de la aplicación de hipertexto (HAL) es un estándar que
describe las normas para los controles de hipermedia que nos exponemos. Como ya
vimos enCapítulo 4, Controles hipermedia son los medios por los cuales permiten a
los clientes explorar progresivamente nuestras APIs para utilizar las capacidades de
nuestros servicios de una manera menos junto a otras técnicas de inte- gración. Si
decide adoptar el estándar hipermedia de HAL, entonces no sólo se puede hacer uso
de una amplia serie de bibliotecas de cliente para el consumo de la API (en el
momento de la escritura, el HAL wiki de la lista 50 librerías de soporte para un
número de diferentes lenguajes) , pero también se puede hacer uso del navegador de
HAL, que le da una forma de explorar la API a través de un navegador web.
Al igual que Swagger, esta interfaz de usuario se puede utilizar no sólo para actuar
como documentación de la vida, sino también para ejecutar llamadas contra el propio
servicio. La ejecución de las llamadas no es tan resbaladiza, sin embargo. Mientras
que con Swagger se puede definir plantillas para hacer cosas como tema una solicitud
POST, con HAL es más por su cuenta. La otra cara de esto es que el poder inherente
de los controles hipermedia le permite explorar mucho más efectiva la API expuesta
por el servicio, como se puede seguir enlaces de todo muy fácilmente. Resulta que
los navegadores web son bastante bueno en ese tipo de cosas!
A diferencia de la fanfarronería, toda la información necesaria para conducir esta
documentación y caja de arena está incrustado en los controles hipermedia. Esta es
una espada de doble filo. Si ya está utilizando controles hipermedia, se necesita poco
esfuerzo para exponer un navegador HAL y tienen los clientes a explorar su API. Sin
embargo, si usted no está utilizando hipermedia, que o bien no se puede usar HAL o
242| Capítulo 11: microservicios a escala
tienen que adaptar su API para utilizar hipermedia, que es probable que sea un
ejercicio que rompe los consumidores existentes.
La auto-describen Sistema | 243
El hecho de que HAL también describe un estándar hipermedia con algunas
bibliotecas de cliente de soporte es una ventaja añadida, y sospecho que es una gran
razón por la que he visto más captación de HAL como una forma de documentar las
API de Swagger para aquellas personas que ya utilizan controles hipermedia . Si está
utilizando hipermedia, mi recomendación es ir con HAL sobre Swagger. Pero si
usted está utilizando hipermedia y no puede justificar el cambio, me def- initely
sugieren dar Swagger una oportunidad.
El sistema de auto-Describiendo
Durante la evolución temprana de SOA, normas como Universal Description,
Discovery and Integration (UDDI) surgió para ayudar a la gente a dar sentido a lo
que los servicios estaban funcionando. Estos enfoques eran bastante pesado, lo que
llevó a ques técnicamente alternativas para tratar de dar sentido a nuestros sistemas.
Martin Fowler discutió el concepto de laregistro humana, Donde un enfoque mucho
más ligero es simplemente tener un lugar donde los seres humanos pueden registrar
información acerca de los servicios de la organización en algo tan básico como un
wiki.
Obtener una imagen de nuestro sistema y cómo se está comportando es importante,
sobre todo cuando estamos en escala. Hemos cubierto una serie de diferentes técnicas
que nos ayudarán a ganar la comprensión directa de nuestro sistema. Mediante el
seguimiento de la salud de nuestros servicios derivados, junto con los ID de
correlación para ayudarnos a ver cadenas de llamadas, podemos obtener datos reales
en términos de cómo se interrelacionan nuestros servicios. El uso de los sistemas de
descubrimiento de servicios como cónsul, podemos ver donde se están ejecutando
nuestros microservicios. HAL nos permite ver qué capacidades están siendo alojados
en cualquier punto final determinado, mientras que nuestras páginas de
comprobación de la salud y sistemas de control nos permiten saber la salud de todo el
sistema y los servicios individuales.
Toda esta información se encuentra disponible mediante programación. Todos estos
datos nos permite hacer nuestro registro humano más poderoso que una simple
página wiki que, sin duda, salir de la fecha. En cambio, debemos usarlo para
aprovechar y mostrar toda la información de nuestro sistema se emite. Mediante la
creación de cuadros de mando personalizados, podemos reunir la gran cantidad de
información que está disponible para ayudarnos a dar sentido a nuestro ecosistema.
Por todos los medios, comenzar con algo tan simple como una página web estática o
wiki que quizás rasguños en un bit de datos desde el sistema en vivo. Pero mira para
tirar en más y más infor- mación con el tiempo. Hacer esta información disponible es
una herramienta clave para la gestión de la complejidad emergente que vendrá de la
ejecución de estos sistemas a gran escala.
Resumen
244| Capítulo 11: microservicios a escala
Como un enfoque de diseño, microservicios son todavía bastante joven, por lo que
aunque tenemos algunas experiencias notables que apoyarse, estoy seguro de que los
próximos años van a producir patrones más útiles en el manejo de ellos a escala. No
obstante, espero que este capítulo se han esbozado algunos pasos que puede seguir en
su viaje a microservicios en la escala que usted tiene en una buena posición.
La auto-describen Sistema | 243
Además de lo que he tratado aquí, recomiendo el excelente libro de lanzamiento de
Michael Nygard It !. En él comparte una colección de historias sobre el fracaso del
sistema y algunos patrones para ayudar a lidiar con él también. El libro está bien vale
la pena leer (de hecho, me gustaría ir tan lejos como para decir que se debe
considerar una lectura esencial para cualquier persona la construcción de sistemas a
escala).
Hemos cubierto un buen montón de tierra, y estamos llegando al final. En nuestro
próximo y último capítulo, vamos a ver a tirar todo de nuevo juntos y resumir lo que
hemos aprendido en el libro general.
246| Capítulo 11: microservicios a escala
CAPÍTULO 12
Uniendo fuerzas
hemos cubierto una buena cantidad en los capítulos anteriores, de lo microservicios
son a la manera de definir sus límites, ya partir de la tecnología de integración a las
preocupaciones sobre la seguridad y la vigilancia. E incluso nos encontramos tiempo
para averiguar cómo el papel del arquitecto encaja. Hay mucho para tomar, ya que
aunque microservicios sí mismos pueden ser pequeños, la amplitud y el impacto de
su arquitectura no son. Así que aquí voy a tratar de summa- Rize algunos de los
puntos clave a lo largo del libro.
Principios de microservicios
Nosotros discutido el papel que pueden desempeñar en principios Capitulo 2. Son
declaraciones acerca de cómo deben hacerse las cosas, y por eso creemos que se debe
hacer de esa manera. Nos ayudan a enmarcar las diversas decisiones que tenemos que
hacer en la construcción de nuestros siste- mas. Debe definir absolutamente sus
propios principios, pero pensé que vale la pena spell- ing lo que veo como los
principios fundamentales para arquitecturas MICROSERVICE, que se puede ver que
se resumen enFigura 12-1. Estos son los principios que nos ayudarán crea- comía
pequeños servicios autónomos que trabajan bien juntos. Ya hemos cubierto everycosa aquí al menos una vez hasta ahora, por lo que nada debe ser nueva, pero hay un
valor en la destilación se reduce a su esencia central.
Puede optar por adoptar estos principios al por mayor, o tal vez ajustar a tener
sentido en su propia organización. Pero tenga en cuenta el valor que viene de su uso
en combinación: el conjunto debe ser mayor que la suma de las partes. Así que si
usted decide dejar caer uno de ellos, asegúrese de que entiende lo que se le echa en
falta.
Para cada uno de estos principios, he tratado de sacar algunas de las prácticas de
apoyo que hemos cubierto en el libro. Como se suele decir, hay más de una manera
de pelar un gato: es posible encontrar sus propias prácticas para ayudar a entregar en
246 | Capítulo 12: Uniendo fuerzas
estos principios, pero esto debe empezar.
245
Figura 12-1. Principios de microservicios
Modelo de negocio en torno a conceptos
La experiencia nos ha demostrado que las interfaces estructuradas en torno a los
contextos de negocio-delimitada son más estables que los estructurada en torno a los
conceptos técnicos. Al modelar el dominio en el que opera nuestro sistema, no sólo
se intenta formar las interfaces ble más Sta, sino que también nos aseguramos de que
estamos en mejores condiciones para reflejar los cambios en los procesos de negocio
con facilidad. Utilizar contextos acotados para definir posibles límites del dominio.
Adoptar una cultura de Automatización
Microservicios añadir un montón de complejidad, una parte clave de la que proviene
de la gran nú- mero de piezas que tenemos que tratar con el movimiento. Adoptar
una cultura de la automatización es una forma clave para hacer frente a esto, y el
esfuerzo de carga frontal para crear las herramientas para apoyar microservicios
pueden hacer mucho sentido. Las pruebas automatizadas es esencial, ya que garantiza
nuestros servicios siguen funcionando es un proceso más complejo que con los
sistemas monolíticos. Tener una llamada de línea de comandos uniformes para
desplegar la misma manera en todas partes puede ayudar, y esto puede ser una parte
clave de la adopción de la entrega continua para darnos retroalimentación rápida de
la calidad pro- ducción de cada registro de entrada.
Considere el uso de definiciones de entornos para ayudarle a especificar las
diferencias de un ambiente a otro, sin sacrificar la capacidad de utilizar un método de
implementación uniforme. Pensar en crear imágenes personalizadas para acelerar el
despliegue, y abrazando la creación de servidores inmutables totalmente
automatizadas para que sea más fácil para razonar acerca de sus sistemas.
246 | Capítulo 12: Uniendo fuerzas
Ocultar internos Detalles de la implementación
A maximizar la capacidad de un servicio a evolucionar de forma independiente de
cualquier otro, es vital que nos ocultan detalles de implementación. Modelado
delimitada contextos pueden ayudar, ya que esto ayuda a centrarnos en aquellos
modelos que deben ser compartidos, y los que deben ser den HID-. Los servicios
también deben ocultar sus bases de datos para evitar caer en uno de los géneros más
comunes de acoplamiento que pueden aparecer en arquitecturas orientadas a
servicios tradicionales, y utilizar los datos bombas o datos de eventos para consolidar
los datos a través de múltiples servicios para los informes.
Siempre que sea posible, recoger las API independiente de la tecnología para darle la
libertad de utilizar diferentes pilas de tecnología. Considere el uso de REST, que
formaliza la separación de datos internos y externos de implementación, aunque
incluso si el uso de las llamadas a procedimiento remoto (RPC), todavía se puede
abrazar estas ideas.
Descentralizar todas las cosas
A maximizar la autonomía que microservicios hacen posible, tenemos que estar
buscando constantemente la posibilidad de delegar la toma de decisiones y el control
de los equipos que poseen los servicios mismos. Este proceso se inicia con abrazar
auto-servicio siempre que sea posible, permitiendo a la gente para desplegar software
en la demanda, por lo que el desarrollo y las pruebas lo más fácil posible, y evitar la
necesidad de equipos separados para llevar a cabo estas actividades.
Asegurar que los equipos son dueños de sus servicios es un paso importante en este
viaje, por lo que los equipos responsables de los cambios que se realizan, a ser
posible incluso hacer que decidan cuándo liberar esos cambios. Haciendo uso de
código abierto interno asegura que las personas pueden hacer cambios en los
servicios de propiedad de otros equipos, aunque recuerda que esto requiere un trabajo
de implementar. Alinear los equipos a la organización para asegurar que la ley de
Conway funciona para usted, y ayudar a su equipo a ser expertos en el dominio de los
servicios de negocios-centrado que están creando. Cuando se necesita alguna
orientación general, tratar de adoptar un modelo de gobierno compartido en el que las
personas de cada equipo comparten colectivamente la responsabilidad de la
evolución de la visión técnica del sistema.
Este principio se puede aplicar a la arquitectura también. Evitar los enfoques como
los sistemas de bus de servicios empresariales o de orquestación, que pueden
conducir a la centralización de la lógica de negocios y servicios mudos. En su lugar,
prefieren coreografía sobre orquestación y middleware mudo, con puntos finales
inteligentes para asegurar que se mantiene la lógica y los datos asociados dentro de
los límites del servicio, lo que ayuda a mantener las cosas cohesiva.
Principios de microservicios | 247
independientemente Deployable
Siempre debemos tratar de asegurar que nuestros microservicios pueden y se
despliegan por sí mismos. Incluso cuando se requieren cambios de última hora,
debemos tratar de coexistir puntos finales ver- Sioned para permitir a nuestros
consumidores cambian con el tiempo. Esto nos permite opti- mizar para la velocidad
de liberación de nuevas características, así como el aumento de la autonomía de los
equipos con estos microservicios asegurándose de que no tienen que orquestar
constantemente sus despliegues. Cuando se utiliza la integración basada en RPC,
evitar la generación de resguardo del cliente / servidor fuertemente unido, como la
promovida por RMI de Java.
Mediante la adopción de un modelo de un servicio-per-host, se reducen los efectos
secundarios que podrían hacer que el despliegue de un servicio a impactar otro
servicio relacionado. Considere el uso de técnicas de liberación azules / verdes o
canario para separar el despliegue de la liberación, lo que reduce el riesgo de un
comunicado que va mal. Utilizar los contratos de consumo impulsado a coger los
cambios de última hora antes de que sucedan.
Recuerde que debe ser la norma, no la excepción, que se puede realizar un cambio en
un solo servicio y lo liberan en la producción, sin tener que implementar cualquier
otro servicio en el bloqueo de paso. Sus consumidores deben decidir cuando se ponen
al día, y hay que adaptarse a este.
aislar fracaso
Una arquitectura microService puede ser más resistente de lo que un sistema
monolítico, pero sólo si entendemos y un plan para fallos en parte de nuestro sistema.
Si no tenemos en cuenta el hecho de que una llamada aguas abajo puede y va a fallar,
nuestros sistemas pueden sufrir fallos en cascada catastrófica, y podríamos
encontrarnos con un sistema que es mucho más frágil que antes.
Cuando se utilizan las llamadas de red, no se trate llamadas remotas como las
llamadas locales, ya que esto ocultará dife- rentes tipos de modo de fallo. Así que
asegúrese de que si usted está utilizando bibliotecas de cliente que la abstracción de
la llamada remota no ir demasiado lejos.
Si mantenemos los principios de antifragility en mente, y esperamos que el fracaso se
producirá en cualquier lugar y en todas partes, estamos en el camino correcto.
Asegúrese de que sus tiempos de espera se establecen apro- tamente. Entender
cuándo y cómo utilizar los mamparos y disyuntores para limitar el otoño-cabo de un
componente que falla. Entender lo que el impacto de cara al cliente será si sólo una
parte del sistema se está comportando mal. Saben cuáles podrían ser las
consecuencias de una partición de la red, y si sacrificar la disponibilidad o la
consistencia en una situa- ción dada es la decisión correcta.
248 | Capítulo 12: Uniendo fuerzas
altamente observable
Nosotros no puede basarse en la observación del comportamiento de una sola instancia
de servicio o el estado de una sola máquina para ver si el sistema está funcionando
correctamente. En su lugar, necesitamos una vista de unión en marcha de lo que está
sucediendo. Utilizar la supervisión semántica para ver si el sistema se está
comportando correctamente, mediante la inyección de transacciones sintéticas en su
sistema para simular el comportamiento del usuario real. Agregar sus registros, y
agregar sus estadísticas, de modo que cuando usted ve un problema se puede
desglosar a la fuente. Y cuando se trata de reproducir problemas desagradables o
simplemente ver cómo el sistema está interactuando en la producción, utilizar los ID
de correlación que permitirá rastrear llamadas a través del sistema.
Cuando no hay que usar microservicios?
A menudo recibo esta pregunta. Mi primer consejo sería que el menos bien a
entender un dominio, más difícil será para usted para encontrar contextos adecuada
delimitadas por sus servicios. Como hemos comentado anteriormente, obtener los
límites de servicio incorrecto puede dar lugar a tener que hacer un montón de
cambios en la colaboración en una operación costosa-servicio-servicio. Así que si
usted está viniendo a un sistema monolítico para el que no entiende el dominio, pasa
algún tiempo a aprender lo que hace por primera vez el sistema, y luego mira a
identificar los límites del módulo de limpieza antes de la división a cabo los
servicios.
el desarrollo de Greenfield también es todo un reto. No es sólo que el dominio es
también probable que sea nueva; es que es mucho más fácil trozo algo que tiene que
algo que no! Así que de nuevo, considere comenzar monolítica primera y romper
cosas cuando estás estable.
Muchos de los retos que va a afrontar con microservicios empeoran con la escala. Si
la mayoría de hacer las cosas de forma manual, es posible estar bien con 1 o 2
servicios, sino 5 o 10? Siguiendo con las prácticas de control de edad en el que basta
con ver las estadísticas como la CPU y la memoria del mismo modo podría funcionar
bien para algunos servicios, pero la mayor colaboración-servicio-servicio lo hace, el
más doloroso esto se convertirá. Usted se encontrará golpear estos puntos de dolor a
medida que agrega más servicios, y espero que los consejos de este libro le ayudará a
ver algunos de estos problemas que vienen, y le dará algunos consejos concretos
sobre cómo tratar con ellos. He hablado antes acerca de REA y la cerda joven
tomando un tiempo para construir las herramientas y prácticas para gestionar
microservicios así, antes de poder utilizarlos en cualquier cantidad grande.
Cuando no hay que usar microservicios? | 249
Las palabras de despedida
arquitecturas MICROSERVICE le dan más opciones y más decisiones que tomar.
ING decisiones MAK- en este mundo es una actividad mucho más común que en los
sistemas más simples, monolíticas. Usted no recibirá todas estas decisiones derecha,
puedo garantizar que. Así, sabiendo que vamos a conseguir algunas cosas mal,
¿cuáles son nuestras opciones? Bueno, yo sugeriría encontrar maneras de hacer cada
decisión pequeña en su alcance; de esa manera, si uno se equivoca, sólo se afecta una
pequeña parte de su sistema. Aprender a aceptar el concepto de la arquitectura
Evolución- ary, donde sus curvas del sistema y flexiona y cambia con el tiempo a
medida que aprende cosas nuevas. No pensar en reescrituras big bang, pero en lugar
de una serie de cambios efectuados en el sistema con el tiempo para mantenerla
flexible.
Esperemos que ahora que he compartido con usted suficiente información y
experiencias para ayudar a decidir si microservicios son para usted. Si lo están,
espero que pienses en esto como un ney distas, no un destino. Ir de forma
incremental. Romper su sistema aparte pieza por pieza, aprender sobre la marcha. Y
acostumbrarse a él: en muchos sentidos, la disciplina para cambiar y evolucionar
continuamente nuestros sistemas es una lección mucho más importante aprender que
cualquier otro que he compartido con ustedes a través de este libro. El cambio es
inevitable. Abrázalo.
250 | Capítulo 12: Uniendo fuerzas
Índice
UNA
test de aceptación, 132
Acceso por referencia,
60 responsabilidad,
202
adaptabilidad, 27
proyecto de Egisto, 100
registros de agregados, 158
sistemas antifragile, 1, 210-215
mamparos, 214
rompedores de circuito, 212
ejemplos de, 210
aumento del uso de,
1 aislamiento, 215
desconexión de carga, 215
tiempos de
espera, 211
sistema de AP
definición del término,
233 vs. sistema CP,
235
La autenticación basada en clave de
API, 177, 181
contenedores de aplicaciones, 118
arquitectos (véase arquitectos de
sistemas) principios de la
arquitectura
desarrollo de, 18
12 factores de Heroku, 18
microservicios principios clave,
245 ejemplo del mundo real, 19
la seguridad de arquitectura, 21,
208 artefactos
imágenes, 113
sistema operativo, 110
plataforma específica, 109
colaboración asíncrona
complejidades de, 57
implementar, 55
vs sincrónica, 42
especificación ATOM,
56
autorización de autenticación, 169-180
definición de términos, 169
de grano fino, 172
servicio-servicio, 173
inicio de sesión único
(SSO), 170 inicio de sesión
único de puerta de enlace,
171 terminología, 170
automatización
beneficios para el despliegue,
121 estudios de caso sobre, 122
autonomía
microservicios y, 3
papel de arquitecto de sistemas en,
27 autoscaling, 230
disponibilidad
en PAC teorema, 232
microservicios clave de principio,
207 sacrificar, 233
si
backends para interfaces (BFFs), 72
bombas de datos de copia
de seguridad, 99 copias de
seguridad, encriptación de,
181 / Despliegue verde
azul, 148
cuellos de botella, 196
contextos acotadas
concepto de, 31
módulos y servicios, 33
anidado, 34
la
descomposición
prematura, 33 compartida
frente a los modelos ocultos,
31 diseño del sistema y, 198
251
Guardafrenos,
187 cambios de
ruptura
evitando, 39
difiriendo, 62
detección precoz de,
63 pruebas quebradizas,
140
fragilidad, 47
construcción de tuberías, 107
mamparos, 214
comunicado de servicio añadido,
108 capacidades de negocio, 34
conceptos de negocio, 36
negocio orientado al análisis, 132
C
almacenamiento en caché
beneficios de, 225
fallos de caché, 228
envenenamiento de caché, 230
lado del cliente, 226
para escrituras, 228
en HTTP, 226
apoderado, 226
lado del servidor, 226
canario de liberación, 149
teorema de la PAC, 232-236
sistemas / CP AP, 235
aplicación de, 236
fundamentos de la, 232
sacrificar la disponibilidad, 233
sacrificar la consistencia, 233
sacrificar tolerancia partición, 234
fallos en cascada, 164
gestión de certificados, 175
Caos del gorila, 211
Caos Mono, 211
arquitectura de la coreografía, 45
rompedores de circuito, 22, 212 mixin
circuit_breaker para Ruby, 214
Clase-responsabilidad-colaboración (CRC),
101
certificados de cliente, 175
bibliotecas de cliente, 59
la caché del cliente, 226
la reutilización de código, 59
arquitecto de codificación, 17
cohesión, 2, 30
Pirámide de prueba de Cohn, 132
colaboración, 27
252| Índice
basada en eventos, 43
solicitar respuesta, 42
Responsabilidad de comandos de consulta de
reparto (CQRS), 224
comete, de dos
fases, 92
comunicación
adaptándose a las vías, 193
protocolos para (SOAP), 8
asincrónica vs sincrónica, 42
compensación de transacciones, 91
del composability, 7
deriva configuración, 113
configuración, el servicio,
115 problema adjunto
confusa, 178 consistencia
en PAC teorema, 232
sacrificar, 233
restricciones, 68
Cónsul, 239
contratos dirigido a los consumidores
(CDC), 144-147 red de entrega de
contenidos (CDN), 226 sistemas de
gestión de contenidos (CMS), 75 entrega
continua (CD), 1, 107
integración continua (IC)
básico, 103
Lista de verificación para, 104
mapeo para microservicios, 105
La ley de Conway
evidencia de, 191
en reversa, 201
declaracion de, 191
resumen de, 203
proceso de coordinación, 92
equipo central, 197
CoreOS, 126
ID de correlación, 162
sistema CP, 235
requisitos interfuncionales (CFR), 151, 206
custodios, 197
imágenes personalizadas, 111
Customer Relationship Management (CRM),
76
clientes, interactuar con inscribir a
nuevos clientes, 40, 43
bases de datos compartidas, 41
re
datos
inserción lote de, 96
durabilidad de, 207
253
cifrado de copia de
seguridad, 181 la
recuperación a través de las
llamadas de servicio, 95
asegurar en reposo, 180
(Véase también la
seguridad) compartida, 86
estática compartida, 85
cifrado de datos,
180 bombas de
datos
apoyo, 99
la recuperación de datos a
través de, 96 evento, 98
el uso de serie, 98
descomposición de la base de datos, 82101 romper relaciones de clave
externa, 84 enfoque gradual para, 100
visión general de, 102
bases de datos de refactorización,
89 la selección de puntos de
separación, 82 la selección de
temporización separación, 101
datos compartidos, 86
datos estáticos
compartidos, 85 mesas
compartidas, 87
límites transaccionales, 89
la integración de bases de
datos, 41 escalamiento de
base de datos
La segregación responsabilidad de mando
en consultas (CQRS), 224
para lecturas, 222
para escrituras, 223
la disponibilidad del servicio frente a la
durabilidad de datos, 222 infraestructura
compartida, 224
directrices de toma de decisiones,
17-20 enfoque personalizado
para, 19 prácticas para, 19
principios para, 18
ejemplo del mundo real, 19
metas estratégicas, 18
técnicas descomposicionales
bases de datos (véase la descomposición
de base de datos) la identificación /
contextos de embalaje, 80
módulos, 10
concepto de la costura, 79
la selección de puntos de
separación, 81 la selección de
temporización separación, 101
bibliotecas compartidas, 9
desacoplamiento, 3, 45
funcionalidad degradantes, 207
en la entrega, 196 despliegue
Índice | 253
artefactos, como imágenes,
113 artefactos, sistema
operativo, 110 artefactos,
específicas de la
plataforma, 109
automatización, 121
/ Despliegue verde azul, 148
la construcción de tuberías, 107
comunicado de servicio añadido,
108 conceptos básicos de
integración continua, 103 lista de
comprobación de integración
continua, 104
integración continua en
microservicios, 105
imágenes personalizadas, 111
definición del entorno,
128 ambientes a tener en
cuenta, 114 servidores
inmutables, 113
interfaces, 127
microservicios vs. sistemas monolíticos,
6, 103
visión general de, 130
separarse de liberación, 148
configuración de servicio,
115
enfoque de virtualización, 122
virtualización, hipervisores, 123
254| Índice
virtualización, tradicional, 123
virtualización, tipo 2, 123
problema adjunto, 178
criterios de diseño, 18, 245-249
(Ver también los principios
arquitectónicos) prácticas de diseño /
entrega
desarrollo de, 19
ejemplo del mundo real, 19
servicio de directorio, 170
DiRT (prueba de recuperación de
desastres), 210 sistemas distribuidos
falacias de, 47, 205
promesas clave de,
7
transacciones distribuidas, 92
servicio de DNS, 237
Estibador, 126
documentación
HAL (Hypertext Idioma de la aplicación),
242 importancia de, 241
sistemas auto-descripción, 242
Pavonearse, 242
Diseño guiado por el dominio, 1
Dropwizard, 22
SECO (Do not Repeat
Yourself), 59 tontos, 137
durabilidad, 207
registros de servicios dinámicos
beneficios de,
238
Cónsul, 239
Eureka, 240
lanzamiento,
241
cuidador del
zoológico, 238
funcionalidad, degradantes, 207
sol
los días de juego, 210
porteros, 197
gobernancia
concepto de, 25
mi
empatía, 27
encriptación,
180 pruebas de
extremo a
extremo
usos apropiados para, 143, 147
Pirámide de prueba de Cohn, 132
creación de, 141
inconvenientes de, 140
ciclo de retroalimentación, 142
implementación de, 138
metaversion, 143
ámbito de aplicación de, 135
tiempo de, 141
criterios de valoración
coexistiendo diferente, 64
la agregación del lado del
servidor, 71 entornos
definición durante el despliegue,
128 consideraciones de
implementación, 114
gerente, 115
módulos de Erlang,
10
Eureka, 240
bombas de datos de
eventos, 98
abastecimiento
acontecimiento, 225
la colaboración basada en eventos, 43
consistencia eventual, 91, 233
arquitectos evolutivos (ver arquitectos de
sistemas) manejo de excepciones, 24
ejemplares, 22
prueba exploratoria, 132
seguimiento) que trata,
205
falsificaciones, 137
equipos basados en características, 195
cortafuegos, 182
pruebas en forma de escamas, 140
relaciones de clave externa, rompiendo, 84
FPM herramienta de gestor de paquetes, 110
F
robots de fracaso, 211
fracasos
en cascada, 164
(Véase también el
Índice | 255
papel de arquitecto de
sistemas en, 27 granularidad, 8
Grafito, 159
H
sistemas habitables, 15
HAL (Hypertext Idioma de la aplicación),
242 Código de mensajes basado en hash
(HMAC), 176 HATEOS principio, 51
beneficios
heterogeneid
ad de, 4
bibliotecas
compartidas y, 9
arquitectura hexagonal,
1
modelos ocultos, 31
alta cohesión, 30
HMAC (código de mensajes basado en
hash), 176 HTTP (Hypertext Transfer
Protocol)
el almacenamiento en caché en, 226
HATEOS principio, 51
HTTP a través de beneficios
256| Índice
REST, 50 HTTP a través de
REST inconvenientes, 54 la
terminación de HTTP, 219
HTTP (S) de autenticación básica, 174
Registro humana, 242
hipermedia, 51
hipervisores, 123
hystrix biblioteca, 22, 214
yo
operaciones idempotente, 215
proveedor de identidad, 170
imágenes
como artefactos, 113
personalizado, 111
servidores inmutables, 113
automatización de la
infraestructura, 1 integración
Acceso por referencia, 60
asíncrono colaboración basada en eventos,
55 interfaz de cliente, 40
DRY (Do not Repeat Yourself), 59
goles a favor, 39
guias para, 78
importancia de, 39
orquestación vs coreografía, 43
extensiones de reactivos, 58
llamadas a procedimientos remotos, 46
REST (Representational State Transfer), 49
servicios como máquinas de estado, 58
bases de datos compartidas, 41
sincrónico vs asíncrono comunica- ción, 42
software de terceros, 73
interfaces de usuario, 67
versiones, 62 las
interfaces
coexistiendo nuevo y viejo, 64
despliegue, 127
establecimiento de normas
para, 21 (Véase también las
interfaces de usuario)
detalle de implementación interna, 40
interna modelo de código abierto, 196
sistemas de detección de intrusión
(IDS), 182 sistemas de prevención de
intrusiones (IPS), 182 aislamiento, 215
arquitectos de TI (ver arquitectos de sistemas)
J
JSON, 53
fichas web JSON (JWT), 176
K
karyon, 22
La autenticación basada en clave, 177
Kibana, 158
L
latencia, 207
Latencia del mono, 211
arquitecturas de capas, 1
bibliotecas
cliente, 59
métricas de servicio, 161
compartido, 9
contenedores de Linux, 124
balanceo de carga, 219
desconexión de carga, 215
llamadas
locales, 47
troncos
agregado, 158
(Véase también el
seguimiento) los
problemas de seguridad,
182
estandarización de, 165
logstash, 158
bajo acoplamiento, 30, 45, 192
METRO
ataques man-in-the-middle, 173
cuadrante de Marick, 131
madurez, 197
tiempo medio entre fallos (MTBF), 150
tiempo medio de reparación (MTTR),
150 intermediarios de mensajes, 55
métrica
bibliotecas para, 161
métricas de servicio, 160
el seguimiento a través de múltiples
servicios, 159 biblioteca métricas, 22
microservicios
aplicación adecuada de, 249
autonomía y, 3, 26
beneficios de, 1
del composability de, 7
definición del término, 2
facilidad de
implementación, 6
inconvenientes de, 11,
249 principios
fundamentales de, 245
alineación de la organización y,
7 orígenes de, 1
intercambiabilidad y, 7
capacidad de resistencia de, 5
de escala y, 5
tamaño y, 2
la heterogeneidad de la
tecnología, 4 vs módulos, 10
frente a la arquitectura orientada a
servicios, 8 vs bibliotecas
compartidas, 9
microservicios en sistemas
antifragile escala, 210
las medidas de seguridad de
arquitectura, 208 autoscaling, 230
el almacenamiento en caché, 225
almacenamiento en caché
de escritura, 228 teorema
de la PAC, 232
Índice | 257
requisitos interfuncionales (CFR), 206
superación de las deficiencias, 205
258| Índice
funcionalidad degradantes, 207
servicios de documentación, 241
registros de servicios
dinámicos, 238 operaciones
idempotente, 215
escalada, 216
bases de datos de escala, 222
sistemas auto-descripción, 242
descubrimiento de servicios, 236
middleware, 56
burlándose frente a tropezar, 137
servicios de modelado
contextos acotados, 31
capacidades de negocio, 34
conceptos de negocio, 36
conceptos clave, 30
módulos y servicios, 33
contextos acotadas anidadas, 34
la descomposición prematura,
33 compartida frente a los
modelos ocultos, 31 límites
técnicos, 36
Descomposición modular, 10
módulos, 33
vigilancia
fallos en cascada, 164
el registro central, 158
complejidades de, 155
ID de correlación, 162
Los resultados se presentan / compartir, 165
seguimiento métrica a través de múltiples
servicios, 159 múltiples servicios / múltiples
servidores, 157 visión general de, 167
informes en tiempo real, 166
semántico, 162
métricas de servicio, 160
solo servicio / varios servidores, 156
solo servicio / servidor único, 156
estandarización de, 165
establecimiento de normas y,
21 sintético, 161
sistemas
monolíticos
bases de código
en, 2
falta de acoplamiento débil cohesión / en, 79
la presentación de informes de bases de
datos en, 93
frente a la arquitectura orientada a
servicios, 8 La ley de Moore, 191
Saltimbanqui, 138
MTBF (tiempo medio entre fallos), 150 MTTR
(tiempo medio de reparación), 150
norte
contextos acotadas anidadas, 34
Índice | 259
segregación de red, 183
requerimientos no funcionales, 151
normalización de la desviación, 140
O
sistemas de aprovisionamiento a la carta, 6
en demanda de virtualización, 1
arquitectura de cebolla, 37
Abrir Web Application Security
Project (OWASP), 187
OpenID Connect, 170, 174
artefactos del sistema operativo,
110 seguridad de los sistemas de
explotación, 183 arquitectura de
la orquestación, 43
alineación de la
organización, 7 estructura
organizativa
La ley de Conway y, 191
efectuar en el diseño de
sistemas, 191 vs suelta
estrechamente unida, 192
servicios de huérfanos, 198
OSGi (Open Source Gateway Initiative),
10 propiedad
compartido, 195
diseño del sistema y, 194
260| Índice
PAGS
Envasador, 112
Pacto, 145
pacto, 146
tolerancia
partición
en PAC teorema, 232
sacrificar, 234
contraseñas, 180
pruebas de rendimiento, 152
plataforma como servicio
(PaaS), 120 artefactos
específicos de la plataforma, 109
Polly para .NET, 214
Ley de Postel, 63
escala predictiva, 230
parte principal, 169
problemas de privacidad, 186
ensayo de las propiedades, 132
el almacenamiento en caché de proxy, 226
R
RabbitMQ, 55
RDBMS (gestión de base de datos relacional
SYS-TEMS), 222
extensiones de reactivos (Rx),
58 escalamiento reactiva, 230
réplicas de lectura, 222
rediseñar, 221
bases de datos de
refactorización, 89 llamadas a
procedimientos remotos, 46-49
ventajas e inconvenientes de, 49
fragilidad, 47
definición del término, 46
las tecnologías
disponibles, 46
acoplamiento de la
tecnología, 47 frente a
las llamadas locales, 47
intercambiabilidad, 7
bases de datos de
informes
bombas de datos de copia
de seguridad, 99
directrices de la bomba de
datos, 96
la recuperación de datos a través
de las llamadas de servicio, 95
bombas de datos de eventos, 98
sistemas de concurso
completo genéricos, 100
enfoque monolítico a, 93
software de terceros, 95
la colaboración de solicitud / respuesta, 42
ingeniería resiliencia, 5, 228
recursos, 49
tiempo de respuesta, 207
REST (Representational State Transfer), 4955 ÁTOMO especificación, 56
concepto de, 49
marcos para, 54
HTTP a través de beneficios
REST, 50 HTTP a través de
REST inconvenientes, 54
formatos de texto, 53
proxy inverso, 226
Riemann, 166
riesgo, la difusión, 217
principio de robustez, 63
Rx (extensiones de
reactivos), 58
almacenamiento), 218 escalada,
216-222
autoscaling, 230
beneficios de, 5
bases de datos, 222
balanceo de carga, 219
razones para, 216
cargas de trabajo de la división, 217
diversificación de riesgos, 217
S
SAML, 170, 174
SAN (redes de área de
Índice | 261
vertical, 217
vs rediseño, 221
Los sistemas basados
en los trabajadores, 220
costuras, el concepto de,
79 seguridad, 169-189
ataques, la defensa de, 182
autorización de autenticación,
169
copias de seguridad, 99, 181
educación / conocimiento de, 187
encriptación, 180
ejemplo de
configuración, 184
verificación externa de,
188 cortafuegos, 182
elemento humano de,
187 importancia de, 169
detección de intrusiones / prevención, 182
almacenamiento de claves, 181
troncos, 182
ataques man-in-the-middle, 173
sistemas operativos, 183
visión general de, 188
contraseñas, 180
problemas de
privacidad, 186
asegurar los datos en
reposo, 180
autentificación / autoriza- ción-servicio-
262| Índice
servicio, 173
selección de la herramienta, 187
nubes privadas virtuales, 183
Desarrollo del ciclo de vida de
seguridad, 187 sistemas autodescripción, 242
monitoreo semántica, 147, 161
versiones semántica, 64
el almacenamiento en caché del lado del
servidor, 226
cuentas de servicio, 175
los límites del servicio, dieciséis
(Ver también los servicios de
modelado), las llamadas de
servicio de recuperación de datos
a través de, 95 configuración de
servicio, 115
descubrimiento de
servicios, 236 la propiedad
de servicio
enfoque integral, 194
compartido, 195
proveedor de servicio, 170
la separación del servicio, puesta en escena, 89
(Véase también la descomposición
de base de datos) plantillas de servicio,
22
pruebas de servicio
Pirámide de prueba de Cohn, 132
implementación de, 136
burlándose frente a
tropezar, 137 servidor
charlatán para, 138 ámbito
de aplicación de, 134
arquitecturas orientadas a servicios
(SOA), concepto de 8
inconvenientes de, 8
reutilización de
funcionalidad en, 7
microservicios frente, 9
servicio-a-host mapeo, 116-121
contenedores de aplicaciones,
118 múltiples servicios por host,
116 plataforma como servicio
(PaaS), 120 servicio solo por
host, 119 terminología, 116
autenticación / autorización de-servicioservicio, 173-180
claves de la API, 177
certificados de cliente, 175
problema adjunto confusa,
178 HMAC a través de HTTP,
176
HTTP (S) de base, 174
ataques man-in-the-middle, 173
SAML / OpenID Connect, 174
sharding, 223
código compartido, 59
datos compartidos, 86
bibliotecas compartidas, 9
modelos compartidos,
31 datos estáticos
compartidos, 85 mesas
compartidas, 87
compartir comportamiento, 42
inicio de sesión único (SSO),
170-172 de pruebas de humo,
148
espías, 137
SSH-multiplexación, 157
certificados SSL, 174
terminación SSL, 219 la
aplicación de las
normas
ejemplares, 22
plantillas de servicio a medida, 22
establecimiento de normas, 20-22
la seguridad de arquitectura, 21
importancia de, 20
interfaces, 21
vigilancia, 21
datos estáticos, 85
Dibujo Aplicación estrangulador, 77,
208 metas estratégicas
ejemplo del mundo real, 19
Índice | 263
comprensión, 18
golpearse contra de burla,
137 Suro, 166
Pavonearse, 242
comunicación sincrónica, 42
monitoreo sintético, 161
diseño de sistemas
rendición de cuentas y, 202
adaptándose a las vías de comunicación,
193 contextos acotados, 198
caso de estudio, 199
ley de Conway, 191 en
la entrega, 196
efecto en la estructura de organización,
201 equipos de características, 195
interna modelo de código abierto,
196 estructura organizativa y, 191
servicios de huérfanos, 198
visión general de, 203
papel de custodios, 197 la
madurez del servicio, 197
la propiedad de servicio, 194
la propiedad de servicios
compartidos, 195 estampación, 198
arquitectos de sistemas
desafíos que enfrenta,
27
directrices para la toma de
264| Índice
decisiones, 17 manejo de
excepciones, 24
gobernancia, 25
responsabilidades de, 13, 24, 27
papel de, 15
los límites del servicio y,
dieciséis la aplicación de las
normas por, 22-23
establecimiento de normas por,
20 por la formación de equipos,
26
por la participación del
equipo, 17 deuda técnica
y, 24
T
mesas, compartida, 87
plantillas de servicio a
medida, 22 formación de
equipos, 26
estructuras de equipo, 198
límites técnicos, 36
deuda técnica, 24
heterogeneidad tecnología, 4
API independiente de la tecnología, 39
tecnología orientada hacia pruebas, 132
plantillas, 22
dobles de prueba, 137
Pirámide de prueba,
132, 144 prueba de
cono de nieve, 136
diseño basado en pruebas
(TDD), 134 pruebas
canario de liberación, 149
consideraciones para, 135
pruebas dirigido a los consumidores, 144
interfuncional, 151
pruebas de extremo a
extremo, 138 MTTR
sobre MTBF, 150
visión general de, 153
pruebas de rendimiento, 152
post-producción, 148
ámbito de aplicación de, 132
seleccionar el número de,
136 monitoreo semántica,
147
separar el despliegue de la liberación, 148
Prueba de la aplicación de servicio, 136
tipos de pruebas, 131
software de terceros, 73-78, 95 la
construcción frente a la compra,
73
sistemas de gestión de contenidos (CMS),
75 Customer Relationship Management
(CRM), 76
personalización de, 74
problemas de
integración, 74 falta de
control sobre, 74 la
presentación de
informes de bases de
datos, 95
Dibujo Aplicación estrangulador,
77 estrecho acoplamiento, 30, 192
el tiempo de vida
(TTL), 237 tiempos de
espera, 211
administradores de transacciones, 92
límites transaccionales, 89-93
actas
compensando, 91
repartido, 92
Transport Layer Security (TLS), 175
De dos fases comete, 92
escriba 2 virtualización, 123
UDDI (Universal Description, Discovery y
Integración), 242
las pruebas unitarias
Pirámide de prueba de Cohn,
132 objetivos de, 134
T
Índice | 265
cuadrante de Marick, 132
ámbito de aplicación de, 134
interfaces de usuario, 67-73
composición API, 68
puertas de enlace de la API, 71
granularidad API, 67
Pirámide de prueba de
Cohn, 132
(Véase también de
extremo a extremo
pruebas) limitaciones, 68
evolución de, 67
composición fragmento, 69
enfoques híbridos, 73
V
Vagabundo, 124
versiones, 62-67
la captura de cambios de última
hora temprana, 63 coexisten
diferentes criterios de valoración,
64 difiriendo cambios de última
hora, 62 múltiples versiones
concurrentes, 66 semántico, 64
la escala vertical, 217
266| Índice
nubes privadas virtuales (VPC), 183
virtualización
hipervisores, 123
tradicional, 123
tipo 2, 123
plataformas de
virtualización
Estibador, 126
contenedores de Linux, 124
Bajo demanda, 1
redes de área de almacenamiento en,
218 Vagabundo, 124
visión, 27
W
Los sistemas basados en los trabajadores, 220
de escritura en segundo cachés, 228
X
XML, 53
Z
Ataque Zed Proxy (ZAP), 187
Zipkin, 163
cuidador del zoológico, 238
Sobre el Autor
Sam Newman es un tecnólogo en ThoughtWorks, donde actualmente divide su
tiempo entre ayudar a los clientes y trabajando como arquitecto de sistemas internos
ThoughtWorks'. Ha trabajado con una variedad de compañías en múltiples dominios
de todo el mundo, a menudo con un pie en el mundo de desarrolladores, y otro en el
espacio de las operaciones de TI. Si usted le preguntó lo que hace, él decía: “Yo
trabajo con la gente para construir mejores sistemas de software.” Ha escrito
artículos, presentado en conferencias, y esporádicamente se compromete en
proyectos de código abierto.
Colofón
Los animales en la portada de microservicios construcción son abejas (del género
Apis). De 20.000 especies conocidas de abejas, sólo siete se consideran las abejas de
miel. Son tinct dis- porque producen miel y tienda, así como la urticaria de
construcción de cera. Apicultura mantener a recoger la miel ha sido una búsqueda
humana durante miles de años.
Las abejas de miel viven en colmenas con miles de personas y tienen una estructura
social muy organizada. Hay tres castas: reina, aviones no tripulados, y el trabajador.
Cada colmena tiene una reina, que sigue siendo fértil para 3-5 años después de su
vuelo de apareamiento, y pone hasta 2.000 huevos por día. Los zánganos son las
abejas macho que se aparean con la reina (y mueren en el acto a causa de sus órganos
sexuales de púas). Las abejas obreras son hembras estériles que llenan muchos
papeles durante su vida, tales como niñera, trabajador de la construcción, tendero,
guardia, empresario de pompas fúnebres, y recolector. Forrajeo abejas obreras se
comunican entre sí por “bailar” en patrones particulares para compartir información
sobre los recursos cercanos.
Las tres castas de la abeja de la miel son similares en apariencia, con las alas, seis
patas y un cuerpo segmentado en una cabeza, tórax y abdomen. Tienen pelos cortos
difusos en un patrón de color amarillo y negro a rayas. Su dieta se compone
exclusivamente de miel, que se crea mediante un proceso de néctar de las flores rico
en azúcar digestión parcial y regurgitar.
Las abejas son cruciales para la agricultura, ya que polinizan los cultivos y otras
plantas con flores, mientras que recogen el polen y néctar. En promedio, cada
colmena de abejas reúne a 66 libras de polen al año. En los últimos años, la
disminución de muchas especies de abejas ha sido motivo de preocupación y se
conoce como Todavía no está claro qué está causando esta mortandad “desorden del
colapso de colonias.”: Algunas teorías incluyen parásitos, el uso de insecticidas, o la
enfermedad, pero no hay medidas preventivas tivos effec- se han encontrado hasta la
fecha.
Muchos de los animales en peligro de extinción cubiertas O'Reilly están; todos ellos
son importantes para el mundo. Para obtener más información sobre cómo puede
ayudar, ir aanimals.oreilly.com.
La imagen de portada es de la historia natural de Johnson. Las fuentes de
presentación son URW Tipo-escritor y Guardián Sans. La fuente del texto es Adobe
Minion Pro; la fuente es encabezado Adobe Myriad condensada; y la fuente de
código es de Dalton Maag Ubuntu Mono.
268| Índice