Public cloud SAAS products are different from traditional software package products. We not only need to be responsible for software R&D, but also for product operation and maintenance. In the face of many users, we need to ensure the uninterrupted operation of products 7X24; customer business is constantly changing, and product needs Continuously upgrade during continuous operation to meet the ever-changing needs of customers' business. Compared with traditional software package products, the upgrade of public cloud products is more complicated and riskier, similar to replacing tires on a sports car.
The essence of design is to make product changes easier. The microservice architecture is an architectural model that has emerged in the Internet era to adapt to rapid business changes, and provides a basis for making changes easier. Since 2014, it has received extensive attention from the industry. In recent years, with the maturity of DevOps technology, the microservice architecture model has been practiced and applied by more and more enterprises. The microservice architecture is characterized by independent development, independent deployment, independent scaling, and independent operation and maintenance. There is no free lunch technically. While microservices bring us many benefits, it also brings a lot of complexity, including DevOps complexity, distributed system complexity, etc. We must adopt appropriate analysis and design methods, tools, and processes to improve product design architecture, automate DevOps, establish high-quality domain models, etc., so as to maximize the benefits of microservice architecture and reduce the negative impact of microservice architecture.
When researching and developing products, we first investigate the market demand background. Throughout the country, there are a large number of small and micro enterprises. Its typical characteristics are large numbers, relatively small business volume of a single enterprise, no special person responsible for system management and maintenance, and low overall IT level, which is particularly suitable for the application of SAAS service mode. In recent years, with the development of cloud computing technology, a large number of commercial business innovations have emerged in society, and commercial infrastructure such as electronic payments, electronic cloud warehouses, and electronic invoices have moved towards commercial applications. How to integrate some commercial infrastructures appearing in the society for use by small and micro enterprises? Therefore, SaaS services have become the only choice for many small and micro enterprises.
When analyzing the problem, it is necessary to clarify the customer group and target a large number of small and micro enterprises, industrial and trading companies, trading companies, and manufacturers. The business of a single enterprise is not complicated, but it is a complicated problem to make a product to satisfy multiple enterprises at the same time. In addition, as a cloud product, it is necessary to ensure that the product is always running within 7×24 hours. It is also a high-risk activity to upgrade and maintain this always-running product.
Based on the above problems and background, we propose several design goals, such as product architecture to support the needs of large-scale concurrent users; models and architectures to support continuous and rapid evolution; to accumulate basic business capabilities of the enterprise through product development, and accumulate for the rapid development of new products in the future Available resources.
Based on the design goals, we clarified the following general ideas.
The first is to attach importance to design. Design is the future of products. Only with good design can our products go further on the road of customer business growth. The second is to make full use of third-party technology and focus on our own areas of expertise. The third is that when time and resources are limited, the concerns are separated and implemented simply to ensure that the system can evolve when resources are available in the future. The fourth is to use the DDD method for domain segmentation and decoupling, and microservices fully guarantee the cohesion of the business. Finally, it is the most business system. The domain model is its core and gene, and it is the foundation to support business evolution in the future. The quality of the domain model is improved and the model design is appropriately advanced.
SAAS products are professionally developed and involve many technology stacks and capabilities. The front and back ends use completely different technology stacks, which are developed independently. In addition, as a product that meets the needs of many users, customization is its basic capability, and the front-end and back-end platforms are the basic capabilities of the product. Correspondingly, the R&D organization is divided into multiple small teams, such as product, UI/UE, front-end, back-end, testing, operation and maintenance, and business operations.
The R&D team is divided into multiple groups, and each group collaborates with each other. How to ensure efficient cooperation between different teams, complete specifications and standards are indispensable. Implementing the specifications of the entire R&D life cycle can effectively provide work quality and collaboration efficiency.
While the microservice architecture model brings benefits, it also brings the complexity of DevOps. The establishment of an automated operation and maintenance process is a necessary condition for using the microservice architecture. Develop appropriate branch plans, product management plans, continuous integration plans, and environmental management plans based on the company's product development and release process.
-
The branches are divided into develop, test and release branches, which isolate development, testing and release spatially;
-
Developers download the latest version from the develop branch, release it to Nexus after the build is successful, publish the snapshot package on Nexus to the "Auto Testing" environment through automatic tasks, and then perform automatic integration tests on the environment;
-
After the automatic test is successful, publish the built package to the develop environment;
-
In the develop environment, the developer completes manual confirmation and verification;
-
After the manual confirmation is completed, the automatic task is driven to merge/rebase the content in the develop to the test branch, and the tester manually executes the jenkins task to complete the process of releasing the release package to the integrated test environment;
- Operation and maintenance personnel are responsible for maintaining the production environment, which supports gray-scale deployment and reduces the risk of new version delivery.
The use of microservice architecture is not only a new technical approach. If it is not assisted by corresponding analysis and design methods, it will bring more harm than good, and we will fall into the embarrassment of jumping from one fire pit to another. It is necessary to carry out step-by-step design from business modeling, system modeling, domain modeling, and physical modeling to improve the quality of microservice design and ensure that the product can continue to evolve in the future.
Analysis and design include tools, methods and processes. The manufacture and use of tools are the hallmarks that distinguish human society from other animals, and the use of appropriate tools can greatly improve the efficiency and quality of analysis and design. The analysis and design tool uses EA, and the DB modeling tool uses ERWin. The method is to aggregate the best practices in the industry, and the domain-driven design method is the return and sublimation of object-oriented thinking. The premise of correctly mastering domain-driven design is the object-oriented design skills. DDD is the most important principle of object-oriented design-software structure reflects the structure of the problem. The DDD analysis method is used to analyze and design the business. The analysis and design process includes business modeling, system modeling, domain modeling and physical model.
For complex systems, the appearance of the system is difficult to imagine, and it must be obtained through analysis of engineering methods, that is, through analysis of business modeling methods to obtain the appearance of the system. Business modeling is to take the entire organization as a research object, select typical business scenarios, identify the roles and systems contained in the organization, and treat the system as a black box, and analyze how the roles and systems in the organization collaborate to complete the business. Export business value externally.
After business modeling, the appearance of the system is obtained, and then the system modeling is used to analyze which components or modules are formed in the system. The purpose of the segmentation module is to separate concerns and reduce system complexity. The system is disassembled into modules, how these modules cooperate with each other to meet the required functions in the appearance of the system, this is the system series diagram. For complex systems, the appearance of each module can be obtained by analyzing the cooperation between the modules.
The business world is complex on the outside, and its internal essence is relatively stable. The purpose of domain modeling is to gain insight into the essence of things through the complex phenomena and appearance of things. The domain model is also a way for us to look at the business world, helping companies clarify the concepts contained in the business and the relationships between them when designing products. The domain model is a model that expresses the essence of the business behind the business function (appearance). The domain model is a knowledge-level model with higher stability and supports online system business changes.
The physical model is the relational expression of the domain model and is oriented to the physical table. Build the table, and use the conversion tool to generate code based on the table, ensuring that the designed model is not just a display on paper or hanging on the wall, it is a thing that can truly drive development.
The implementation plan based on SaaS products includes a number of important technical options, such as tenant mode, layered design, application architecture, overall technical architecture, technical architecture in modules, and a consistent solution for products under a micro-service architecture and a distributed environment. .
What is the tenant model? SaaS products need to use three resource resources: application, virtual machine and DB. According to the use of virtual machine, application and DB, it is divided into different modes. The virtual machine model is that each tenant has an independent virtual machine, an independent application and an independent DB, the tenant resources are not shared, the isolation between tenants is good, but the resource utilization rate is low. In the tenant independent DB mode, each tenant shares virtual machines and applications, and the DB is dedicated to each tenant. The utilization of virtual machines and application resources is high, but the utilization of DB resources is low.
The third mode is the tenant sharing DB mode. Virtual machines, applications, and DB are shared by all tenants, with high resource utilization, soft isolation between tenants, and poor isolation.
For small and micro enterprises, where the number of tenants is large, the load is uneven, and the requirements for individualization are not high, we decided to adopt the tenant shared DB model.
For complex systems, layered design is one of the important means to solve the complexity problem. The DDD method is adopted to hierarchically design the system according to the business perspective. It can be called between the same layer and between the upper and lower layers, strictly control the cycle call, and control the complexity of dependence.
The front and back ends adopt different technology stacks, and the front and back ends are designed separately and developed by independent departments. The back-end is divided into application service layer and domain layer. The application service layer is to use the service capabilities provided by domain knowledge to provide business functions and solve specific business problems. The domain layer includes the core domain layer, the supporting subdomain layer and the general subdomain layer, providing domain knowledge service capabilities.
-
Core domain layer-to provide services for customers' core business;
-
Support sub-domain layer-a sub-domain that supports a certain aspect of the business;
- Common subdomain-a subdomain used for the entire system
From a technical perspective, the capability layer (including general sub-domain services, support sub-domain services and core sub-domain services) calls between microservices through RPC. The application service layer calls the domain service layer through RPC. The application service layer publishes services externally through REST, which is called by the front-end NodeJS interface server. Front-end applications access NodeJS services through HTTP/HTTPS.
After the physical model is generated, the Repository layer, domain layer, and persistence layer are generated based on the physical model and plug-ins. The model is no longer a decoration on the wall, and the model is driven by the code to make the model really fall. The knowledge binding method is used to bind the anemia object to the knowledge piece, and the anemia object becomes a smart object (Smart Object). In fact, this solution is a compromise between automatic code generation and anemia and congestion models.
Unlike traditional monolithic systems, XA transactions can be used to solve distributed resource data consistency issues. In a distributed system operation scenario, each service runs in different processes, and each process runs independently. Maintaining business consistency is a complex issue. The system provides two consistency mechanisms, namely the strong consistency of TCC and the final consistency based on message + TCC call. The two consistency mechanisms adapt to different scenarios.
In many business scenarios, the system needs to perform a series of complex operations after a customer request. Among these operations, some operations need to be executed and responded immediately; some operations do not require high real-time performance and can be handed over to the system for processing after a response is requested. The final consistency method based on message + TCC is to apply the consistency mechanism of this scenario. The system is decoupled by means of messages, and asynchronous operation is carried out. At the same time, it also plays the role of peak shaving and valley filling, and balances the system load.
Compared with traditional software package products, cloud product upgrading is a high-risk activity. Designing high-quality domain architecture and flexible domain models is the foundation for cloud products to calmly respond to business changes. When building a cloud product research and development system, building basic company business service capabilities including core business service capabilities, supporting business service capabilities, and general business service capabilities can greatly shorten the later product development cycle. These basic service capabilities are the company’s rapid business innovation. basis.