阿里巴巴的云原生应用开源探索与实践

导读:从拥抱开源、贡献开源、自主开源,到赋能开源,开源已升级为阿里技术战略之一,且正为开发者源源不断地输送切实可见的价值。云原生是阿里开源的重要领域,短短几年,以 K8s 为核心的云原生开源生态迅猛发展,这是全世界开发者合作杰出成果,也是开源力量的结晶。

阿里巴巴的应用架构演进

大家好,我是司徒放,目前在阿里巴巴负责阿里云的应用平台和微服务产品线。在和大家分享我们在云原生应用方面的探索之前,先和大家介绍一下阿里巴巴在整个应用架构方面的演进历程。

今年是阿里巴巴成立的二十周年,二十年前,阿里巴巴使用的这个应用的架构,还是单体应用模式,它有很多的业务模块都在一个应用里面,各个业务都在一个应用里面开发,这个架构的一个好处是简单,也非常容易部署,对小的创业公司来说是很方便的。它的缺点在于团队变大变多之后,不能满足快速迭代要求,因为每一个业务它需要去发布的时候,都需要在同一个应用上做修改、发布,当这个业务迭代非常快的时候,它同时的一个并发修改就非常多。

所以在 2008 年的时候,阿里巴巴就引进到了微服务架构,只是当时并不叫微服务,而是叫服务化架构。各个业务模式就按照服务的边界来拆分,这是比较松耦合的一种方式,一个微服务应用是无状态的,可以快速扩展实例。而且某个实例有异常比如宕机时会可以自动下线,不会影响整个服务架构的稳定性。微服务架构也比较容易推动整个互联网公司的快速迭代需求。

大概三年前,阿里巴巴就走向了云原生的架构。这是一个天然适合云的、能够充分利用云的弹性能力和标准云服务,给整个阿里巴巴的电商降低机器的准备成本,特别是类似于在大促双十一需要很多机器去支撑,但是大促结束之后,这些机器有一半以上就可以归还到云上。

这个时候,阿里巴巴就在往云原生的方向去迈进,而且通过整个云服务能够更快地加快整个阿里巴巴的技术构建。而且云原生架构,是一个比较开放、标准、没有侵入性的技术架构。

阿里巴巴在云原生的开源进程

在阿里巴巴进入到了云原生之后,我们看一下阿里巴巴在开源方面做了一些什么样的事情呢?

运维领域

首先,整个云原生架构里面最重要、最关键的一个基石就是 Kubernetes。
阿里巴巴在两年前,就在大规模的落地 Kubernetes 的整套技术用来做我们机器资源的调度和管理。在内部有数十万台级别的机器以及上百万级别的容器规模,直接拿开源的 Kubernetes 到这种生产规模下是用不起来的,所以我们在上面做了很多性能优化,包括针对规模上的改造,使得整个 Kubernetes 在阿里巴巴内部能够很顺畅地 run 起来,阿里巴巴也在不断地向上游去贡献我们内部实践和优化的代码。
除了 Kubernetes 之外,在整个云原生生态里还有像容器、etcd,我们也在不停地优化它的规模能力以及安全隔离方面的一些能力。同时,也开源了内部使用的蜻蜓(Dragonfly)用来做大规模的镜像快速分发。

开发领域

在开发领域,阿里巴巴很早就已经使用了微服务架构,也对外进行了开源,比如说 Apache Dubbo,这个是比较知名的 RPC 框架;还有去年开源的 Nacos ,作为阿里巴巴集团支撑大规模的服务注册发现、配置推送一个组件;另外,还有 Spring Cloud Alibaba,基于阿里开源的组件提供了一整套 Spring Cloud 最佳实现;还有像支撑整个阿里巴巴高可用的 Sentinel、以及 Apache RocketMQ 消息队列,都是我们在开发领域做的开源。

这些组件其实随着阿里巴巴进入云原生时代之后,也在逐步结合云原生做一些改进,比如说 Apache Dubbo,会更好地去适配我们未来的微服务 Service Mesh 架构,它会理解 Istio 的 xDS 协议,成为一种数据面;比如 Nacos,它为 Service Mesh 的 Istio 提供 MCP 协议的对接,成为云原生微服务和传统微服务互通的桥梁。

应用

