关于云原生:云原生-02ROS-资源编排用-Custom-Container-做-ServerlessFlow-云效流水线

系列专栏申明：比拟流水，次要是写一些踩坑的点，和实际中与文档差距较大的中央的思考。这个专栏的典型特色可能是 次佳实际，争取能在大量的最佳实际中生存。

本期基于阿里云，次要介绍用阿里云资源编排服务 ROS，Resource Orchestration Service 和 Custom Container 做 Serverless 的踩坑；不包含 Terraform，不包含 AWS 等其它厂商。
以 Spring Boot 类比，一个执行继续交付的企业，应该会抉择 1 Service + 1 Function = 1 原 Method 的计划；一个执行双周迭代的企业，应该会抉择 1 Service + 1 Function = 1 原 Controller 的计划
发新版的形式是点批改，而后把 Function 的 CustomContainerConfig 的 Image 的版本号 +1。

最近忽然发现原来 FC，Function Compute 是反对用自定义容器部署的，翻了一下这个性能是 2020-09 上线的，忽然就感觉去年一年白折腾了；包含 ECI，Elastic Container Instance，Midway / Egg-Layer 部署模式，都不须要了，Custom Container 就是我始终在找的那个解决方案。又认真翻了一下产品日志，云效是 2021-03 反对构建镜像并推送到公有仓库的，尝试甩锅是因为云效跟进得太慢导致我没有在内容农场中找到这个宝藏。

一、部署指标

最终的指标必定是 IaC，但在这个演进过程中得有取舍，哪些是不得不优先自动化的，哪些是能够临时用 ClickOps 来过渡的。如果一味的高举 IaC 的口号，那么最先自动化的肯定是那些 最容易 被自动化的，而不是 最应该 被自动化的。

二、利用 云效 Flow 拉取代码，并构建镜像公布到 镜像仓库 ACR

对于怎么开明 云效 以及 CodeUp 和 Flow 看官网文档吧。

Flow 对标的是 Jenkins / Pipeline / CICD，看文档旧版是有配置文件所以能够 IaC 的，新版没有找到这个性能。新版的 ClickOps 够用了，而且我的场景简直是一次性配置的，不会常常变更，所以够用了。

第一个坑点是，代码源是反对 GitHub 的，但理论并不反对。首先在墙外拉不动代码，比照镜像仓库 ACR 自带的构建性能就能够勾选用海内服务器构建，Flow 没有这个选项。其次就算连上了，速度也会很慢，而流水线是按耗时而不是次数免费的，所以代码源，包含三方库的源实际上都必须在阿里云下面。以及构建镜像时的 FROM，官网文档也倡议把根底镜像提前上传到本人的 ACR 公有仓库里，以进步拉取时的效率。跨生态是不存在的，vender lockin 了。

因而就天然引出了第二个坑点，云效的自建三方库只有 Maven 和 NPM，所以这个生态里只能用 Java 和 JavaScript。尽管实践上能够应用自建的 Nexus，但我上云效的目标不就是不想自建么。对于怎么本地开发怎么配置 .m2/settings.xml 能力应用云效提供的 Maven，以及上传一些公有包，参考须要登录云效能力看的文档，能搜到的惯例文档里是旧版的，还没更新。Flow 里的 settings.xml 都是配置好的，应用零碎举荐不要批改就能够了。

第三个须要留神的点是 工作目录 的概念。代码是能够有多个起源的，实践上能够将来自不同上游的代码别离拉取，而后混在一起，微信小程序的分包仿佛就是这个逻辑？从体验上说 monorepo 会更直觉一点，但对多源的反对兴许落地时 对企业外部凌乱的组织架构反对更好，更容易帮忙甲方转型一点。能够将源 A 的工作目录指定为 /path/to/app-a，源 B 的工作目录指定为 /oath/to/app-b，而后应用一些诸如 cd app-b 的命令来操作。

以上，尽管云效是 ClickOps 但刻意没有附云效的截图和代码片段，一是因为没有 IaC 不想贴脚本，等找到了再来更新这个局部；二是交互做得意外的不错吧，按提醒到处点点上手很快的。

三、部署在 函数计算 FC 里的最终架构应该是什么样子

以 Spring Boot 类比，直觉的想法是，Service 对应原微服务的 Application，Function 对应的是 Controller 的一个 Method，实际下来并不是这样。

