作者|刘浩杨
起源|尔达 Erda 公众号
​

本文整顿自刘浩杨在 GopherChina 2021 北京站主会场的演讲，微信增加：Erda202106，分割小助手即可获取讲师 PPT。

前言

当今时代，数字化转型概念在 ToB 畛域十分炽热，越来越多的企业须要数字化转型，因而越来越多的厂商涌入了 ToB 市场，端点就是其中一员。
​

端点的外围业务是给企业提供从洽购、交易、履约、仓储到批发全链路的数字化转型解决方案。围绕这个目标，咱们建设了一整套面向云原生的企业数字化软件产品，其中：
​

• PaaS 平台 Erda 是技术底座。
• Trantor 是具备 HPAPaaS 能力的研发底座，运行在 Erda 之上，提供低代码和高效开发的能力。
• Gaia 是残缺的业务能力平台，笼罩打算、寻源、洽购、营销、服务、销售、交易、履约、结算等企业供应链业务畛域，提供会员营销、全渠道经营、SRM 洽购和在线销售平台等业务产品。

​

通过这几层能力的组合，使咱们具备了生产可定制 SaaS 化产品的能力，为企业客户提供端到端的解决方案，满足各行业不同客户的各类需要。所以能够看到在这个分层的企业数字化研发体系中，咱们通过 PaaS 平台向下屏蔽简单的基础设施，使整个业务零碎领有架构多云之上的能力；同时，PaaS 平台也向上提供微服务研发和治理的技术中台能力，让下层用户可能更专一于业务零碎本身的构建。
​

接下来，简略介绍一下咱们在构建 Erda 过程中的思考，文章后半局部将回到技术自身，来分享一下咱们如何应用 Golang 实现云原生的 PaaS 平台。
​

软件交付面临的问题和挑战

端点从 2012 年成立到当初，始终聚焦在企业级软件开发和交付上，咱们也从最开始的软件定制交付，到明天应用规范软件 + 二开机制解决定制需要的形式交付。在这个过程中，咱们遇到的问题能够总结为以下 4 点：
​

1. 随着交付规模的快速增长，开发和交付团队要如何提效？
2. 业务软件系统如何适配简单的客户部署环境？
3. 大规模交付的部署过程须要可被标准化。
4. 交付上线后须要继续保障业务稳定性。

现在，麻利开发是一个绝对遍及的概念，咱们在做软件交付的时候，也须要把开发流程从传统的瀑布式开发转变为麻利开发，比方一个现实的开发方式是：应用我的项目协同工具来治理研发过程的需要、工作、缺点；应用 gitflow 来治理性能需要的开发；应用自动化的流水线实现继续集成；而后基于容器化来部署咱们的软件；部署之后触发自动化测试来验证性能的正确性。同时，像 API 网关、微服务治理、容器服务、流计算等这些在互联网公司风行的技术，也逐步开始受到大型传统企业的青眼，这对咱们的要求也是进一步提高。
​

为了解决这些问题，咱们就须要一个残缺的 DevOps 平台来撑持整个研发交付的流程，来达到进步研发效力的目标。

方才讲了在研发过程中的问题，接下来聊一下在需要开发实现后，去企业提供的环境进行交付的环节。
​

在咱们做过的客户外面，有自建机房用 zstack 来提供虚拟化，也有洽购阿里云、腾讯云、或者微软云 azure 的 ECS，还有的会提供现成的容器环境但治理接口不同，比方 Rancher 和 OpenShift，这些状况咱们都碰到过。甚至最近的一个我的项目里，客户提供的是 arm 架构的运行环境。
​

因为这些企业提供的环境千差万别，所以交付就变成了一件很苦楚的事件。
​