在开发领域和运维领域之间,其实我认为还有一个很大的空缺,就是专门用来连接整个开发和运维的应用这一块。

对于开发阶段,写完代码之后交付的是一个应用包,而这个应用包也是整个运维系统上运行的一个基础颗粒。我们认为现在在云原生阶段,缺少了一个很好的应用交付和运维标准,大家在不同的公司会看到每个公司都有不一样的运维平台,应用的部署和交付都没有办法被标准化。我们现在进入云原生时代,推崇的是标准、开放,所以我们认为在这一块上面还有很大的机会去做进一步的应用标准建设,这是我接下来想要和大家重点分享的一个话题。

云上应用交付和运维的痛点

先看一下云原生在交付和运维方面有哪些痛点呢?

刚刚也讲到了,在进入到了微服务之后,我们面临的一个问题就是应用的实例数会越来越多,会到成百上千的规模不断往上增长;另外还有我们部署的环境也变得越来越多,比如说现在有不同的云厂商,以及我们有很多专有云的自建机房的输出;另外还有很多自建的环境,这些环境多样化以及我们应用在运行时它会以容器的方式去运行,可能还是以传统的虚拟机的方式去运行,或者它会以函数的方式去运行,但是运行时也会有很多不一致,比如不同的环境、或运行时的不一致,会导致整个分布式运维体系变得越来越复杂,它的监控、日志采集也是一个很大的挑战。

当这些应用已经放到云上去运行的时候,由于很多的云服务并没有被标准化,很多这种云的能力需要集成到应用上的时候,也会有很大集成的困难。而这些云上应用运维的痛点以前也有类似的,我们可以跟过往的解决方案做一个对比。

过往解决方案

首先,是类似 Ansible、Puppet 这些基础设施运维自动化的工具。这些工具对整个运维效率起到了很大的提升作用,减轻了运维同学的工作量,但是它使用的是一些自应用的模块,而且它的概念是偏向于脚本运维的方式,非常的底层。

随后出现了类似 Cloud Foundry 、Heroku 这种比较经典的应用平台,这些应用平台是以应用为中心去做运维和交付,往上把运维的工作进行了一个抽象,按照 buildpack 的方式去做运维和交付,通过 buildpack 的方式,可以简化整个应用运维的工作,但是 buildpack 本身覆盖的范围比较窄,在运维和交付方面,缺乏一些运维交付的标准,所以它的可扩展性是比较差的。

随着 Docker 容器的横空出世,打破了传统基于 buildpack 的应用交付模式,所以就出现了新一代的容器管理平台,而 Kubernetes 成为了云原生时代一个新的容器平台事实标准。Kubernetes 本身提供了很多基础服务抽象,比如说 Deployment、Service。在社区里面它有一句很著名的定位:“Kubernetes is the platform for platforms.”也就是说,Kubernetes 定位是构建平台的平台,能够简化构建应用平台的复杂度,它不会再去做上层基于应用的抽象。大家可以发现历史总是那么相似,从过去的运维工具到后来基于应用的抽象,到现在容器出现打破运维格局,重新对这个领域进行洗牌,自然,在云原生时代需要一个对应交付和运维应用的平台。

从过往解决方案引发的思考

关于云原生时代的应用抽象,我们要做一个思考:我们需要什么样的应用抽象呢?

首先,它需要解决我们运维交付的一个复杂度,以及屏蔽底层细节差异。无论什么时候,都是应用平台需要解决的问题。另外,参考我们过去比较传统的应用平台的问题,比如说 buildpack 这种方式,它存在不通用/不易于扩展的问题,我们认为接下来的应用抽象,它应该要具备在应用运维方面更加通用、可扩展的描述能力。

除此之外,我们在推广应用抽象的时候,还是要采用开源和社区的方式去推进,因为未来一定是更加标准和开放的,我们推广这个应用抽象,就是希望有更多开发和运维工作者,能够给这个标准提供更多的建议,能够通过整个社区进一步推动整个应用交付和运维标准的发展。

Open Application Model - 开放应用模型

在上个月中旬,阿里云和微软联合发布了“Open Application Model(开放应用模型)”这一个开源项目。我们希望通过这个开放应用模型,解决“在云原生时代缺乏一种应用交付标准”的问题。(“Open Application Model -开放应用模型”后面简称为“OAM”)

