Extracting the Delivery Service - Step 4: using new Delivery Service

This article describes the fourth step in the process of extracting the Delivery Service from the FTGO application monolith. The previous articles are as follows:

  1. About the FTGO monolith
  2. Step 1: Split the code
  3. Step 2: Split database
  4. Step 3: Create and deploy the Delivery Service

After step 3, the Delivery Service is deployed but unused. The fourth step is to route production traffic to the Delivery Service.

First, we must change the FTGO application’s order management logic to invoke the service to schedule, and cancel deliveries. This is accomplished by defining a DeliveryServiceProxy class, which implements the DeliveryService, and sends command messages to the Delivery Service.

Second, we must route some requests from the courier’s mobile application to the Delivery Service instead of the FTGO application This is accomplished by introducing an API gateway that routes requests to either the FTGO application or the Delivery Service.

The following diagram shows the revised architecture.

Module structure

The following diagram shows the new module structure:

There are two new modules:

Lets look at each of the changes starting with the DeliveryServiceProxy class.

The DeliveryServiceProxy class

The FTGO application’s order management logic invokes delivery management via the DeliveryService interface. The DeliveryServiceProxy class, which is in the ftgo-delivery-service-proxy module, implements that interface by sending command messages to the Delivery Service using the Eventuate Tram Command API:

public class DeliveryServiceProxy implements DeliveryService {

  @Override
  public void scheduleDelivery(LocalDateTime readyBy, Long orderId, long restaurantId, Address deliveryAddress) {
    String commandId = commandProducer.send(DeliveryServiceChannels.DELIVERY_SERVICE_CHANNEL,
            new ScheduleDelivery(readyBy, orderId, restaurantId, deliveryAddress),
            "Dont_Care",
            Collections.emptyMap());
  }

...

Let’s now look at how the @Bean for the DeliveryServiceProxy is configured.

Toggling between the old and new implementations of delivery management

We could simply define an @Bean for the DeliveryServiceProxy in one of the FTGO application’s @Configuration classes. However, when extracting functionality into a service, it’s often useful to be able to switch back to the old implementation when unexpected errors occur. In this particular example, we can use the Spring framework’s profile mechanism to implement a feature flag for toggling between the old and new implementations of delivery management.

There are two @Configuration classes in the ftgo-delivery-service-proxy module The first configures the FTGO application to use the DeliveryServiceProxy. It’s only enabled when the RemoteDeliveryService profile is active.

@Configuration
@Import(TramCommandProducerConfiguration.class)
@Profile("RemoteDeliveryService")
public class DeliveryServiceRemoteConfiguration {

  @Bean
  public DeliveryService deliveryServiceProxy(CommandProducer commandProducer) {
    return new DeliveryServiceProxy(commandProducer);
  }
}

The second @Configuration configures the FTGO application to use the existing embedded delivery management logic. It’s enabled when the RemoteDeliveryService profile is not active.

@Configuration
@Import(DeliveryServiceWebConfiguration.class)
@Profile("!RemoteDeliveryService")
public class DeliveryServiceEmbeddedConfiguration {
}

Both @Configuration classes are @Imported by FtgoApplicationMain:

@Configuration
@EnableAutoConfiguration
@Import({
        ...
        DeliveryServiceEmbeddedConfiguration.class,
        DeliveryServiceRemoteConfiguration.class,
        ...
        })
public class FtgoApplicationMain {
...

With these two @Configuration classes defined, the FTGO application will only use the Delivery Service when the RemoteDeliveryService profile is active. We can, for example, activate the profile using -Dspring.profiles.active=RemoteDeliveryService on the command line or by setting the SPRING_PROFILES_ACTIVE=RemoteDeliveryService environment variable.

API gateway

The API gateway, which is implemented by the ftgo-api-gateway module, routes requests to either the Delivery Service or the FTGO application. Specifically, it routes all requests to the FTGO application except for those handled by the Delivery Service’s DeliveryController.

The API gateway is built using Spring Cloud API Gateway. The ApiGatewayConfiguration @Configuration class defines a RouteLocator @Bean, which configures the routes.

@Configuration
@EnableConfigurationProperties({ApiGatewayDestinations.class})
public class ApiGatewayConfiguration {

