Desarrollo y diseño

Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev
Personas que ya no estan aqui :(




Soltrac
Soltrac #34621 May '22 MV Wizard

#34614 Y no se ha solucionado nada ^^

1
Kaledros
Kaledros #34622 May '22

#34619 ¿Por qué quedarte ahí?

Otra alternativa para no ser una víctima de Pegasus es utilizar un teléfono básico, como los famosos Alcatel para llamar y recibir mensajes de texto.

O usar el fijo, enviar una carta por correo, dar un recado a un conocido...

pantocreitor
pantocreitor #34623 May '22

#34610 han parado el servicio y ya funciona todo, menos lo suyo.

Ahora les tocará ver que ha pasado (dejan miles de sesiones en base de datos y lo joden todo)

1 respuesta
frekaice
frekaice #34624 May '22

#34623 Entiendo que esto pueda pasar en empresas pequeñas, pero la tuya parece ser una de las grandes. No tienen entornos de preproduccion?

1 respuesta
desu
desu #34625 May '22

#34613 no conozco apache pulsar. si tienes jetty en lugar de netty. LOL.

yo si fuera vosotros como digo, no tomaria decisiones de arch sin antes tener una poc que mas o menos sea representativa de la realidad.

te recomiendo mi leer mi blog post sobre jardineria de software, no somos arquitectos, somos jardineros.

planta una semilla, mira como crece y adaptate.

1 respuesta
pantocreitor
pantocreitor #34626 May '22

#34624 se tiene, por eso no entiendo como se ha podido colar eso.

El tema es que a mi parte que normalmente mantiene entre 5 y 15 sesiones con bases de datos le provoca que por instancia cree unas 300-400.
Obviamente estas instancias que dan servicio a muchos otros servicios peten, creando una reacción en cadena muy divertida (tan divertida como que estiman que unas 2000 personas llevan hoy todo el día sin trabajar)

JuAn4k4
JuAn4k4 #34627 May '22

#34625 El poc lo vamos a empezar pero con una idea general. Si maño si, jetty…

MTX_Anubis
MTX_Anubis #34628 May '22 :psyduck:

#34613 sí, más o menos me refiero si es que necesitas una queue que tenga que ingresar 10Mmps o que basicamente el cluster tiene esos mensajes cada segundo, que no es lo mismo xD. Lo mismo ocurre con el ordering, at least once, at most once, exactly once, etc. Necesitais persistencia de estos mensajes, replicación a otros brokers?

Por cierto, cuán antiguo es eso para usar jetty? Que la última versión tiene casi 10 años xD

1 respuesta
aren-pulid0
aren-pulid0 #34629 May '22

Como se pasa de ser un pica cruds a hacer ese tipo de trabajos? @desu @JuAn4k4

JuAn4k4
JuAn4k4 #34630 May '22

#34628 El cluster entero tiene esos mensajes, pero por la queue pasan esos mensajes para procesar, seguramente lo tengamos que partir por tenants, pero a la larga van escalando. Más años que la polca aquí se mueve todo muy despacio, he entrado para darle un empujón a todo esto. Usan dropwizard y akka en una versión ya no soportada. Y la AMI de Aws que usamos la quitan a final de año. Todo deprecated. Java 8.

2 respuestas
MTX_Anubis
MTX_Anubis #34631 May '22 :psyduck:

#34630 llamalo partir por tenants o particiones de un topic/queue. Yo es lo primero que atacaría (a parte de la mierda de jetty esa claro) y sin eso no hay ninguna solución opensource que te vaya a ayudar.

Tampoco explicas mucho más del caso de uso, como digo hay muchos factores que intervienen en "procesar 10 millones de mensajes por segundo". No soy un experto en consumir millones de mensajes por segundo pero imagino que si puedes separarlos por queues, mejor. Si una queue puedes a su vez volver a particionarla para consumir de forma paralela de ella (si es que el ordering importa), mejor también

Si quieres ver distintas soluciones de Queues aquí hay una comparativa bastante chula que te explica las diferencias de cada una

https://softwaremill.com/mqperf/

1 1 respuesta
desu
desu #34632 May '22

#34630 que latencias te puedes permitir? <20ms? <100ms? o puedes alargar hasta 500ms o mas? eso me parece mas importante que la carga.

yo lo que hice el otro dia para tunear un servicio fue una simulacion con request y suponiendo fallidas que ps de latencias tendria... me salio que daba igual tunear el servicio XD

yo apuntaria a un 90-95p estable para empezar, y que la cola no te cause ningun incidente ni estes haciendo ninguna locura... si pasas de 50ms a 5 segundos si el servicio final es algo que agrega cada 10 minutos (como los logs de aws por ejemplo, que creo que el minimo es 15? o 10?) pues estas bien y tienes mucho margen para cagarla o mejorar.

a la que tienes un bloque estable para tus requerimientos de latencia, escalas horizontal.

edit: https://blog.danslimmon.com/2016/08/26/the-most-important-thing-to-understand-about-queues/

este link lo comparti hace tiempo, relacionado con lo que digo. el tema de la congestion por latencias es jodido de calcular/predecir.

1 1 respuesta
B
[Borrado] #34633 May '22

Un temita para alegrar la tardeeee

1 respuesta
B
[Borrado] #34634 May '22

#34633

1 respuesta
B
[Borrado] #34635 May '22

#34634 uff de cuando el langui molaba

Lecherito
Lecherito #34636 May '22 A toda leche

Langui y molar en la misma frase xdd

Slowbro
Slowbro #34637 May '22

#34587 Pues me encantaría responderte pero tengo bastante poca idea de vuestro mundo. Yo lo utilizaba para montar un pub/sub con video y funcionaba muy bien, pero ahí el reto era payload/latencia y no cantidad de conexiones/participantes.

En cualquier caso te diré que está excesivamente bien documentada (tienes ejemplos bastante complejos en el libro), la librería es muy pequeñita, la tienes en chorrocientos lenguajes, y el protocolo no es excesivamente complejo (si necesitarais montar vuestra propia implementación).

JuAn4k4
JuAn4k4 #34638 May '22

#34632 #34631 Gracias. El caso de uso es un Websocket Gateway en el edge que sirve de servicio de plataforma para diferentes servicios que se construyen por encima: Chat/Conversations, Eventos, Audio/Vídeo, etc, todo real-time. En algunos casos la latencia es <3-5s en otros más prioritarios <1s roundtrip, pero no tenemos marcado nada. Esperamos que no nos suba mucho la latencia en principio, e intentaremos bajarla después metiendo ciertas mejoras y atajos (saltarnos la cola y el pub/sub en ciertos casos) e ir por grpc directo según prioridades.

Lo que necesitamos básicamente es que escale, lo que tenemos ahora no escala y es un monolito que si lo tocas se rompe (además de ser muy viejo).

La idea es partirlo y hacerlo async para resiliencia, y metemos queues para escalar el edge mejor (websocket termination) de forma que no esté CPU bound y aprovechar mejor para ahorrar ahí costes.

El workflow nuevo sería algo así:
edge -> queue -> procesar -> pub/sub -> edge

La latencia subirá, pero también la resiliencia.
No hay ordenación ni requisito de la misma, preferimos tener at least once y deduplication en el edge y cliente para ser un best effort de only once, aunque ahora mismo es un best effort donde se pierden muchos mensajes hasta por ttl de entrega.

1 respuesta
_Rpv
_Rpv #34639 May '22

Car sure

3 2 respuestas
B
[Borrado] #34640 May '22

#34639 he buskao cursos de inglés en google y solo apareces tú pidiendo perras

1
desu
desu #34641 May '22

#34638 esa latencia no tiene sentido, esta medida de edge a edge? el worker para procesar lo pone cada microservicio entiendo y lo estas contando? no deberiais contarlo si no lo implementais. por lo que dices estaria tranquilo, es empezar de 0. nosotros tambien hemos cambiado nuestras 2 gws de lecturay escritura de netflix stack a golang. ya la tenemos 100% en prod. de hecho desplegue un viernes a prod mientras nos estaban haciendo una migracion y estaba la carga a tope XD con 2 cojones.

por curiosidad, que diferencias ves entre implementar una gw http a una tcp a pelo (websocket)? yo es que no veo ninguna diferencia si tuviese que hacer algo. a parte de no poder usar el protocolo http, usaras otro para no picarte tu las cosas...

solo veo jodido el tema de gestionar las lecturas y duplicaciones, pero espero meterle un protocolo como zmq(yo no lo usaria este) o amqp o algo asi que me lo gestione. ni idea de que tendriais que meter, ya nos lo diras tu. y de ahi tener cosas de resiliencia de colas... no tiene mucho secreto la arquitectura. mas que masticada.

https://www.arnaudiaz.com/blog/engineers-as-gardeners/

Yo plantaria una semilla sencilla y empecaria a evolucionarla. No me preocuparia de que maquina usar para podar los arboles hasta que no hayan crecido. Mientras sepas que los tienes que podar y te prepares. Es suficiente.

1 respuesta
B
[Borrado] #34642 May '22

#34639

** Pido disculpas, no lo pude resistir.

1
JuAn4k4
JuAn4k4 #34643 May '22

#34641 e2e es la latencia. La diferencia es dar la feature de service to client y channels/topics. Lo de procesar es porque el websocket acaba en nuestro edge y se transforma a http hacia el servicio para mensajes client to service, así abstraemos a los servicios de lidiar con websockets. Así que partimos toda la parte de procesar esas llamadas, límites a los servicios, protecciones y tal… y dejamos el edge más tonto para meter mas conexiones por nodo. También damos authentication, limits, y protecciones con WAF, NLBs y self healing, etc. Aunque todo esto es propio del otro gateway que tenemos http (que también da open-api).

Tener tenemos latencias de 7-10s por la lentitud del cliente móvil al recibir

Kaledros
Kaledros #34644 May '22

Acción: https://www.macrumors.com/2022/04/11/apple-employees-returning-to-offices/

Reacción: https://www.macrumors.com/2022/05/07/apple-director-of-machine-learning-resigns/

Para quien no sepa quién es este tío: https://en.wikipedia.org/wiki/Ian_Goodfellow No se les ha ido el conserje, precisamente…

2 1 respuesta
r2d2rigo
r2d2rigo #34645 May '22 Inocente

#34644 hay que sacarle provecho al campus monstruoso que montaron, aunque eso signifique que se les vaya media plantilla.

1
desu
desu #34646 May '22

llevo 3h de meetings hoy. se me ha ocurrido 1 teoria. quiero compartirla con vosotros. esto es unix philosophy y system design de alto nivel. alto toque y facherio expected.

la comparto con vosotros. os invito a todos a tratar de resolverlo. pregunta tipica de entrevista.

Imaginaos que estais haciendo una CLI. Teneis un comportamiento booleano que esta activado o desactivado y tiene ademas un comportamiento por defecto. Com dise;ariais esta feature?

A

Si el feature esta enabled o disabled por defecto, el flag sirve para settear lo contrario

cli -flagEnable

cli -flagDisable

B

cli -flag=[true/false]
2 respuestas
Traber
Traber #34647 May '22

#34646

Usando operandos +/-

Habilitar flag
Desabilitar flag

Usando parámetros semánticos with/without

Habilitar flag
Desabilitar flag

Poniendo los flags por defecto a false y haciendo que puedan ser habilitados

Habilitar flag
1 1 respuesta
eondev
eondev #34648 May '22 Rawe Ceek

#34646
En caso de hacerlo con alias, lo veo mejor así.

cli --enableFlag
cli --disableFlag

La decisión tómala conforme el diseño del resto de la API, para ser coherentes.

desu
desu #34649 May '22

#34647 La gracia esta en el comportamiento por defecto. Cuando este CLI evolucione puede ser que otro feature necesite este valor y tengas dependencias, puede ser que el valor por defecto cambie en el futuro...

No es lo mismo usar opcion A que opcion B.

La pregunta no es sobre sintaxis, sino system design.

BTW no sabia que podias usar +/- XD

1 respuesta
Kaledros
Kaledros #34650 May '22

Sin tener más información, yo a priori no metería parámetros y elegiría la opción A. Pero es que estoy pensando desde el punto de vista de seguridad, si le pones un parámetro de entrada se te puede colar un bug.

2 respuestas

Usuarios habituales