OAM 的三种角色

OAM 里面有三种不同的角色。

  • 首先是应用开发。很明显,应用开发是负责编写业务逻辑的。比如说它会写 Spark、Wordpress、Spring Cloud 等微服务的程序,它写完这个微服务的程序之后呢,会按照 OAM 标准编写一段应用定义;
  • 第二个是应用运维的角色,就是负责应用的交付与运维;
  • 第三个角色是基础设施平台。基础设施平台在 OAM 里的一个重要定位,在于它要将自己的基础服务能力抽象成可被复用、被重用的模块,并提供给开发和运维人员去使用。

OAM 核心概念解读

下面为大家解读以上的三个角色对应的三个核心概念。

  • 首先是 Component。它是被开发人员定义的一个可被重用的应用组件,这个应用组件描述的就是这个应用它运行的方式;
  • 第二个重要概念是 Trait。它是一种应用的运维特征,是由基础设施平台这个角色定义的,而这个定义它包含了可组合的应用运维特征,这个特征是其实是这个平台可以提供出来的某种运维能力抽象;
  • 最后一个是 ApplicationConfiguration。运维人员负责把 Component 和 Trait 两个绑定在一起,并且作为一个具体的实例化,生成了这个应用配置(ApplicationConfiguration)之后,就可以把应用部署起来。

用 OAM 描述的应用配置示意

接下来是一个具体的用 OAM 描述的应用配置文件(上图文件做了一定内容简化,具体以下面的 yaml 文本为准)。

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:name: wordpress
spec:workloadType: core.oam.dev/v1alpha1.Servercontainers:- name: testimage: docker/wordpress:latestenv:- name: key1fromParam: test-keyports:- type: tcpcontainerPort: 9999name: httpparameters:- name: test-keytype: string
---
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:name: wordpress-app
spec:components:- name: wordpressinstanceName: wordpress-instanceparameterValues:- name: replicasvalue: 3- name: test-keyvalue: value-from-opstraits:- name: serviceparameterValues:- name: portMappingvalue: - protocol: "TCP"port: 52014targetPort: 9999- name: rolloutparameterValues:- name: canaryReplicasvalue: 1

由运维人员编写的 ApplicationConfiquration 文件,它将 Component 和 Trait 两个概念绑定在一起。首先里面描述运维要部署一个叫 wordpress-app的应用,它引用了一个叫 wordpress 的 Component。这是开发人员在另一个配置文件 Component 定义的,他除了定义 wordpress 应如何运行(比如配置镜像位置)以外,还允许运维配置运行实例的副本数以及运行时环境变量 test-key 的值。在 ApplicationConfiquration 里同时引用了两个运维特征,运维人员会填写这个应用需要一个负载均衡,要做外网的端口映射,部署时需要采用金丝雀发布策略。这个文件对应到实际上的部署阶段会变成如上图右侧所示,上面会有一个负载均衡,比如在云上运行时,就会使用 SLB 去做负载均衡的自动分发,会给它配置外网 IP 和内外端口映射。

通过这个简单的 yaml 文件,大家就可以了解到这个应用怎么做快速部署,并且描述运维要具备什么能力。

OAM 的设计理念

给大家总结一下,我所认为的 OAM 的重要的设计理念。

  • 首先第一个是配置即代码。所有的 OAM 上面的运维和交付的操作都会使用配置的方式,完全通过 yaml 文件去完成所有的交付运维配置;
  • 第二个是依赖倒置。这个依赖倒置有点像 JAVA Spring 开发者使用 IoC 或者 DI 的这种模式,在写这个应用配置的时候,只是依赖应用标准抽象,而这个标准抽象背后的实现实际上是由 OAM 的运行时去做“注入”,通过这个方式就使得我们的应用运维不依赖于我们具体的运行环境;
  • 第三个是重要的设计理念就是角色关注点分离。刚刚上面讲过 OAM 里的三种不同的重要角色:开发、运维以及基础设置平台。这三种角色只需要编写对应不同的配置文件,互相解耦。这样开发不需要关心应用是怎么运维的,只需要把运行时需要的配置暴露并描述出来;基础平台只需要把平台能力提炼成 Trait;最终由运维人员把开发需要的参数和运维需要的能力进行结合。
  • 第四个就是整个 OAM 的设计是一个可组合可扩展的方式。它会通过让我们刚刚说到的 Traits 能够按需组合、重用、移植和扩展。

