Serverless 进阶03 拓展能力

12 编排：如何协调多任务的运行？

工作流

工作流是通过 DSL 来定义一组结构和模型，它以 JSON 或 YAML 的形式存在，服务引擎会根据定义的蓝图来进行调度和执行任务

将工作流视为一组状态节点的集合以及这些状态节点的转换，每个状态节点都可以关联事件或功能，并且有明确的输入和输出

DSL 是什么

架构设计

func (flow *Flow) ProcessState(input *Input, flowDefinition *FlowDefinition) *Output {
 
    ...
 
    var output *Output
    state := flow.getStartState(flowDefinition)
 
    for {
        switch state.GetType() {
        case api.Event:
            output = flow.processEvent(state, input)
        case api.Operation:
            output = flow.processOperation(state, input)
        case api.Inject:
            output = flow.processSleep(state, input)
        case api.Switch:
            output = flow.processSwitch(state, input)
        case api.Parallel:
            output = flow.processParallel(state, input)
        case api.Foreach:
            output = flow.processForeach(state, input)
        default:
            flow.logger.Errorf("invaid state type: %v", state)
            ...
            break
        }
 
        if output.Error != nil {
            break
        }
 
        // 遍历到最后一个state退出
        state = state.NextState(flowDefinition)
        if state == nil {
            break
        }
 
        // 当前state的输出为下一state的输入
        input.Input = output.Output
    }
   
    return output
}

13 构建多维度视角下的Serverless监测体系

提供监控度量、日志以及链路三种数据，再根据用户开发与平台运维的实际需求，构造一个多维度的可观测体系

   其中的 Scheduler 就是扩缩容课程中提到的流量调度模块。在请求的返回路径上，它会将函数指标上报到 kafka，之后通过 Function Exporter 进行数据消费，并对不同节点产生的数据进行一次汇聚，完成之后，再交由 Prometheus 二次汇聚，最终再通过 TSDB 完成数据落盘。

图中 Prometheus 不光需要从 FunctionExporter 获取指标，还可能从每个节点的 Node-Exporter 获取资源信息指标，这就是我前面提到的“指标数据一旦增多就会加大汇聚服务的压力”的原因。

在集群规模不大时，这的确是一个比较轻便的解决方案，但在集群节点数量比较多的情况下，我更建议你针对业务指标和资源指标分别配置 Promethues。

14 构建多维度视角下的Serverless监测体系

在采集数据时，由于 Fluent-Bit 在 Kubernetes 集群等容器化环境中的运行比较出色，所以通常我们会使用轻量的 Fluent-Bit 对日志数据进行整体的上报，如果是集群的日志信息，则会以 DaemonSet 的形式部署。

因为 Logstash 过滤功能强大，但资源耗费多，所以并不能像 Fluent-Bit 那样以 DaemonSet 的形式部署在整个集群，只需部署少量虚机实例，并利用 Logstash 进行整体的数据清洗即可。

如果考虑到峰值问题，比如前面提到的某一时刻存在请求高峰导致日志量显著增大，也可以利用 kafka 缓冲一轮。最后，再由 Logstash 将过滤后的数据交由相应的存储服务。

日志的存储与检索

Elasticsearch 是一个分布式、高扩展、高实时的搜索与数据分析引擎，配合 Kibana 这种数据可视化工具，能快速搜索和分析我们上传的日志

15 不同阶段的数据应如何存储

其中，控制面由元数据和代码包两个维度组成；从请求的执行过程出发，数据面主要需要考虑元数据在获取时的缓存处理、 函数 Pod 资源的调度处理、服务之间的协同操作以及日志相关的收集等维度。其中，日志和服务的协同也可以认为是贯穿在整个系统始终的，比如服务协同包括服务的注册与发现、消息的通知与协调、选主等。

而对象存储是支持 HTTP 访问的，并不需要进行挂载操作，并且 KV 的特性也会让代码包路径具有很高的可读性，虽然在表格上也提到了对象存储是无法直接对对象内容进行修改的，但是对于函数代码包而言，通常都是读多写少，因此，对象存储非常适合用来保存用户的代码。

etcd

etcd 是一个采用 go 语言的开发的类似 zk 的分布式协调服务框架，是一个用于共享配置，服务发现的分布式，一致性 kv 存储系统，etcd 在实现上，一致性协议选择上，运维上，安全上比 zk 要优秀好多，etcd 提供 HTTP JSON, gRPC 接口，跨平台跨语言，这一点要比 zk 好很多，对多语言开发者来说是福音，etcd 也支持 http 所访问，安全性好。

云平台进行流程编排

17 在云函数场景下实现一个有状态的服务

有状态服务

不过，它存储的状态信息有限，如果涉及到上下游服务的依赖和持久化存储，例如高并发的日志消息、视频 / 图片审核等，仅依靠函数状态 context 是无法实现的，也就不太适用了。

FaaS 提供业务逻辑层的处理，BaaS 提供基础服务层的能力，让有状态的数据、过程消息等存储在 BaaS 化的服务中

先说 Serverless 数据库。业界内知名的 Serverless 数据库有阿里云的 PolarDB Serverless、腾讯云的 PostgreSQL for Serverless、亚马逊的 Amazon Aurora Serverless。Serverless 数据库会将计算能力和存储资源解耦，根据业务需求合理分配 CPU 和 Memory 资源。

对于内存数据库而言，需要大量的 Memory 资源，但 CPU 资源使用量很少；对于事务操作很多的数据库而言，资源需求恰好相反。Serverless 数据库可以大幅降低成本，适合多样化的业务场景。再说 Serverless 消息队列。它支撑着函数计算的异步执行，消息缓冲、消息解耦能力，业界内常用的有 Apache Pulsar 等。

广告物料数据的存储，我们选择云数据库。函数计算负责对读取的物料数据进行校验

这篇好文章是转载于：学新通技术网