重构到微服务，第 3 部分 微服务采用路线图

原文地址：https://www.ibm.com/developerworks/cn/cloud/library/cl-refactor-microservices-bluemix-trs-3/index.html

一步一步地将您的应用程序从一个整体服务迁移到一组微服务

在本系列的 第 1 部分 中，我介绍了为获得一个基于微服务的方法而重构您的代码的一些关键原因和建议。

现在，在本系列的结尾部分，我会将该建议绘制成一幅将您的应用程序从一个整体服务转换成一组微服务的路线图，该路线图包含 4 个阶段。

“在我帮助客户采用微服务时，很少看到客户一次性直接采用一个完全由微服务组成的战略。相反，大多数客户都采用循序渐进的方法，成功地迁移到了微服务。”

1

宏服务

宏服务是您旅程的第一步。宏服务是大多数客户查看他们现有的 “SOA 服务” 时可以看到的服务。可以实现 Web 服务来使用 RESTful 协议，这就像在 SOAP 中发现服务实现一样也很常见。

您的起始点是采用一个用于实现服务访问的常见协议：REST。（使用了消息传递系统的异步服务是一种特例，为了保持本文简单，我不打算在此处介绍它）。因此，一旦您同意在 REST 上实现规范化，如果您现有的 Web 服务支持 REST，那么您已经迈出了这一步 — 非常不错！

但是，如果您有一个根本没有任何 Web 服务的完整的整体，那么就从这里开始，看看您是否能够将您的业务逻辑与 RESTful Web 服务分离。

或者您有一些 Web 服务，但它们都基于 SOAP，您需要将基于功能的 SOAP 接口重构为基于实体的 REST 接口。

Bluemix 上的 API 管理

管理并实施一些策略，以便使用您的商业服务。一个用于共享 API 的自助服务门户支持 API 版本控制、生命周期管理和使用情况分析。
概述 | 使用指南

一旦重构到 REST，您可能想确保自己能够记录和编目 REST 服务。此处描述了一些格式，比如 Swagger，它们可能很有帮助，特别是在与 Bluemix® 中的一些工具（比如 API Management）联合使用时，API Management 可在 Swagger 文档中使用，生成个别的 Bluemix 服务磁贴，用于绑定和调用那些 RESTful 服务。

2

迷你服务

在同意使用 REST 并记录您的接口后，下一步就是开始分裂这些服务。请确保您已尽最大努力按照功能来分解服务，并为每项服务实现了一个容器。请记住，按照本系列 第 1 部分 中的分解准则进行操作。

可能需要花费一段时间才能完成服务分解。该微服务架构需要一定水平的操作准则，许多团队都不准备采用操作准则。如果采用了 “每项服务一个容器” 策略，您可能需要采用一些支持技术，比如 Bluemix 中的 Cloud Foundry 或 Docker。许多团队可能想暂缓迈出这一步。

Bluemix 上的监视和分析

获取应用程序的性能和健康情况的及时洞察。代码行诊断和嵌入式分析可帮您消除和快速解决各种问题。
概述 | 使用指南

同样，“每项服务一个容器” 的策略可能要求您从传统的中间件（比如 WebSphere® ND）迁移到 WebSphere Liberty。花费一些时间，确保设置了正确的基础架构来执行监测和记录，以便能够支持此方法。在 Bluemix 中，您可以使用 Monitoring and Analytics 服务 或第三方服务，比如 New Relic。在任何情况下，您可能都想采用一个标准化方法来跟踪使用和执行服务的方式。

3

微服务

Bluemix 上的交付管道

自动化您的应用程序构建、测试和部署。
概述 | 使用指南

除非您不仅了解部署服务的方式，而且还了解构建它们的方式，否则无法实现一个完整的微服务架构。在这一步中，您要为每项服务实现一个完全独立的持续集成/持续交付 (CI/CD) 管道。IBM Devops Services Delivery Pipeline 等工具可以帮您实现此目标。

Bluemix 上的 IBM Containers 和 Auto-Scaling

对于需要可伸缩性和可靠性的应用程序，可使用 IBM Containers 创建一个容器组，或使用 Auto-Scaling 实现动态缩放。
IBM Containers | Auto-Scaling

在前进到旅程的这一点时，您可以开始考虑独立缩放您的微服务。Bluemix Container 服务中的 Container Groups 或针对 Bluemix 服务的 Auto-Scaling 等特性会给您提供帮助。借助 Auto-Scaling，可以根据您定义的缩放策略来动态调整应用程序实例的数量。

4

大规模的微服务

最后一步是移动到一个完全向外扩展的微服务方法。许多团队永远无需走这一步！根据我的经验，多数项目最终只有几个（通常少于10 个）微服务。

Bluemix 上的 Service Discovery

微服务可动态注册并找到彼此。
概述 | 使用指南

在此步骤中，必须考虑服务发现的问题：如何发现服务，以及如何设置路由规则？Bluemix 中的 Service Discovery 可为您提供帮助。Service Discovery 可以通过逻辑名称而不是硬编码网络地址来定位微服务，它还可以自动删除不健康的微服务。

Bluemix 上的 Active Deploy

发布新软件并更新正在运行的应用程序或容器组，而无需停机。 快速恢复到原始版本。
概述 | 使用指南

您还需要考虑一些更高级的配置和部署选项，比如那些受 Bluemix 上的 Active Deploy 支持的选项。

最后，您可能要考虑在下游服务失败时会发生什么。在这种情况下，类似 Netflix Hystrix 之类的库可以在 Bluemix 上的 IBM Container 中运行。

结束语

现在，您已经查看了一个路线图，您的应用程序现在将依照该路线图完成微服务的最终 “涅槃”，您可以开始您的旅程了！此外，您可以了解每一步的构建方式，老实说，如果您需要的话，停止实现最终目标也没什么关系。

只是您一定要记住我在 前面文章 中的的警告 — 不要只是为了玩酷而采用微服务。请确保您正在解决哪个微服务架构非常适合您的问题，而且采用微服务只是增加应用程序业务价值的总进程的一部分。

相关主题

• “重构到微服务” 系列的所有部分
• 微服务实战，第 1 部分：微服务介绍
• 微服务实战，第 2 部分：容器和微服务 — 完美的一对
• 在 developerWorks 上的微服务电视节目
• 微服务理论到实践：在 IBM Bluemix 中使用微服务方法创建应用程序（IBM Redbooks®）