回顾计算机软件的倒退历史，咱们晓得 java 是当初很风行的一个开发语言和平台，java 能风行的很大一个起因是因为它提出了 Java 虚拟机，通过编译 Java 代码到通用的字节码，再由运行时去即时编译字节码到不同平台的汇编形式来实现“一次编写，到处运行”。那么，咱们构建的软件系统是否也能够像 java 一样“一次打包，到处运行”？说到这里，可能很多人都会想到：基于 Docker 和 Kubernetes 作为软件的运行时也能够让咱们的软件制品屏蔽掉不同的部署环境。然而，治理不同环境下的 Kubernetes 也是一件很简单的事件，咱们须要一个平台来向上承载不同的业务零碎，向下治理资源和利用调度。
​

咱们明天的做法是通过一个多云治理平台来解决这个问题。

​

很多软件系统在验收交付上线后，如果没有一个残缺的平台实时监控、洞察零碎的衰弱状态，将会导致各种问题（稳定性、异样、谬误、攻打）时有发生，重大影响业务的失常运行。保障业务稳定性也是咱们能够提供给客户的外围服务之一。
​

在之前的案例里，咱们利用 PaaS 上监控的高度扩展性，帮忙一家排名世界 500 强的外企搭建了一套云上的对立监控运维平台，真正实现了从云产品，比方 SLB、WAF、ECS、RDS，到平台层、再到 PaaS 上运行的业务零碎的全链路监控和日志数据的对立剖析，再通过 PaaS 内置的可视化和告警入口，使得客户只须要投入很少的 IT 运维人员就可能保证系统的稳定性。
​

另一个场景是咱们的 PaaS 平台本身。咱们当初同时在运维着 100+ 的 Kubernetes 集群，但全职负责运维的共事大略只有三四人，而且可预感规模扩充的同时，也不须要在运维上投入更多的人力，这也得益于咱们对平台可观测性的全面笼罩。
​

所以能够看到，研发、交付、运维遇到的很多问题，咱们都是通过 PaaS 很好地解决了。

端点一站式 PaaS : Erda

后面提到，咱们构建 PaaS 很大一部分是来自端点本身的需要。早在 2016 年咱们就开始搭建端点的部署和利用监控平台，过后的抉择是应用 Docker 和 Jenkins 等开源工具、让业务利用手写 dockerfile 的形式来进行公布；在监控的选型上，应用 Zipkin 作为分布式应用的追踪零碎、应用 ELK 作为日志平台，这可能也是很多公司常见的做法。这套零碎搭建起来当前，在一段时间里满足了公司外部的开发应用，然而随着业务对平台要求越来越多，咱们也引入了更多的开源组件，保护这套零碎的老本也越来越高。同时，有客户心愿咱们能把技术平台也一起对外输入，很显然应用开源组件混搭的这台零碎并不能满足咱们的要求。
​

在 2017 年，咱们想要从新设计一个以利用为核心的研发平台产品，于是抉择了以 DC/OS 为底座，在下层应用 Java 构建 DevOps 和服务治理平台，并且在 2018 年初交付了第一个客户。当初来看，抉择 mesos 而不是 K8s，过后是走了弯路的，所以从 2018 年下半年开始，咱们也全面拥抱 K8s 生态。同时因为 Java 的性能和资源占用问题，咱们做了第二次的 PaaS 架构降级，开始应用 Golang 重写了大部分的平台组件，也因为要同时反对 DC/OS 和 K8s 两个容器平台，咱们拆分出了异构的调度器模块和流水线模块。时至今日，咱们正在交付的所有客户都曾经在应用 K8s 架构。
​

越往后走，咱们开发的性能就越多，平台笼罩的范畴也越大。咱们陆陆续续在平台上实现了微服务治理、快数据、挪动开发、边缘计算等诸多平台级利用，演变成了明天 Erda 的一站式 PaaS 产品矩阵。

上图是 Erda 现今的产品大图，其中以多云治理、DevOps、微服务治理和快数据四个平台为外围。咱们在多云治理平台外面实现了两个比拟重要的能力：
​

