Shulou(Shulou.com)06/01 Report--

This article compares the differences between micro-services and modular overall architecture (modularized monolith). Now people are moving from monolithic monolith to microservices, but is this shift really right for your company? It is true that there are many problems with the overall monolithic monolith, but has modularized monolith been ignored as a competitor to microservices?

Modularity can bring the following characteristics:

1. Powerful encapsulation: hides the implementation details within the component to achieve low coupling between different parts.

two。 Good interface: components rely on stable API, and one component can be replaced by any other component that implements the interface specification.

3. Explicit dependency: modular systems need to combine different components to work together, so you need a good way to clearly express their relationship.

These principles can also be implemented using microservices. A microservice can be implemented in any way, as long as it exposes a well-defined interface (usually a REST API) to other services. The implementation details are the internal affairs of the service, and you can change these details without affecting the entire system. The dependencies between micro-services are usually not very clear at development time, which may cause the service's business process to fail at run time, so the last module principle is a little better than micro-services.

Microservices also contain important principles of modularity and have the following tangible benefits:

1. Teams can work independently and scale up.

two。 Microservices are small and focused, reducing complexity.

3. Services can be changed internally or replaced as a whole without affecting the overall situation.

But the disadvantage of microservices is that you have moved from a single approach (albeit slightly obese) to a distributed system of microservices, which brings great complexity to table manipulation. All of a sudden, you need to constantly deploy many different (perhaps using container wrappers) services. New problems arise: service discovery, distributed logging, tracing, and so on. Version control interfaces and configuration management can also be a big problem.

The complexity of the connection between microservices is due to the need for all microservice individuals to work together to implement business logic.

Modular choice

Do we either use the chaotic overall monolithic architecture of monolith, or will we be overwhelmed by the complexity of microservices? Modularity is actually another option. The important thing is that through modularization we can effectively draw and execute boundaries during development, which of course requires us to actively embrace programming languages and development tools to support modularity.

There are several modular systems in java, of which OSGi is the most famous, but as the java 9 native module system is released and added to the java platform itself. Modules are now part of the language and platform, built as first-class citizens. Java modules can express dependencies on other modules and expose the export interface while implementing classes for powerful internal encapsulation. Even the java platform itself (a huge code base) has been modularized.

Other languages provide similar mechanisms. For example, JavaScript has a modular system in ES2015. Prior to this, Node.js has provided a standard JavaScript back-end module system. However, as a dynamic language, JavaScript supports weak (typed) interfaces and encapsulation between modules. Microsoft's .NET Framework has a strong type similar to Java, but it is not equivalent to java's upcoming modular system. However, a good module architecture can be implemented using the. Net standard inversion control mode. Even C++ is considering increasing modularity.

When you consciously use the modularity of the development platform, you can use modularity to get the same benefits as microservices. In essence, a better module system can help you in the development process. Different teams can work in different parts, which are called only through well-defined interfaces, and these modules can be deployed together in a single unit at deployment time. This prevents the huge complexity and costs associated with development and management associated with the migration to Jingwei.

Modular design

Creating a good module also requires well-designed and good micro-services. A module should be modeled based on bounded context (bounded context). The choice of micro-service boundaries is an important architectural decision, and it will be expensive if you make the wrong choice. The boundaries of modules are easier to change in a modular application. Cross-module refactoring is usually supported by type systems and compilers. Redrawing the boundaries of microservices involves a lot of internal personal communication to ensure that they do not fail. To be honest, can you correctly demarcate your service boundaries the first time or the second time?

In many ways, statically typed language modules provide better builds through well-defined interfaces. Calling directly the interface methods exposed by another module is more robust than calling another micro-service REST endpoint, but REST+JSON is ubiquitous, but it is less interactive due to lack of structures such as compiler checking, and traversing the network, including serialized data, is not free.

A module is a natural unit of code ownership, and the team can be responsible for the system of one or more modules. The only thing that is shared with other teams is their common API module. At run time, there is less isolation between microservice modules, and everything runs in the same process.

Modules can also share data through well-defined interfaces and messages, and there is no need to share a database. The biggest difference between modularization and micro-services is that everything happens in the same process. In the end, the issue of consistency should not be underestimated. The use of modular architecture for ultimate consistency can be an active policy choice. For micro-services, there is no choice for ultimate consistency: it is doomed, and you have to adapt.

Is microservice suitable for your company?

When your company reaches the size of Google or Netflix, it may make sense to embrace microservices. You need to have the ability to build your own platforms and tools. But most companies can't reach this scale. Even if you think your company will one day become a billion-dollar unicorn, it won't hurt to implement a modular holistic architecture (modularized monolith) in the first place.

One advantage of using microservices is that different services can take different technology stacks. Then, you have to attract these different stacks of talent and keep these platforms up and running.

Microservices can be deployed independently, and different microservices can be deployed on matching hardware. Modularized monolith can be scaled horizontally, but you need to bundle modules together to expand, not independently.

Original text link https://www.jdon.com/48797

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.