EDAS & OAM

上面我们说了这么多其实都是比较一些概念性的东西,接下来我们看一下,在阿里巴巴的云产品 EDAS 对 OAM 所做一些落地方面的尝试,这也是第一个在实际生产上面基于 OAM 对外可开放使用的云产品。

下面会用 EDAS 为例,给大家做一个介绍,讲解一下 OAM 具体怎么运作。

EDAS 是什么?

首先介绍一下 EDAS 是阿里云上面的一个云产品,它扮演着我刚才讲到的类似于一个应用平台的一个角色:

  • EDAS 从开发方面就提供了开发框架给我们云上的开发者去使用;
  • 开发者开发完程序之后,会把应用交付到 EDAS 上面去进行部署;
  • 与此同时 EDAS 会对这个应用进行监控诊断,根据容量情况进行实例弹性伸缩;
  • EDAS 会对上面的微服务进行注册发现、服务治理;
  • 提供应用的高可用保护,比如限流降级、熔断等。

这些是 EDAS 作为应用平台在阿里云上的产品定位。

EDAS 支持 OAM 的运行示意图

那么它在支持 OAM 在运行的时候又是什么样的呢?

如图所示,一个开发人员,他首先需要去编写一个按照 OAM 标准为参考去定义一个 Component。这个 Component 里面会定义如开发应用类型是什么样子,比如它的镜像路径、它需要多大的存储空间,以及它的环境变量是什么样子,这些都是开发人员在开发的时候需要去描述的内容。

对于阿里云来说,它是一个基础设施平台的身份。它在上面其实有很多运维的能力,比如说像监控报警、块存储、需要发布策略和弹性伸缩的策略。EDAS 会把这些平台能力抽象成一个一个独立的 Trait,开放给运维人员使用。

在需要部署应用的时候,运维人员会选择 EDAS 上提供的 Trait 并填写相关参数,同时也设置好开发人员的 Component 的参数,这作为一次应用部署,生成了 ApplicationConfiguration 提交给 EDAS。

EDAS 作为 OAM 的运行时,在读取到这份部署配置后,它会去实现 Trait 提供相应的运维特征动作,比如说运维描述需要一个块存储,那么 EDAS 会在阿里云上面去申请一个具体的块存储对象,并绑定到这个应用上面。同时 EDAS 会提供一个容器环境(如 Kubernetes)去运行开发者定义的 Component 的工作负载,比如购买 ECS,配置好容器环境,把环境变量传给容器,使 Component 能够正常运行。

以上就是整个 EDAS 支持 OAM 的一个运行示意图。

EDAS 支持 OAM 的对比

那么 EDAS 在支持 OAM 之后,它的使用情况又会发生怎样的变化呢?

在没有使用 OAM 的时候,客户需要和系统解释我要做些什么事情、我要怎么做这个事情。比如说,他需要申请 5G NAS 存储,并且要把它挂载到某个机器的某个目录上面;或者他还有一个监控的需求,他需要告诉系统现在有一个业务指标文件,需要被监控采集,他要去设置这个文件的指标处理规则,最后把这个指标存储成时间序列数据,并且设置报警阈值。在使用 OAM 之后,它就变成了描述式,他只要描述我需要什么东西就够了。比如开发者可以说这个目录上面需要有 5G 的外置可读写存储就够了,具体这 5G 存储怎么申请是由 OAM 运行时去帮助解决的。另外,在监控的时候,他只需要描述自己的这个应用需要被监控、哪个指标需要被监控并报警就够了,他不需要了解对接到具体是哪一个监控系统,他不需要去关心这些事情。

原来很多云产品或者原来很多自定义运维平台都是需要依赖特定的 API 或者 CLI 这种模式去做运维的,这个时候应用要迁移到另外一个运维平台,它的代码、镜像、二进制包可以带走,但是它的很多运维的设施、运维的配置包括监控的配置,这些东西都是只能留在这个平台上的,没有办法很容易地迁移到另外一个平台上面。而通过 OAM,可以将平台所有的运维配置以 yaml 导出,并且能够很快地导入到另外一个环境、甚至是另一个应用平台上,整个系统会变得更加标准。

