Choosing SOA means expressing business processes or functions with services, and the granularity of services directly affects the quality of services, including flexibility and efficiency. Therefore, choosing the right granularity is crucial for service design. Because I was always asked, I had the idea to write something about "service granularity" before the festival, but I didn't expect it to bother me throughout the National Day. Looking back, one of the important reasons for this is that the industry has not formed a very clear answer to this. What granularity a service should choose is basically a subjective measure at present, and there is no strict standard to follow, which largely depends on the experience of the designer.
What is the granularity of service? Generally speaking, service granularity refers to the size of the functions contained in a service. For example, for the business acceptance in the Telecom 97 system, submitting customer orders is a typical coarse-grained service, and a series of internal operations of this order submission service are realized, such as creating customer information and generating customer orders. Recording product attributes, updating accounting relationships, etc. may become a series of fine-grained services. Fine-grained services provide relatively small units of functionality, or exchange small amounts of data. Completing complex business logic often requires orchestrating a large number of such fine-grained services, which can only be achieved through multiple service request interactions. On the contrary, coarse-grained services encapsulate a large block of business/technical capabilities in an abstract interface, reducing the number of service request interactions, but it will also bring the complexity of service implementation and a large number of interactions. data, and therefore cannot be flexibly changed to accommodate changes in demand. Just like everything has two sides, the service granularity can't be too big or too small, it should be the right size. A good SOA architecture design must maintain a balance in the service granularity design to obtain the benefits of cost reduction and flexible response.
Although there is no Bible that allows us to correctly design the granularity of services, we can draw some rules of thumb that can help us choose the correct granularity of services from the design practice of many trade-offs associated with it. To identify and design a service with moderate granularity, we can mainly consider the following three aspects.
Reusability Reusability refers to the ability of a service to be used in different contexts. Reuse can be said to be the core thinking of SOA. Through reuse, various benefits such as reducing development and maintenance costs, shortening application delivery cycles, and improving quality can be obtained.
Consistent with any decomposition-based paradigm, the size of the granularity directly affects the reusability of the service. A simple rule of thumb is that fine-grained services are easier to reuse. In other words, the coarser the granularity, the less or more difficult a service is to be reused. Because as granularity increases, more and more business rules and contextual information are embedded in the business logic, and services gradually become business-specific. To use it, we must first understand what rules it encapsulates, otherwise we can't be confident that the service is exactly what we need. This does not mean that we should not build coarse-grained services. In fact, coarse-grained services are often still at the "business-grained" level. They allow business users and IT personnel to have direct conversations, and have direct business implications. exposed. At the same time, if we only consider reusability mechanically, it will lead to a large number of functional units with small granularity, which will have a serious impact on the overall performance and capacity of the system. Take the Lego toy that everyone often uses to describe SOA as an example, a Lego block with a minimum size of 1x1, with a standard raised interface, through which almost any other Lego block can be assembled to any imaginable object. Extensive reusability is self-evident. But when you actually try to use this granularity of building blocks to complete a complex object assembly, you may sigh: "Oh, My God! It's mission impossible!", because the time and cost paid for this is almost impossible accepted. Therefore, we need to weigh our choices of service granularity before we set out to build a beautiful world of reuse.
Here, I try to express the trade-offs in the choice of granularity of service by borrowing a well-known "law of miniskirts" from speech. "mini-skirt theory" tells us that a good speech should be "short enough to keep people interested, but long enough to cover the important part". Applied to the choice of service granularity, a well-designed service should be "fine-grained enough to be reusable, but coarse-grained enough to make business sense". Flexibility
Flexibility is the ability to easily make changes to a situation.
One of the goals of SOA is to make IT more flexible and able to adapt more quickly to a constantly changing business environment. Therefore, flexibility, as an important consideration for a well-designed service, is of course also one of the important criteria for choosing a service granularity. It is well known that fine-grained services can be assembled more easily, providing more flexibility for delivering new business functions or changing business processes. However, just thinking about flexibility will result in a large number of fine-grained services, incurring expensive development costs, and making maintenance difficult. Therefore, considering the good organization, efficiency, and development and maintenance costs of back-end services, along with business process flexibility, is critical for identifying and designing services with moderate granularity.
We know that one of the service identification methods is the top-down first-level process decomposition, until further decomposition is impossible or unnecessary, and the identified business activities are the candidate business services. Therefore, a good rule of thumb is to treat different business processes differently because not every business process needs the same flexibility. How to determine which processes need more flexibility and which processes don't, you can refer to a SAP point of view on enterprise business processes. SAP divides processes into core processes and context processes. Among them, supporting processes refer to those processes that are indispensable but do not affect the differentiation of enterprises, such as accounting management processes, etc. They focus on how to improve production efficiency and reduce production costs. So these processes in the decomposition process can end as soon as autonomous (transactionally consistent, context independent), coarse-grained services are identified because they are relatively stable. The core process refers to the unique and differentiated business process that represents the competitiveness of the enterprise, such as the marketing and sales process. They need to be broken down more fine-grained than supporting processes for maximum flexibility because they are constantly changing.
Performance
Flexibility and efficiency often appear in pairs, and performance factors are naturally one of the constraints that limit service granularity from being too large or too small. Dan Foody once suggested in his weblog that each operation execution of Webservice should be completed between 5ms and 5s. Less than 5ms or greater than 5s means that the service granularity is either too small or too large. I don't want to evaluate the guiding significance of this quantitative indicator here, but I hope to arouse everyone's thinking. It is not that the smaller or larger the service granularity, the better the system performance will be.
The complexity of a service itself and the complexity of business-to-service mapping (ie, the number of service calls required to implement a business activity) are the two main aspects that affect SOA performance. The larger the service granularity, the more functions it contains, the more complex the business logic, and theLatency increases and the response to the client becomes slower. The smaller the service granularity, the simpler the included functions. Although the execution efficiency of a single service is very high, in a business sense, the more the number of service calls required to complete a business task, the increase in the number of back-and-forth requests and responses. . Typically, services are invoked remotely, and this increased number of back-and-forth requests for responses means significant performance overhead. Therefore, in order to ensure that the performance of the service is controllable, on the one hand, it is necessary to limit the scope and complexity of the functions included in the service, that is, the service granularity cannot be too coarse; on the other hand, it is necessary to limit the number and complexity of service calls, that is, the service granularity. Not too thin. I guess that's the real reason behind the aforementioned 5ms and 5s. Obviously, the focus of the two is deviated, and in order to meet the performance requirements, a compromise needs to be made between the two.
In addition to the above points, there are other factors that may affect service granularity decisions, such as service category and scope of use. If the scope of service usage is limited, such as only in the Intra-Application category, a relatively fine-grained service interface can be selected to provide more flexibility for service requesters; as the scope expands, the service size should also expand. For example, in the category of Multi-Enterprise, services are required to provide coarse-grained and relatively stable interfaces as much as possible to ensure that service requesters use the services exposed in the system in a consistent manner. Finally, one thing to keep in mind is that the granularity of a service is not static during its life cycle. It is constantly evolving, refining, and even refactoring as the business adjusts and changes, as well as the iterative development process of the service.
The design of services involves two important concepts, one is granularity and the other is coupling.
Granularity represents the size of a service, which can be understood as the scope of service operations. For coarse-grained services, the contents of operations are wide and complex; for fine-grained services, the contents of operations are fine and simple. Coarse-grained service design can reduce the coupling between services, but the price paid is to increase the complexity of services. Services have too many functions, which increases the complexity of design and the difficulty of maintenance; fine-grained services , which can make the implementation of services simpler, but this will increase the number of services, and the services will be too detailed, so there must be some services that need to be combined to achieve certain functions, which will increase the coupling between services, as long as one of them The service has changed, it is bound to affect the whole body.
Coupling represents the relationship between services and services. The original intention of SOA is to reduce the coupling between various parts of the system so that services can be reused. But obviously, the coupling is greatly affected by the service granularity, and to some extent, the choice of granularity determines the coupling within the system.
So what should be the criteria to determine the granularity of a service? Unfortunately, after searching the Internet for various SOA introductions and various manufacturers' documents, it seems that a unified standard cannot be found, because the service granularity is often determined according to the requirements. SOA advocates that services should be coarse-grained, but such a statement is too general, and there must be fine-grained services in the system. Many coarse-grained services are just a combination of some fine-grained services. So my opinion is that there is a fine line in the rough.
My idea is to decompose services into three types, one basic service, one composite service, and one composite service.
- Basic service. Basic services are the smallest granular services provided by the system, or atomic services. Such services are designed to take advantage of their reusability, and they form the basis for some larger-grained services. The basic service can be said to be the intermediate point of integration between the original system and the segmentation of business requirements. It is not only the most fine-grained service that the original system can provide, but also the most fine-grained service of the system to be designed.
- Synthetic service. A composite service is a simple combination of basic services, just to combine basic services that have the same function but operate different business objects together to form a service that provides the same function to the outside world. It is similar to the factory pattern in the design pattern. As long as the service interface is told which business object is passed in, the service can automatically identify which basic service should be called.
- Combination services. The composite service is the most complex part of the system. It is not a simple accumulation of basic services. It is the service with the largest granularity. The relationship between the basic services is controlled by the workflow. It is a combination of basic services and workflow.
Based on the above understanding, our service design follows this design idea: first separate the basic service from the functional module, each functional module can be regarded as a composite service, and the basic service is separated from the functional module; then, on the basis of the basic service Design components and business objects; design composite services after designing components and business objects. In this way, no matter how many composite services are required and how complex the composite services are, they can be combined in various forms through basic services and workflows. And composite services often need to change, this design can ensure that these changes will not cause too much change. Their combined relationship can be represented by the following figure.
This design idea also reflects the top-down design method of SOA: functional modules -> services -> components and business objects. Service is not imagined out of thin air, it must meet the needs of customers, and the embodiment of customer needs is the function to be provided by the system, so the design of functional modules is the premise of service design. Taking our team's plan for this IBM competition as an example, in addition to understanding the business requirements given by the competition organizing committee, we also imagined some requirements ourselves. In response to these requirements, we designed the functional modules of the system. Different business roles have different business requirements, so the functional modules corresponding to different roles are also different. The following figure lists the functional modules required by financial personnel:
The system function module is the arrangement and synthesis of various services provided by the system. After the functional modules of the system are designed, the services of each functional module are extracted on this basis. A functional module may be composed of one service or multiple services.
The foundation of services is components, and some important components can be individually packaged into services. A basic service is actually a business component, which is an atomic operation based on business objects. It is a packaged component, and it only cares about the defined component interface and the objects that need to be passed, not how to implement this operation with code. Business components contain two important meanings, one is "operation" and the other is "object of operation". The design of the component is based on object-oriented. It can be said that it is a class, but it can only be an abstract class with only definition and no implementation.
The relationship between basic services, composite services, and composite services can be exemplified by the following diagram:
Order Service is a combination of various basic services, including ProdClass Service, ProdStorage Service, Customer Information Service, Msg Service, etc. . The basic service is aimed at a specific business operation object. For example, the customer information service deals with customer information, and the object it operates is customer information. The operations include basic operations such as adding, modifying, deleting, and searching. The order processing service includes various basic services, but instead of calling these basic services at the same time, it must follow a certain workflow, such as adding customer information first, then looking up product categories, product inventory, and then sending messages. The sequence is controlled by the workflow engine.
Synchronize Service is the synthesis of various basic services, including product category service (ProdClass Service), product inventory service (ProdStorage Service), customer information service (Cust Service) and so on. Compared with order processing, it is much simpler. It only needs to call the corresponding service according to the request to complete the operation, and there is no order requirement.
Although this article describes only the choice of service granularity in a business scenario, I think from the design experience of our team, we can summarize a method for selecting service granularity, that is, from top to bottom, from coarse to fine, Then from the basics to the synthesis, the combination.