What is architecture and the essence of architecture
In the software industry, there is a lot of debate about what architecture is, and everyone has their own understanding of it. What you mean by architecture is not necessarily the same as what you mean by architecture. Therefore, before discussing architecture, we should first discuss the definition of the concept of architecture. Concept is the basis for people to understand the world and the means to communicate. If people have different understandings of the concept of architecture, the communication will not be smooth.
Linux has architectures, MySQL has architectures, JVMS have architectures, business systems that use Java development, MySQL storage, and run on Linux have architectures. Which one should you focus on? To make sense of the above questions, we need to comb through several related but similar concepts: systems and subsystems, modules and components, and frameworks and architectures:
1. Systems and subsystems
System: Generally refers to a group of related individuals, operating according to certain rules, capable of performing tasks that individual components cannot do independently.
Subsystem: A system also composed of a group of related individuals, often as part of a larger system.
2. Modules and components
It’s all part of the system, just breaking it apart from different angles. Modules are logical units and components are physical units.
Module is to logically decompose the system, that is, divide and conquer, simplify complex problems. The granularity of a module can be large or small. It can be a system, several subsystems, a service, a function, a class, a method, a functional block, and so on.
Components can include application services, databases, networks, physical machines, as well as MQ, containers, Nginx and other technical components.
3. Framework and architecture
Framework is the specification of component implementation, such as MVC, MVP, MVVM, etc., is the product that provides basic functions, such as open source framework: Ruby on Rails, Spring, Laravel, Django, etc., which can be used directly or developed on this basis.
A framework is a specification and an architecture is a structure.
I’m redefining architecture here: Software architecture refers to the top-level structure of a software system.
Architecture is the most reasonable decision under the constraints of existing resources after systematic thinking, weighing advantages and disadvantages, and finally defining the system framework, including subsystems, modules and components. And the collaboration between them, the constraints, the guidelines. And it guides everyone on the team to agree on the level of thinking. It involves four aspects:
Systematic thinking of rational decisions: such as technology selection, solutions, etc.
Define the system skeleton: Define the components of the system.
System collaboration: How components work together to fulfill business requests.
Constraint specification and guiding principle: ensure the orderly, efficient and stable operation of the system.
Therefore, architects have the ability to understand the business, control the overall situation, select the right technology, solve the key problems, and guide the implementation of r&d.
The essence of architecture is the systematic reconfiguration of the system to meet the current business development, and can be rapidly expanded.
Then what kind of system should be considered to do architecture design technology does not come out of nowhere and self-driven development, and architecture development and requirements are based on business driven.
Architecture is all about business,
Requirements are relatively complex.
Non-functional requirements occupy an important place in the overall system.
The system has a long life cycle and scalability requirements.
The system is based on component or integration needs.
The need for business process reengineering.
Ii. Architecture stratification and classification
Architecture can be divided into business architecture, application architecture, technical architecture, code architecture, and deployment architecture
Business architecture is strategy, application architecture is tactics, and technical architecture is equipment. Among them, application architecture connects the preceding and the following, on the one hand to undertake the landing of business architecture, on the other hand to affect the selection of technology.
Get familiar with the business, form the business architecture, according to the business architecture, make the corresponding application architecture, and finally implement the technical architecture.
Software developers, especially architects, need to think deeply about how to choose an appropriate application architecture for current requirements and how to ensure smooth transition of architecture for the future.
1. Business Architecture (View Architecture) :
Including business planning, business modules, business processes, the business of the whole system is split, the domain model is designed, the real business into abstract objects.
There is no optimal architecture, only the most appropriate architecture, all system design principles should be to solve business problems as the ultimate goal, from the actual business of the technical feelings of the architecture will often bring the system into a pit, any not based on business to do whimsical architecture is a rogue.
The premise of all problems should be clear about how much business we are facing today, what kind of growth trend is, and the process of solving high concurrency must be a gradual and gradual process. A reasonable structure that anticipates business development 1-2 years in advance is desirable. In this way, we can pay a reasonable price to achieve the effect of technology-led business growth.
Take a look at THE business structure of JD (online sharing picture) :
2. Application Architecture (section architecture, also called logical architecture diagram) :
Hardware-to-application abstraction, including abstraction layers and programming interfaces. Application architecture and business architecture complement each other. Every part of the business architecture has an application architecture.
Similar to:
Application architecture: An application, as an independent deployable unit, demarcates a clear boundary for the system and has a profound impact on system function organization, code development, deployment, operation and maintenance. Application architecture defines what applications a system has and how they divide and collaborate. Applications are logical modules or subsystems.
There are two key points in the application architecture diagram:
Responsibility division: clear application (each logical module or subsystem) boundaries
Logical layering
Subsystem, module definition.
The key classes.
②. Coordination between responsibilities:
Interface protocol: indicates the interface for outputting applications.
Collaboration: Invocation relationships between applications.
Layering can be applied in two ways:
One is horizontal division (horizontal), which divides the application according to the order of function processing. For example, the system is divided into Web front-end/intermediate services/background tasks, which is business-oriented division.
The other is vertical division (vertical), which divides applications according to different business types. For example, the invoicing system can be divided into three independent applications, which is oriented to business breadth.
The combination of applications reflects how applications cooperate to jointly complete complex service cases. The communication mechanism and data format between applications can be synchronous invocation, asynchronous message, shared DB access, and data format can be text, XML, JSON, or binary.
The division of applications tends to reflect business architecture, while the combination of applications tends to affect technology architecture. It reduces the business complexity and makes the system more orderly, while it increases the technical complexity and makes the system more disorderly.
The essence of application architecture is to balance business and technical complexity through system fragmentation to ensure that the system is not fragmented.
The application architecture adopted by the system is affected by the complexity of the business, including the development stage and business characteristics of the enterprise. IT is also affected by the complexity of technology, including the stage of IT technology development and the level of internal technical personnel. Service complexity (including large volume of services) inevitably leads to technical complexity. Application architecture aims to avoid technical complexity while solving service complexity and ensure service architecture implementation.
3. Data architecture
Data architecture guides the design of databases. Consider not only the database and entity model involved in development, but also the design of the data store in the physical architecture.
4. Code Architecture (also called development architecture) :
Subsystem code architecture mainly provides practical guidance for developers, if the code architecture design is inadequate, it will cause the overall impact of the architecture design. For example, different development teams within the company use different technology stacks or components, and as a result, the overall architectural design of the company can get out of control.
Code architecture main definitions:
①. Code unit:
The configuration design
Frameworks, class libraries.
②. Code unit organization:
Coding conventions, coding conventions.
Project module division
Top-level file structure design, such as MVC design.
dependencies
5. Technical architecture
Technical architecture: Identify the actual running components (LVS, Nginx, Tomcat, PHP-FPM, etc.) that make up the application, the relationships between these running components, and the strategy for deployment to hardware.
The technical architecture mainly considers the non-functional characteristics of the system, and makes a system-level grasp of high availability, high performance, expansion, security, scalability and simplicity of the system.
The design of system architecture requires architects to have excellent knowledge of the functions and performance of software and hardware, which is also the most difficult work in architecture design.
6. Deployment topology diagram (actual physical diagram) :
Topology architecture, including the deployment of several nodes in the architecture, the relationship between nodes, high availability of servers, network interfaces and protocols, determines how applications operate, performance, maintainability, scalability, and is the foundation of all architectures. This diagram is the main concern of operation and maintenance engineers.
The physical architecture mainly considers hardware selection and topology, software-to-hardware mapping, and the interaction between hardware and software.
Architecture level
We use the architectural level of the pyramid to illustrate that the upper level contains the lower level:
System level: that is, the relationship between the various parts of the whole system and how it is governed: layering
Application level: the overall architecture of a single application and its relationship with a single application in the system.
Module level: the internal module architecture of the application, such as modularization of code, data and state management, etc.
Code level: that is, ensuring architecture implementation at the code level.
Strategic design and tactical design
Based on the architecture pyramid, we have a perfect combination of strategic and tactical design of the system architecture:
Strategic Design: Business architecture is used to guide architects on how to design systems architecture.
Tactical design: The application architecture is designed according to the business architecture.
Tactical implementation: After the application architecture is determined, it is technology selection.
Iv. Application architecture evolution
Business architecture is productivity, application architecture is relations of production, and technical architecture is tools of production. The service architecture determines the application architecture, which needs to adapt to the service architecture and evolve with the service architecture. At the same time, the application architecture is finally implemented based on the technical architecture.
Evolution of the architecture: Single application → distributed application servitization → microservice
1. Monomer application
At the beginning, the business of an enterprise is relatively simple. It only applies a simple scenario. The application service supports data addition, deletion, modification, and query as well as simple logic.
Typical three-tier architecture, front-end (Web/ mobile) + intermediate business logic layer + database layer. This is a typical Java Spring MVC or Python Django framework application. Its architecture diagram is shown below:
Approach to single application, non-functional requirements:
Performance requirements: Use caching to improve performance
Concurrency requirements: Use clustering to improve concurrency
Read/write separation: Read/write separation of the database
Use reverse proxy and CDN acceleration
Use distributed files and distributed databases
Monolithic applications are easier to deploy and test, and run well in the early stages of a project. However, as the requirements increased and more people joined the development team, the code base expanded rapidly. As a result, individual applications become more and more bulky, with lower maintainability and flexibility, and higher maintenance costs. Here are some of the drawbacks of using a single architecture:
High complexity: Take a single application at the level of a million lines as an example, the whole project contains many modules, the boundaries of modules are vague, the dependencies are not clear, the quality of the code is uneven, and they are piled together in disorder. As you can imagine, the whole project is very complicated. Every time you make a change to your code, even adding a simple feature or fixing a Bug can lead to hidden bugs.
Technical debt: Over time, requirements change, and people change, an application’s technical debt builds up and accumulates. “Don’t break it, don’t fix it” is very common in software development, and even more so in monolithic applications. Used system design or code is difficult to modify because other modules in the application may use it in unexpected ways.
Low deployment frequency: As the code increases, so does the build and deployment time. In a single application, each functional change or defect fix causes the entire application to be redeployed. Full deployment takes a long time, has a large impact range, and has high risks. As a result, single application projects are seldom deployed online. The low frequency of deployment leads to a large number of feature changes and bug fixes between releases, resulting in a high error rate.
Poor reliability: An application Bug, such as an infinite loop or memory overflow, may crash the entire application.
Limited scalability: A single application can only be expanded as a whole, but cannot be scaled based on service modules. For example, some modules in your application are computationally intensive and require a powerful CPU; Some modules are IO intensive and require more memory. Because these modules are deployed together, hardware choices have to be compromised.
Impeding technology innovation: Individual applications tend to use a common technology platform or solution to solve all problems, everyone on the team must use the same development language and framework, and it can be very difficult to introduce new frameworks or technology platforms.
2. The distributed
As services go deeper, more and more functions are required, and the logic of each service module becomes more complex, and the depth and breadth of services increase. As a result, individual applications become bloated, and their maintainability and flexibility decrease. As a result, the development cycle for adding new functions becomes longer, and maintenance costs become higher.
In this case, the system needs to be split according to service function modules, and each module is servified into a distributed system. Service modules are deployed on different servers and interact with each other through interfaces.
Compared with single architecture, this architecture provides the ability of load balancing, greatly improves the system load capacity, and solves the high concurrency requirements of the website. In addition, there are the following characteristics:
Reduce the degree of coupling: split the module, use interface communication, reduce the degree of coupling between modules.
Clear responsibilities: Divide the project into sub-projects, with different teams working on different sub-projects.
Convenient expansion: when adding functions, you only need to add a sub-project and call the interfaces of other systems.
Easy deployment: Flexible distributed deployment.
Improve code reuse: For example, the Service layer, if the distributed REST Service mode is not adopted, the architecture will be in the mobile phone Wap mall, wechat mall, PC, Android, iOS each end needs to write a Service layer logic, the development is large, it is difficult to maintain and upgrade together, at this time can adopt the distributed REST Service mode, A common service layer.
Disadvantages: The interaction between systems needs to use remote communication, interface development increases the workload, but the advantages outweigh the disadvantages.
3. The micro service
Followed by a business model is more and more complicated, order, goods, inventory and price of each module are very deeply, such as price to distinguish the member level, access (app or PC), sales (bulk or ordinary), etc., there are a lot of price promotion, these rules are complex, and easy to conflict each other, need to disperse to the price of the business logic for unified management, Transparently provided to the upper application in the form of basic price services, it becomes a microkernel service-oriented architecture, that is, microservices.
Features of microservices:
Easy to develop and maintain: A microservice focuses on a specific business function, so it is clear and has less code. Developing and maintaining individual microservices is relatively simple. The entire application is built from several microservices, so the entire application is kept in a controlled state.
Quick startup of a single microservice: a single microservice has a small amount of code, so it starts quickly.
Local changes are easy to deploy: Changes to a single application require the entire application to be redeployed, and microservices solve this problem. Typically, to make changes to a microservice, you simply need to redeploy the service.
Technology stack is not limited: In the microservice architecture, the technology stack can be reasonably selected based on the characteristics of the project business and the team. For example, some services can use the relational database MySQL; For some microservices with graphical computing requirements, Neo4j can be used; Some microservices can even be developed in Java and some in Node.js as needed.
Microservices, for all their attractions, are not a free lunch and use comes at a price. Challenges with microservices architecture.
Operation and maintenance requirements are high: more services mean more operation and maintenance investment. In a single architecture, only one application needs to run properly. However, in microservices, it is necessary to ensure the normal operation and cooperation of dozens or even hundreds of services, which brings great challenges to operation and maintenance.
Inherent complexity of distribution: You build distributed systems with microservices. For a distributed system, system fault tolerance, network latency, distributed transactions and so on all bring great challenges.
High cost of interface adjustment: Microservices communicate through interfaces. If you change the API of a microservice, you may need to change all microservices that use that interface.
Duplication of effort: Many services may use the same functionality, but this functionality is not decomposed into a microservice, in this case, each service may develop this functionality, resulting in code duplication. Although shared libraries can be used to solve this problem (for example, you can encapsulate this functionality as a common component that is referenced by microservices that need it), shared libraries are not necessarily viable in a multilingual environment.
5. Measure the rationality of the architecture
Architecture is a business service, there is no optimal architecture, only the most appropriate architecture, architecture always to efficiency, stability, security as the goal to measure its rationality.
Reasonable architectural design:
1. Business requirements perspective
Can solve current business needs and problems
Efficient delivery of business requirements: Ability to solve all current business problems in an elegant and reusable manner
Forward-thinking design: The ability to satisfy the business in a second way for some time to come, so that the architecture doesn’t change dramatically every time the business evolves.
2. Non-business requirements perspective
①. Stability. Indicators:
High availability: To make your software as usable as possible, I don’t think anyone wants to see their work fail. Black-box and white-box testing, unit testing, automated testing, fail-injection testing, improved test coverage, and more.
②. Efficiency indicators:
Documentation: It must be documented throughout the entire life cycle, whether as a whole or as part of it. Sources of change include but are not limited to bugs and requirements.
Extensible: Software is designed with low coupling in mind, taking care to abstract where appropriate. It facilitates feature changes, additions, and iterations of application technology, and enables refactoring of the architecture when necessary.
High reuse: To avoid duplication of effort and to reduce costs, we want to be able to reuse old code, old design. This is most dependent on the architectural environment.
③. Safety indicators
Security: Data generated during the operation of an organization is of commercial value, and ensuring data security is also an urgent part. In case of scandal like XX door. Encryption and HTTPS are common methods
6. Common architectural mistakes
If you go high, you don’t get to the ground
Missing critical constraints and non-functional requirements
Overdesigning to pay for a future that’s not there
Make critical decisions too early
Whatever the customer says becomes the transmitter
Work without foresight
The architecture should also consider system testability
Don’t try to design your architecture all at once
Common misconceptions about
Myth # 1 — Architecture is done exclusively by architects, not by business developers: no matter how good an architecture is, it ultimately needs to be implemented, and the larger the organization, the more difficult it is to implement. Not only system architecture, but also each solution and each project has its own architecture, such as layering, design patterns, and so on. If each brick is not strong enough, the whole system is still at risk of collapse. The so-called “a thousand li dike, collapse nest”.
Myth # 2 — The mission is over once the architect has established the architectural blueprint: The architecture is not a castle in the air, it will eventually land, but how does the architect know where the “ground” is without going to the ground? How can ability fall of steady dangdang.
Myth # 3 — Don’t Start without Perfect Architecture: There is no best architecture, only the right one. Don’t try to do it all at once. What we need is not a car all at once, but a unicycle, then a bicycle, then a motorcycle, and finally a car. Imagine a product that will take two years to build. Will the market still exist?
Myth 4 — Over-design for the Future: In the early days of a startup, when business scenarios and requirements boundaries are hard to grasp, products need to be quickly iterated and realized, and requirements need to be updated frequently, fast implementation is needed. Don’t think too much about future extensions, you may not be able to use them if they don’t work. If the business model and application scenario boundaries are clear, future scalability design should be properly considered.
Myth # 5 — Following big company solutions: Because of the halo effect of big company success, and the influence of the tech whips hired from big companies, one of the most persuasive phrases in discussing architecture decisions on websites is “This is how Taobao does it” or “this is how Tencent does it.” Of course, the experience and success model of large companies are important and worth learning from, but if they become blind to this, they lose the courage to adhere to their own, and sooner or later they will get lost on the road of architectural evolution.
Myth 6 — Technology for technology’s sake: Technology is there for the business, and nothing else. In the selection of technology and architecture design, divorced from the actual business development of the website, blindly pursuing fashionable new technology, technology development may lead to a bumpy path, the more difficult the road of architecture. Consider the realization of cost, time, personnel and other aspects should be considered comprehensively, ideal and reality need to compromise.
7. Structure knowledge system
1. Architecture evolution
Initial phase: LAMP, deployed on a server
The application server is separated from the data server
Use caching to improve performance
Use clustering to improve concurrency
Database read and write separation
Use reverse proxy and CDN acceleration
Use distributed files and distributed databases
business
Distributed service
2. Architectural patterns
Layer: Horizontal layer: application layer, service layer, and data layer
Split: Vertical split: Split functions and services
distributed
Distributed applications and services
Distributed static resource
Distributed data and storage
Distributed computing
Clustering: Improves concurrency and availability
Cache: Optimize system performance
cdn
Access resources to an agent
The local cache
Distributed cache
Asynchronous: Reduces the coupling of the system
Provide system availability
Speed up response
Redundancy: Cold backup and hot backup to ensure system availability
Automation: release, test, deploy, monitor, alarm, failover, recovery
Security:
3. Architecture core elements
High performance: the soul of a website
The performance test
The front-end optimization
Application of optimization
Database optimization
Availability: Ensure that servers do not break down. This is usually done by deploying redundant backup servers
Load balancing
The data backup
Automatic release
Gray released
Monitoring alarm
Scalability: How quickly you can build a cluster to handle massive increases in traffic and how easy it is to add new machines
The cluster
Load balancing
Cache load balancing
Scalability: Focuses on functional requirements, responds to service expansion, and quickly responds to service changes. Whether to practice the open and close principle, system coupling depends on
Distributed message
As a service
Security: all kinds of attacks on the website, whether all kinds of loopholes are blocked, whether the architecture can be used to limit the flow and prevent ddos attacks.
XSS attacks
SQL injection
CSR attack
Web Firewall Vulnerability
Security vulnerabilities
ssl
Structure book recommendations
1. Technical Architecture of Large Websites: Core Principles and Case Studies
This is an early, systematic introduction to the technical architecture of large web sites. It is easy to understand and full of wisdom. Even if you have no previous experience in web development, you can quickly get familiar with the technical architecture and application scenarios of web sites by reading through the first few chapters. Very nice.
2. Core Technology of Website Architecture with 100 million Traffic
Compared to the “large website technology architecture” of a strategic position, tao kaitao this “100 million level traffic website architecture core technology” is implemented to the details, the website architecture in a variety of common technologies, such as caching, queues, thread pools, agents… , all covered, and with core code. Even Nginx configuration!
If you’re looking for reference techniques and code to implement a high-traffic website, this is the book for you.
3. Architecture is the Future
This is a “magic book” that goes beyond the technical details to look at the root causes of architectural problems and help us figure out how to manage, lead, organize, and deploy teams.
4. Distributed Services Architecture: Principles, Design, and Practice
This book comprehensively introduces the principle and design of distributed service architecture, and summarizes the best solution to ensure the health and reliability of services on the line based on the author’s practical experience in the implementation of micro-service architecture. It is a weighty work of architecture level and practical type.
5. Talk about Architecture
This is a magic book on architecture, starting from the beginning of architecture, starting from business separation, talking about the purpose of architecture, the role of architects, how architects put architecture into practice… Highly recommended.
However, for those who have no practical experience in architecture, they may feel that this book is rather empty, with more concepts and less practice. But if you’ve had experience with the architecture of a project or two, you’ll agree with the book’s philosophy of going back to basics.
6. 12 Lessons for Software Architects
Most of the time the so-called “glass ceiling of technology” is really just a lack of soft skills. These skills can be learned, and the lack of knowledge can be made up for by determined change efforts.
Java programmer benefits: Gold three silver four, I have experienced the recent year of Java job interview, and some brushed interview questions have made PDF, PDF is free to share with everyone, scan to get