首先 FC 的很多重要配置都是在 Service 这个粒度的，比方 VpcConfig，LogConfig，TraceConfig，NasConfig，所以 Service 这个粒度是最重要的须要认真思考架构的中央，能够假想对应为一个拆得比拟洁净的微服务中台 原子 Application。然而事实中的微服务大多拆得不洁净，如果是做现存利用的无痛迁徙的话，实际上 Application 会对应多个 Service。其次，Method 的粒度又太细了，不好治理，所以实际上 Function 对应的是 Controller。EnvironmentVariables 是配置在 Function 上的，所以如果有一些参数不便共享，也能够应用 Function 来隔离。

接下来直觉的想法必定是，一个 Service 对应多个 Function，实际下来这样还是不行的，因为现存利用的迁徙并没有那么无痛，甚至是很痛，业务方期待的其实还真的是 Method 粒度的渐进式迁徙，通过网关，顺次将每个接口流量打到新的架构下来察看。所以一个执行继续交付的企业，应该会抉择 1 Service + 1 Function = 1 原 Method 的形式做迁徙；一个执行双周迭代的企业，应该会抉择 1 Service + 1 Function = 1 原 Controller 的形式做迁徙。至于迁徙全副实现后怎么去做合并，那是另一个故事了。

最初，因为我的我的项目中只存在 Http 类的接口需要，所以只须要 Http 类型的 Trigger。这里有一个限度，其它类型的 Trigger 能够在 Function 启动之后增删，但 Http 类型的 Trigger 必须在创立 Function 时一并创立，所以我最终的选型是 1 Service + 1 Function + 1 Http Trigger = 1 原 Controller。

四、ROS 的最小可用够用集

先吐一个坑点，说是反对 JSON 和 YAML，但文档和示例只有 JSON，而且交互的局部显著只反对了 JSON，比方某个参数是 Map 类型的，即便在 YAML 版里也要传 JSON 进去。总之认为理论只反对 JSON 就对了。

ROS 模板文档。首先设想一下，最终利用是对着一个 YAML 启动的，这个 YAML 就是该利用的 Declarative IaC，通过编排零碎的 Reconcile 能力，保障利用的状态和 YAML 的冀望是统一的。而后，对于一组架构统一或相似的利用 YAML，把其中的要害参数扣掉改成占位符，等着用户去输出，这就是模板。ROS 把利用的 YAML 叫做 资源栈 Resource Stack，把模板叫做 Template。Template 是有专门的交互去治理的，真的是 YAML 格局，既能够在线编辑，也能够上传下载，也就意味着你能够 GitOps。Resource Stack 没有这个能力，你不能从一个手工写好的填好参数的 YAML 间接启动，必须要先形象出模板，第一步应用模板，第二步在交互中填入参数。这些参数，比方 VpcId，ROS 是不会帮你治理的，所以我猜实际上企业还是须要自建 CMDB？

