From the micro to the SOA services, distributed enterprise application architecture to reshape how the native cloud era?
HTTPS: // yq.aliyun.com/articles/720090?utm_content=g_1000078933 content and are very careful that you need to read several times to learn.
Ali sister REVIEW: more than ten years ago from a variety of distributed systems development to the current container cloud, from supporting existing business incubator to each new business development is inseparable unified technical architecture of the times. This article describes the changes in cloud computing architecture provides native from the distributed enterprise application architecture level, hoping to help more enterprise IT transformation, the use of cloud computing technology to promote competition in the market to become its agile force.
In the 21st century, we have witnessed the enterprise distributed application architecture from SOA (Service-oriented Architecture), to the micro-service architecture, to the evolution of cloud-native application architecture.
In order thinking behind the evolution of enterprise architecture description, let's talk about some metaphysics.
- First, the complexity of enterprise IT system (entropy) in line with the second law of thermodynamics. With the deduction of time, changes in the business, the complexity of enterprise IT systems is increasing;
- Second, there is a well-known law of conservation of complexity [1] In the design of computer interaction. The complexity of the interactive applications will not disappear, only to put it another way exists. This principle also applies to software architecture. The introduction of new software architecture, will not reduce the overall complexity of IT systems.
Hearing this, whether you want is life, not just toss us feel a little cool?
One of the core tasks of modern software architecture is defined border infrastructure and applications, reasonable segmentation complexity, reduce the complexity of application developers need to face. In other words, it is to allow developers to focus on the core values of innovation, and put some more questions to the right people and systems to solve.
We started from the image below, explore business logic behind the evolution of distributed application architecture.
Metamorphosis pain: SOA
In 2004, IBM established a global SOA Design Center, I, as R & D and TL architects involved in a range of customers worldwide pilot project to help Pepboys, Office Depot and other international enterprises use SOA to optimize business processes within the enterprise and between enterprises, enhance business agility sex.
The big picture then is: With the gradual deepening of economic globalization, companies face increased competition, changes in business began to accelerate. Within the large enterprise IT systems has undergone decades of evolution, the whole system becomes very complex technology, coexist on a host system, such CISC / COBOL trading applications, minicomputers AS400 RPG in business systems, and X86 / Power and other distributed systems C / JEE / .Net applications.
A large number of applications provided by third-party vendor, some systems have even no maintenance. And with the business of iterations, some new business system is continuous build up, due to the lack of a reasonable methodology to guide the lack of organic links between the systems, the formation of a number of the island, continued to increase the complexity of the IT infrastructure can not support business development aspirations. This seemed to master in order to help the injured parties Linghu, the heterogeneous infuriating enter the body, although for a short time can ease the injury. But not infuriating multi-channel integration, stirring each other for a long time down will hurt plus injury.
Therefore, the primary challenge faced by IT companies is the integration of a large number of enterprises in vertical barrel (silo-ed) IT systems, supporting increasingly complex business processes, rapid changes in effective business decisions and support services.
In this context, IBM and other companies proposed SOA (Service Oriented Architecture) concept, abstract application system into a more coarse-grained services, building loosely coupled services architecture can be flexible combination of services through business processes, improve enterprise IT asset reuse, improve the adaptability, flexibility and scalability to address the "information island" problem.
SOA presents a set of principles for building distributed systems, these reflections is still applicable today:
- Service with a standardized interface clearly defined. We will achieve the service consumer (Service Consumer) and service provider (Service Provider) to decouple defined by the service description and contract-first service should be used rather than code-first approach to development. Communication between services using document-oriented RPC protocol message instead of a specific language, and services can solve decoupled language, on the other hand to achieve the flexibility to choose the synchronous or asynchronous communication to improve system availability and scalability;
- Services should be loosely coupled, there should be no time, space, technology, rely on the team between services;
- Service should be stateless, making service calls and session context state decoupling;
- Service should be autonomous and self-contained, implementation of the service can be deployed independently, version control, self-management and recovery;
- Service is found that can be combined. For example, the service can be found to achieve a dynamic binding service consumers and service providers through the Service Registry. Business process orchestration can be assembled on business services from different systems.
When the initial build SOA system, they use a point to point communication link, and the service invocation logic is embedded in the application integration implementation. In this way the number of services is relatively small, when really is a simple and efficient way of development. But the biggest problem is that, with the growth in the size between services, communication services become more complex, and complexity of the connection path will surge to service enormous governance challenges.
To address these challenges, enterprise service bus (Enterprise Service Bus, ESB) began to be introduced. Enterprise Service Bus provides the connection between the service (connection), conversion (transformantion), and the ability to deal with an intermediary (mediation) is. And a variety of services within the enterprise can be connected to the service bus architecture to achieve loose coupling between information systems, shielding the complexity of system integration, improve the flexibility of IT infrastructure and reduce the cost of internal information sharing.
SOA methodology is like being Yijinjing can help sort out, go gather different infuriating, mastery, as I used to. However, the cultivation process was not easy. A large number of ambitious SOA projects did not achieve the desired results, what is the reason behind this is?
Any successful IT architecture are inseparable from each other in conjunction with business objectives, technology infrastructure and organizational capacity.
In business, time is focused on solving the problem of SOA enterprise IT stock market. This makes the SOA methodology to a large extent is narrowing as Enterprise Application Integration (EAI Enterprise Application Integration).
In the SOA philosophy, open up the meridians between the information system is only the first step, but also xiu internal strength for iterative reconstruction of enterprise IT infrastructure, so as to maintain their enterprise IT infrastructures agile, flexible, continue to support the development and changes in the business.
The organizational structure, because at that time most of the enterprise IT sector remains a cost center, is a subsidiary of the business support sector, most companies lack a long-term IT strategic planning, IT team also recognized the lack of growth, SOA system operation and reduced project no organized security and continued investment.
Even when the success of the project will be aggressive in complexity over time and gradually lose its vitality. Last year in American life friend sent me pictures, 15 years ago for our customers to build business systems also support its existing stores nationwide business. This is a successful technology projects, it reflects the lack of corporate technology strategy.
Technically, ESB architecture implements the business logic and although the service integration decoupling can better manage centralized service, but also exposed some serious problems:
- Due to excessive emphasis on reusability of business systems, rather than governance and reconstruction of the enterprise IT infrastructure. A large number of service integration logic is implemented to sink into the interior ESB (rightmost as shown above), the logic is very hard to maintain, and difficult to transplant extended, become Burden for ESB. We must properly handle the complexity in the right place and not be simply transferred;
- ESB is based on a centralized messaging system, but with the rapid development of the Internet, ESB has been unable to cope with the challenges of the growing scale enterprise IT;
- ESB Smart Pipes such, Dumb endpoints of a system architecture is unable to adapt to a rapidly changing infrastructure and public innovation.
Analogy a bit, telecom operators had hoped complex features video communications, conference calls into the telecommunication infrastructure, just a Dummy telephone terminal can enjoy rich communication services. However, with the popularity of smart phones, micro-channel and nail distributed collaboration tools such innovations have revolutionized the way people communicate, and the telecommunications network return the fate of the pipeline.
The emergence of the United States: Micro Service
With the development of the Internet, particularly the arrival of the mobile Internet era, the world economic structure has undergone tremendous changes change. Enterprise IT focus from the traditional System of Record (trading systems, such as ERP, SCM, etc.) the evolution of the System of Engagement (interactive systems, such as full-channel marketing).
These systems need to be able to cope with the rapid growth of Internet-scale, and can rapidly iterate and cost of trial and error. Enterprise IT has become one of the driving engines of innovation, ideal technology to expand business boundaries also help IT teams better sense of mission, to further accelerate the evolution of enterprise IT.
With Netflix, Ali, led a series of Internet companies dominate the corporate structure of the new changes - the micro-service architecture. Apache Dubbo, Spring Cloud services such as micro-framework has been widely used.
The core idea is to split the application functionality and decoupling micro services, reduce business system implementation complexity. Micro-service stressed that the application functions as a set of loosely coupled dismantling services, each single comply with the principle of responsibility (Single Responsibility Principle). Micro-service architecture solves several problems inherent in traditional monolithic architecture: Each service can be deployed independently and delivery, greatly enhance business agility; each service independently of the lateral expansion / contraction, the challenge of Internet-scale.
Martin Fowler from the original definition of the micro-services architecture [3]
Of course, the dismantling of large monolithic applications into multiple micro-services, will certainly increase the IT system development coordination, delivery, operation and maintenance complexity. At this time the micro-service architecture and the natural vessel DevOps and come together, constitute the prototype of native cloud application architecture.
Micro-service architecture inherited the architectural principles of SOA, but at implementation level, it tends to be replaced by constructing intelligent endpoints and ESB to the center of the distributed architecture style of dumb pipes.
Micro-service architecture must first face the endogenous complexity of distributed architecture, please refer misunderstanding of distributed computing [4]. Micro-services framework needs to be able to solve complex communications and service management services, such as service discovery, fusing, current limiting, Link-tracing challenge.
Micro services framework, such as HSF / Dubbo manner or Spring Cloud code library to encapsulate these capabilities. The code base is built in the application itself, together with the release of the application and maintenance.
服务通信和治理本质是横向的系统级关注，是与业务逻辑正交的。但在微服务架构中，其实现方式和生命周期与业务逻辑耦合在一起的。
微服务框架的升级会导致整个服务应用的重新构建和部署。此外由于代码库通常与特定语言所绑定，难以支持企业应用的多语言（polyglot）实现。
进化之光：云原生
SOA 采用中心化的服务总线架构，解耦了业务逻辑和服务治理逻辑；微服务架构回归了去中心化的点对点调用方式，在提升敏捷性和可伸缩性的同时，也牺牲了业务逻辑和服务治理逻辑解耦所带来的灵活性。
为了解决上述挑战，社区提出了 Service Mesh（服务网格）架构。它重新将服务治理能力下沉到基础设施，在服务的消费者和提供者两侧以独立进程的方式部署。
这样既达到了去中心化的目的，保障了系统的可伸缩性；也实现了服务治理和业务逻辑的解耦，二者可以独立演进不相互干扰，提升了整体架构演进的灵活性。同时服务网格架构减少了对业务逻辑的侵入性，降低了多语言支持的复杂性。
Google, IBM，Lyft 主导发起的 Istio 项目就是服务网格架构的一个典型的实现，也成为了新的现象级“网红”项目。
上图是 Istio 的架构，逻辑上分为数据平面和控制平面：
- 数据平面由一组以 sidecar 方式部署的智能代理组成，负责截获应用网络流量，收集遥测数据并且执行服务治理策略；
- 控制平面中，Galley 负责配置管理，Pilot 负责下发配置，Mixer 负责策略检查和遥测数据聚合，Citadel 负责通信中安全证书管理。
Istio 提供了一系列高阶的服务治理能力，比如：服务发现和负载均衡，渐进式交付(灰度发布)，混沌注入与分析，全链路追踪，零信任网络安全等，可以供上层业务系统将其编排到自己的 IT 架构和发布系统之中。
但是 Service Mesh 不是银弹，其架构选择是通过增加部署复杂性（sidecar）和损失性能（增加两跳），来换取架构的灵活性和系统的可演化性。
为了解决部署复杂性的挑战，社区和云服务商都在共同进行努力：
- 一方面简化服务网格自动化运维水平（比如阿里云通过 operator 大大简化了 Istio的升级运维和跨 K8s 集群部署的复杂度）；
- 另一方面提供托管的服务网格服务，帮助用户关注在业务层面的服务治理而非基础架构实现。
关于性能问题：
- 一方面 Service Mesh 需要降低自身控制平面和服务平面的性能开销，比如尽可能 offload mixer 负载，将治理策略执行下沉到数据平面完成；
- 另一方面还需要重新思考整个通信栈中应用与网络基础设施的边界。
为了实现容器应用之间的互联互通，Kubernetes 社区提出 CNI 网络模型，将容器网络连通性与底层网络实现的进行解耦，同时 K8s 提供了 Service, Ingress, Network policy 等基本元语来支持应用层的服务通信和访问控制。但是这些能力远不能满足应用对服务治理的需求。
服务网格在 L4/L7 增加了流量管理、全链路可观测性、安全互联等新功能，这些是通过引入运行在用户空间的 Envoy 代理实现的，在提升灵活性的同时也不可避免地增加了性能开销。
为了系统化解决这个问题，社区在进行有趣的探索。比如在 Cillium 容器网络中，可以利用 eBPF/XDP 等操作系统和底层网络能力，将应用层的服务控制能力（如 Kube-Proxy 提供的 service, network policy）下沉到操作系统内核和网络层解决，并优化了 Service Mesh 数据链路，减少上下文切换和数据拷贝，有效地减少了性能开销。
目前 Service Mesh 技术还处在技术成熟度曲线的初期，除了在 L4/L7 层提供灵活的服务通信功能，社区也在探索通过网络 Service Mesh[6] 实现灵活的 L2/L3 组网能力。我们相信其会成为未来企业分布式应用通信基础设施。
在这个过程中会有一些新的理念和项目被持续创造出来，我们需要能够理性地分析其业务价值和技术局限性。我们要避免将 Service Mesh 作为万灵药，不要将应用集成、应用侧安全等业务逻辑下沉到服务网格中，避免我们重蹈复杂性覆辙。可以参考 Application Safety and Correctness Cannot Be Offloaded to Istio or Any Service Mesh[7]。
回望历史
天下大势，分久必合，合久必分。企业分布式应用架构也走过一条分分合合的进化道路。在新技术迭起的今天，我们既要拥抱新技术带来的架构变化，更加要关注其背后的演进逻辑和核心价值，系统化地控制复杂性。
原文链接
本文为云栖社区原创内容，未经允许不得转载。