Microservice architecture The anatomy of a microservice can be varied, as shown in figure 1.7, but design similarities are bound to occur. These elements can be grouped together to form the applicationcomponent layers. It’s important to provide test coverage at each layer, and you’ll likely be presented with new challenges along the way; we’ll address these challenges and offer solutions throughout the book. Microservice architecture 9 Resource (REST API) Figure 1.8 The resource component publicly exposes the service. Let’s look at these microservice component layers from the top down. NOTE A microservice should encapsulate and expose a well-defined area of logic as a service. That doesn’t mean that you can’t allow interaction from other systems by other means. For example, your service may expose specific documents that are stored in Elasticsearch (ES). In such a case, it’s perfectly legitimate for other applications to talk natively to ES in order to seed the documents. 1.3.1 Resource component Resources are responsible for exposing the service interaction via a chosen protocol. This interaction occurs using mapped objects, usually serialized using JSON or XML. These mapped objects represent the input and/or output of the business domain. Sanitization of the incoming objects and construction of the protocol-specific response usually occur at this layer; see figure 1.8. NOTE Now that we’re here, it’s worth mentioning that the resource-component layer is the layer that puts the micro in microservice. For the rest of this book, and for the sake of simplicity, we’ll focus on the most common form of resource providers today: RESTful endpoints. 1 If you aren’t familiar with RESTful web services, please take the time to research and understand this important topic. 1.3.2 Business-domain component The business-domain component is the core focus of your service application and is highly specific to the logical task for which the service is being developed. The domain may have to communicate with various other services (including other microservices) in order to calculate a response or process requests to and from the resource component; see figure 1.9. A bridge is likely to be required between the domain component and the resource component, and possibly the remote component. Most microservices need to communicate with other microservices at some point. 1.3.3 Remote resources component This component layer is where your piece of the jigsaw puzzle may need to connect to the next piece, or pieces, of the picture. It consists of a client that understands how to send and receive resource objects to and from other microservice endpoints, which it 1 See “What Are RESTful Web Services?” in the Java EE 6 tutorial, http://mng.bz/fIa2. Business domain Figure 1.9 The businessdomain component is your service’s business logic. 10 CHAPTER 1 An introduction to microservices Remote resources Figure 1.10 The remote resources component is the gateway to other services. then translates for use in the business component layer; see figure 1.10. Due to the nature of remote resources, you must pay special attention to creating a resilient design. A resilient framework is designed to provide features such as circuit breakers and timeout fallbacks in the event of a failure. Don’t try to reinvent the wheel: several resilient frameworks are available to choose from, including our top pick, Hystrix (https://github.com/Netflix/Hystrix/wiki), which is open source and contributed by Netflix. A gateway service should act as a bridge between the domain component and the client component. It’s responsible for translating request-and-response calls to and from any remote resource via the client. This is the best place to provide a graceful failure if the resource can’t be reached. The client is responsible for speaking the language of your chosen protocol. Nine times out of ten, this will be JAX-RS (https://jax-rs-spec.java.net) over HTTP/S for RESTful web services. We highly recommend the open source services framework Apache CXF (http://cxf.apache.org) for this layer, because it’s fully compliant with JAX-WS, JAXRS, and others, and it won’t tie you down to a specific platform. 1.3.4 Persistence component More often than not, an application requires some type of persistence or data retrieval (see figure 1.11). This usually comes in the form of an object-relational mapping (ORM)2 mechanism, such as the Java Persistence API (JPA),3 but could be something as simple as an embedded database or properties file


Q- using a e-commerce application try to apply all the information is the last article oky