Alibaba sister introduction: From the development of various distributed systems more than ten years ago to the current container cloud, from supporting original businesses to incubating various new businesses, the development of enterprises is inseparable from unified and keeping pace with the times. technical architecture. This article introduces the changes brought about by cloud-native computing architecture from the perspective of enterprise distributed application architecture, hoping to help more enterprises transform their IT and use cloud computing technology to promote them to become an agile force in market competition. Since
entered the 21st century, we have witnessed the evolution of enterprise distributed application architecture from SOA (Service-oriented Architecture), to microservice architecture , to cloud native application architecture .
In order to explain the thinking behind the evolution of enterprise architecture, let us first talk about some metaphysics.
- First, the complexity (entropy) of enterprise IT systems is consistent with the second law of thermodynamics. As time goes by and business changes, the complexity of enterprise IT systems will become higher and higher;
- Second, there is a well-known law of conservation of complexity in computer interaction design [1]. The complexity of application interaction will not disappear, it will only exist in a different way. This principle also applies to software architecture. Introducing new software architecture will not reduce the overall complexity of IT systems.
Hearing this, does it make us, who are constantly struggling with our lives, feel a little bit cool?
One of the core tasks of modern software architecture is to define the boundaries between infrastructure and applications, reasonably segment complexity, and reduce the complexity that application developers need to face. In other words, it allows developers to focus on core value innovation and leave some problems to more appropriate people and systems to solve.
Let’s start from the picture below to explore the logic behind the evolution of enterprise distributed application architecture.
The pain of transformation: SOA
In 2004, IBM established the SOA Global Design Center. As a R&D TL and architect, I participated in a series of pilot projects for global customers, helping international companies such as Pepboys and Office Depot to use SOA to optimize intra-enterprise and inter-enterprise business. processes to improve business agility. The general background of
at that time was: as economic globalization gradually deepened, the competition faced by enterprises intensified, and business changes began to accelerate. IT systems within large enterprises have evolved over decades, and the entire technical system has become extremely complex, with coexistences such as CISC/COBOL transaction applications on host systems, RPG business systems in minicomputers AS400, and X86/ C/JEE/.Net applications for Power and other distributed systems. A large number of
application systems are provided by third-party suppliers, and some systems are even unmaintained. Moreover, with business iteration, some new business systems are continuously built. Due to the lack of reasonable methodological guidance, there is a lack of organic links between systems, forming a number of isolated islands, which continues to increase the complexity of the IT architecture and cannot support the business. development demands. It was as if the masters of various sects injected alien energy into the body in order to help the injured Linghu Chong, although the injury could be relieved in a short time. However, multiple strands of Qi cannot merge and agitate each other, which will cause more injuries over a long period of time.
Therefore, the primary challenge facing enterprise IT is to integrate a large number of silo-ed IT systems in the enterprise, support increasingly complex business processes, make efficient business decisions and support rapid business changes.
In this context, IBM and other companies have proposed the concept of SOA (service-oriented architecture), which abstracts application systems into coarse-grained services and builds an loosely coupled service architecture, which can flexibly combine services through business processes. , improve the reuse of enterprise IT assets, improve the adaptability, flexibility and scalability of the system, and solve the problem of "information island".
SOA proposed a series of principles for building distributed systems, and these ideas are still applicable today:
- services have clearly defined and standardized interfaces. Through the service definition description, the implementation of the service consumer (Service Consumer) and the service provider (Service Provider) are decoupled from to , and the service should be developed in a contract-first rather than code-first manner.Communication between services uses document-oriented messages instead of language-specific RPC protocols. On the one hand, it can solve the decoupling of services and implementation languages. On the other hand, it can flexibly choose synchronous or asynchronous communication implementation to improve system availability and scalability;
- service It should be loosely coupled, and there should be no time, space, technology, or team dependencies between services;
- services should be stateless, decoupling service calls from session context states;
- services should be autonomous and self-contained Yes, the service implementation can be independently deployed, versioned, self-managed and restored; the
- service is discoverable and composable. For example, service discovery can be performed through Service Registry, which enables dynamic binding of service consumers and service providers. In business processes, business services from different systems can be orchestrated and assembled. When
initially built the SOA system, most of them used point-to-point communication connections, and service calls and integration logic were embedded in the application implementation. This method is indeed a simple and efficient development method when the number of services is relatively small. But its biggest problem is that as the scale of services grows, communication between services becomes more and more complex, and the connection paths and complexity will increase dramatically, posing huge challenges to service governance.
In order to solve the above challenges, Enterprise Service Bus (Enterprise Service Bus, ESB) began to be introduced. The enterprise service bus provides connection, transformation, and mediation capabilities between services. It can connect internal enterprises and various services to the service bus to achieve a loosely coupled architecture between information systems, shield the complexity of system integration, improve the flexibility of IT system architecture, and reduce the cost of information sharing within the enterprise.
SOA The goal of the methodology is like the Yi Jin Jing, which can help sort out and gather different qi, and integrate them for my use. However, the cultivation process is by no means easy. What's the reason behind the large number of ambitious SOA projects that don't achieve the desired results?
The success of any IT architecture is inseparable from the cooperation with business goals, technical foundation and organizational capabilities.
In terms of business, SOA at that time focused on solving the existing market problems of enterprise IT. This has greatly narrowed the SOA methodology to Enterprise Application Integration (EAI Enterprise Application Integration).
In the SOA concept, opening up the meridians between information systems is only the first step. You also need to diligently cultivate your internal skills and continue to reconstruct and iterate the enterprise IT architecture. Only in this way can you maintain the agility and flexibility of the enterprise IT architecture and continue to support business development and changes.
In terms of organizational structure, since the IT department of most enterprises at that time was still a cost center and a subsidiary support department of the business, most enterprises lacked long-term IT strategic planning, and the IT team also lacked growth recognition, so SOA was reduced to a project-based operation. There is no organizational guarantee and continuous investment.
Even successful projects at the time will gradually lose their vitality under the erosion of complexity over time. Last year, a friend living in the United States sent me a photo. The business system we built for our client 15 years ago is still supporting the business of its existing nationwide stores. This is the success of technology projects, but it reflects the lack of corporate technology strategy.
Technically, although the ESB architecture realizes the decoupling of business logic and service integration and can better implement centralized service governance, it also exposes some serious problems:
- due to excessive emphasis on the reusability of business systems, and It is not the governance and reconstruction of enterprise IT architecture. A large amount of service integration implementation logic has been sunk into the ESB (as shown on the far right side of the figure above). These logics are very difficult to maintain, transplant and expand, and have become an unbearable burden for the ESB. We must handle complexity reasonably at the right place, rather than simply transferring it;
- ESB is based on a centralized message processing system, but with the rapid development of the Internet, ESB can no longer cope with the challenges of the scale growth of enterprise IT;
- ESB Such a system architecture of Smart Pipes and Dumb endpoints is an architecture that cannot adapt to rapid changes and mass innovation.
By analogy, telecom operators once hoped to incorporate complex functions such as video communication and telephone conferencing into telecom infrastructure, so that they could enjoy rich communication services with just a Dummy phone terminal. However, with the popularity of smart phones, innovations in distributed collaboration tools such as WeChat and DingTalk have completely subverted the way people communicate, and telecommunications networks have returned to their fate as pipes. The beauty of
feathering: microservices
With the development of the Internet, especially the advent of the mobile Internet era, the economic form of the entire world has undergone tremendous changes. The focus of enterprise IT has evolved from traditional System of Record (transaction systems, such as ERP, SCM, etc.) to System of Engagement (interactive systems, such as omni-channel marketing).
These systems need to be able to cope with the rapid growth of the scale of the Internet, and be able to iterate quickly and trial and error at low cost. Enterprise IT has become one of the engines driven by innovation. The ideal of technology expanding business boundaries has also helped IT teams have a greater sense of mission, further accelerating the evolution of enterprise IT.
A series of Internet companies led by Netflix and Alibaba have led a new change in enterprise architecture - microservice architecture. Microservice frameworks such as Apache Dubbo and Spring Cloud have been widely used. The core idea of
microservices is to split and decouple application functions to reduce the complexity of business system implementation. Microservices emphasize decomposing application functions into a set of loosely coupled services, and each service adheres to the Single Responsibility Principle. The microservice architecture solves several inherent problems of the traditional monolithic architecture: each service can be independently deployed and delivered, greatly improving business agility; each service can independently expand/shrink horizontally to cope with the challenges of the Internet scale.
The original picture comes from Martin Fowler's definition of microservice architecture [3]
Of course, dismantling a large single application into multiple microservices will definitely increase the complexity of IT system R&D collaboration, delivery, and operation and maintenance. At this time, microservice architecture, DevOps and containers naturally came together, forming the prototype of cloud-native application architecture. The
microservice architecture inherits the architectural principles of SOA, but at the implementation level, it tends to replace ESB by constructing a decentralized distributed architecture style of intelligent endpoints and dumb pipes. The
microservice architecture must first face the inherent complexity of the distributed architecture. Please refer to the misunderstandings of distributed computing [4]. The microservice framework needs to be able to solve the complexity of service communication and service governance, such as service discovery, circuit breaker, current limiting, full-link tracking and other challenges.
microservice frameworks, such as HSF/Dubbo or Spring Cloud, encapsulate these capabilities in the form of code libraries. These code bases are built into the application itself and are released and maintained along with the application.
Service communication and governance are essentially horizontal system-level concerns and are orthogonal to business logic. But in the microservice architecture, its implementation and life cycle are coupled with the business logic. The upgrade of the
microservice framework will cause the entire service application to be rebuilt and deployed. In addition, because the code base is usually tied to a specific language, it is difficult to support multi-language (polyglot) implementation of enterprise applications.
Light of evolution: Cloud native
SOA adopts a centralized service bus architecture to decouple business logic and service governance logic; the microservice architecture returns to the decentralized point-to-point calling method, while improving agility and scalability. It also sacrifices the flexibility brought by the decoupling of business logic and service governance logic.
In order to solve the above challenges, the community proposed the Service Mesh (service mesh) architecture. It re-downloads service governance capabilities to the infrastructure and deploys them as independent processes on both the consumer and provider sides of the service. In this way,
not only achieves the purpose of decentralization and ensures the scalability of the system, but also achieves the decoupling of service governance and business logic. The two can evolve independently without interfering with each other, improving the flexibility of the overall architecture evolution. At the same time, the service grid architecture reduces the intrusion of business logic and reduces the complexity of multi-language support.The Istio project led by
Google, IBM, and Lyft is a typical implementation of the service grid architecture and has also become a new phenomenon-level "Internet celebrity" project.
The above picture is the architecture of Istio, which is logically divided into data plane and control plane:
- data plane consists of a set of intelligent agents deployed in sidecar mode, responsible for intercepting application network traffic, collecting telemetry data and executing service governance policies;
- control In the plane, Galley is responsible for configuration management, Pilot is responsible for delivering configurations, Mixer is responsible for policy inspection and telemetry data aggregation, and Citadel is responsible for security certificate management in communication.
Istio provides a series of high-level service governance capabilities, such as: service discovery and load balancing, progressive delivery (grayscale release), chaos injection and analysis, full-link tracking, zero-trust network security, etc., which can be used by upper-level business systems Orchestrate it into your own IT infrastructure and publishing systems.
However, Service Mesh is not a silver bullet. Its architectural choice is to increase the deployment complexity (sidecar) and lose performance (adding two hops) in exchange for architectural flexibility and system evolvability.
In order to solve the challenge of deployment complexity, the community and cloud service providers are working together:
- on the one hand simplifies the service grid automation operation and maintenance level (such as Alibaba Cloud greatly simplifies the upgrade operation and maintenance of Istio and cross-K8s cluster through the operator deployment complexity);
- on the other hand provides managed service mesh services to help users focus on service governance at the business level rather than infrastructure implementation.
Regarding performance issues:
- On the one hand, Service Mesh needs to reduce the performance overhead of its own control plane and service plane, such as offloading the mixer load as much as possible and moving governance policy execution to the data plane;
- on the other hand, it also needs to rethink the entire communication. The boundary between applications and network infrastructure in the stack.
In order to realize the interconnection between container applications, the Kubernetes community proposed the CNI network model to decouple the container network connectivity from the underlying network implementation. At the same time, K8s provides basic primitives such as Service, Ingress, and Network policy to support the application layer. Service communication and access control. However, these capabilities are far from meeting application needs for service governance. The
service grid adds new features such as traffic management, full-link observability, and secure interconnection in L4/L7. These are implemented by introducing the Envoy proxy running in user space. While improving flexibility, it is also inevitable Added performance overhead. In order to solve this problem systematically, the
community is conducting interesting explorations. For example, in the Cillium container network, operating systems and underlying network capabilities such as eBPF/XDP can be used to sink the service control capabilities of the application layer (such as service and network policy provided by Kube-Proxy) to the operating system kernel and network layer. The Service Mesh data link is optimized to reduce context switching and data copying, effectively reducing performance overhead.
Currently Service Mesh technology is still in the early stages of the technology maturity curve. In addition to providing flexible service communication functions at the L4/L7 layer, the community is also exploring flexible L2/L3 networking capabilities through network Service Mesh[6]. We believe it will become the future enterprise distributed application communications infrastructure.
will continue to create some new ideas and projects during this process, and we need to be able to rationally analyze their business value and technical limitations. We must avoid using Service Mesh as a panacea, and do not sink business logic such as application integration and application-side security into the service mesh to avoid repeating the mistakes of complexity. Please refer to Application Safety and Correctness Cannot Be Offloaded to Istio or Any Service Mesh[7].
Looking back at history
The general trend of the world is that if we divide for a long time, we will unite, and if we unite for a long time, we will divide. Enterprise distributed application architecture has also gone through an evolutionary path of division and integration. Today, with the emergence of new technologies, we must not only embrace the architectural changes brought about by new technologies, but also pay more attention to the evolutionary logic and core values behind them, and systematically control complexity.
Author: Yi Li
