选择技术之后，接下来的课题就是服务的操作或生命周期管理和缩放。

     允许独立控制版本、部署及缩放的代码和状态

     无论选择何种方式来编写微服务，代码和（可选）状态都应该独立部署、升级和缩放。 这确实是难以解决的问题之一，因为这涉及到所选的技术。 在缩放方面，难以了解如何分区（或分片）代码和状态。 当代码和状态使用不同的技术时（目前的普遍情况），微服务的部署脚本必须能够妥善缩放两者。 这也关乎到灵活性和弹性，以便可以升级某些微服务，而无需一次性全部升级。

     暂时回到单一式方法和微服务方法的比较，下图显示了状态存储方法的差异。

     应用程序样式之间的状态存储

     左侧的单一式方法具有单一数据库和多层的特定技术。

     右侧的微服务方法显示互连的微服务图，其中状态通常以微服务为范围，并使用各种技术。

     在单一式方法中，应用程序通常使用单一数据库。 优点是这是单一位置，很容易部署。 每个组件可以通过单个表来存储其状态。 困难之处在于团队必须严格区分状态。 无可避免地就想将新的列添加到现有客户表、在表之间执行联接，并且对存储层形成依赖性。 发生这种情况后，无法缩放各个组件。

     在微服务方法中，每个服务都管理并存储自己的状态。 每个服务将负责同时缩放代码和状态，以满足服务的需求。 不足的是，需要创建应用程序数据的视图或查询时，必须跨不同的状态存储进行查询。 为了解决此问题，通常由一个独立的微服务构建一个跨许多微服务的视图。 如果需要对数据执行多个即席查询，每个微服务应该考虑将其数据写入数据仓库服务以供脱机分析。

     版本控制特定于部署的微服务版本，以便能够部署和并行运行多个不同的版本。 当较新版的微服务在升级期间失败，因而需要回滚到旧版时，版本控制可以解决这种情况。 版本控制的另一种情况是执行 A/B 式测试，其中不同的用户将体验到不同版本的服务。 例如，在更广泛推出新功能之前，通常先对一组特定的客户升级微服务以测试新功能。 在微服务的生命周期管理之后，便可以在微服务之间的通信。

      通过定义完善的接口和协议来与其他微服务交互

     本主题无需花费太多时间，因为过去 10 年来发布的大量关于面向服务的体系结构的文献对通信模式进行了介绍。 一般而言，服务通信使用 REST 方法，并配合 HTTP 与 TCP 协议及 XML 或 JSON 作为序列化格式。 从接口观点来看，这涉及到采用 Web 设计方法。 但仍可以使用二进制协议或自己的数据格式。 如果这些协议和格式非公开可用，微服务使用起来就很难，因此要有心理准备。

     具有用来解析位置的唯一名称 (URL)

     记得我们一直在说，微服务与 Web 有点类似吗？ 就像 Web 一样，微服务无论在何处运行，都必须可寻址。 若要在计算机上运行特定微服务，很快就会陷入困境。

     就像 DNS 解析特定计算机的特定 URL 一样，微服务需要有唯一的名称来发现它目前所在的位置。 微服务需要有可寻址的名称才能独立于它们运行所在的基础结构之外。 这意味着服务的部署和发现方式之间互相影响，因为需要有服务注册表。 同样地，当计算机发生故障时，注册服务必须指出服务现在的运行位置。

     接下来的主题：复原能力和一致性。

     在出现故障时可保持一致且可用

     处理意外的故障是最难解决的问题之一，特别是在分布式系统中。 开发人员编写的代码大多是在处理异常，这也是测试时花费最多时间的地方。 问题比编写代码来处理故障更复杂。 当运行微服务的计算机发生故障时，该怎么办？ 不仅需要检测这种微服务故障（本身就是棘手的问题），还需要设法重新启动微服务。

     微服务必须能够从故障复原，出于可用性理由，通常还必须能够在另一台计算机上重新启动。 这也涉及到代表微服务存储的状态、微服务可从何处恢复此状态，以及微服务是否能够成功重新启动它。 换句话说，需要能够复原计算（也就是重新启动进程）以及状态或数据（不丢失任何数据，数据保持一致）。

     在其他情况下，复原能力的问题更难处理，例如应用程序升级期间失败。 在配合部署系统一起运行时，微服务不仅需要恢复。 它还需要确定是要继续升级到更新版本，还是回滚到旧版以维持一致的状态。 需要考虑一些问题，例如，是否有足够的计算机可用于继续升级，以及如何恢复旧版的微服务。 需要微服务发出运行状况信息才能做出这些决定。

     报告运行状况和诊断

     微服务必须报告其运行状况和诊断，这一点看似明显，但却经常被忽视。 否则，难以从操作观点上深入了解。 面临的难题是关联一组独立服务的诊断事件并修正计算机时钟偏差以识别事件顺序。 同样地，通过议定的协议和数据格式来与微服务交互时，需要将运行状况和诊断事件的记录方式标准化，这些事件最终将写入可供查询和查看的事件存储。 在微服务方法中，关键在于不同团队同意采用单一记录格式。 需要有一致的方法来查看整个应用程序中的诊断事件。

     运行状况与诊断不同。 运行状况是指微服务报告其当前状态，以便采取适当的措施。 一个很好的例子便是使用升级和部署机制来保持可用性。 虽然当前服务可能由于进程崩溃或计算机重新启动而状况不正常，但服务可能仍可运行。 不应该执行升级而让情况恶化。 最好是先进行调查，或让微服务有时间恢复。 微服务中的运行状况事件可以帮助我们制定明智的决策，并且实际上也有助于创建自愈服务。

     Service Fabric 作为微服务平台