[JAVA] J'ai réfléchi à la façon de le rendre sans serveur tout en évitant le verrouillage des fournisseurs

Ceci est l'article du 19ème jour du Calendrier de l'Avent Architecture sans serveur 2016.

Alors qu'une configuration d'architecture sans serveur est susceptible d'avoir des avantages en termes de coûts opérationnels, elle dépend fortement d'un fournisseur de cloud particulier pour un trajet simple. Si possible, j'aimerais voir si API Gateway ou Lambda d'AWS met soudainement fin à son service. Par conséquent, sur la base de la définition de Swagger, j'ai créé un outil appelé Swagger Code Builder afin qu'il puisse être utilisé avec plusieurs types de configurations.

Il est similaire à Swagger CodeGen, mais la structure du projet est très différente, donc [swagger-parser](https://github.com/swagger- J'ai essayé de le recréer en détournant uniquement api / swagger-parser).

Composition visée

Configuration normale

\o/         +-----+   +-----------+
 | -------->|Nginx|-->|File System|
/ \         +-----+   +-----------+
User           |
               |
               |
               |  +---------------+   +----+   +-----+
               +->|Spark Framework|-->|Java|-->|MySQL|
                  +---------------+   +----+   +-----+

Le Spark Framework (http://sparkjava.com/) est un microframework Java similaire à Sinatra en Ruby et Flask en Python. Spring Boot allait bien, mais j'ai choisi celui qui semblait plus léger (je vous expliquerai plus tard, mais cela a peut-être été un échec). Veuillez également vous référer aux Articles précédents concernant l'utilisation de Spark Framework.

Configuration sans serveur

\o/         +----------+   +--+
 | -------->|CloudFront|-->|S3|
/ \         +----------+   +--+
User              |
                  v
            +-----------+   +------+   +---------+
            |API Gateway|-->|Lambda|-->|Dynamo DB|
            +-----------+   +------+   +---------+

Je pense qu'il existe différentes manières d'utiliser Cognito pour l'authentification, mais je me concentrerai une fois sur cette configuration. Même s'il s'agit de Lambda, Java l'est parce que de nombreuses personnes dans l'entreprise d'aujourd'hui peuvent utiliser Java. Si vous utilisez plus de JavaScript, node.js et Express semblent être meilleurs. Personnellement, je préfère Python et Flask, mais il semble y avoir quelque chose qui s'appelle Zappa dans ce champ. Il diffère de la rumeur Serverless Framework en ce qu'il vise à être compatible.

stratégie

Couche contrôleur

Générez automatiquement du code pour chaque configuration à partir de la définition Swagger, ce qui vous permet d'écrire du code indépendant de l'appelant. Le développeur écrit le code qui reçoit et renvoie le POJO selon la convention, et l'appelant convertit le code généré automatiquement selon chaque configuration.

#Modèle logique selon la convention
./swagger-code-builder \
    --structure java-services \
    --api-spec-path swagger-spec.yaml
#Modèle de composition normale
./swagger-code-builder \
    --structure sparkjava \
    --api-spec-path swagger-spec.yaml
#Modèle de configuration sans serveur
./swagger-code-builder \
    --structure java-awsserverless \
    --api-spec-path swagger-spec.yaml \
    --aws-region ap-northeast-1 \
    --aws-account-id [Account ID]

Cependant, je renonce à résoudre les dépendances sur les bibliothèques et les objets et je les écris individuellement. J'écrirai les dépendances de Gradle, le module de Guice utilisé dans Spark Framework et le constructeur de Lambda à la main. Je pense que ce domaine peut être simplifié si la DI est bien utilisée, mais ce n'est pas encore bien organisé.

En outre, le code qui convertit l'objet Spark Framework Request est automatiquement généré, mais si vous souhaitez utiliser autre chose que l'objet généré automatiquement pour la destination de conversion, cette conversion doit également être retravaillée. De plus, la génération automatique de POJO comme Swagger CodeGen est encore à moitié cuite. Je pense qu'il est également nécessaire de coopérer avec la couche de perpétuation dans ce domaine, donc je n'ai pas fait grand-chose.

En ce qui concerne les paramètres d'API Gateway, Vendor Extension est automatiquement généré. Il vous suffit donc d'exécuter les scripts de téléchargement Lambda, import-rest-api et d'accorder des autorisations. Vous pouvez également définir le CORS et la clé API dans leur ensemble en option au moment de la génération. Tout ce que vous avez à faire est de cliquer plusieurs fois sur l'écran AWS pour terminer le déploiement.

Concernant la partie qui accepte les requêtes avant Controller (proxy inverse de Nginx, Origine et Comportement de Cloud Front), je devrais réfléchir à une autre méthode en regardant Kong. pense.

Couche de persistance

Divisez le modèle en une logique (couche de service) et une partie qui lit et écrit des données spécifiques (couche d'objet d'accès aux données), et bascule avec l'injection de dépendances. Quant à DAO, j'ai écrit deux fois le code par simple calcul, il semble donc qu'une autre solution au problème soit nécessaire ici.

Manipuler DynamoDB avec JDBC semble être quelques-uns en propriétaire, mais pas en open source. RDB ← → DynamoDB gère List, Map, Set et DynamoDB ← → Cassandra semble être difficile à gérer les définitions de type. Bien qu'il ne soit pas inclus dans le corps principal, Spring aurait peut-être été meilleur compte tenu de l'existence de Spring Data DynamoDB.

finalement

Swagger Code Builder est toujours un outil difficile, mais il est en fait utilisé dans le développement de petits outils internes. En particulier, je pense qu'il est très reconnaissant que vous n'ayez pas à vous soucier de l'intégration d'API Gateway à l'écran. Si vous souhaitez développer une architecture sans serveur qui évite le blocage du fournisseur, veuillez l'essayer. Nous attendons vos commentaires et vos problèmes avec impatience.