Why do YOU need architectural visualization
As the enterprise carries out microservice architecture transformation, the complexity of the system architecture becomes higher and higher, and the architecture changes become more and more frequent. The actual architecture model after microservice transformation may be greatly different from the expected, and it is difficult for architects or system operation and maintenance personnel to accurately remember the composition and interaction of all resource instances. Secondly, the system architecture may introduce some unreliable factors in the process of dynamic evolution, such as weak dependence to strong dependence, insufficient local capacity, excessive system coupling and so on, which bring great security risks to the stability of the system. Therefore, every time before facing the system transformation, business promotion and stability governance, we would present the interaction mode between the components in the system architecture by combing the architecture diagram. Architecture visualization can clearly help us identify the problems in the architecture and establish a highly available system.
Micro-service architecture visualization platform practice
Architecture visualization gives us the following advantages, but not limited to:
Determining system boundaries
A good architecture diagram should make clear the various components contained in the system and the core call relationship between each component. The collection of these components is the processing boundary of the system, and the boundary of the system architecture also reflects the boundary of the business domain to a certain extent.
Architecture Problem identification
Based on highly available architecture criteria, combined with visual architecture diagrams, it is possible to assess the security risks of the architecture, such as the robustness of the system in the dimensions of disaster recovery, isolation, and self-healing. Secondly, some architecture link visualization tools (such as Hawk-Eye) have greatly improved the efficiency of troubleshooting and locating problems.
Improve system availability
With upstream and downstream dependency diagrams of the system architecture, developers can quickly locate the source of the problem when a failure occurs with dependency data, greatly reducing the problem repair time (MTTR). With the help of the architecture diagram, we can also sort out the strong and weak dependencies in the system, degrade the weak dependencies in the business peak, or conduct fault simulation for each component of the system to evaluate the reliability of the whole system in the face of local failures.
Common architectural visualization practices
The architecture diagram we are familiar with is static and stays on THE PPT. Many times our architecture has changed greatly, but we still use the classic but outdated architecture diagram. The long-term use of an architecture diagram that is not consistent with the actual architecture can do great harm to the perception of the architecture online, and we need to constantly update our view of the system architecture in our mind to remain sensitive to the system architecture. Every big promote or major system renovation become our carding system architecture, the architecture of a new chance to the cognitive, at the moment we need through a variety of tools to check the distribution of various components of the system and the different components of the internal and external dependencies, comb the architecture diagram method is the most commonly used way, can call it “by hand”.
For things that are often done manually, some students who pursue efficiency will help themselves to do this by using automated means brought by computer systems. For example, we often see micro-service visualization solutions based on data burial points. Such architectural visualization means are often used in monitoring fields such as distributed tracking and APM. The following figure shows an application dimension architecture visualization scheme for an APM product:
Micro-service architecture visualization platform practice
We call this visualization method “buried point perception”. The identification of architectural components relies on key core class detection and buried point. This scheme has the following disadvantages:
Language correlation: as long as the system is buried, language-related features can not be removed, and different dependency packages need to be provided for different languages.
Difficult to maintain: Because it is a test of the core class, when significant changes are made to the component package, the changes need to be synchronized;
Not easy to expand: because it is the client identification scheme, once the client is opened out, the support of new components can only wait for the user to update the components;
Limited scale: Another disadvantage of client recognition is that the algorithm is limited. The server can identify it more effectively and accurately by means of big data analysis.
There is also an automated architecture sense visualization method, which we call “××× Architecture sense”, which is a language-independent architecture recognition scheme. It collects the metadata of the process and container on the user host, the monitoring number and the most basic data of network data, and constructs the architecture diagram on the server side.
We design the concept of architectural visualization
In order to minimize the cost of architecture visualization for users, we adopt ××× architecture awareness – application non-intrusive micro-service visualization. By collecting process data and network call data, the network call relationship between processes is constructed, and the architecture information of micro-service is constructed. Users only need to install our AHAS Agent probe to complete the visual operation of the architecture. For aliyun native system, we provide automatic installation without logging in the machine.
The core essence
The core of software architecture visualization is to find a meaningful and effective view of the elements in the software architecture and the relationships between those elements. We believe that a good software architecture visualization product should help users eliminate unimportant information and give them a view that is valuable to them, especially in the context of a large and complex chain of call relationships under a microservice architecture. The core of this is meaningful and valid, and to do both, we need to identify what are the elements and relationships that are meaningful and valid, and what we do in this area boils down to “identification,” identifying what each process on the machine is, what is the remote end of the network call that occurs, Only by knowing what these elements are can we have a reason and basis to determine whether they are meaningful to the user and how important they are in the user architecture.
After combing through a large number of architecture diagrams, we found that the architectural elements that users care about fall into three main categories:
Own application services;
Application dependency on external resources;
Information about the server itself.
Applications depend on external resources in the form of other applications, common middleware or storage services. Therefore, we divide the processes to be identified into application services and common component services (such as Redis and mysql, etc.). These component services are further divided into services built by users and services provided by public Cloud. Especially for Cloud Native applications, the identification of Cloud services is particularly important.
At present, we provide the identification of 20 aliyun cloud services and 21 common tripartite service components including mysql, Redis, Tomcat, etc. This component library is still expanding, so as to maximize the understanding of what elements are in the architecture.
Micro-service architecture visualization platform practice
Micro-service architecture visualization platform practice
Micro-service architecture visualization platform practice
Architectural layering
We also believe that the effectiveness of architectural visualization is related to the person’s cognitive level, and that the focus of architectural visualization is to determine whether the tool better supports a top-down approach, a bottom-up approach, or a combination of the two. Developers are more concerned with the architecture on the application dimension, while architects or managers are more concerned with the overall system architecture. Therefore, it is necessary to provide different levels of architectural visualization for different users. The ideal architecture diagram needs to support the macro dimension as well as the micro perspective of drilling down. We have designed the architecture in layers, currently divided into process layer, container layer and host layer, and we may further expand or drill down to support the region layer or service layer.
Architecture back
The architecture of no system is immutable. The architecture of the system will evolve with the iteration of the system. Therefore, for architectural visualization operations, the ability to automatically update architectural information over time is also required. Products we provide the architecture of the perception of the default architecture diagram will refresh automatically over time, at the same time support back to history, you can choose a moment in the history of information architecture, for example, the major version changes, issued before and after the release of the system architecture of the question of whether or not to breach happened some principles of high availability, or trying to identify whether shouldn’t some rely on problems.
Micro-service architecture visualization platform practice
Visible available
Architectural visualizations solve visible problems, but they should also provide us with a convenient interoperable entry point that allows us to complete the closed loop of problem discovery and resolution when we find problems that need to be solved from the architecture diagram. For example, if the traffic of an application is monitored through architecture awareness and we need to limit the traffic or plan for the application, the expected operation can be completed through the architecture diagram. Incorporating interactively operational operations into architectural diagrams allows us to go from seeing to acting to seeing problems recovered to being represented in diagrams, much like the transition from command line view to window view in the history of computing.
Our positioning for architectural visualization
Architectural visualization is not an end, but a means to achieve high availability of the system. Based on the architecture data collected by architecture awareness, after identifying the components used by users (we collectively refer to mysql, Redis, MQ, etc.), we can use these components and the fault library matching the components to automatically recommend the faults that these components may encounter to users. The evaluation service provided by us makes it more convenient for users to simulate and drill components for various faults, so as to improve the robustness of the system. Secondly, Java Application can be identified through architecture awareness. If it is found to have a high load, it can be combined with the function of limiting traffic degradation (Sentinel commercial edition of Alibaba open source) provided by us to escort the continuous availability of the service.
Micro-service architecture visualization platform practice
We position AHAS as a high availability assurance product based on data analysis, which helps improve the high availability of cloud native architecture systems. Architecture visualization is the window for efficient operation and control that we provide to users. We expect to establish an application-centered integrated operation and maintenance platform through the rich cloud native data system combined with the visualization and operability of the architecture diagram. In the future, we will strengthen the integration with other cloud services, such as monitoring and container services, to enrich the data dimension of architecture awareness; Secondly, it will invest more energy in the in-depth mining of data and intelligent consumption, so as to truly make data become the core value of enterprises and make data become a sharp weapon to guarantee the stability of business.