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.
An architecture diagram from Daniel Woods’ presentation on microservices
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:
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 “unbounded architecture awareness”, a language-independent architecture recognition scheme, which collects metadata of processes and containers on the user host, monitoring numbers, and the most basic data of network data to build architecture diagrams on the server side.
What else can you do with architectural visualization
In order to reduce the cost of architecture visualization for users to the maximum extent, we adopt the application of non-invasive micro-services for visualization. By collecting process data and network call data, we build the network call relationship between processes and construct the architecture information of micro-services. The user only needs to install our ref=”cn.aliyun.com/notfound”>AHAS Agent probe to complete the architecture visualization operation; For aliyun native system, we provide automatic installation without logging in the machine.
How to make architectural visualization more effective
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.
The following figure shows the visual three-layer architecture interface of an Aliyun ECS deployed with microservice application after the installation of AHAS probe:
- Address architectural variability
No technology company’s system architecture is static, and it evolves over successive iterations 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.
- The heart of architectural visualization
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.
- Element identification in architectural visualization
After combing through a large number of architecture diagrams, we found that the architectural elements that users care about are mainly divided into three categories: 1. Own application services; 2. The application depends on external resources. 3. Information about the server. 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.
The figure shows the Nginx, Redis components, Mysql services and AHAS services identified by the identification service
The figure shows basic information such as the request direction of node details and the monitoring of nodes
The figure shows part of the process information on the identified host
What else can you do with 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.
Configure system traffic limiting with architecture awareness
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.
The original link
This article is the original content of the cloud habitat community, shall not be reproduced without permission.