Article Directory
Architecture research
This architecture survey is mainly divided into two parts: business architecture and technical architecture.
One, business structure
1. Pain points of single application
Before the birth of the GPF framework, all services were carried in a single application. Every time a new business is added, our application engineering becomes more bloated, the software entropy becomes larger, the code is difficult to maintain, and many categories have more than a few thousand lines. Different business codes are mixed in one class or one method.
Every time we undertake a new business, we have to add a lot of if else-style patching code. Seriously violates the principle of opening and closing, this way of writing is a typical bad smell of code. As more and more businesses are undertaken, the system becomes larger and larger. Whether it is to undertake a new business or make changes to an old business, it is becoming more and more troublesome.
This sentence also applies to software engineering. In order to solve the pain point of the monolithic application architecture: new services are patched to the old code. The GPF framework that realizes the powerful functions of business code is available.
The core appeal of the new architecture: business isolation. To be more specific, code isolation, configuration file isolation, and runtime process isolation. Focusing on the core demand of business isolation, we have actually done more things, which will be discussed later.
2. How to achieve business isolation
We build a model for each business identity and assign a business id. The business model contains the components, extension points, and process configuration used by this business. All business identities constitute a list of business identities. Each business model has a business identification logic-whether the current user request hits the business. When a user request comes in, they will go through this routing algorithm to determine the unique business identity.
After the unique business identity id is determined, the corresponding component set, extension point set, and process configuration are also determined.
1. Components
The release page of each business is composed of dozens to dozens of components. Among them are the common components of the platform, such as product titles, product barcodes, category attributes, sales attributes, sku and other business components required by the entire industry. Vertical business has customized components for vertical business. For example, charity business has a donation amount component. Except for charity business, other businesses cannot use this component; Hema business has components that are characteristic of the new retail industry, such as stores and management agencies.
"Business-needed components = business customized components + required platform common components"
2. Extension points
- Component extension point
- Process extension point
"Expansion points needed for business = business customization expansion points + common platform expansion points needed"
3. Isolation plan
From the above, it can be found that the common extension points and components of the platform are code reuse! Did not meet the previous code isolation requirements. The solution is also simple: when the system is initialized, each business identity id will create a new copy of common components and extension points, and merge its own custom components and extension points. Therefore, in the memory, each business identity id will have a set of independent and complete sets of components and extension points at runtime. When the system is actually running, it gets the objects of components and extension points, not code. In this way, code reuse and business data isolation. This is the most reasonable solution.
3. How to achieve flexible and easy-to-access mid-Taiwan products
Merely achieving decoupling of business codes is not enough. The product release system should be a mid-Taiwanized product. It is one of our goals to be able to quickly support the access of new services, allowing new services to be built together or even for students of new services to independently access their services on the GPF framework. To achieve high expansion and fast access to new services, the "microkernel + plug-in" technology must be mentioned here.
Microkernel technology:
The microkernel is a simplified form of the kernel. The system service layer that is usually integrated with the kernel is separated, and plug-ins can be added according to needs.
This can provide better scalability and a more effective application environment. Use the micro-kernel design to upgrade the system, as long as the old module is replaced with a new module, there is no need to change the entire operating system.
The microkernel technology originated from the operating system, but under the big wave of "platformization" of Internet products, this technology has been widely used.
The GPF microkernel exposes a series of SPI (Service Provider Interface) interfaces, and different services implement these plug-in interfaces on demand. When the system starts, the program scans out all the plug-ins that implement the SPI interface and integrates them into the system to provide external services. When a new service needs to be accessed, define a service identity and implement the required SPI interface at the same time to complete service access and achieve service isolation at the same time.
2. Technical architecture
The main content includes the overall structure of the enterprise, the design of a single project structure, the unified application layering, and the debugging tool WinDbg.
1. The overall structure of the enterprise
When we have hundreds of applications, we need not only the architecture design of a single project, but also the top-level thinking and guidance of the overall enterprise architecture. The business thinking of large companies and small vendors is the same, but it is harder for large companies to see the full picture and essence of business. However, small companies lack application scenarios for customer traffic and middleware, while medium-sized companies have both, so the overall corporate structure is relatively easy to implement.
The overall structure of the enterprise needs to switch easily between technology, business, and management. It includes business architecture, application architecture, data architecture, and technical architecture. The attached file is a real case after desensitization of sensitive information, which refers to the TOGAF standard. However, the content is oriented to solve the structural problems of the company's system and takes time as the main line, including the enterprise business model, the current state of the architecture, the architecture planning and the implementation of the architecture.
2. Single project architecture design
The architectural design of a single project is like construction drawings, which can directly guide the implementation of engineering codes. The last one is functional requirements, and the next one is code implementation. This is where the value of architecture design lies. From functional requirements to use cases, to use case activity diagrams, to domain diagrams, architecture layering, and core code, they are interlinked.
A poorly done domain diagram may stem from not doing a good job in the use case activity diagram, because the use case activity diagram is the last link of the domain diagram. Focusing on responsibilities, boundaries, application relationships, storage, and deployment are the core of the architecture design. The following figure is a reference for specific cases.
3. Unified application layering
It is very simple to layer applications, but it is not a simple matter to let hundreds of applications of a company adopt a unified layered structure. It can be large or small, easy to use, and support multiple scenarios. We use the IPO method: I for Input, O for Output, P for Process, one input and one output, one processing. The essence of the application system is a machine, a processing device, and also a one-in-one-out one. The IPO method is simpler and more practical than DDD.
4. Debugging tool WinDbg
There are occasional abnormal problems in the production environment, and WinDbg or GDB is a powerful tool to solve such problems. The debugging tool WinDbg is like a doctor's stethoscope. It is a reverse analysis tool for problem diagnosis when the system is sick. The Dump file is similar to the black box of an airplane and records the running status of the production environment program.
Mainly introduce the use of debugging tool WinDbg and packet capture tool ProcDump, and share a real case. I don't know who wrote the code N years ago, causing occasional CPU spikes every two months.
We first use ProcDump to grab the Dump file of the abnormal process in the production environment, and then analyze it through the WinDbg command without understanding the code, and finally locate the problematic line of code.
reference: