How did the chief architect of Ali choose and implement the architecture solution

How to choose an appropriate application architecture for current needs, how to face the future, and ensure a smooth transition of the architecture are issues that software developers, especially architects, need to think deeply about.

No architecture, no system, architecture is the key to large systems. From a metaphysical point of view, the architecture is the skeleton of the system, supporting and linking all parts; from a spiritual point of view, the architecture is the soul of the system, which profoundly reflects the essence of the business.

Architecture can be subdivided into business architecture, application architecture, and technical architecture. Business architecture is strategy, application architecture is tactics, and technical architecture is equipment. Among them, the application architecture is the link between the previous and the next. On the one hand, it undertakes the implementation of the business architecture, and on the other hand, it affects the selection of technology.

How to choose an appropriate application architecture for current needs, how to face the future, and ensure a smooth transition of the architecture are issues that software developers, especially architects, need to think deeply about. Based on the author's practice and thinking in large-scale Internet systems, this article discusses the selection of application architecture with you.

The essence of application architecture

As an independent and deployable unit, an application defines a clear boundary for the system, which profoundly affects system function organization, code development, deployment, and operation and maintenance.

There are two ways to divide, one is horizontal division, which divides applications according to the functional processing order, such as dividing the system into web front-end/intermediate services/back-end tasks, which is a business-depth division. The other is vertical division, which divides applications according to different business types. For example, the invoicing system can be divided into three independent applications, which is a division for business breadth.

The combination of applications reflects how applications cooperate to complete complex business cases, mainly in the communication mechanism and data format between applications. The communication mechanism can be synchronous call/asynchronous message/shared DB access, etc., and the data format can be text. /XML/JSON/binary etc.

The division of the application is biased towards the business, reflecting the business architecture, and the integration of the application is biased towards the technology and affects the technical architecture. Dividing reduces business complexity and makes the system more orderly, while combining increases the technical complexity and makes the system more disorderly.

The essence of the application architecture is to balance the complexity of business and technology through system splitting, so as to ensure that the system remains intact.

What kind of application architecture the system adopts is affected by business complexity, including enterprise development stage and business characteristics; at the same time, it is affected by technical complexity, including IT technology development stage and internal technical personnel level. Business complexity (including large business volume) will inevitably lead to technical complexity. The goal of application architecture is to solve business complexity while avoiding technical complexity and ensuring the implementation of business architecture.

There are many common application architectures. The following is an analysis based on how the system is split and how to balance business and technology, discusses their applicability, and provides a reference for enterprise application architecture selection.

Monolithic application

1. Architecture model

The system has only one application, and accordingly, the code is managed in a project; packaged into an application; deployed on a machine; and data is stored in a DB. The architecture of the monolithic application is shown in the following figure:

Please click here to enter image description

The monolithic application adopts a layered architecture. According to the calling sequence, from top to bottom, it is generally the presentation layer, business layer, data access layer, and DB layer. The presentation layer is responsible for user experience, the business layer is responsible for business logic, and the data access layer is responsible for the DB layer. data access.

Monolithic applications are used in the horizontal direction, and the responsibilities between the upper and lower layers are clearly divided; but there is no clear boundary in the vertical direction, and there is a many-to-many dependency between the upper and lower modules. For example, business module 1 (BO1 in the figure) may call data All modules of the layer DAO 1~3, DAO1 may also be called by all modules BO1~3 of the business layer.

The monolithic application reduces business complexity through horizontal layering; at the same time, the modules are called within the process, and the technical implementation is simple.

However, the segmentation of the system by a single application is not complete, only horizontal segmentation, and it is logical, so it is suitable for systems with relatively single business but relatively complex depth, such as TCP/IP network communication, from the application layer/transport layer/ Network layer/link layer, layer-by-layer advancement, and systems like this can easily add levels to adapt.

For businesses that are complex in breadth, due to the lack of vertical segmentation, different businesses are forcibly bound together, and the whole system remains scattered, which brings a series of problems. For example, the OTA website contains multiple vertical business segments such as air tickets/hotels/tourism, each of which is relatively independent, so it is not suitable to be developed and maintained together.

2. Advantages and disadvantages

The advantages and disadvantages of monolithic applications are clear, as shown in the figure below.

Please click here to enter image description

The advantages of a monolithic application are obvious:

• The existing IDEs are all integrated development environments, which are very suitable for monolithic applications. Development, compilation, and debugging can be done in one stop.

• One application contains all the functions and is easy to test and deploy.

• Running on a physical node, the environment is single, the operation is stable, and the fault recovery is simple.

The disadvantages of monolithic applications are also obvious:

• The business boundary is blurred, and the responsibilities of modules are unclear. When the system gradually becomes larger, the code dependencies are complex and difficult to maintain.

• Everyone is developing on the same project at the same time, which is prone to code modification conflicts. The complexity of dependencies makes project coordination difficult, and the impact of partial modifications is unknown. Full coverage testing is required, and redeployment is required, making it difficult to support parallel development by large teams.

• Compilation and deployment are time consuming when the system is large.

• It is difficult to expand the application horizontally. On the one hand, the state is managed within the application and cannot be routed transparently. On the other hand, the resource requirements of different modules vary greatly. When the business volume increases, adding machines to all modules equally leads to a waste of hardware.

The author worked for a large e-commerce company before. At that time, the entire website was a single application with millions of lines of code. There was a dedicated team for code merging, a dedicated team for compilation script development, and a complex train model. Coordinating different teams, the entire process system is very sophisticated and complex, but this is not the helplessness and cost of a single application.

Distributed Architecture Application

1. Architecture model

Please click here to enter image description

In the distributed application architecture, applications are independent of each other, each application code is independently developed and deployed independently, and applications are related to each other through limited API interfaces. The API interface is part of the application and is generally at the same level as the presentation layer. The two share the business logic layer. The API and presentation layer use the same web-side technology. The communication protocol generally uses HTTP, and the data format is JSON. The application integration method is relatively simplified.

The distributed architecture first divides the system vertically according to the business, realizes the physical decoupling of the complex business in breadth, and divides the application internally horizontally, and realizes the logical decoupling of the complex business in depth. The distributed architecture can also solve the problem of large business volume. For some high-concurrency/large-traffic systems, the system is divided into different applications, and according to the characteristics of resource requirements (such as CPU/IO/storage-intensive), the hardware configuration is strengthened to meet the requirements. To meet the needs of different applications, avoid the waste of resources caused by a one-size-fits-all approach.

Technically, the API uses standard HTTP/JSON for communication, and it is not difficult for both parties to implement it. However, the API is generally "streaking". At the system level, the call dependencies are not transparent, and the reliability of the call is not guaranteed, so it is only applicable to the application. A system with few interdependent links and a small amount of calls, that is, a system with loose coupling between applications.

2. Advantages and disadvantages

The distributed architecture has high internal cohesion for each application, independent development, testing and deployment, and supports agile development; at the same time, applications are loosely coupled, business boundaries are clear, and business dependencies are clear, supporting parallel development of large projects and achieving business agility.

In a distributed architecture, there is no physical separation between the application's presentation layer and the API. It needs to meet its own business needs and related business needs at the same time, and affect each other. For example, the API interface will often change with the needs of external applications, which will lead to redeployment of the entire application. .

When running, the API provides external interfaces through the network in HTTP/REST mode. Its communication reliability and data encapsulation are relatively poor compared to in-process calls. If there are no reliable technical mechanisms, such as routing guarantee/failure retry/monitoring, etc. , the streaking API method will seriously affect the overall availability of the system.

SOA Architecture

1. Architecture model

Please click here to enter image description

Broadly speaking, SOA is also a distributed application architecture, but with different connotations.

There are two types of "applications" here. Applications 1~N are front-end applications, facing users, and services 1~N are services, which only provide business logic and data. These applications are deployed independently. Front-end applications are no longer directly related through APIs, but share business logic through back-end services.

In addition, compared to the "streaking" API, the SOA architecture provides supporting service governance, including service registration, service routing, service authorization, service degradation, service monitoring, and more. These functions are supported by specialized middleware in two ways: centralized and decentralized. The specific technical implementation mechanism and applicable scenarios are described on the Internet, so I will not expand them here.

Based on the vertical segmentation of the distributed architecture, the SOA architecture further separates the business logic layer of the original single application into a service, so as to achieve a complete physical separation.

Each service focuses on specific responsibilities and realizes the core business logic of the system. By calling each other, services can complete complex business logic and solve business depth problems. At the same time, services are oriented to many applications and support logic reuse in a shared way. Therefore, the SOA architecture not only reflects the division of business, but also reflects the integration of business, and considers system splitting more from the business as a whole.

Compared with the distributed application architecture, the SOA-based system has a large number of service applications, and the entire system is based on service calls, so high requirements are placed on the transparency of service dependencies and the reliability of service calls, which require special SOA framework support, and also need Supported by the supporting monitoring system and automated operation and maintenance system, the technical complexity is high, and the SOA architecture can centrally reflect an enterprise's IT technical capabilities.

2. Advantages and disadvantages

The advantages and disadvantages of SOA architecture are shown in the following figure:

Please click here to enter image description

Compared with the ordinary API method, the SOA architecture goes one step further:

• Each service is a concentrated essence, focusing on a certain aspect of the core business, and at the same time being shared by the entire system in a reusable manner.

• As an independent application, the service is independently deployed and has a clear interface, making it easy to automate testing and deployment.

• The service is stateless, and it is easy to scale horizontally; through the container virtualization technology, fault isolation and efficient use of resources can be achieved. When the business volume is large, machines can be added.

• SOA-based systems can flexibly control service resources according to service operation conditions, including services on and off the shelf, service upgrades and upgrades, etc., so that the system truly has the ability to operate.

Of course there is no such thing as a free lunch, and SOA also brings additional complexity and drawbacks:

• Complex system dependencies bring a series of challenges to development/testing/deployment.

• The end-to-end call link is long and reliability is reduced, depending on network conditions, service framework and the quality of specific services.

• Distributed data consistency and distributed transaction support are difficult, which are generally simplified and solved by eventual consistency.

• End-to-end testing and troubleshooting are complex, and SOA puts forward higher requirements for operation and maintenance.

SOA landing method

In practice, the SOA architecture continues to develop in depth, and the specific implementation forms are also varied.

1. External SOA

The predecessor of SOA is web service. The original intention of web service is to interconnect enterprises through the Internet, as shown in the following figure:

Please click here to enter image description

Each company publishes its own advantageous resources through web services. As shown in the figure, the weather service/air ticket service/hotel reservation service comes from different companies, and other companies can directly invoke the service or integrate multiple services to realize resource sharing among enterprises.

2. Application-oriented SOA

Application-oriented SOA strips out the business logic layer in the original single application and provides it as a separate service.

Taking an e-commerce example, there are two applications here. The product details page used by customers displays product information, product inventory, and product prices; the customer service system used by internal customer service personnel is used to modify orders according to customer calls. Get the basic information and price information of the product.

After SOA transformation, the application architecture is shown in the following figure:

Please click here to enter image description

The service here realizes the transparency of the underlying data to the front-end page, the presentation layer and business logic are maintained independently, and all business logic is open to other applications. New applications can freely integrate interfaces from multiple services to quickly support business innovation.

However, each service is the encapsulation of the business logic of the original system, and the interface design is oriented to the business case of the original application. If the requirements of other applications are different, create a service by yourself to access the underlying data. As a result, the service responsibilities are not focused enough, similar interfaces are decentralized, and the underlying data tables are accessed by multiple parties, which makes it difficult to modify the data model and ensure data consistency.

In the end, the overall dependence of the system is complex, and it is easy to form a network structure. When it is modified, it often affects the whole body.

3. Microkernel SOA

Every enterprise has its own core data. For example, for an e-commerce system, users/commodities/orders/stocks/prices are all core data, called master data. Microkernel SOA focuses on various types of master data and encapsulates all access to related tables. The architecture is shown as follows:

Please click here to enter image description

Each service exclusively encapsulates the access to the corresponding main data table. These services constitute the basic services of the system and together form the microkernel of the system, which is shared by all upper-layer applications.

Microkernel services are atomic services with fine-grained interfaces. Aggregated services can be constructed on them to provide coarse-grained services for upper-layer applications. It can be information aggregation, such as the basic information/inventory/price of commodities integrated by the commodity aggregation service in the figure; it can also be process aggregation, such as ordering interface, calling interfaces from multiple services to complete complex ordering operations together.

The services here are hierarchical, the aggregation service is the upper layer, the basic service is the bottom layer, and the dependency rules are as follows:

• The upper-layer service can call the same-layer service and the basic service

• Basic services are atomic services and cannot call each other

• Front-end applications can call aggregation services and call basic services across layers

The micro-kernel has a limited number of micro-representation services and fine-grained interfaces; the kernel represents that these basic services are at the bottom of the call and are responsible for core data and services. This is similar in concept to the kernel of an operating system. The main data is equivalent to the core hardware, such as cpu/memory / External memory, etc., each basic service of the microkernel is responsible for the management of these core resources, shielding the complexity of the bottom layer, and providing unified entry and transparent access to the upper layer applications.

Recently, microservices are very popular, which are characterized by single responsibility, fine-grained interface, lightweight communication protocol, etc. The microkernel SOA architecture has the shape of microservices, and at the same time has the god of the business core, which is a very good idea for the architecture. It is a good reflection that this has been widely practiced in large-scale e-commerce systems such as Taobao, Jingdong, and Yihaodian.

4. Comparison of methods

Facing the external SOA of the enterprise, the business scenarios have particularities, and no in-depth analysis is required. Here, we mainly compare the difference between application-oriented SOA and microkernel SOA. In a large B2C e-commerce system, applications and master data are many-to-many dependencies, as shown in the figure below. :

Please click here to enter image description

Application-oriented services start from a specific application and integrate the application's access requirements to related data; starting from a specific master data, it converges the data access requirements of each business.

Under the application-oriented service design, the access entry of the data table is divergent and comes from multiple applications, which brings a series of disadvantages:

1) Fragmentation of the data model

Each application will add fields to the table based on its own needs. Many e-commerce product tables/order tables have as many as 200 fields, which are the result of savage growth and lack of control.

2) It is difficult to modify the data model

Similar access requirements are scattered across multiple services, lack of integration, and table schema modifications will affect many services and applications.

3) Low utilization of connection resources

Multiple services are directly connected to the database, and each service will configure as many connections as possible. In the case of a large number of applications and a large amount of business concurrency, the number of database connections is often insufficient.

Microkernel SOA ensures data model consistency, optimizes interfaces, and effectively utilizes database connection resources by converging access to master data. At the same time, through service layering, system dependencies are simplified. More importantly, the microkernel service ensures the consistency of the business model. For example, the commodity system of the e-commerce system includes a series of complex concepts such as single product/series product/combination product/tie-in product/virtual product. These complex logic It is processed in the basic commodity service, transparent and consistent to the upper-level business.

If the business model is simple, the number of applications is small, and the vast majority (for example, 80%) of access to specific master data comes from a certain application, it is possible for the service design to be application-centric, and the adverse impact is relatively small.

For large-scale Internet systems, the business breadth and depth are complex, but no matter how complex the system is, the main data types are limited. By focusing on limited basic business, it can support unlimited application business. As a result, the underlying business model is stable. The upper-layer business can be flexibly expanded.

Application-oriented service design is the primary stage of SOA, starting from the specific business, bottom-up, and low difficulty; microkernel service design is the advanced stage of SOA, starting from the overall situation, highly abstracting business and data models, top-down, and difficult .

It is worth noting that while providing basic services, each application can also create the services it needs (but the access to the main data must pass through the basic services), so microkernel services and application-oriented services can be organically combined. Business applications have become numerous and growing, and you can consider gradually transitioning to basic services to integrate business logic related to specific master data.

