EXTERNAL APP SERVICE WEB SERVICE TV SERVICE EXTERNAL SERVICE AGGREGATION SERVICE META AUTH PAYMENT ETC (Components) CLIENTS AGGREGATION SERVICE BACKEND MICROSERVICE
called by client. - The role of aggregating each data after checking what data is required through front API services Aggregation services Backend services - Server components responsible for multiple business logic - Such as authorization, contents playing, payment and movie meta etc .. Front API services - Manage the client-specific authentication and API invocation
Armeria (https://armeria.dev) - Powered by LINE (current version : 1.12.0) - Go-to microservice framework - Support gRPC, Thrift, Kotlin, Retrofit, Reactive Streams, Spring Boot and Dropwizard.
Armeria (https://armeria.dev) - Support HTTP/2 - Integration with gRPC and Thrift - gRPC-over-HTTP/1 & 2 - Thrift-over-HTTP/1 & 2 - gRPC-Web - Essential features for building microservices - Metrics - Circuit breaker - Distributed call tracing via Zipkin - Completely asynchronous and reactive - Even higher performance on Linux
Enables automatic documentation - Can be called directly from the web without using a separate gRPC testing tool (e.g. bloomRPC) - Most frequently used features ! Unlike the native gRPC server, it supports various mime-types with a single port. - application/grpc+proto - application/grpc-web+json - application/grpc-web+proto - application/grpc-web-text+proto - application/json; charset=utf-8; protocol=gRPC - application/protobuf; protocol=gRPC
– Auto documentation Example protobuf e.g. LibraryService Auto documentation Automatic protobuf-based documentation and testing like Swaggers. Documenting time is greatly reduced
team Add Title 40pt - Add your Text here / Arial, normal, 35pt - Add your Text here / Arial, normal, 35pt Add Title 40pt Add Title 40pt - Set of common frameworks and library dependencies. - Initialize project using a single-line command - Helm charts for Kubernetes - Gradle based project A set of common rules within the team auth-service payment-service meta-service
component specifications within the team - No more confusion on project settings - Building up knowledge on Boilerplate can reduce related errors later on. Applying boilerplate within the team Applying Armeria with gRPC - Most of the MSA’s concerns are included, so it can be developed quickly - Possible to focus on business logics - Can develop REST API as well as gRPC - +@ : Useful DocService function
E.g. Team A (APP) : “We need meta information in API A” - E.g. Team B (TV) : “Please include coupon information in API B” - E.g. Team C (Player) : “In the C API … .. lol” GraphQL is the best consideration for clients (APP, PC, MOBILE, and TV) Apply GraphQL for requirement implementation faster - It is always a controversial part of service development. Considered the ways to make the API faster, and easier to use - REST API + HATEOAS vs GraphQL
services - Each client can call the required schema using GraphQL query Strength Weakness - Hard to track and debug requests from clients APP WEB TV GQL query A GQL query B GQL query C GraphQL
front API service layer Manage the GraphQL queries and support the authentication. APP WEB TV EXTERNAL APP SERVICE WEB SERVICE TV SERVICE EXTERNAL SERVICE GraphQL META AUTH PAYMENT ETC ETC ETC Uses GraphQL as a microservices aggregator GQL query
front API service layer E.g. API-Request of the purchased list on TV TV TV SERVICE GraphQL META AUTH PAYMENT ETC ETC ETC /v1/libraries GQL query Meta Library, Auth libraryGroups { … rightContext { deviceUseContext { … } }, product { title } }
Possible for versioning GraphQL query and history management for each client - Both of the strengths of GraphQL and the Rest API can be utilized (hybrid). Apply to the front API service layer Use GraphQL as a microservices aggregator - Get closer to the client team (?) - Elegantly solve N+1 problems using the graphql batch dataLoader - The more dataLoader for the model, the faster speed in development - Since GraphQL is flexible, it is necessary to design the initial schema well
- Provides Zipkin Tracing Integration from Armeria - Easily connects to existing legacy Springboot components (using Sleuth, Brave) - Support storages : Cassandra, MySQL, Elasticsearch - Can be easily setup using zipkin-server, zipkin-ui and zipkin-dependency - Combination of Zipkin and Elasticsearch is considered the most flexible Zipkin (https://zipkin.io)
components - Request from the same thread are not guaranteed. - (Important) Should try not to lose the TraceContext in the same request. In an asynchronous environment (Reactive, Coroutine)
components E.g. Case in which TraceContext was delivered abnormally (losing TraceContext) TV SERVICE GraphQL META AUTH CONFIG (Thread-1) spanB (losing spanA) /v1/libraries spanA (Thread-2) spanC (losing spanA) (Thread-3) spanD (losing spanA) /v1/libraries - spanA spanB spanC spanC Untraceable – Each request is recognized as one request
components - When converting to Mono or Flux, need to pass TraceContext if running in different ThreadPool - Or pre-specify with subscribeOn so that it can be executed in one Thread In reactive
components - Like reactive, this can be solved by injecting a CoroutineContext - Armeria will support coroutine context injection in version 1.12.0 In coroutine
line_devday2021
trycycle
databricksjapan
infiniteloop_inc
itkq
mitsuzono
baseballyama
bkuhlmann
kaz1437
hirotomotaguchi
wmsbill
__allllllllez__
masahirokawahara
revolveconf
chrislema
wjessup
phodgson
quramy
jcasabona
bcantrill
addyosmani
jmmastey
lara
brianwarren
jnunemaker
