search

JJ / SerU

Arquitectura de servicios web para usuarios de una institución académica.
Apache License 2.0
13 stars 0 forks source link

Definición general de arquitectura #2

Closed JJ closed 1 year ago

JJ commented 7 years ago

Un inicio sería

angrykoala commented 7 years ago

¿Cómo actualizarán la db los crawlers?, si estos se ejecutan periodicamente (y, en algunos casos, fallarán al extraer informacion) podría ser conveniente diseñar algun middleware (por ejemplo, algo basado en colas/cache) para gestionar esta actualizacion. Otra opción más simple, al menos para ir empezando, es que los crawlers modifiquen la db directamente

JJ commented 7 years ago

El 20 de julio de 2017, 17:39, Andrés notifications@github.com escribió:

¿Cómo actualizarán la db los crawlers?, si estos se ejecutan periodicamente (y, en algunos casos, fallarán al extraer informacion) podría ser conveniente diseñar algun middleware (por ejemplo, algo basado en colas/cache) para gestionar esta actualizacion. Otra opción más simple, al menos para ir empezando, es que los crawlers modifiquen la db directamente

También podemos crear una arquitectura de microservicios basada en eventos donde las modificaciones de la BD se propaguen a los diferentes clientes. Desde luego con muchísimos clientes escalará mucho mejor (y la optimización prematura es la madre de todos los vicios, ya lo sé)

angrykoala commented 7 years ago

Esto estaría de acuerdo con la opción 1. En este caso los crawlers actuan como servicios, mediante eventos (un middleware con rabbitmq por ejemplo) pueden actualizar la db. La verdad, no creo que el cuello de botella, o los problemas, se encuentren en la parte cliente/db, al final, esa parte es bastante estándar, con una api conectada a una db, que no debería ser un problema enorme de escalar, los crawlers sin embargo podrían llegar a dar muchos problemas si no se diseña bien esa parte

JJ commented 7 years ago

Piensa de todas formas que para que sea sostenible toda la infraestructura debería de meterse en hosting gratuitos tipo OpenShift o zeit.co. De todas las opciones, conviene elegir la más simple.

angrykoala commented 7 years ago

A ver que os parece estas opciones:

Probablemente, lo ideal es comenzar con la arquitectura más simple posible:

Esta arquitectura es útil como primera implementación, ya que no presenta ninguna complejidad al desplegarla (2 servicios, 1 con base de datos) y es relativamente facil de extender

Ñapa-diagram: arch_v1 Arquitectura v1

Idealmente (y si fuera necesario escalar en el futuro) se pueden dividir algunos servicios:

La cola de eventos permite tener mayor "reliability" en los mensajes, evitando perder información si alguno de los servicios está caido temporalmente, o si los webscrappers fallan.

Tener una api que únicamente lee base de datos debería simplificar el escalado, si hubiera muchos clientes.

Obviamente, está opción es considerablemente más compleja, intentar desarrollar algo como esto sin necesidad me parece overengineering

arch_v2 Arquitectura v2

JJ commented 7 years ago
  1. ¡Se dice scraper!
  2. Pon los fuentes en algún sitio, por favor.
  3. Hay una arquitectura intermedia que no usa la cola de eventos, pero en la que el crawler y *data gatherer sí va directamente a la base de datos.
angrykoala commented 7 years ago
  1. Ups, perdona
  2. Es un screenshot ñapa, más adelante, cuando terminemos de definir la arquitectura, ya pongo los diagramas chulos con source y cosicas
  3. En ese caso no veo por qué data gatherer sería necesario.
    • Si los crawlers pueden acceder a la base de datos, acabariamos con algo muy similar a la opción 1, pero sin tanto control de acceso a la DB
    • Tratar de conectar los scrapers a data gatherer a pelo no veo que suponga una gran ventaja respecto a opción 1, ya que igualmente necesitariamos una API en algún sitio
    • Una ventaja de la solucion 1 respecto a la 1.5, es que es muy facil cachear en WebApi los ultimos datos, si fuera necesario un mejor rendimiento, sin llegar a la complejidad de la 2

