About osg μservice and microservices

Some concepts - they are not some normative standards, so there is no clear, concrete implementation. Because the understanding of concepts is not necessarily consistent, we cannot clearly judge whether some specific implementations are within the scope of these concepts.

Regarding service-oriented architecture, there are many such concepts, such as SOA, microservices.

What exactly is SOA? What are microservices? There are only a few entries in the industry, but there are no clear and rigid standards and norms. There is no such thing as a reference implementation.

As a result, different implementations or architectures continue to come out, claiming to be SOA and microservices. From a positivist point of view, these are all true, because there is no standard to falsify, just make sense.

Although the current concept of microservices is very hot, it is undeniable that this multi-process application architecture will have pressure on operation and maintenance, so DevOps came into being, trying to use automated operation and maintenance, multi-instance deployment and other means to solve the problem of operation and maintenance. Peacekeeping reliability issues.

In essence, microservices are designed to solve the problem of Internet application performance expansion, rather than structural problems. Some people may say that microservices divide a large application into many small areas. Divide and conquer will solve the problem of structure. In fact, this ignores the problem of operation and maintenance. No matter how finely the application is divided, it will be divided The resulting parts will eventually be combined into a complete application, but the single application is combined based on development methods, while the microservices are combined based on operation and maintenance methods, so the structural problem is just transferred.

From this point of view, the modularity of monolithic applications and microservices can be helpful in structure, avoiding spaghetti code structure.

The microservice architecture requires autonomy through independent process deployment, which is an architectural constraint set on the boundary, which is conducive to the boundary division of the optimization field. This has a similar effect to osgi's classloader isolation, so when designing osgi applications, it should also learn from the method of domain-driven design.

In terms of service, osgi services have dynamic characteristics. This dynamic is not simply the dynamic of service publishing and service offline, but also the dynamic of service assembly. This characteristic is called Fast forwards. In the osgi environment, we can assemble many fine-grained services into coarse-grained services. Coarse-grained services depend on the existence of fine-grained services. When the dependent service goes offline, the service that depends on it also goes offline immediately. That is to say, as long as a service is published, it is available, there will be no external callable, but the internal is incapable.

Enterprise applications and Internet applications are somewhat different. Usually, the structure of enterprise applications is more complex, but the performance requirements are much lower than those of Internet applications. Therefore, enterprise applications should not only emphasize microservices and ignore modularity.

To be continued...



Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326665767&siteId=291194637