关于fc组件service字段问题讨论

[lowkeyrd]

现在关于service的误解很多，我们能否把service和function的抽出单独的组件出来？

services:
  fc-service: 
    component: devsapp/fc-service
    props:
      region: cn-hangzhou
      name: test-service
      internetAccess: true
      logConfig: auto
      nasConfig: auto
      role: ''
      
  fc-function-1:
    component: devsapp/fc-function
    props:
      region: ${vars.region}
      serviceName: ${service.fc-service.output.name} #指定当前工程的service
      handler: index.handler
      instanceConcurrency: 1
      instanceType: e1
      memorySize: 512
      runtime: nodejs12
      timeout: 60
      name: fc-function-1
      codeUri: .
      
  fc-function-2:
    component: devsapp/fc-function
    props:
      region: ${vars.region}
      serviceName: test
      handler: index.handler
      instanceConcurrency: 1
      instanceType: e1
      memorySize: 512
      runtime: nodejs12
      timeout: 60
      name: fc-function-2
      codeUri: .

这样的好处是：

1. service不会有歧义
2. 不用每次部署function时再check service

[lowkeyrd]

service独立出来是有很多好处的：

1. service的变更是比较小的，特别是在多人协同开发的时候，service的权限范围跟function是不太一样的。开发人员甚至都不应该具有变更service的权限
2. service独立出一个组件，可以把版本、别名的操作都以声明式进行描述，流水线可以单独操作service进行版本发布。service和function是完全不同的关注点，fc组件的version、alias命令跟function是完全无关的
3. service和function耦合，如何解决回滚的问题？如果我有多个函数关联相同的service，那应该操作哪个devs service进行回滚呢？
4. service和function耦合，这个设计本身已经受到很多挑战了，通过工具是可以把这个问题化解的，因为工具有组件间依赖编排的能力。

[rsonghuster]

同意， FC 的 Service 更像是 group或者 namespace 的概念， 归属在这个 group 的函数， 复用相同的日志配置， vpc 配置等环境信息

[heimanba]

原来的yaml配置需要兼容，这个可能会有些改造

[lowkeyrd]

原来的yaml配置需要兼容，这个可能会有些改造

一种方式是将这两个新组件基于fc组件进行封装，这样fc是需要做些兼容性的改动的；另一种方式是基于fc-deploy组件进行封装，这样fc组件是不动的。我倾向的是后者，影响更小，而且拆分模式和耦合模式都有一些实际场景：

1. 拆分模式：适合单service多函数的开发模式
2. 耦合模式：适合单service单函数的开发模式，目前阿里内部用的大部分就是这种方式

[DevDengChao]

适合单service单函数的开发模式，目前阿里内部用的大部分就是这种方式

本来我就觉得 Logstore 绑在 service 上也让 service-function 和 LogProject-Logstore 没法很好的一一对应.. 现在看来你们内部也遇到了这样的问题 🤣

[lowkeyrd]

适合单service单函数的开发模式，目前阿里内部用的大部分就是这种方式

本来我就觉得 Logstore 绑在 service 上也让 service-function 和 LogProject-Logstore 没法很好的一一对应.. 现在看来你们内部也遇到了这样的问题 🤣

是的，fc service的设计有其历史的背景，单service多函数的好处是统一管理，更贴近微服务架构，适合业务比较统一的场景；单service单函数更加灵活，更接近传统单体应用的开发模式