cs架构嵌入bs_「分布式系统前沿技术」专题 | 复杂分布式架构下的计算治理之路...

分布式技术的发展，深刻地改变了我们编程的模式和思考软件的模式。值 2019 岁末，PingCAP 联合 InfoQ 共同策划出品“分布式系统前沿技术 ”专题， 邀请众多技术团队共同参与，一起探索这个古老领域的新生机。本文出自微众银行大数据平台负责人邸帅。

在当前的复杂分布式架构环境下，服务治理已经大行其道。但目光往下一层，从上层 APP、Service，到底层计算引擎这一层面，却还是各个引擎各自为政，Client-Server 模式紧耦合满天飞的情况。如何做好“计算治理”，让复杂环境下各种类型的大量计算任务，都能更简洁、灵活、有序、可控的提交执行，和保障成功返回结果？计算中间件 Linkis 就是上述问题的最佳实践。

复杂分布式架构环境下的计算治理有什么问题？

什么是复杂分布式架构环境？

分布式架构，指的是系统的组件分布在通过网络相连的不同计算机上，组件之间通过网络传递消息进行通信和协调，协同完成某一目标。一般来说有水平（集群化）和垂直（功能模块切分）两个拆分方向，以解决高内聚低耦合、高并发、高可用等方面问题。

多个分布式架构的系统，组成分布式系统群，就形成了一个相对复杂的分布式架构环境。通常包含多种上层应用服务，多种底层基础计算存储引擎。如下图 1 所示：

图 1

什么是计算治理？

就像《微服务设计》一书中提到的，如同城市规划师在面对一座庞大、复杂且不断变化的城市时，所需要做的规划、设计和治理一样，庞大复杂的软件系统环境中的各种区域、元素、角色和关系，也需要整治和管理，以使其以一种更简洁、优雅、有序、可控的方式协同运作，而不是变成一团乱麻。

在当前的复杂分布式架构环境下，大量 APP、Service 间的通信、协调和管理，已经有了从 SOA（Service-Oriented Architecture）到微服务的成熟理念，及从 ESB 到 Service Mesh 的众多实践，来实现其从服务注册发现、配置管理、网关路由，到流控熔断、日志监控等一系列完整的服务治理功能。服务治理框架的“中间件”层设计，可以很好的实现服务间的解耦、异构屏蔽和互操作，并提供路由、流控、状态管理、监控等治理特性的共性提炼和复用，增强整个架构的灵活性、管控能力、可扩展性和可维护性。

但目光往下一层，你会发现在从 APP、Service，到后台引擎这一层面，却还是各个引擎各自为政，Client-Server 模式紧耦合满天飞的情况。在大量的上层应用，和大量的底层引擎之间，缺乏一层通用的“中间件”框架设计。类似下图 2 的网状。

图 2

计算治理，关注的正是上层应用和底层计算（存储）引擎之间，从 Client 到 Server 的连接层范围，所存在的紧耦合、灵活性和管控能力欠缺、缺乏复用能力、可扩展性、可维护性差等问题。要让复杂分布式架构环境下各种类型的计算任务，都能更简洁、灵活、有序、可控的提交执行，和成功返回结果。如下图 3 所示：

图 3

计算治理问题描述

更详细的来看计算治理的问题，可以分为如下治（architecture，架构层面）和理（insight，细化特性）两个层面。

计算治理之治（architecture）-架构层面问题

紧耦合问题，上层应用和底层计算存储引擎间的 CS 连接模式。

所有 APP & Service 和底层计算存储引擎，都是通过 Client-Server 模式相连，处于紧耦合状态。以 Analytics Engine 的 Spark 为例，如下图 4：

图 4

这种状态会带来如下问题：

• 引擎 client 的任何改动（如版本升级），将直接影响每一个嵌入了该 client 的上层应用；当应用系统数量众多、规模庞大时，一次改动的成本会很高。
• 直连模式，导致上层应用缺乏，对跨底层计算存储引擎实例级别的，路由选择、负载均衡等能力；或者说依赖于特定底层引擎提供的特定连接方式实现，有的引擎有一些，有的没有。
• 随着时间推移，不断有新的上层应用和新的底层引擎加入进来，整体架构和调用关系将愈发复杂，可扩展性、可靠性和可维护性降低。

重复造轮子问题，每个上层应用工具系统都要重复解决计算治理问题。

每个上层应用都要重复的去集成各种 client，创建和管理 client 到引擎的连接及其状态，包括底层引擎元数据的获取与管理。在并发使用的用户逐渐变多、并发计算任务量逐渐变大时，每个上层应用还要重复的去解决多个用户间在 client 端的资源争用、权限隔离，计算任务的超时管理、失败重试等等计算治理问题。

图 5