https://hangyan.github.io/tags/%E5%BA%94%E7%94%A8/Recent content in 应用 on 涯余的博客Hugozhhang.yan@hotmail.com (涯余)hang.yan@hotmail.com (涯余)Thu, 22 Oct 2020 11:34:13 +0800https://hangyan.github.io/post/2020-10-22-oam/Thu, 22 Oct 2020 11:34:13 +0800hang.yan@hotmail.com (涯余)https://hangyan.github.io/post/2020-10-22-oam/<p>OAM 是指阿里开源的一个应用模型，主要是云原生场景。年初的时候出来到现在，断断续续地了解过一些，之前一直没有特别想清楚，其实现在也是，但多多少少有一点点感悟，在这里记录一下.</p> <h2 id="云原生应用的现状">云原生应用的现状</h2> <p>这里主要就是说围绕 kubernetes 生态的应用现状，基本上就是一团糟。没有标准，没有好的开源产品，没有社区来推动这个事情。先看看目前有啥:</p> <ul> <li>Helm: 适合作为rpm/apt类似的东西，不适合直接给 end user 用</li> <li>Application CRD: 社区不活跃，结构定义也不好</li> <li>Operator: 过于复杂，目前仅有的统一规范是 ocp 弄的 operator framework. 尚未推广开来</li> <li>其他林林总总的各种 ad-hoc 方案</li> </ul> <p>这就导致云厂商要么是完全自己做一套新的应用模型，要么是用上面这一类现成的，但功能受限，扩展不易。且用户需要有一定的前置知识才能用好。</p> <h2 id="oam-的主要优点">OAM 的主要优点</h2> <p>目前看来其最主要的优点是角色分离。Kubernetes YAML 的一个主要问题就是，它是一个大而全的 cofig 方案，不宜手写，只适合运维方向。如果想要做成用户友好的模型，OAM提供了一种可能性: 将大的 config 按角色分拆开，开发人员写一部分，运维人员写一部分，各自只关心各自的部分，最终再合并成一个整体的 config. 细节问题比如具体分成几个角色，谁来合并，可以再迭代改进。但这个分离的设计可以认为是走在一个正确的方向上。</p> <p>其他的几个重要的方面有：</p> <ol> <li>跨平台性。从设计上来讲，一开始设计成跨平台的思路当然是对的。但实际上可能还是90%以上的人主要是用在 k8s 上，所以 spec 设计时比较贴近于 k8s 的设计。其他平台的实现估计会花不少时间，这也是导致目前没有其他平台实现的主要原因</li> <li>插件系统。OAM 提供的 <code>traits</code> 能力，可以理解为对应用的一个插件系统。之前国内有厂商做过类似的东西，是一个非常好的尝试。以插件形式给应用附加能力，是一种非常自然和方便的用户体验，<code>traits</code>可以用来提供类似的能力。</li> </ol> <h2 id="用户体验">用户体验</h2> <p>即使做了职责分离，OAM 看起来仍然是非常难以直接 edit 的东西。这也是之前我一直比较纠结的一个点。因为它更像一个面向开发者的 spec, 而不是一个对 end user 的产品。我们如何让用户方便地使用这个功能呢，有下面几种可能:</p> <ol> <li>纯 UI 封装。这里需要 UI 设计的比较好，能够隐藏比较多的细节，不要暴露太多的底层名词给用户，不然用户就要去理解 OAM 是个什么东西了。而我们理想的形式就是让用户不去学习新概念。一个可能的点就是我上面说的，把 <code>traits</code> 叫做 <code>插件</code>等等。这里需要考虑的一个点是API怎么设计，因为一般UI/API都是必须的产品。如果直接把 OAM 用 API 暴露出来也不怎么友好，这就涉及到下面的第二点</li> <li>我们能否再设计一层 spec, 简单一点的，能提供便捷的API,UI也方便？ 这个诱惑力比较大，但其实又回到了远点，因为又回到了老的大的 config 上? 假设我们想做的更简单一些，那势必又无法全面覆盖 OAM 的能力。似乎唯一的可能性就是，我们换了一种 spec 格式，让用户更容易理解，但可以和 OAM 一一对应。</li> </ol> <p>因为之前有厂商放出了一些 OAM UI 的截图，比如:</p>