1.2 解耦

为了充分理解运维一个云所面临的挑战，我们必须从理解底层构建块开始：运行在商用硬件上的基于软件的微服务集合。这种构建块的出现，源自对以前那种专用软硬件捆绑方式进行解耦。从管理的角度来看，当我们进行这种转换时，需要确定什么事情会变得更加容易，以及什么事情会变得更加困难。这既是解耦带来的挑战，也是机遇。

从广义上讲，解耦是将捆绑在一起的大组件分解成一组更小的组件的过程。SDN就是一个很好的例子，它将网络的控制平面和数据平面解耦，前者以云服务方式运行，后者则运行在商品交换机中。微服务架构是解耦的另一个例子，它将单体应用分解为一组单一功能组件的网格。解耦是加快特性开发速度的关键举措，Weaveworks[5]很好地总结了这一点。

而这种转变的挑战在于，我们需要整合、协调和管理更多变化的部件。回到之前的术语，编排和生命周期管理成了主要挑战，因为：1）许多更小的部分必须通过编排器组装起来；2）这些独立的部分预计会被更频繁地变更。本书大部分内容都集中在这两个问题上。

好消息是，业界事实上已经将容器作为“组件打包”的通用格式，并将Kubernetes作为一级容器编排器（我们之所以说“一级”，是因为只有Kubernetes本身是不够的）。以此为基础，可以使得许多其他挑战更易于被我们管理：

● 监控和其他与遥测相关的系统将被实现为一组基于容器的微服务，并部署到它们所观测的云中。

● ISSU变得更容易处理，因为微服务架构鼓励使用无状态的组件，同时将持久化状态隔离在与业务功能无关的存储服务中，比如键值对存储。

● 云所用的硬件都是同构的商用硬件，因此零接触配置更容易落地。这也意味着绝大多数配置都只涉及初始化软件参数，因此更容易实现自动化。

● 云原生意味着一组用于解决许多FCAPS需求的最佳实践，尤其是与可用性和性能相关的需求，这两者都是通过水平扩展实现的。安全通信通常也内置在云RPC机制中。

另一种说法是，通过将捆绑的软硬件重构为运行在商用硬件上的水平可伸缩的微服务，过去一组一次性的运维问题，现在由分布系统中被广泛应用的最佳实践解决了。而这些最佳实践反过来又被固化到了先进的云管理框架（如Kubernetes）中。这就给我们留下了以下问题：1）提供商品化硬件；2）编排容器化构建块；3）部署微服务架构的监控系统以统一的方式收集和归档监控数据；4）随着时间的推移不断集成和部署独立微服务。

最后，由于云是无限可编程的，因此被管理的系统有可能随着时间的推移而发生巨大变化[6]，这意味着云管理系统本身必须是易于扩展的，以支持新特性（以及重构现有特性）。这可以通过将云管理系统以云服务方式实现来解决，这意味着读者将在本书中看到很多递归依赖关系。此外，我们还要利用好编排的声明性规范，这些规范用于说明被分解的组件如何组合在一起运行。然后我们可以使用这些规范来编排管理系统的组件，而不是手动重新编码（标准也不统一）。这是一个有趣的问题，我们将在后面的章节中讨论，但最终我们希望能够自动配置（负责自动配置系统其余部分的）子系统。