Shulou(Shulou.com)05/31 Report--

This article will explain in detail what are the requirements and principles of SOA/ micro-service. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Concept

According to the definition, the core of SOA can be divided into two important contents: one is to find coarse-grained reusable services according to the business modeling and architecture design process; the other is that these services can be combined, assembled and choreographed to meet the needs of business processes. The former focuses on the ESB service bus, while the latter focuses on the related business capabilities of BPM and BPEL.

Design

Problems to be solved in order of priority: decoupling, reuse, orchestration, control

Decoupling

Through business modeling and architecture analysis, a complete business system should be divided into multiple business components according to the principle of loose coupling, and the business components are finally transformed into application modules (service components + technical components) in the implementation of the application system. Each component is relatively independent and can be independently analyzed, designed, developed, tested, deployed and managed by subsequent operations and maintenance.

To achieve complete decoupling, not only the business layer components, but also the underlying data sources should be completely separated.

Components should provide services, not CRUD in the form of channels.

The service itself is a lightweight API. It doesn't matter whether the communication is webservice,rest or message. The important thing is that the service interface and contract remain the same.

Reuse

The purpose of the service is not only to solve the interaction between components, but also to achieve the goal that the service can loosely couple the components. In order to meet the reusability of services, it is necessary to consider that on the basis of each business module, there should be a lower-level basic public module that provides common capabilities, which provides shared reusable service capabilities.

Technical components: security, message, cache, file, log, exception, process engine, etc.

Arrangement

The granularity of component partitioning requires detailed design, and domain activities within each component may rely on multiple services or even other components. At this point, it is necessary to ensure that there is no chaotic cross-invocation between components. The implementation of business processes or complex business logic should reflect the idea of service assembly or service orchestration.

The fewer other component services that depend on activities in the component domain, the better.

The orchestration service avoids distributed transaction processing as far as possible, and we need to consider the self-implementation of transaction management scheme.

Other services within a component domain activity are not dependent on that component.

Maintain the independence of services within components, avoid business overlap, and reconsider the design of services once business overlap is found.

Control

A business system can choose to implement the simplest service bus, also known as the system internal lightweight ESB.

This is not done for UDDI's unified service catalog library. However, after the service of the business system itself, there will be a large number of service consumption and calls between components, a business system needs unified control of these business access calls, including service operation monitoring, security and authentication, unified service address and so on. These are the basic needs.

Of course, it doesn't matter if there is no service bus in the real sense. After a business system is serviced, it is easy to implement and access to an ESB under a standard modular service architecture. This is not the focus of business systems based on SOA architecture. Including the current OSGI framework, it does not fully meet the requirements of lightweight ESB bus. On the other hand, more complexity in implementation is introduced to the business system.

So much for sharing the requirements and principles of SOA/ micro-service. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.