{
    "ROSTemplateFormatVersion" : "2015-09-01", // 十分神奇，原来这么早就开始搞了
    "Description" : "","Resources": {"ServiceA": {"Type":"ALIYUN::FC::Service","Properties": {"ServiceName": { // 这里的命名要按接口文档来"Ref":"ServiceName" // 这里 ref 的是 Parameter 外面定义的「占位符」处由用户输出的值，这里的命名本人定，比方不同的 Type 有同名的，就能够自定义命名成 ServiceNameForServiceA},
                ...
            }
        },
        "FunctionA": {"Type": "ALIYUN::FC::Function", "DependsOn": "Service", "Properties": {} },
        "TriggerA": {"Type": "ALIYUN::FC::Trigger", "DependsOn": "Function", "Properties": {} },
    },
    "Parameters" : {}, // 参数，每种资源都有本人独立的文档详解须要哪些参数
    "Metadata" : {}, // 例如寄存用于可视化的布局信息
    "Outputs" : {}// 用于输入一些资源属性等有用信息。能够通过 API 或控制台获取输入的内容}

对于 Resource，这里是 Declarative 的局部，就是你对最终心愿启动的资源达到的状态的形容。ServiceA 是 变量命名 ，不须要带有 Service 字样，"Type": "ALIYUN::FC::Service" 才是指定资源类型。如果须要一组启动多个 Service，那命名就应该形如 ServiceA，ServiceB；Function，Trigger 及其它也一样。这个 变量命名 是用来在配置文件内 编程 的，好奇怪的说法，我也没钻研过 Terraform，不晓得这个了解是否正确。比方在 Output 里，因为 Service 是零碎拉起来的，所以 ServiceId 是实时生成的，那么如果前面须要应用到这个值，就能够用 "Fn::GetAttr": ["ServiceA", "ServiceId"] 来获取这个值。

Type 指定了资源类型，每种 Type 都有专门的文档形容该类型有哪些参数必填或选填，从这外面挑你须要的参数放到 Properties 外面，在从模板启动的时候会要求用户提供这些参数，作为输出来启动资源。

"Parameters": {
    "TriggerName": {
      "Type": "String",
      "Default": "http-index"
    },
    ...
}

Parameters 是用来做低代码主动生成交互的，Type: String 会被渲染成 <input type="text" />，Type: Boolean 会被渲染成 <input type="radio" /> 等等。另外有一个 AssociationProperty 的概念，看上去能够渲染成对接阿里云资源接口的 <select /> 不便手选，而不是复制粘贴，等有空钻研一下。再次，不晓得 Terraform 怎么解决低代码的，等有空钻研一下。

MetaData 是用来对 Parameters 做 <fieldset /> 的，具体翻文档吧。

Outputs 是用来输入参数的，相当于 return 或者 export，即向上游申明这些变量是能够用的，目前我没有用到上下游的概念，都是一批次启动的，所以没有钻研。

对于 Mappings，Conditions 本人翻文档吧。

另外资源栈还有一个 嵌套 的概念，这个命名也有点奇怪，看上去是复用的意思，然而我没有设想进去理论的场景，所以没有钻研。

五、通过 ROS 定义 Resource Stack 并启动详解

为了排版方面，以下就大部分写 YAML 了，请记得下面提到过理论只反对 JSON；顺便也让你们感触下 YAML 和 JSON 混写的苦楚。

Service 的配置如下，大部分都是字面意思，细节翻下文档：

Resources:
  Service:
    Type: 'ALIYUN::FC::Service'
    Properties:
      ServiceName:
        Ref: ServiceName
      Description:
        Ref: ServiceDescription
      Role:
        Ref: Role
      VpcConfig:
        Ref: VpcConfig
      LogConfig:
        Ref: LogConfig
      InternetAccess:
        Ref: InternetAccess
Parameters:
  ServiceName:
    Type: String
  ServiceDescription:
    Type: String
  Role:
    Type: String
  VpcConfig:
    Type: Json
  LogConfig:
    Type: Json
  InternetAccess:
    Type: Boolean
    AllowedValues:
      - 'true'
      - 'false'
    Default: 'true'
MetaData:
  'ALIYUN::ROS::Interface':
    ParameterGroups:
      - Parameters:
          - ServiceName
          - ServiceDescription
          - Role
          - VpcConfig
          - LogConfig
          - InternetAccess
        Label:
          default: Service

其中以 VpcConfig 为例看一下，残缺的定义应该是（伪代码）：

Parameters:
  VpcConfig:
    SecurityGroupId:
      Type: String
    VSwitchIds:
      Type: List<String>
    VpcId:
      Type: String

但 ROS 的语法只反对一层，所以理论的成果看上去形如，心态崩了：

Parameters:
    VpcConfig:
      "{\"SecurityGroupId\": \"\", \"VSwitchIds\": [\"\"], \"VpcId\": \"\"}"

这是目前对 ROS 的第二大坑点（第一是 Resource Stack 不能 IaC），等我把 DSL 那本书看完回来，看能不能自己答复这个问题。

Function 的配置如下：

Resources:
  Function:
    Type: 'ALIYUN::FC::Function'
    DependsOn: Service # 有启动的先后顺序的
    Properties:
      ServiceName:
        Ref: ServiceName
        # 这里是有点取巧的，因为我用的是 1 Service + 1 Function 的设计，所以这里间接用名字去找就好了
        # 更严格的做法我猜应该是 Fn::GetAttr [Service, ServiceName]
      FunctionName:
        Ref: FunctionName
      MemorySize:
        Ref: MemorySize
      EnvironmentVariables:
        Ref: EnvironmentVariables
      CustomContainerConfig:
        Ref: CustomContainerConfig
      Timeout:
        Ref: Timeout
      CAPort:
        Ref: CAPort
      Runtime:
        Ref: Runtime
      Handler:
        Ref: Handler
Parameters:
  FunctionName:
    Type: String
  MemorySize:
    Type: Number
    MinValue: 256
    MaxValue: 3072
    Default: 256
  EnvironmentVariables:
    Type: Json
    # 敏感参数在这里，比方数据库链接
    # Serverless 不是常驻的，每次启动还要去连 Vault 不适合，须要钻研
  CustomContainerConfig:
    Type: Json
    # {"Image" : "填你的公有 ACR"}
  Timeout:
    Type: Number
    MinValue: 1
    MaxValue: 600
    Default: 10
  CAPort:
    Type: Number
    Default: 8080
  Runtime:
    Type: String
    Default: custom-container
    # 本文要害，指定自定义容器模式，默认的应该是代码模式
  Handler:
    Type: String
    Default: index.handler
    # 仿佛不重要，这个是给默认代码模式用的，然而是必填项，那就按明码模式写了
Metadata:
  'ALIYUN::ROS::Interface':
    ParameterGroups:
      - Parameters:
          - FunctionName
          - MemorySize
          - EnvironmentVariables
          - CustomContainerConfig
          - Timeout
          - CAPort
          - Handler
          - Runtime
        Label:
          default: Function

Trigger 的配置如下：

Resources:
  Trigger:
    Type: 'ALIYUN::FC::Trigger'
    DependsOn: Function
    Properties:
      ServiceName:
        Ref: ServiceName
      FunctionName:
        Ref: FunctionName
      TriggerType:
        Ref: TriggerType
      TriggerName:
        Ref: TriggerName
      TriggerConfig:
        Ref: TriggerConfig
Parameters:
  TriggerType:
    Type: String
    Default: http # 本文要害
  TriggerName:
    Type: String
    Default: http-index
  TriggerConfig:
    Type: Json
    # {"AuthType": "anonymous", "Methods": ["GET", "POST", "PUT", "DELETE", "HEAD", "PATCH"]}
MetaData:
  'ALIYUN::ROS::Interface':
    ParameterGroups:
      - Parameters:
          - TriggerName
          - TriggerType
          - TriggerConfig
        Label:
          default: Trigger

以上，拆成 3 段是为了表述不便，理论是拼成一个 YAML 的 Template，新建 Resource Stack 的时候选中或上传这个 Template，而后在低代码生成的交互中输出对应的参数，一路点下一步就启动了。

于是第三个坑点就是，只有第一次启动的时候的 YAML（包含 Template 和输出）是对的，能力失常启动，而后如果有变动能力点批改。如果第一次失败了，那么只能删除重建。十分奇怪的设计，几乎能够设想产品跪在开发背后说你们棘手把这个性能修复了好么，开发答复又不是不能用.jpg。

对应的，发新版的形式是点批改，而后把 Function 的 CustomContainerConfig 的 Image 的版本号 +1。

六、其它没有提到的零散的坑点

funcraft 没啥用，而且官网应该曾经弃坑了。serverless-dev 仿佛也没啥用，太全家桶了，看上去没有运维该有的简洁感。cdk 可能有用，看上去有 IDE 插件，待钻研。

七、对于 Custom Container 做 Serverless 再多说几句

Container 的劣势是可移植，旧代码和架构选型都不须要大改，也不必放心某个个性厂商是否反对，根本能够间接怼下来。FaaS 号称的劣势是冷启动会快一点，但既然都筹备上 Serverless 了，必定是衡量过的，应该会抉择一些放弃基线的形式去兜底，比方能够搭着预留实例一起用，而不是在冷启动上花大力量。

FaaS 的生态还是不够成熟，有太多新常识要学，动不动就推倒重来。Container 天生就是来解决开发和运维的分工问题的，这里只须要运维 格局关上，不须要配合也能怼下来的。当然不须要配合也只是个比喻，开发还是须要学习一些简略易落地的准则，如《王四条》，但因为学习曲线如此平坦就像不须要学习一样。

大量的手工重复劳动基本不是问题，学习曲线太平缓才是，程序员最爱的事件就是复制粘贴了。判断好的架构的指标应该是看能不能反对专业分工，反对线性招聘，反对复制粘贴。云原生的实质是 IaC，人类花了这么久的学术实践钻研，终于学会了用 Code 形容解决方案，怎么又想着改回 可视化 了。

阿里云函数计算公布新性能，反对容器镜像，减速利用 Serverless 过程
什么是阿里云云开发平台
开发函数计算的正确姿态——轻松解决大依赖部署，“谬误”示范
阿里云田涛涛：高效智能的云，CloudOps 让运维更简略
云原生基础设施，云原生软件架构，云原生利用交付与运维，和本文间接关系不大，但作为综述写得很棒，值得一看

关于云原生:云原生-02ROS-资源编排用-Custom-Container-做-ServerlessFlow-云效流水线

TL;DR

参考文献