  @Bean
  public RouteLocator routing(RouteLocatorBuilder builder, ApiGatewayDestinations apiGatewayDestinations) {
    return builder.routes()

            // route to Delivery Service - DeliveryController

            .route(r -> r.path("/couriers/**/availability").uri(apiGatewayDestinations.getDeliveryServiceUrl()))
            .route(r -> r.path("/orders/**/pickedup").uri(apiGatewayDestinations.getDeliveryServiceUrl()))
            .route(r -> r.path("/orders/**/delivered").uri(apiGatewayDestinations.getDeliveryServiceUrl()))

            // everything else goes to monolith

            .route(r -> r.path("/**").uri(apiGatewayDestinations.getFtgoApplicationUrl()))
            .build();
  }

}

End-to-end testing

Because the FTGO application can either use the old, embedded delivery management logic or the new Delivery Service, there are two versions of the end to end tests.

  • monolith (./build-and-test-ftgo-monolith.sh) - deploys the FTGO application along with the necessary infrastructure services and tests the monolith’s REST API.

  • microservices (./build-and-test-ftgo-microservices.sh) - deploys the FTGO application, Delivery Service and API Gateway and make HTTP requests to the API Gateway.

Git commits

These changes are in the extract-delivery-service-04-use-service branch and consist of a single commit

What’s next



Copyright © 2024 Chris Richardson • All rights reserved • Supported by Kong.

About Microservices.io

Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original CloudFoundry.com, and the author of Microservices patterns.

New workshop: Architecting for fast, sustainable flow

Enabling DevOps and Team Topologies thru architecture

DevOps and Team topologies are vital for delivering the fast flow of changes that modern businesses need.

But they are insufficient. You also need an application architecture that supports fast, sustainable flow.

Learn more and register for my June 2024 online workshops....

NEED HELP?

I help organizations improve agility and competitiveness through better software architecture.

Learn more about my consulting engagements, and training workshops.

LEARN about microservices

Chris offers numerous other resources for learning the microservice architecture.

Get the book: Microservices Patterns

Read Chris Richardson's book:

Example microservices applications

Want to see an example? Check out Chris Richardson's example applications. See code

Virtual bootcamp: Distributed data patterns in a microservice architecture

My virtual bootcamp, distributed data patterns in a microservice architecture, is now open for enrollment!

It covers the key distributed data management patterns including Saga, API Composition, and CQRS.

It consists of video lectures, code labs, and a weekly ask-me-anything video conference repeated in multiple timezones.

The regular price is $395/person but use coupon GIVLKECM to sign up for $145 (valid until June 19th, 2024). There are deeper discounts for buying multiple seats.

Learn more

Learn how to create a service template and microservice chassis

Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.

Signup for the newsletter


BUILD microservices

Ready to start using the microservice architecture?

Consulting services

Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,


The Eventuate platform

Use the Eventuate.io platform to tackle distributed data management challenges in your microservices architecture.

Eventuate is Chris's latest startup. It makes it easy to use the Saga pattern to manage transactions and the CQRS pattern to implement queries.


Join the microservices google group

Topics

Note: tagging is work-in-process

DDD   ·  GitOps   ·  Microservices adoption   ·  ancient lore   ·  anti-patterns   ·  api gateway   ·  application api   ·  application architecture   ·  architecting   ·  architecture   ·  architecture documentation   ·  assemblage   ·  beer   ·  books   ·  build vs buy   ·  containers   ·  dark energy and dark matter   ·  deployment   ·  deployment pipeline   ·  design-time coupling   ·  developer experience   ·  development   ·  devops   ·  docker   ·  eventuate platform   ·  fast flow   ·  generative AI   ·  glossary   ·  health   ·  hexagonal architecture   ·  implementing commands   ·  implementing queries   ·  inter-service communication   ·  kubernetes   ·  loose coupling   ·  microservice architecture   ·  microservice chassis   ·  microservices adoption   ·  microservices rules   ·  microservicesio updates   ·  modular monolith   ·  multi-architecture docker images   ·  observability   ·  pattern   ·  refactoring to microservices   ·  resilience   ·  sagas   ·  security   ·  service api   ·  service architecture   ·  service blueprint   ·  service collaboration   ·  service design   ·  service discovery   ·  service granularity   ·  service template   ·  software delivery metrics   ·  success triangle   ·  tacos   ·  team topologies   ·  testing   ·  transaction management   ·  transactional messaging   ·  wardley mapping

All content


Posts

20 Mar 2024 » A tour of two sagas
21 Dec 2023 » Thoughts about team size
24 Jul 2017 » Revised data patterns