Google App Engine 上的微服务架构

微服务是指用于开发应用的架构样式。通过微服务，可将大型应用分解成多个独立的组件，其中每个组件都有各自的责任领域。在处理一个用户请求或 API 请求时，基于微服务的应用可能会调用许多内部微服务来共同生成其响应。

如果能以正确的方式实现基于微服务的应用，则可以实现以下目标：

• 定义各项微服务之间的强契约。
• 允许相互独立的部署周期，包括回滚。
• 方便在子系统上执行并发 A/B 版本测试。
• 最大限度地减少测试自动化开销和质量保证开销。
• 提高日志记录和监控的清晰度。
• 提供精细的成本核算。
• 提高应用的整体可扩缩性和可靠性。

Google App Engine 具备多种非常适合基于微服务的应用的功能。本页面介绍了在 Google App Engine 上将应用部署为基于微服务的应用时可以采用的最佳做法。

将 App Engine 服务用作微服务

在 App Engine 项目中，您可以将多项微服务分别部署为独立的服务（以前在 App Engine 中称为“模块”）。这些服务的代码彼此之间完全隔离；如需执行这些服务中的代码，唯一的方式是通过 HTTP 调用，例如用户请求或 RESTful API 调用。一项服务中的代码不能直接调用另一项服务中的代码。您可以将代码单独部署到各项服务，并且可以使用 Python、Java、Go 和 PHP 等不同的语言编写不同的服务。对于这些服务，自动扩缩、负载均衡和机器实例类型均可单独管理。

服务中的版本

每项服务还可以同时部署多个版本。对于每项服务，其中一个版本是默认服务版本，但您可以直接访问服务的任何已部署版本，因为每项服务的每个版本都有自己的地址。这种结构开创了无数种可能性，包括对新版本执行冒烟测试、在不同版本之间执行 A/B 测试以及简化了前滚和回滚操作。App Engine 框架提供多种机制以帮助执行其中大多数操作，我们将在后面的部分详细介绍这些机制。

服务隔离

虽然大部分服务都是相互隔离的，但这些服务会共享一些 App Engine 资源。例如，Cloud Datastore、Memcache 和任务队列都是 App Engine 项目中各服务之间的共享资源。虽然这种共享具有一定优势，但对基于微服务的应用来说，保持微服务之间的代码隔离性和数据隔离性非常重要。有一些架构模式可以帮助减少不必要的共享，我们将在本文后面的部分介绍这些模式。

项目隔离

如果您不想依赖这些模式来实现隔离，而是希望更正式地实施分离，则可以使用多个 App Engine 项目。使用多个项目（而非多项服务）有利有弊，您需要根据自己的情况进行权衡。除非您对因使用多个项目而带来的某项优势有特定需求，否则最好先在单个项目中使用多项服务，因为这样性能会更好，管理开销也将减至最低。当然，您也可以选择混用这两种方法。

服务隔离与项目隔离的对比

下表展示了在微服务架构中使用多项服务与使用多个项目之间的对比：

	多项服务	多个项目
代码隔离	在服务和版本之间，部署的代码完全独立。	在项目之间以及每个项目的服务和版本之间，部署的代码完全独立。
数据隔离	Cloud Datastore 和 Memcache 可在各服务和版本之间共享，但命名空间可用作一种开发者模式来隔离数据。对于任务队列隔离，可以使用开发者队列名称约定，例如 user-service-queue-1。	在各项目之间，Cloud Datastore、Memcache 和任务队列完全独立。
日志隔离	每项服务（和每个版本）都具有独立的日志，可统一查看所有这些日志。	每个项目（以及每个项目的服务和版本）都具有独立的日志，但同一项目的所有日志可同时查看。无法统一查看多个项目的日志。
性能开销	同一项目的服务部署在同一个数据中心内，因此使用 HTTP 从一项服务调用另一项服务的延迟时间非常短。	项目可能部署在不同的数据中心内，因此 HTTP 延迟时间可能会更长，但由于 Google 拥有世界一流的网络，因此延迟时间仍然相当短。
成本核算	各服务的实例小时费用（用于运行代码的 CPU 和内存）未分开核算；整个项目的所有实例小时都集中在一起。	不同项目的费用是分开核算的，因此不同微服务的费用一目了然。
操作员权限	操作员可以部署代码、前滚和回滚版本，并查看项目的所有服务的日志。无法限制对特定服务的访问权限。	可在不同项目中单独控制操作员的访问权限。
请求跟踪	借助 Google Cloud Trace，您可以通过一个组合跟踪记录，集中查看某个请求及其引发的对同一项目中多项服务发出的微服务请求。此功能可帮助您轻松优化性能。	如果多个 GCP 项目属于同一组织，您可以跨这些项目直观呈现 Cloud Trace 调用。

后续步骤

• 了解如何在 App Engine 中使用微服务来创建开发、测试、质检、模拟和生产环境并为这些环境命名。
• 了解可以采用哪些最佳做法来设计用于在微服务之间进行通信的 API。
• 了解提高微服务性能的最佳做法。
• 了解如何将现有的单体式应用迁移并转化为一个具有多项微服务的应用。
• 了解微服务是否适用于您的情况。Google 解决方案架构师 Preston Holmes 在其个人博客上发布了一篇博文，其中列出了他认为微服务中存在的一些缺点。