En cualquier caso, a partir de la opción 1 es fácil pasar a la intermedia que propones

No se muy bien la diferencia entre scraper vs. crawler, y no se cual queremos implementar

JJ commented 7 years ago

No se muy bien la diferencia entre scraper vs. crawler, y no se cual queremos implementar

Un scraper extrae información de una sola página web. Un crawler te lleva hasta esa página web, incluyendo autenticación, navegación por el sitio, cosas así.

gDanix commented 7 years ago

Con respecto a la arquitectura, propondría utilizar la V1, principal por velocidad: El acceso a una BBDD "cercana" al servicio web siempre será más rápido que hacer scraping bajo demanda (Además de que utilizará menos ancho de banda y recursos del servidor), además de que podremos aprovechar tecnologías de cacheo de contenido.

Los únicos contras que le veo es que habría que implementar una forma de detectar cambios de útlima hora en el contenido (¿quizás almacenando el checksum del fichero html analizado cuyos datos se han introducido en la BBDD y calculando cada dia de nuevo el checksum de la web para detectar cambios?)

angrykoala commented 7 years ago

@gDanix Ambas arquitecturas usan una DB, ninguna usa scrapping bajo demanda

La idea es que los scrapers actuen periodicamente (2~5 minutos?), la arquitectura 2 además contempla hacer peticiones bajo demanda (por ejemplo, si lleva mucho tiempo sin actualizarse o algo)

JJ commented 7 years ago

Cada scraper tendría que tener su periodicidad. Se programa y listo. Los del comedor no sé si es semanal o diaria.

gDanix commented 7 years ago

@angrykoala cierto, malinterpreté la arquitectura. Ahora, si me lo permitís, cambio de opinión y voto por la opción 2. Quizás en un principio se pueda simplificar, pero creo que conforme crezca la aplicación nos resultará más útil.

@JJ Normalmente se actualiza un par de veces a la semana

angrykoala commented 7 years ago

@gDanix aunque la version 2 mola bastante, pienso (y lo pienso seriamente) que es overengineering, bien implementado quizás ni es necesario cambiarlo en el futuro, y si se hace bien, no deberia ser dificil pasar de V1 a V2 (o a cualquier otra opción que se nos ocurra en el futuro) ya que siempre es más facil pasar de algo más simple a otra cosa más compleja que al reves

gDanix commented 7 years ago

Si comenzamos con la V1 y luego cambiamos, que no se nos olvide versionar las APIs, porque en el momento del cambio de arquitectura, la API también cambiará.

JJ commented 7 years ago

El 21 de julio de 2017, 17:39, Daniel Trujillo Viedma < notifications@github.com> escribió:

Si comenzamos con la V1 y luego cambiamos, que no se nos olvide versionar las APIs, porque en el momento del cambio de arquitectura, la API también cambiará.

Cierto...

angrykoala commented 7 years ago

No deberia cambiar la API, lo dicho, si se diseña bien, la api que cambiaria sería unicamente la interna (scrapers) la api externa a los clients, que es la importante, debería mantenerse.

De hecho, incluso la base de datos deberia mantenerse tambien

angrykoala commented 7 years ago

Propongo dividir la 1º iteracion del proyecto en 3 partes (milestones o kanbanes):

gDanix commented 7 years ago

Ahora que ya tenemos medianamente desechada la arquitectura 2, tenemos estas 2 opciones para refinar la arquitectura 1:

Fuentes: diagramas arq v1 SerU.zip

Yo, personalmente, voto por la segunda. Permitiría simplificar los scrapers ya que, por lo general, creo que es más complejo acceder a bases de datos que hacer peticiones web. Además, seguimos la filosofía de otros servicios como Apache Solr.

angrykoala commented 7 years ago

Me parece que @gDanix ha colgado el mismo diagrama

La principal diferencia es añadir una API entre la BBDD y los scrapers, para que estos no accedan directamente

Coincido en que creo que esta es la mejor opción, generalmente es mejor desacoplar todo lo posible las base de datos de la lógica, más aun cuando los scrapers (potencialmente) pueden ser procesos dinámicos, personalizados o corriendo en una especie de "sandbox"

