This project is a simple skeleton code for microservice architecture pattern using Spring Cloud, Spring Boot, and Docker. Thanks to Piggy Metrics which has inspired and given really good knowledge for setting up this project.
By now, the functional services are still decomposed into three core services. Each of them can be tested, built, and deployed independently.
Provides several API for user authentication and authorization with OAuth 2.0.
Method | Path | Description | Scope |
---|---|---|---|
POST | /uaa/oauth/token | Get new access token and refresh access token | ui |
POST | /uaa/oauth/logout | Logout to revoke access token | ui |
Contains API related to creating and retrieving all user information. In this service, we are also demonstrating how we use
user's privilege in accessing the API. For example, the access to GET
/accounts
endpoint will only be allowed for user whose READ_BASIC_INFORMATION
privilege, but the access
to other endpoints don't require any special privilege as long as it has correct scope. Please refer to spring security docs here for more details.
Method | Path | Description | Scope | Privilege |
---|---|---|---|---|
POST | /accounts | Create new account | ui | ALL_ACCESS |
GET | /accounts | Get All user informations | ui | READ_BASIC_INFORMATION |
GET | /accounts/{username} | Get account with username | server | ALL_ACCESS |
GET | /accounts/current | Get current account data | ui | ALL_ACCESS |
[WIP aka Work In Progress]
- Each microservice has it's own database and there is no way to access the database directly from other services.
- The services in this project are using MySQL for the persistent storage. In other case, it is also possible for one service to use any type of database (SQL or NoSQL).
- Service-to-service communiation is done by using REST API. It is pretty convenient to use HTTP call in Spring since it provides a simplify HTTP layer service called Feign (discussed later). For the next iteration, I'm also planningto use asyncronous message transfer using Apache Kafka since Kafka will allow us to send message to several service easily.
Spring Cloud is a really good web framework that we can use for building a microservice infrastructure since it provides broad supporting tools such as Load Balancer, Service registry, Monitoring, and Configuration.
Image source: PiggyMetrics
Spring Cloud Config is horizontally scalable centralized configuration service for distributed systems. It uses a pluggable repository layer that currently supports local storage, Git, and Subversion.
For the purpose of proof-of-concept, we just use spring native profile
, which simply loads config file from local classpath. You can see that we have shared
diretory in Config service resource. When a service (e.g. Account-service) wants to request it's configuration, the config service will response with shared/service-account.yml
and shared/application.yml
(which is shared among all services).
Just build Spring Boot application with spring-cloud-starter-config
dependency, autoconfiguration will do the rest.
Now you don't need any embedded properties in your application. Just provide bootstrap.yml
with application name and Config service url:
spring:
application:
name: notification-service
cloud:
config:
uri: http://config:8888
fail-fast: true
Authorization responsibilities are completely extracted to separate server, which grants OAuth2 tokens for the backend resource services. Auth Server is used for user authorization as well as for secure machine-to-machine communication inside a perimeter.
This project only uses two type of authorizations, they are Password credentials
grant type for users authorization and Client Credentials
grant for microservices authorization.
There are two ways of storing the authorization token granted for users. First, we can us in memory database provided by Spring security oauth2 library. Second, we can use persistent storage such as (MySQL, MongoDB, PostgresSQL, etc) to keep access tokens, refresh tokens and client credentials. In this project, I'm using MySQL database to keep all authorization information along with the database schema that will be executed by flyway. To change the implementation into in-memory database, simply:
- Comment
@Configuration
,@EnableAuthorizationServer
and@EnableWebSecurity
inJdbcOAuth2Config.java
andJdbcServerSecurityConfig.java
. - Comment out
@Configuration
,@EnableAuthorizationServer
and@EnableWebSecurity
inInMemoryOAuth2Config.java
andInMemoryWebSecurityConfig.java
- Build the program.
Spring Cloud Security provides convenient annotations and autoconfiguration to make this really easy to implement from both server and client side. You can learn more about it in documentation and check configuration details in Auth Server code.
From the client side, everything works exactly the same as with traditional session-based authorization. You can retrieve Principal
object from request, check user's roles and other stuff with expression-based access control and @PreAuthorize
annotation.
Each client in this application (service-account, service-auth, and service-notification) has a scope: server
for backend services, and ui
- for the browser. So we can also protect controllers from external access, for example:
@PreAuthorize("#oauth2.hasScope('server')")
@RequestMapping(method = RequestMethod.POST)
public void createUser(@Valid @RequestBody User user) {
userService.create(user);
}
In addition, I also use role and privilege authorization for several endpoints in this project to protect the controller from unauthorized access. To add specific authorization checking, we can use hasAuthority()
or hasRole()
as the parameter of the @PreAuthorize
annotation. For example:
@PreAuthorize("hasAuthority('READ_BASIC_INFORMATION')")
@RequestMapping(path = "/", method = RequestMethod.GET)
public ResponseEntity<AccountResponse> getAllAccounts() {
AccountResponse response = new AccountResponse();
response.accounts = accountService.findAll();
return new ResponseEntity<>(response, HttpStatus.OK);
}
I use MySQL for persistent data storage for several services in this application. To help me in doing some database schema migration, I use Flyway by boxfuse to help me creating all tables and updating the schema.
To use flyway in Spring application, simply define this configuration in service config file and put all migration scripts in db/migration
under resources folder.
flyway:
url: jdbc:mysql://service-auth-db:3306/auth
user: ${SERVICE_AUTH_DB_USER}
password: ${SERVICE_AUTH_DB_PASSWORD}
locations: classpath:db/migration
enabled: true
Using flyway in this project is really simple because we don't have to explicitly run migration command. Spring will handle this process for us.
As you can see, there are three core services, which expose external API to client. In a real-world systems, this number can grow very quickly as well as whole system complexity. Actualy, hundreds of services might be involved in rendering one complex webpage.
In theory, a client could make requests to each of the microservices directly. But obviously, there are challenges and limitations with this option, like necessity to know all endpoints addresses, perform http request for each peace of information separately, merge the result on a client side. Another problem is non web-friendly protocols, which might be used on the backend.
Usually a much better approach is to use API Gateway. It is a single entry point into the system, used to handle requests by routing them to the appropriate backend service or by invoking multiple backend services and aggregating the results. Also, it can be used for authentication, insights, stress and canary testing, service migration, static response handling, active traffic management.
Netflix opensourced such an edge service, and now with Spring Cloud we can enable it with one @EnableZuulProxy
annotation. In this project, I use Zuul to store static content (ui application) and to route requests to appropriate microservices. Here's a simple prefix-based routing configuration for Notification service:
zuul:
routes:
service-auth:
path: /uaa/**
url: http://service-auth:5000
stripPrefix: false
sensitiveHeaders:
service-account:
path: /accounts/**
serviceId: service-account
stripPrefix: false
sensitiveHeaders:
That means all requests starting with /uaa
will be routed to Authentication service and /accounts
will be forwarded to account service. There is no hardcoded address, as you can see. Zuul uses Service discovery mechanism to locate Notification service instances and also Circuit Breaker and Load Balancer, described below.
Another commonly known architecture pattern is Service discovery. It allows automatic detection of network locations for service instances, which could have dynamically assigned addresses because of auto-scaling, failures and upgrades.
The key part of Service discovery is Registry. I use Netflix Eureka in this project. Eureka is a good example of the client-side discovery pattern, when client is responsible for determining locations of available service instances (using Registry server) and load balancing requests across them.
With Spring Boot, you can easily build Eureka Registry with spring-cloud-starter-eureka-server
dependency, @EnableEurekaServer
annotation and simple configuration properties.
Client support enabled with @EnableDiscoveryClient
annotation an bootstrap.yml
with application name:
spring:
application:
name: servuce-account
Now, on application startup, it will register with Eureka Server and provide meta-data, such as host and port, health indicator URL, home page etc. Eureka receives heartbeat messages from each instance belonging to a service. If the heartbeat fails over a configurable timetable, the instance will be removed from the registry.
Also, Eureka provides a simple interface, where you can track running services and number of available instances: http://localhost:8761
Ribbon is a client side load balancer which gives you a lot of control over the behaviour of HTTP and TCP clients. Compared to a traditional load balancer, there is no need in additional hop for every over-the-wire invocation - you can contact desired service directly.
Out of the box, it natively integrates with Spring Cloud and Service Discovery. Eureka Client provides a dynamic list of available servers so Ribbon could balance between them.
Hystrix is the implementation of Circuit Breaker pattern, which gives a control over latency and failure from dependencies accessed over the network. The main idea is to stop cascading failures in a distributed environment with a large number of microservices. That helps to fail fast and recover as soon as possible - important aspects of fault-tolerant systems that self-heal.
Besides circuit breaker control, with Hystrix you can add a fallback method that will be called to obtain a default value in case the main command fails.
Moreover, Hystrix generates metrics on execution outcomes and latency for each command, that we can use to monitor system behavior.
Feign is a declarative Http client, which seamlessly integrates with Ribbon and Hystrix. Actually, with one spring-cloud-starter-feign
dependency and @EnableFeignClients
annotation you have a full set of Load balancer, Circuit breaker and Http client with sensible ready-to-go default configuration.
Here is an example from Account Service:
@FeignClient(name = "service-auth")
public interface AuthServiceClient {
@RequestMapping(method = RequestMethod.POST, value = "/uaa/users", consumes = MediaType.APPLICATION_JSON_UTF8_VALUE)
void createUser(User user);
}
- Everything you need is just an interface
- You can share
@RequestMapping
part between Spring MVC controller and Feign methods - Above example specifies just desired service id -
service-auth
, thanks to autodiscovery through Eureka (but obviously you can access any resource with a specific url)
In this project configuration, each microservice with Hystrix on board pushes metrics to Turbine via Spring Cloud Bus (with AMQP broker). The Monitoring project is just a small Spring boot application with Turbine and Hystrix Dashboard.
See below how to get it up and running.
Let's see our system behavior under load: A service calls another service and it responses with a vary imitation delay. Response timeout threshold is set to 1 second.
[WIP]
- Install docker and docker compose
- Export environment variables:
SW_CONFIG_SERVICE_PASSWORD
,MSW_ROOT_PASSWORD
,MSW_DB_USER
,MSW_DB_PASSWORD
,MSW_SERVICE_ACCOUNT_PASSOWRD
,MSW_DB_TEST_PASSWORD
.
In production mode, all images will be pulled from docker hub.
docker-compose up -d
For development mode, all source code will be compiled and packaged as a jar. These jar files will be used later for creating the image for every service. To build, use this command:
docker-compose -f docker-compose.yml -f docker-compose.dev.yml up
- http://localhost:80 - Gateway
- http://localhost:8761 - Eureka Dashboard
- http://localhost:9000/hystrix - Hystrix Dashboard (paste Turbine stream link on the form)
- http://localhost:8989 - Turbine stream (source for the Hystrix Dashboard)
- http://localhost:15672 - RabbitMq management (default login/password: guest/guest)
[TBD]
[TBD]
*This part is taken from PiggyMetrics with some adjustment because there is no significant differences in the way I use it