• 一个是对异构资源环境的反对，反对治理物理机、虚拟机、反对原生的 K8s 集群、DC/OS 集群等。
• 另一个能力是原生的多集群架构，能够通过不同的集群对环境进行物理隔离，比方实现开发、测试和生产环境的资源互不影响。基于容器化，咱们也能够很容易地实现对资源池的精密治理，按 CPU 和内存的粒度准确管制不同利用的资源分配等。

​

在多云平台之上，DevOps、微服务和快数据平台别离来治理业务和数据。在业务侧提供软件开发的需要、开发、测试、部署、运维全生命周期的性能，在数据侧也通过批流一体实现真正快数据治理能力。除此之外，业务和数据的对立协同，业务能够更大程度地通过数字进行形容，从而实现更为精细化的经营。

Erda 架构的思考

后面介绍了 Erda 提供的的一站式能力，那么咱们是怎么去实现在 PaaS 上实现构建不同的平台服务，实现同一个内核反对微服务开发和数据治理的能力呢？首先来看咱们对 PaaS 扩大架构的思考。
​

在最后的版本里，咱们只有简略的利用部署性能，把所有的代码放在一起构建了一个单体服务。随着平台性能逐步增多，咱们也开始把零碎拆分成更多的微服务，在拆分的过程中，严格遵守一些设计准则，进行正当的架构分层来防止服务爆炸。在 Erda 以后的零碎架构中，咱们把零碎分为三层：平台应用层，服务层和 PaaS 的内核层，并且约定每一层之间不容许产生横向调用，只容许调用下一层服务提供的接口。
​

内核层 提供了 PaaS 和基础设施交互的能力 ， 它蕴含三个外围组件和绝对独立的监控零碎：
​

• cluster manager 通过和每个集群的 cluster agent 通信，实现多集群治理的能力。
• pipeline 服务实现了 workflow 的编排和 job 调度能力，包含短时工作、数据的批工作、流工作等。
• orchestrator 服务实现了 workload 的编排和有状态 / 无状态的服务调度能力。
• 监控零碎负责收集、计算和展现每个集群上报的可察看性数据。

​

服务层 相似于业务零碎中提到的中台概念，提供平台中的公共功能模块的能力，如用户、租户、权限、告诉、报表、事件、审计、版本控制、项目管理等。
​

应用层 则是每个平台调用上层的能力进行本身的业务逻辑封装，同时提供和前端交互的接口。
​

通过这样一个分层架构，能够很容易地去实现一个新的平台利用。例如在实现挪动开发平台时，代码治理、构建流水线、审计能够复用 DevOps 原有的能力，用户行为剖析、异样剖析等性能依赖监控零碎的能力得以实现。
​

家喻户晓，Kubernetes 作为云原生利用的最佳部署平台，凋谢了容器运行时接口（CRI）、容器网络接口（CNI）和容器存储接口（CSI），这些接口让 Kubernetes 的开放性变得最大化，而 Kubernetes 自身则专一于容器调度。同样，在以利用为核心的 DevOps 平台中，CI/CD 是最为外围的能力，而咱们也认为 CI/CD 的外围是对 workflow 和 workload 的治理，所以咱们也凋谢了 workflow 接口和 workload 接口，让 DevOps 平台专一于利用开发治理，而不用关注 JOB 和利用被部署到何种平台上。

这里咱们也在实际基础设施即代码的思维。在 Erda 上，你能够应用 pipeline.yaml 来定义利用的 CI/CD 全流程，比方代码拉取、品质扫描、单测执行、利用编译、构建和部署。
​

一个 pipeline.yaml 的示例如下：

stages:
  stage:
  - git-checkout:
  stage:
  - buildpack:
      params:
        context: ${git-checkout}
  stage:
  - release:
      params:
        services:
          trade-server: ${buildpack:image}
          erda_yaml: ${git-checkout}/erda.yaml
  stage:
  - deploy:
      params:
        release_id: ${release:id}

​

同时，还能够应用申明式的 erda.yaml 来形容你的利用微服务架构，包含微服务之间的依赖关系、对中间件的依赖等，任何规范的 erda.yml 都能够被 DevOps 平台所部署。一个 erda.yaml 的示例如下：
​

