原文作者：行云创新产品总监 陈晓露

了解CloudOS或Methodot的童鞋可能都知道，平台中有个概念——架构图。

点击，了解CloudOS详情>>

· 平台中的架构图究竟是什么？

· 平台中的架构图跟应用开发中的架构图是什么关系？

这篇文章，我给大家解释一下。

架构图的由来

你可能听说过3D打印，也可能了解3D打印。举个例子，为了生产一辆汽车，先为汽车建个模，大小、样式、各个组成部分的材料等等，描述完整。然后把“模型”和“原材料”给到一个3D打印机，打印机就能打印出一辆汽车。

这样的话，汽车生产的关键就是建立模型了。

那么，软件应用的生产能否也采取类似于3D打印的方式呢？你可能猜到了，跟上面的例子类比，CloudOS平台的架构图就相当于汽车模型。（PS：先介绍一下，Methodot是CloudOS的SaaS版。）

平台中真实的架构图，一个电商应用的架构图：

说起来，我们的架构图一开始叫蓝图，后来我们的客户反馈，蓝图这个名字太大了，不太贴切，我们经过讨论后就改为架构图了。有意思的是，改了之后，有其他客户反馈，还是叫蓝图比较好。

平台中的架构图与开发人员理解的架构图有什么关系？

很显然，CloudOS平台的架构图可以一键“打印”成应用，并且图上的元素都能产生实际的作用，而开发人员画的架构图仅仅是一张图。

平台中的架构图与k8s yaml有什么关系 ？

不懂K8s的童鞋可以跳过本段。懂K8s的童鞋可能会说，这个架构图，不就是k8s yaml的图形化展示吗？并不尽然，CloudOS平台的架构图是k8s yaml的超集：

1. 架构图有组件与组件之间的关系：带箭头的连线。这个连线不仅是视觉上的一个标记，它有实际的意义：

· 连线在架构图中会影响部署过程中的组件部署顺序。

· 平台可以基于连线做组件之间的访问控制，比如：有连线才能访问。

· 平台支持API调用控制，比如：允许A组件调用B组件10个API中的2个API。

2. 架构图的组件比yaml中的一个部署单元有着更丰富的信息：

· 代码组件，包括代码库信息、技术栈信息等。

· API信息。

· 组件负责人信息。

· 组件描述信息。

3. 架构图有group的概念，比如有3个组件同属于1个业务域，这3个组件可以建一个gruop。

4. 架构图的组件有位置信息，体现了一个应用的技术架构中的组件层级。

可以这么理解，CloudOS平台的架构图部署成应用时，会先转化成K8s yaml，然后部署到K8s中。

平台中的架构图有什么作用？

先来说说比较具体的作用，主要有如下几点：

· 平台中的应用都由架构图部署而成，那么应用的实际架构与架构图是对应的，不会存在黑盒子。在很多公司的项目中，人员的更迭会导致应用的实际架构无人知晓，迭代开发时战战兢兢，生怕带来不可预知的后果，使用我们平台后，这个问题将会被彻底解决。

· 应用架构可视化，可视化的价值是很大的，无论是用来汇报、评审、学习都非常重要，是企业的重要资产。传统的架构图靠手绘，一段时间后，手绘的架构图与实际的技术架构会出现很大偏差。

· 架构变更可回溯。架构图的每一次修改都会归档为历史记录，我们可以回溯每一次变更。

· 架构图可以一键部署成应用。这个能力对微服务的应用太有帮助了，一般一个应用会有好几套环境：生产环境、测试环境、开发环境、预发布环境、有的还有特性分支开发环境。比如，有个应用有30个微服务，传统方式下，每部署一套新的环境出来都是巨大的工作量和资源消耗。但基于一键部署的能力，这个事情变得非常简单。

· 封装K8s。K8s的学习成本很高，而架构图上的配置封装了K8s，开发人员不需要懂K8s，就可以轻易将应用部署到K8s上，充分利用K8s的能力。

· Design once and run anywhere。一处开发，交付到任何云。架构图设计一次，将整个应用完整描述，部署的时候，直接部署到任何云，比如阿里云、腾讯云、自己公司的私有云。

其实，一言以蔽之，架构图的作用体现的就是云原生的本质——以应用为中心。什么叫以应用为中心？就是完整的描述应用，然后一键部署成应用，可以交付到任何地方。底层资源只是应用的附属，底层资源的生命周期跟应用完全绑定，创建应用时自动创建资源，应用负载高时自动扩资源，应用销毁时自动回收资源，开发人员完全不用关注底层资源。而在我们平台上，应用的完整描述就是可视化的架构图。

再来畅想一下，有了这张架构图，是不是能发挥更多的作用？应用开发过程的所有协作活动是不是可以基于这张图？应用开发过程的所有活动的入口是不是也可以基于这张图？比如执行测试、比如代码评审。

平台的架构图是什么？

最后，咱们来给平台的架构图做个定义：以应用为中心，完整描述应用技术架构，能够直接部署成应用并交付到任何地方的一张图。

点击，了解CloudOS详情>>