Today we talk about the SOFA modular, for a first look at the introduction of SOFA:
SOFABoot ants gold dress open source development framework based on Spring Boot, on the basis of its Spring Boot on offer such as Readiness Check, class isolation, log space isolation capabilities. At the same time enhancing the Spring Boot, SOFABoot provided so that users can easily use the SOFA middleware Spring Boot in capacity.
Before touching the modular concept of SOFA, I developed a modular server cognitive remain in the "modular" this level, I usually will follow the structure of the organization shown in the figure responsible for their own application code.
Spring System module (Module), it is to manage the respective module Spring bean in different contexts, modular development and compile, but at runtime the entire application or in a Spring context, these codes are also is loaded a class loader.
In Figure 1, I defined in the manager module bean, can be referenced at any time in the service, without the need to focus on this quote is reasonable; this development model is no problem in the application still small, however, as the business development and application upgrades, references between these modules will be increasingly complex to manage (this time the application has become a "big ball of mud"), when one day need to split applications as a service, We need to spend a lot of effort to sort out the coupling and reference relationships between the different modules. The modular nature of SOFA is to solve this problem occur, this feature can force developers to design and think carefully increasing references between the two modules of the time.
SOFA Modular
SOFA module, the module is an operation; regular Spring project module, it is common Jar. A complete SOFA module and a common Jar package there are two differences:
- SOFA module contains a
sofa-module.propertiesfile, a document which defines the dependencies between modules as well as the name of SOFA module. - SOFA module
META-INF/springdirectory, can be placed as many Spring configuration file, SOFA automatically load them up Spring configuration as this module.
After using the modular nature of SOFA, the bean between two modules can not communicate directly, requires the use of communication protocols SOFA, SOFA supports two communication protocols:
- jvm call, two modules are running in the same JVM virtual machine, without going through the network calls.
- rpc call, the two modules is not running in the same JVM virtual machine, not even on a machine, you need to call through the network.
SOFA provides three forms of publication and reference services for developers: xml way, annotation mode, program mode. I am using more or xml way, because SofaService and SofaReference are published and cited jvm only support services, and xml mode can support two forms of call.
SOFA impact on the development model of modularity
SOFA provides a modular solution, not only to achieve a true modular runtime, and no excessive complexity introduced OSGI, is an effective compromise. I contacted SOFA great influence on the development of ideas to the familiar process of SOFA, but after familiar SOFA modular thinking, I found this feature to my usual development work has several advantages.
Security architecture of the proximal and distal
In order to reduce the pressure service side, we need to provide a SDK for the business side use, before the next Spring system, this architecture can also be performed, but there are drawbacks --SDK application classes and JAR packages for applications to the business side He said also visible, in some cases, there will be a conflict or potential introduction of BUG.
The modular nature of the use of SOFA, the proximal end of the package we offer application sharing, though still with the business side of a JVM, but in the class loader to achieve a level of isolation, for the business side, they just need to know what is the use of our interfaces without the need to focus our SDK introduces a number of tripartite JAR package.
Better code sharing
SOFA use modular code-share to be no next Spring system so simple - a direct reference to the module can be used. In SOFA, the code to be shared, there are typically two situations: (1) code sharing near the distal end (2) and the managed runtime code sharing.
With the first (1) case, for example, a proximal and distal components are the same, in order to avoid duplication of code, how do we achieve code sharing it? My current practice is to: define the need to share the interface and implementation class in a public test-core module; this test-core module can not be defined as SOFA module can only be defined as an ordinary JAR package; then the need to use SOFA the interface module (module proximal end and a distal end module), the declarations and references that are shared by the bean, the example as shown in FIG.
The point here is that:
- javaadu-core module is a common module JAR, only the definition and implementation of the interface, there is no statement on the bean in this module
- javaadu-remote module is a module SOFA The entire interface and implementation of javaadu-core, there needs to be declared bean (bean declaration) and publishing (sofa-service), other modules in order to use the current application Interface, only need to reference javaadu-core and javaadu-remote, then use the sofa-reference cited this interface can be, here are generally jvm calls; other applications if you want to use the interface, and there is no near-end demand, then you need to reference javaadu- core and javaadu-remote, and use the sofa-reference references. As can be seen, SOFA blurred concept calls across applications and calls within applications modularity make it absolutely
- javaadu-client module is a module SOFA, the proximal end of the module is, and where the interface also needs to achieve their definitions and use of javaadu-core.
to sum up
This paper describes the development framework and SOFA Spring system the most obvious difference between a characteristic: SOFA modular form of a Spring context through each module, the isolation true running.
Based on my personal experience, SOFA excellent modular impact on the service side development is more than bad: During the maintenance code will be carefully considered the current application module dependency structure is reasonable; may have to provide more security to the business side SDK use; when implementing code-sharing, but also what code needs to be carefully considered worth sharing and which do not.
Reference material
- Sofaboot- Modular Development Overview
- Ants gold dress business systems modular program of modular isolation
- Alibaba Java Development Manual (Mountain Edition) .pdf
- JVM release service with reference
***
This number (javaadu) focused on the back-end technology, optimization and troubleshooting JVM, Java interview questions, personal growth and self-management, and other topics, providing front-line developers work and growth experience for the reader, look forward to here you can gain something.