Componentized, modularized, centralized, distributed, service-oriented, service-oriented architecture, microservice architecture
What is the hottest word recently? That is probably Microservice. Recently, Docker and AppOps, which have become confused, are all around the field of microservices. There are many related terms in the field of microservices. These terms have a common feature that is obscure and difficult to understand. They are like ancient Chinese words such as Dao, Qi, and Bagua. They understand as soon as they explain, they don't know when they ask, and they fight when they discuss.
This article mainly introduces several concepts related to microservices. These concepts are all personal opinions summarized by bloggers after browsing a lot of information. If there is any bias, please correct me and encourage each other.
Componentization and modularization
First, let's talk about two more common words on the front end and the mobile end: componentization and modularization (I will talk about why we should introduce componentization and modularization first).
First of all, it is certain that the central idea of componentization and modularization is divide and conquer. The purpose is to split a huge system into multiple components or modules.
Componentization
Let's first look at the introduction of Component-based software engineering in Wikipedia:
Component-based software engineering (CBSE), also known as component-based development (CBD), is a branch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system. It is a reuse-based approach to defining, implementing and composing loosely coupled independent components into systems. This practice aims to bring about an equally wide-ranging degree of benefits in both the short-term and the long-term for the software itself and for organizations that sponsor such software.
It probably means: Componentization is based on the purpose of reusability, splitting a large software system into multiple independent components in the form of separation of concerns, the main purpose is to reduce coupling.
- An independent component can be a software package, web service, web resource, or a module that encapsulates some functions. In this way, independent components can be maintained and upgraded separately without affecting other components.
Modular
The definition of Modular Programming in Wikipedia is as follows:
Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.
With modular programming, concerns are separated such that modules perform logically discrete functions, interacting through well-defined interfaces.
The purpose of modularization is to split a program into independent modules according to its functions, so that each module only contains content related to its function, and the modules are called through interfaces. After modularizing a large system, each module can be highly reused.
The difference between modularity and componentization
As can be seen from the above definition, componentization and modularization mean the same thing, and the main idea is divide and conquer. Only one called each fragment after splitting as a component, and the other called each fragment after splitting as a module. So is there any difference between the two splits in the way of splitting?
Regarding the difference between componentization and modularization, I have read a lot of information on the Internet, and no one can give an accurate answer. In fact, the reason for the inaccurate answer is also obvious, that is, most of the time we don't really need to distinguish between the two names strictly. What we have to learn is the idea and purpose of decoupling and divide and conquer.
From another perspective, if you really want to distinguish between componentization and modularization, then you can think that the purpose of the two divide and conquer is slightly different:
The purpose of modularization is to reuse. After modularization, it can be easily reused and plugged into different platforms and different business logic processes.
The purpose of componentization is to decouple, split the system into multiple components, separate component boundaries and responsibilities, and facilitate independent upgrades and maintenance.
Centralized and distributed
To talk about microservices, it must be built on a distributed basis, and there is no need to talk about microservices for a centralized system. In another article of my first knowledge of distributed systems, I introduced the difference between centralized systems and distributed systems, here is a brief review:
Centralized
The centralized system can be summarized in one sentence: a host with multiple terminals. The terminal has no data processing capability and is only responsible for data input and output. The calculation and storage are all performed on the host.
The biggest feature of the centralized system is that the deployment structure is very simple, and the bottom layer generally uses expensive mainframes purchased from manufacturers such as IBM and HP. Therefore, there is no need to consider how to deploy services on multiple nodes, and there is no need to consider the distributed collaboration between nodes. However, due to the stand-alone deployment. It is likely to bring problems such as large and complex systems, difficult to maintain, single point of failure (when a single point fails, it will affect the entire system or network, resulting in the paralysis of the entire system or network), poor scalability and other issues.
distributed
Distributed is a group of independent computers collectively providing services to the outside world, but for the users of the system, it is like a computer providing services. Distributed means that more ordinary computers (compared to expensive mainframes) can be used to form a distributed cluster to provide external services. The more computers there are, the more CPU, memory, storage resources, etc., and the greater the amount of concurrent access that can be processed.
Take an e-commerce website as an example. We generally split an e-commerce website horizontally into product modules, order modules, shopping cart modules, message modules, payment modules, etc. Then we deploy different modules to different machines, and communicate between each module through remote service calls (RPC) and other methods. Provide external services in a distributed system.
Servicing
When it comes to distributed, a word that has to be mentioned is servicing. The servicing architecture makes it possible to build a distributed system.
Traditional software development faces many problems, such as: high code repetition rate, huge code and difficult to maintain, inability to fast iteration, high test cost, poor scalability, poor reliability, and high inter-module dependence. In order to solve these problems, we generally adopt methods such as splitting, decoupling, layering, and independence. With a service-oriented architecture, we can solve these problems to a large extent.
Servicization is a coarse-grained and loosely coupled service-centric architecture. Services communicate through well-defined protocols and interfaces.
The "service" mentioned here essentially means "RPC". The implementation of pure RPC function is actually very simple. It is nothing more than the client initiates the call, and some component (or even the client itself) intercepts the call information, and then transmits the information to the server after serialization. The server deserializes after receiving the call request. , According to the request, the actual call is initiated in detail and the response is returned and transmitted back to the client. Such RPC is very common, such as a common stored procedure call. But in a complex business environment, how to manage and coordinate these massive RPCs is the most troublesome thing. Therefore, the "servitization" generally mentioned refers more to the management of RPC. Servicization generally focuses on service registration, service coordination, service availability, service communication protocol and content exchange.
Service Oriented Architecture
Service-Oriented Architecture (SOA), also known as "service-oriented architecture", is the concept of service-oriented architecture proposed by Gartner in the mid-1990s.
Service-oriented architecture, semantically speaking, is the same as process-oriented, object-oriented, and component-oriented, it is a way of software construction and development. Like the previous software development and architecture models, SOA is just a system and an idea, not a specific software product.
Here, we use an example to explain what is SOA? How to achieve SOA?
What is SOA
SOA can also be said to be a design principle (pattern), so what does it contain? In fact, there is no standard answer in this regard, most of which follow the generalization of the famous SOA expert Thomas Erl:
Standardized service contract
Service loose coupling
Service abstraction
Service reusability
Service autonomy
Service statelessness
Service discoverability
Service composability
The general purpose of these principles is to improve the reusability of software, reduce the cost of development and maintenance, and ultimately increase the agility of a company's business.
Since it is a service-oriented architecture, let's define a service first,
public interface Echo {
String echo(String text);
}public class EchoImpl implements Echo {
public String echo(String text) {
return text;
}
}
The above code is believed to be familiar to anyone who has experience in JavaWeb development. It defines the interface and implementation of a service.
So, after defining the service, have we achieved SOA?
Let's compare the principles defined by Thomas Erl, and try to analyze the above Echo example with the principles of loose coupling and reusability:
Echo's service contract is defined by a Java interface, rather than a standardized protocol independent of platform and language, such as WSDL, CORBA IDL. Of course, you can lift the bar. Java is also an industry standard, and even things recognized by the national dental defense group are also industry standards.
The Java interface greatly increases the coupling with the Service client, that is, the client must also be Java, or a dynamic language on the JVM (such as Groovy, Jython), etc...
At the same time, Echo is a native interface of Java, which requires the caller to be in the same JVM process...
Although Echo's business logic is simple and independent, the above technical limitations prevent it from being easily reused in other situations in the future, such as distributed environments, heterogeneous platforms, etc. ESB is the infrastructure for the realization of SCA ideas. The main role of ESB is to centrally register and publish services, decoupling services and transport protocols. Not all SOA architectures need ESB, ESB is unique to SCA. Of course, any solution that meets the characteristics of the ESB can be called an ESB, and it is not only internal to the SCA.
Therefore, we can think that Echo does not quite conform to the basic design principles of SOA.
Implement SOA
Modify the Echo above and add the @WebServices annotation of Java EE
@WebServices
public class EchoImpl implements Echo {
public String echo(String text) {
return text;
}
}Echo is now published as Java WebServices, and the underlying framework automatically generates WSDL as a standardized service contract, so that it can interoperate with various remote languages and platforms, which better solves the loose coupling and availability mentioned above. The problem of reuse. According to a general understanding, Echo seems to be an ideal SOA service.
Using WebServices is just a relatively simple solution. The most common solution for SOA is SCA, followed by JBI, BPEL, etc. ESB is the infrastructure for the realization of SCA thinking. The main role of ESB is to centrally register and publish services, decoupling services and transport protocols. About SCA and ESB is not the focus of this article, interested friends can get more information from the Internet. (You can see the role of ESB in the entire SOA architecture from the above figure)
Object-oriented and service-oriented comparison
Object-oriented (OO) and service-oriented (SO) have a lot in common in basic concepts, such as pursuing abstraction, encapsulation, and low coupling as much as possible.
Compared with OO, SO has very different typical application scenarios, such as:
-
Most OO interfaces (interfaces) are only used by a limited number of people (such as teams and departments), while SO interfaces (or contracts) generally should not make too many restrictions and assumptions on the scope of users (it can be Different departments, different companies, different countries). Remember the Bezos principle? "The team must plan and design well in order to open the interface to programmers all over the world in the future without any exception."
- Most OO interfaces are only accessed within the process, while SO interfaces are usually called remotely.
To put it simply, the use of SO interfaces may be much broader than general OO interfaces. Let’s use a website as an analogy: the web interface of a large website is the entry point and boundary of its entire system, which may have to face visitors from all over the world (so it often does work such as internationalization), while the system’s internal traditional OO The interface and program are hidden behind the web interface and are only used internally in a small area. The ideal SO interface, like the web interface, also becomes a system entry and boundary, which may be open to developers all over the world. Therefore, there are actually many differences between SO and OO in design and development. (Micro SOA: Service Design Principles and Practice Methods (Part 1))
Microservice architecture
MicroService architecture (MicroService) is a service-oriented architecture style that decouples solutions by decentralizing functions into discrete services. The first focus of the microservice architecture is that the business system needs to be completely componentized and service-oriented (this is why we introduce componentization and service-oriented first). The birth of microservices is not accidental. It is the product of the rapid development of the Internet, the penetration of agile, lean, and continuous delivery methodology, the rapid development of virtualization technology and DevOps culture, and the inability of traditional monolithic architecture to adapt to rapid changes.
Martin has contributed to the popularity of microservices. Let’s take a look at how he defines microservices:
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services , which may be written in different programming languages and use different data storage technologies.
In summary, there are four points:
- A series of independent services make up the system
- Deploy separately and run in its own process
- Each service is an independent business development
-
Distributed management
Martin himself said that everyone can have their own understanding of microservices, but there are still some general standards. - System of Distributed Services
- Divide the organization by business rather than technology
- Make a living product instead of a project
- Smart endpoints and dumb pipes (my understanding is strong service individuals and weak communication)
- Automated Operation and Maintenance (DevOps)
- Fault tolerance
- Rapid evolution of
SOA and microservices
After looking at SOA and microservices, many people think that this is the same thing. In fact, SOA and microservices are similar.
If you talk about the difference between SOA and microservices in one sentence, that is, microservices no longer emphasize the ESB enterprise service bus that is heavier in the traditional SOA architecture. Microservices put all the "thinking" logic including routing, message analysis, etc. inside the service, removing a unified ESB, and light communication between services, which is a more thorough split than SOA. (Microservice)
This is just a brief introduction about microservices. There are still many ways to go to truly understand microservices, such as Conway's Law (I will write an article on Conway's Law later), communication between services, and services Registration and discovery, service governance and service orchestration, etc. . .
to sum up
This article mainly introduces the concepts of componentization, modularization, centralized, distributed, service-oriented, service-oriented architecture, and microservice architecture. However, as the saying goes, practice leads to true knowledge. It still needs practical application in daily work to truly master it.
Recommended reading
What exactly are ESB and SOA?
Micro SOA: Service Design Principles and Practice Methods (Part 1)
Micro SOA: Service Design Principles and Practice Methods (Part 2)
Every day I talk about SOA and microservices, but do you really understand what a service is?
The thing about Microservice
Reference
Thinking and summary of componentization and modularization
The definition of modularization and componentization of front-end development, and the relationship between the two?
Module vs. component design
Talking about Service Architecture
Analyze Microservice Architecture (2) Overview of Microservice Architecture
The connection between SOA, ESB, SCA
Micro SOA: Service Design Principles and Practice Methods (Part 1)
The thing about Microservice