gDanix commented 7 years ago

@angrykoala cierto. Ya está arreglado, siento muchísimo el error

angrykoala commented 7 years ago

No problem @gDanix , me gustan los diagramas que has puesto, ¿podriamos cambiar el nombre "Api de mantenimiento" a otra cosa? (scrapers API o lo que sea...)

JJ commented 7 years ago

Sin problema, hombre. Un buen trabajo. Sube también los fuentes cuando puedas. Me sigue gustando más la opción 1. Si tenéis alguna buena razón para la opción 2, estoy dispuesto a escucharla.

gDanix commented 7 years ago

Ok, ya están subidos también los archivos fuente. Están comprimidos en zip porque GitHub no te deja adjuntar el tipo de archivos que he generado.

@angrykoala sin problema, lo llamé así por diferenciarlo de la API de consulta (o clientes o lo que sea), pero lo podemos llamar como querais.

@JJ En realidad, tanto en un modelo como en otro se pueden implementar las mismas medidas de seguridad, y se tiene la misma funcionalidad. Si bien es cierto que Solr utiliza una interfaz web, es porque realiza un indexado complejo que requiere cierto procesamiento, mientras que nuestra aplicación es mucho más sencilla, por lo que, siguiendo ese criterio, no sería estrictamente necesaria esa API.

angrykoala commented 7 years ago

@JJ

  1. Simplifica la implementación de los scrapers
  2. Desacopla la BBDD que estemos usando por debajo (cambiar la BBDD o implementar cache no afectaria a la implementación de los scrapers)
    • Facilitará versionado de webscrapers, por ejemplo, actualizar la BBDD y seguir teniendo scrapers antiguos
  3. Nos permite validar los datos en el servidor, evitando problemas de implementación en los scrapers/huecos en seguridad
    • Por ejemplo: scraper de comedores intenta modificar datos de notas
    • @gDanix Con la opción 1, la seguridad debe estar en todos los scrapers, si uno es vulnerable, toda la BBDD podría resultar comprometida y practicamente hay que olvidarse de que un tercero añada un custom scraper. en la opción 2, en el peor de los casos se comprometen los datos de ese scraper, y siempre siendo datos válidos pues la comprobación se hace en el servidor,
  4. Si en algún momento optamos por una arquitectura más compleja (por ejemplo la opción con cola de mensajes) es más facil cambiar una interfaz scraper/api a algo con mensajes que cambiar el acceso a la db de todos los scrapers

En general, son las ventajas que se pueden obtener de desacoplar cualquier sistema externo, cuantas menos interdependencias tengamos, más fácil es cambiarlo y testearlo

La principal desventaja de usar la opción 2 (al menos que yo vea, si hay alguna más comentadla) es que aumenta la complejidad de la api (hay que implementar un 2º "servicio" de la api) pero me da la impresión que la complejidad de implementar una API REST con CRUD es muchisimo menor que tener accesos a la BBDD en todos los scrapers.

No se si me he perdido algo por lo que no te parezca bien la opción 2 :(

JJ commented 7 years ago

Como queráis. Vosotros sois los pro :-)

Sólo os digo que nada simplifica la implementación de un scraper.

angrykoala commented 7 years ago

Si no te gusta es que habrá alguna cosa, mejor saber ahora las pegas que no descubrirlas a medio camino

Me imagino, por eso creo que es mejor quitar toda la complejidad de los scrapers que no sea exclusiva del propio scraping

JJ commented 7 years ago

Si se descubren a medio camino, se refactoriza y listo. Únicamente os repito lo de antes, ponéis el interfaz web como un bloque monolítico y no tiene por qué serlo. Pueden ser diferentes interfaces a diferentes servicios.

gDanix commented 7 years ago

Esta nueva propuesta creo que soluciona los problemas de las otras dos:

screenshot_20170728_231350

Fuente: diagrama SerU V3.zip

JJ commented 7 years ago

Me parece estupendo.

¿Puedes subir la fuente al repo?