在使用 OAM 以前,运维人员需要去学习很多知识,比如使用的是 Kubernetes,他需要去了解整个容器和 Kubernetes 的使用方式,他要做定制和拓展就需要去学习 Kubernetes。如果他是从虚拟机的模式切换到容器的运维模式,这个时候他就需要很多时间去理解容器和虚拟机运维之间的差异。迁移到 OAM 之后,相当于 OAM 屏蔽了整个平台底层的细节,所以使得整个运维平台的 OAM 配置没有多大差别。

最后一点就是定制的难度上面。刚刚也讲到过,这个是 OAM 的一个重要的目标,让整个运维的扩展能够更容易的被发现、被组合、被替换。在使用 OAM 之前,运维的逻辑都散落在脚本里面,或者说都在运维平台内部,这个时候很难去统一管理。而一套 OAM 的运行环境是可以自描述的,可以非常容易把平台提供的 Trait、Component 工作负载罗列出来,使用者可以替换或增加新的 Traits,在运行应用时可以自由选择和组合这些 Traits。


原文链接
本文为云栖社区原创内容,未经允许不得转载。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/517443.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

RuoYi-Vue 部署 Linux环境 若依前后端分离项目(war 包+nginx版本)

文章目录一、软件安装部署1. 安装jdk2. mysql8安装部署3. redis安装4. nginx 安装部署5. Tomcat10 下载和配置 Linux 环境6. 克隆项目二、后端项目2.1. 修改数据库连接2.2. 修改Redis连接信息2.3. 文件路径2.4. 日志存储路径调整2.5. 修改war打包2.6. 编译打包三、前端项目3.1.…

技术直播:讲一个Python编写监控程序的小故事

今年疫情“黑天鹅”事件改变了大家的生活。相信大家都经历过,每天早晨起床第一件事,就是查看数据。这些数据不仅仅是人们对活着的渴望,也是在建立对战胜疫情的决心。那么技术人怎么能通过自己所学的去进行数据监控呢?今天CSDN邀请…

高精地图中地面标识识别技术历程与实践

导读:本文将主要介绍高德在高精地图地面标识识别上的技术演进,这些技术手段在不同时期服务了高精地图产线需求,为高德地图构建高精度地图提供了基础的技术保证。 1.面标识识别 地面标识识别,指在地图道路中识别出各种类型的地面…

RuoYi-Cloud 部署篇_04(windows环境 mysql+nginx版本)

文章目录一、nginx 操作流程1. nginx 安装启动2. nginx 配置3. nginx 重新启动二、前端项目编译2.1. 前端编译打包2.2. 静态复制迁移三、后端项目启动2.1. 我启动了6个服务2.2. 测试验证一、nginx 操作流程 1. nginx 安装启动 nginx(windows环境安装) …

从P4到P9, 在马云家写代码到双11前端PM

阿里妹导读:今年的双11已经是阿里资深前端技术专家舒文来阿里的第11年,从应届生到双11前端PM,他一路升级打怪,实现了岗位上从P4到P9的晋升。这第11届双11顺利结束之际,他把在阿里这些年的成长经历做一个总结和分享&…

在Java虚拟机上班是一种怎样的体验?

来源 | 编程技术宇宙责编| Carol封图 | CSDN 下载自视觉中国本文用知乎体的风格简单介绍了JVM中几个内置线程的工作,希望对大家学习JVM有一点帮助。匿名用户JVM老鸟228 人赞同了该回答利益相关,匿了!JVM公司里面线程众多,派系林立…

微服务架构四大金刚利器

概述 互联网应用发展到今天,从单体应用架构到SOA以及今天的微服务,随着微服务化的不断升级进化,服务和服务之间的稳定性变得越来越重要,分布式系统之所以复杂,主要原因是分布式系统需要考虑到网络的延时和不可靠&…

RuoYi-Cloud 部署篇_01(linux环境 Oracle +nginx版本)

文章目录一、基础准备1. 技术选型2. 源码克隆3. 安装依赖4. 安装oracle5. 安装启动Mysql6. 安装启动Redis7. 创建数据库,执行 SQL脚本文件二、安装与配置 nacos2.1. 下载nacos2.2. 安装 nacos2.3. nacos持久化配置2.4. 执行脚本文件2.5. nacos连接 mysql 配置信息2.…

