Service granularity troubles

Selecting SOA means that business processes or functions are expressed by services, and the granularity of services directly affects the quality of services, including flexibility and efficiency. Therefore, selecting appropriate granularity is crucial to service design. As I was asked, I had the idea of writing something about "service granularity" before the festival. I did not expect it to disturb my National Day. Looking back, one of the most important reasons is that the industry does not have a very clear answer. What kind of granularity should a service choose? Currently, it is basically a subjective measurement, and there is no strict standard to follow. It depends largely on the experience of the designer. What is service granularity? In general, service granularity refers to the function size of a service. For example, for business acceptance in China Telecom's 9th and 7th systems, submitting customer orders is a typical coarse-grained service, and a series of internal operations such as creating customer information are implemented for this order service, generating customer orders, recording product properties, and updating accounting relationships may become a series of fine-grained services. Fine-grained services provide relatively small functional units or exchange a small amount of data. To complete complex business logic, you often need to orchestrate a large number of such fine-grained services, which can be achieved through multiple service request interactions. On the contrary, a coarse-grained Service (coarse-grained) encapsulates large business/technical capabilities in an abstract interface to reduce the number of service request interactions, however, it also brings about complexity of service implementation, interacts with a large amount of data, and therefore cannot be changed flexibly to adapt to changes in demand. Just as everything has two sides, the Service granularity cannot be too large or too small, but the size should be appropriate. A good SOA architecture design requires maintaining a balance in the design of service granularity to achieve the benefits of reduced costs and flexible response. Although there is no Bible that allows us to correctly design the granularity of the service, we can still weigh the advantages and disadvantages of the design practices, this article summarizes some empirical rules that can help you correctly select service granularity. To identify and design a moderately fine-grained service, we can consider the following three considerations. X ReusabilityReusability refers to the ability that a service can be applied to different contexts. Reuse is the core idea of SOA. It reduces development and maintenance costs, shortens application delivery cycles, and improves quality. Similar to any decomposition-based example, the granularity directly affects service reusability. A simple rule of thumb is that fine-grained services are easier to reuse. In other words, the finer the granularity, the less the service is reused or the harder it is to be reused. As the granularity increases, more and more business rules and context information are embedded into the business logic, and services become of specific business significance. To use it, we must first understand which rules it encapsulates. Otherwise, we cannot be sure that this 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 stuck at the "business-grained" layer, which allows business users and IT staff to directly talk to each other, it has direct meaning on the business and should be exposed. At the same time, if we only mechanically consider reusability, it will lead to a large number of small-granularity functional units, which will have a serious impact on the overall performance and capacity of the system. Taking Lego toys, which are commonly used to describe SOA, as a metaphor, a minimum 1x1 Lego block with a standard raised interface, it is self-evident that it can be assembled with almost any other lego building blocks to make things happen. But when you try to assemble a complex object with such a granularity, you may sigh: "Oh, My God! It's mission impossible !", Because the time and cost paid for this is almost unacceptable. Therefore, before building a better world for reuse, we need to clearly understand the choice of service granularity. Here, I borrowed a famous "mini skirt Law" about my speech to try to express the trade-offs in the choice of service granularity. "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 ". When applied to the choice of service granularity, a well-designed service should "fine-grained enough to be reusable, but coarse-grained enough to make business sense ". X FlexibilityFlexibility is the ability to easily make changes based on the situation. One of the goals of SOA is to make IT more flexible and faster to adapt to the ever-changing business environment. Therefore, flexibility, as an important consideration for well-designed services, is naturally one of the important criteria for selecting service granularity. As we all know, fine-grained services can be assembled more easily, providing more flexibility for delivering new business functions or changing business processes. However, considering Flexibility alone will lead to a large number of fine-grained services, resulting in expensive development costs and making maintenance difficult. Therefore, considering the Business Process flexibility and the good organization, efficiency, and development and maintenance costs of background services is crucial for identifying and designing services with moderate granularity. We know that one of the service identification methods is the top-down process decomposition until it cannot or does not need further decomposition. The identified business activities are candidate business services. Therefore, an effective rule of thumb is to treat different business processes differently, because not every business process requires the same flexibility. To determine which processes require more flexibility and which processes are not required, refer to SAP's Viewpoint on enterprise business processes. SAP divides the process into core process and context process ). Supported processes refer to processes that are indispensable but do not affect enterprises' differentiation, such as accounting management processes. They focus on how to improve production efficiency and reduce production costs. Therefore, in the decomposition process, once the self-governed (transaction consistency, context-independent) and coarse-grained services are identified, they can end because they are relatively stable. The core process refers to the unique and differentiated business processes that represent the competitiveness of enterprises, such as marketing and sales processes. They need to be broken down more fine-grained than supporting processes for maximum flexibility, as they change at all times. X PerformanceFlexibility and efficiency are often paired. performance factors are also one of the constraints that limit the granularity of services. Dan Foody once suggested in his weblog that the execution of each operation of Webservice should be completed between 5 ms and 5s. smaller than 5 ms 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 it will lead everyone to think that the smaller or larger the service granularity, the better the system performance. The complexity of a service and the complexity of business-to-service ing (that is, the number of service calls required to implement a business activity) are two main aspects that affect SOA performance. The larger the service granularity, the more functions it contains, the more complicated the business logic, the more network latency, and the slower the response to the client. The smaller the service granularity, the simpler the contained functions. Although the execution efficiency of a single service is very high, the more service calls required to complete a business task in the business sense, the number of response requests increases. In general, services are called remotely. This increase in the number of response requests means significant performance overhead. Therefore, to ensure the service performance is controllable, on the one hand, the scope and complexity of the service must be limited, that is, the Service granularity cannot be too rough; on the other hand, the number and complexity of service calls must be limited, that is to say, the Service granularity cannot be too small. I think this is the real reason behind 5 ms and 5 s. Obviously, the two focus is on deviation. In order to meet the performance requirements, we need to compromise between the two. In addition to the above, there are other factors that may affect service granularity decision-making, such as service category and scope of use. If the service scope is limited, for example, only in the Intra-Application Scope, you can select a relatively fine-grained service interface to provide more flexibility for the service requestor. As the scope expands, the service size should also be extended. For example, Multi-Enterprise requires the Service to provide coarse-grained and stable interfaces as much as possible, ensure that the service requestor uses the services exposed in the system in a consistent manner. The last thing to remember is that the granularity of a service is not static within its lifecycle. It is a process of service iteration and development as the business changes and changes, constantly evolving and refined, or even reconstructed. There are two reasons for writing this article: First, sort out and record the scattered cognition in your mind; more importantly, we hope that more people can talk about the ideas on this issue and strive to make it clearer and clearer. This is the original intention of this article. After all, the answer to this question comes from the test and conclusion in practice. Therefore, if you have any opinions or experience on this, I will benefit a lot from it.