2.2　组织云基础设施

当管理在云原生部署的不同的资源时，首先需要询问组织内不同的团队关于如何组织云资源的问题。

• 是否采用“自己吃自己的狗粮”的模式，即团队负责自己的基础设施或采用集中式管理的方式？

• 云基础设施是在同一个账户上，还是分散在不同的账户上？

• 部分应用程序是否需要运行在专有的服务器组中？

• 不同的团队在管理基础设施时是否有不同的习惯和方法？

• 不同的实例或容器是否在相同的服务器组中？

• 云基础设施的资源命名是否规范？不同的资源命名是否代表它们的作用？

• 如何处理内部和外部流量的安全性及负载均衡问题？

只有这些问题得到解答之后，持续部署团队才能确定如何组织云基础设施。

2.2.1　以应用为中心

在几乎所有的公有云控制面板上，组织云资源的方式通常以资源类型而不是应用为中心。例如，云服务器的管理实例、服务器组、安全组及负载均衡都被组织到控制台完全独立的区域。如果你的云资源是跨地区甚至是跨账户的，那么你需要在不同的模块下额外进行数次操作，以便查看某个应用程序的云资源。

现实的情况是，无论是开发人员还是运维人员，他们关注的重点在于应用。例如，当某个应用出现问题时，他们需要先找到其使用的云资源是否有故障，再进行修复。当应用需要进行扩容时，同样也要先找到应用对应的云资源对象，再进行扩容操作。可见，这种组织方式是云提供商对于资源“SKU（商品化）”定义的结果，并不符合团队日常基于应用的管理粒度。

解决该问题的方式之一，是安排一个特殊的基础架构团队来管理整个团队的云资源和使用规范。这种安排是有意义的，但如果能够让每个应用团队自行部署和管理自己的基础设施，那么围绕他们开发的应用程序来组织云资源将变得更加高效。

这也是为什么在Spinnaker中，一切资源（包括云基础设施）都是围绕着应用进行管理的。应用组织如图2-1所示。

2.2.2　抽象对云的操作

一个值得考虑的问题是如何与云资源进行交互，好的交互方式可以让团队实现更快速的交付和循环反馈。通常可以使用云提供商提供的控制台来实现交互，但控制台涉及的产品线广且资源组织不够友好。为了给团队提供一致性和最佳实践方案，许多组织倾向于开发一套自定义的控制台。此类控制台通过接入云提供商的API并对云资源操作进行抽象，可以快速处理团队的开发需求，集成审核日志，并与其他上下游的工具进行集成，同时内置部署策略的最佳实践，对云的操作进行标准化。

在Netflix团队中，Spinnaker是作为一套云设施的自定义控制台来使用的，通过内置部署的最佳实践（如蓝绿部署、灰度发布、自动金丝雀发布等）为团队提供部署解决方案。此外，Spinnaker还支持快速查看和操作应用的基础设施，例如删除实例、快速回滚和禁用等。Spinnaker基础设施界面如图2-2所示。

图2-2是Spinnaker进入应用后的第一个界面，展示了应用的所有基础设施，这个界面很好地体现了对云的抽象。

① 代表应用名称。

② 代表一个集群，包含一个云账户（PROD）和服务器组，以及集群的健康状态（100%）。

③ 表示服务器组内包含一个实例，并且在US-WEST-2地域运行，运行的制品版本为V001，对应的Jenkins Build是#189版本。

④ 展示了这个实例的运行详情，例如状态、启动时间、服务器组、VPC等信息。

通过对云的抽象，结合工具为团队提供标准化的部署方案，能够显著提高团队的效率。

2.2.3　云模型

云模型是指围绕着云设施的命名约定及服务器组的组织架构。

每个应用通常由一个或多个服务器组构成，每个服务器组又由多个运行着相同版本号应用程序的实例组成，这是一种典型的云模型组合。

在命名规则上，良好的命名约定有助于用户识别设施的环境和版本。参考Netflix的约定，可命名为“名称-运行环境（可选）-详情（可选）-版本号”。

• 名称可以是应用名称或服务名称。

• 运行环境可能是开发环境（Dev）、预发布环境（Stag）、生产环境（Pord）等。

• 详情可以用来标注一组用于运行专用应用的服务器组，例如Redis缓存或MySQL集群。

• 版本号是有序的，每次经过持续集成产生的版本号将加1。

根据上述约定，一个典型的例子是website-prod-v1，含义是生产环境v1版本的website应用对应的服务器组，这样便能对应用涉及的资源一目了然。此外，对应用版本号的管理至关重要，因为当需要对应用进行扩容时，会以当前运行的版本号进行一致性的扩容操作，以便当发布的应用出现问题时根据版本号进行快速回滚。

2.2.4　多云配置

为了进一步提高可用性，避免云提供商锁定的问题，越来越多的企业倾向于使用混合云。常见的使用场景是针对不同的产品使用不同的云提供商，甚至在不同的运行环境中使用不同的云提供商。

即便是仅使用一个云提供商的状态，也应该考虑混合云的情况，因为从商业的角度考量，从一个云迁移至另一个云的情况也时有发生。

每个云提供商的产品概念和功能都有一定的差别，提供的云配置工具差异则较大。这就需要使用自定义的云基础设施控制台对多云管理进行统一化。通过集成云提供商的工具包（SDK），将对云的具体操作抽象为统一对云提供商API的访问请求，屏蔽不同云提供商之间的产品和功能差异。

Spinnaker面向多云的管理和配置正是通过以上原理屏蔽了底层与云提供商的交互细节，实现了单一平台管理多个云的一致性操作。