当60亿次攻击来袭,人机联合打了一场漂亮的防御战

云是大规模体量下各种小概率事件常态化的一个复杂场,云上的攻防对抗是攻击者和防御者在这张复杂场上的博弈与演化。大规模的环境之中充斥着各种各样转瞬即逝的信息,对于威胁,没有什么是比「大规模」和「转瞬即逝」还更好的隐匿与庇护。任何一…

RuoYi-Cloud 部署篇_02(linux环境 Oracle +nginx版本)

文章目录一、模块配置修改1. ruoyi-gateway-dev.yml2. ruoyi-auth-dev.yml3. ruoyi-system-dev.yml4. ruoyi-gen-dev.yml5. ruoyi-job-dev.yml6. ruoyi-file-dev.yml二、后端配置预启动2.1. 部署资料整合2.2. 模块端口划分2.3. 组件端口划分2.4. 服务脚本编写2.5. 前端编译生产…

一个多业务、多状态、多操作的交易链路?闲鱼架构这样演进

前言 双十一刚刚结束,成交额2684亿震惊全世界,每秒订单峰值达54.4W笔。在闲鱼2000万DAU,交易数额同样增长迅速的今天,我们如何保障交易链路的稳定与快速支撑业务?这篇文章从客户端开发的角度,介绍闲鱼交易…

RuoYi-Cloud 部署篇_03(linux环境 Oracle +nginx版本)

请参考RuoYi-Cloud 分布式部署_03(linux环境 Mysqlnginxredis版本)

没想到 Google 排名第一的编程语言,为什么会这么火?

没想到吧,Python 又拿第一了! 在 Google 公布的编程语言流行指数中,Python 依旧是全球范围内最受欢迎的技术语言!01为什么 Python 会这么火?核心还是因为企业需要用它!因为其易用、逻辑简单并拥有海量扩展包…

写1行代码影响1000000000人,这是个什么项目?

不带钱不带卡,只带手机出门就能畅行无阻,这已是生活的常态。益普索发布的《2019第一季度第三方移动支付用户研究》报告显示,移动支付在手机网民中的渗透率高达95.1%,截至今年1月,支付宝全球用户数已经突破10亿。你或许…

高德客户端及引擎技术架构演进与思考

2019杭州云栖大会上,高德地图技术团队向与会者分享了包括视觉与机器智能、路线规划、场景化/精细化定位、时空数据应用、亿级流量架构演进等多个出行技术领域的热门话题。现场火爆,听众反响强烈。我们把其中的优秀演讲内容整理成文并陆续发布出来&#x…

免费直播:主流深度框架对比:总有一款适合你~

常常有小伙伴在后台反馈:想了解深度学习该怎么学?自学难度大又没有效果,该怎么办?CSDN为了解决这个难题,联合唐宇迪老师为大家带来了一场精彩的直播【一节课掌握深度学习必备框架】。本次直播将带大家了解在开始深度学…

Swift 在 GAIA 平台云端一体化的探索

作者|姜沂(倾寒) 出品|阿里巴巴新零售淘系技术部 S1 阶段在使用 SwiftUI 编写集团内部使用的 SOT APP 时,有幸参与到 GAIA (FaaS)平台云端一体化的探索,从头到尾实现了一套基于 Swift 语言实现的遵守 GAIA…

微信小程序实现刷脸登录

🎨领域:Java后端开发🔥收录专栏: 系统设计与实战 🐒个人主页:BreezAm 💖Gitee:https://gitee.com/BreezAm ✨个人标签:【后端】【大数据】【前端】【运维】 文章目录&am…

SOFAStack的前世今生

十二年前,为了解决支付宝第一代架构在迅猛发展的业务面前捉襟见肘的困境,蚂蚁金服技术团队开启了一次前所未有的尝试。创新都是被逼出来的,今天高速发展的SOFAStack同样如此。 十二年时间,几代蚂蚁技术人参与攻坚,SOFA…

从浪漫走向坚韧:开源数据库的演变

图:Peter Zaitsev作者 | Adrian Bridgwater译者 | 火火酱,责编| Carol“最初,所有的软件都是开源的。”——这是Percona首席执行官彼得扎伊采夫(Peter Zaitsev)在其公司今年虚拟年度用户/客户峰会上的开场白。如果我们…