services:
  trade-server:
    resources:
      cpu: 2
      mem: 2048
    deployments:
      replicas: 2
    ports:
     - port: 8080
    envs:
      ENABLE_ALIPAY: true
addons:
  mysql:
    plan: mysql:basic
    options:
      version: 5.7.23
      create_dbs: trade_db 

​

值得一提的是，基于 pipeline（流水线）和 erda（部署）两个定义之上，咱们构建了丰盛的 addon 和 action 市场，你能够把本人的服务打包成一个开箱即用的 addon，也能够来实现本人的流水线 action，这些机制让 DevOps 平台的扩展性失去极大的加强。

咱们再来看一下 Erda 微服务平台的设计。共分为管制面和微服务引擎两个局部，它们之间通过咱们设计的协定进行通信。通常，咱们会应用 Erda 内置的微服务引擎，这里的选型是应用了 Spring Cloud Alibaba 组件作为内置实现，能够兼容企业原有的 Spring Cloud & Dubbo 的业务利用，不须要改变任何代码即可接入。同时，对于有非凡需要应用云服务的用户，也反对间接对接云厂商的微服务引擎，咱们曾经实现了阿里云 MSE 的可选实现。在这样的设计下，当初很风行的 ServiceMesh 零碎比方 Istio 也能够很容易的作为 Erda 微服务引擎的一种实现被接入。

最初，咱们再来讲一下监控零碎的设计。在 Erda 的场景里，监控零碎同时撑持根底监控、APM 和浏览器端的监控，所以咱们没有间接应用社区风行的监控零碎，比方 Prometheus 或者 Skywalking，而是抉择了自研一套监控零碎，在采集端适配社区的标准化协定。
​

首先咱们在每个集群中装置基于 Telegraf 深度定制的 Cluster Agent，负责采集 Kubernetes、Erda 在集群中部署组件的可察看性数据，同时这个 Agent 也能够模仿成一个 Prometheus Server，拉取集群中被主动发现的 Exporters 数据。
​

那么在每个节点上，也会部署一个 Node Agent，能够主动发现节点上的 Pod，并把 Pod 辨认为 Erda 平台定义的 Service、Job 或者 Addon 组件。同时 Node Agent 也会作为一个本地 Proxy，接管 Pod 中的业务利用 Java Agent 探针和 NodeJS 探针上报的利用申请和 Trace 数据，转发给后端的 Metrics Gateway 组件。
在将来，咱们打算反对更多的第三方协定，如 SkyWalking 和 OpenTelemetry，来更多地进步 Erda 在可察看性上的扩大。

Erda Infra 模块化开发框架

后面从架构的角度讲了咱们对 PaaS 扩大的一些思考，也提到通过微服务的形式来构建整个平台，实现微服务化的重点就是要对系统性能进行正当拆解，把零碎拆解成诸多边界清晰、能够内聚的业务模块。
​

尽管在 golang 社区中有很多 web 开发框架，如 gin、go-zero、beego，但三思而行后，咱们发现须要的不仅仅是一个 Web 框架和微服务框架，而且还须要一个以模块化开发为外围，能够通过接口对系统进行扩大的开发体系。基于此咱们设计了 Erda Infra，一套轻量级 Go 微服务框架，蕴含大量现成的模块和工具，可能疾速构建起以模块化驱动的应用程序。
​

Erda-Infra 的外围个性包含：
​

• 以模块化设计形式来驱动利用零碎实现，反对模块可插拔。
• 对立配置读取，反对默认值、反对从文件、环境变量、命令行参数读取。
• 对立模块的初始化、启动、敞开。
• 对立治理模块间的依赖关系。
• 反对模块间的依赖注入。
• 蕴含大量现成的微模块 Provider，包含 etcd、docker、cassandra、es 的 sdk、Http Server、gRPC Server 等。
• 应用 Protocol Buffer 定义接口，反对主动生成 gRPC 和 HTTP 接口和客户端调用代码。
• 提供疾速构建模块的代码生成工具。