By the way, the application architecture will affect the organizational structure. If an application-oriented service design is adopted, the specific service is generally responsible for the relevant application team; if it is a microkernel service design, a separate shared service department is generally responsible for all basic service development. Parallel with each business R&D department to ensure the neutrality of design and the timeliness of demand response.

The evolution of application architecture

Software is the virtual representation of human activities, business architecture is the embodiment of production activities, and application architecture is the embodiment of specific division of labor and cooperation.

Monolithic applications are similar to the primitive clan era, with simple division of labor within clans and no connection between clans; distributed architecture is similar to feudal society, each family is self-sufficient, and there is a small amount of exchange relationships between families; SOA architecture is similar to the industrial era, enterprises provide various Kind of finished service, I am for everyone, everyone is for me, and interdependent. The SOA architecture of the microkernel is similar to the post-industrial era. Some companies focus on providing infrastructure services such as water, electricity, and coal, while other companies provide life services on top of them, and there are layers of dependence.

The business architecture is productivity, the application architecture is the production relationship, and the technical architecture is the production tool. The business architecture determines the application architecture. The application architecture needs to adapt to the business architecture and evolves with the business architecture. At the same time, the application architecture relies on the technical architecture to finally land.

The business of the enterprise is relatively simple at the beginning, such as invoicing, and at this time, it provides a simple information management system (MIS) for internal users, and supports data addition, deletion, modification, and query, and the single application can meet the requirements.

With the deepening of the business, each business of invoicing and storage has become more complex. At the same time, customer relationship management has been added to better support marketing. The depth and breadth of the business have increased. At this time, the system needs to be split according to the business and become a distribution system. system.

Further, enterprises turn to the Internet + strategy to expand online transactions. The online system is similar to the internal system business, and there is no need to redo a set. At this time, the logic of the internal system is transformed into a service, and it can be used by the online and offline systems at the same time. into a simple SOA architecture.

Immediately after, the business model became more and more complex, and the order, commodity, inventory, and price were all very in-depth, such as the price to distinguish the membership level, the access channel (wireless or PC), the sales method (group purchase or ordinary), etc., and a large number of For price promotion, these rules are very complex and easily conflict with each other. It is necessary to manage the price logic scattered in each business in a unified manner, and transparently provide it to upper-layer applications in the form of basic price services, turning it into a microkernel SOA architecture.

At the same time, the functions required by internal users or external customers are supported by many subdivided applications. Portals need to be provided to integrate related applications to provide a unified view for different users. The top layer becomes an AOA architecture (application orientated). architecture).

With the continuous evolution of business and systems, the last relatively complete large-scale Internet application architecture is shown in the following figure:

Please click here to enter image description

I specially sorted out the above technologies. There are many technologies that can’t be explained clearly in a few words, so I just asked a friend to record some videos. The answers to many questions are actually very simple, but the thinking and logic behind them are not simple. If you know it, you also need to know why. If you want to learn Java engineering, high performance and distributed for free, explain the profound things in simple language. Friends of microservices, Spring, MyBatis, and Netty source code analysis can add my Java advanced group: 694549689. In the group, there are Ali Daniel's live broadcast technology and Java large-scale Internet technology videos to share with you for free.

1. Those with 1-5 work experience, who do not know where to start in the face of the current popular technology, and who need to break through the technical bottleneck can join the group.

2. After staying in the company for a long time, I lived very comfortably, but the interview hit a wall when I changed jobs. Those who need to study in a short period of time and change jobs to get high salaries can join the group.

3. If you have no work experience, but have a solid foundation, you can join the group if you are proficient in the working mechanism of java, common design ideas, and common java development frameworks.

In the end, the whole system will be broken down into pieces, with both form and spirit, supporting building block assembly, and supporting development agility and business agility.

The application architecture needs to stand in the middle of business and technology, and make the right architecture choices at the right time to ensure the orderly evolution of the system.