Erda 当初有数千个性能点蕴含在几十个服务外面，一旦服务性能拆分设计的不合理，很容易引发整个我的项目的保护老本问题。咱们在从架构层面扫视模块拆分的同时，也冀望应用开发框架来对开发进行一些束缚。
​

第一个准则 是对模块的拆分粒度要尽可能小，让每个模块的逻辑能高度内聚，对外的依赖能够松耦合。拿利用监控这个子系统来说，咱们拆解成了拓扑、服务列表、服务监控、浏览器监控、谬误剖析、链路追踪等绝对独立的模块，而后应用 Erda Infra 提供的能力拼装到一起组成监控的服务。
​

第二个准则 是模块的开发者须要面向接口开发，而不是面向实现；模块之间依赖接口，而不是具体的实现类。这样做的益处是须要对模块进行扩大的时候，能够不须要批改已有的代码。咱们也在 Erda Infra 中实现了依赖注入容器，通过相似 Spring 中 IoC 的形式，让开发模块的人更关注本人负责的逻辑单元。
​

上面来看一个 Erda Infra 中最简略的模块示例，咱们把模块定义为 provider 构造，能够把须要注入的接口申明在 provider 的字段中，同时还须要实现 Init、Run 函数来管制模块的生命周期，最初把定义好的模块注册到全局的服务容器中，即可实现一个微模块的实现。
​

​

那么咱们如何在服务容器中定位到实现的接口呢？Erda Infra 提供了一个 Provide 接口，在这个接口中咱们能够显示申明接口的具体实现，上面是 mysql-client 模块的申明示例：
​

​

对于接口的获取，Erda Infra 提供了主动注入和应用服务定位器来解析两种形式。
​

主动注入和 Spring 的应用一样，通过在字段上标记 autowired 标签即可失效：
​

​

服务定位器模式则能够应用在后台任务中，通过框架的服务上下文来获取须要的接口具体实现：
​

​

最初再来聊一聊 Erda 中的 API 定义形式，咱们把 API 对立都定义在 Protobuf 文件中，这样能够对立生成 gRPC、HTTP、OpenAPI 接口，以及 Client 的代码。
​

假如零碎中有一个服务叫 Greeter，定义如下所示。其中：通过 google.api.http 选项，来定义 http 相干的信息，能够主动把申请的数据解析到 Path 参数和 Query 参数上。还能够通过在对应的接口上申明 +publish 非凡的正文，来示意公布该接口到 OpenAPI 上，如果想要把某个接口强制标记为外部接口，那么也能够通过 +private 正文来实现。

// +publish prefix:"/api/greeter" backend-prefix:"/api" service:"user-center"
service GreeterService {
    // say hello
    // +publish
    rpc SayHello (HelloRequest) returns (HelloResponse)  {option (google.api.http) = {get: "/api/hello/{name}",
      };
    }
  }
  
  message HelloRequest {string name = 1;}
  
  message HelloResponse {string data = 1;}

​

Erda Infra 作为咱们应用的根底框架，当初还有一些不欠缺的中央，咱们后续打算持续增加服务注册发现的反对，来实现运行时的服务模块治理等，以此继续加强 Erda 的平台扩展性。
​

总结

咱们从 3 月开始打算 Erda 的开源，到当初曾经构建了第一个稳固的开源版本，第二个版本也将在近期公布。
​

Erda 自身提供的一站式服务开发治理和数据治理性能曾经十分丰盛，咱们接下来将会重点对用户体验和性能细节进行打磨，对开源代码重构以进步代码品质，简化平台的装置部署形式等。欢送大家关注 Erda 开源我的项目，一起探讨、交换云原生 PaaS 相干的技术，共建开源社区。
​

• Erda Github 地址：https://github.com/erda-project/erda
• Erda Cloud 官网：https://www.erda.cloud/