在这篇由 2 部分组成的帖子的 第 1 部分 中，我描述了什么是微服务以及我如何将 3 层单体应用程序转换为使用微服务架构。如果您还没有阅读 第 1 部分 ，我建议您现在回去阅读。此外，如果您还没有阅读 我关于构建云原生应用程序的帖子， 我建议您也查看一下，以便更好地了解为什么微服务在构建云应用程序时很重要。
在第 1 部分结束时，我们离开了一个应用程序，该应用程序已分解为多个微服务，所有微服务协同工作，为最终用户提供整体体验。架构看起来像这样
虽然这种架构比我们原来的整体架构更适合云，但我提到我们仍然有一些问题需要解决。
第一个问题与脆弱性有关，正如我在 关于构建云原生应用程序的帖子 中提到的那样，脆弱性是敌人。这种架构的脆弱性在哪里？那么它实际上是在客户端代码和服务之间。就目前而言，我们的客户端代码对所有服务都有很强的依赖性。这是一个很好的例子，说明为什么这是不好的。在微服务应用程序中，服务不断发展是很常见的。通常这涉及一个微服务变得太大，需要拆分成两个或更多新服务，但也可能涉及完全删除一个服务。当这样的事情发生时（它必然会在我们应用程序生命周期的某个时刻发生）我们的客户端代码突然被破坏，因为它直接与不断发展的服务通信。
一个更微妙的问题与与服务通信的客户端类型有关。以台式机和手机为例。这两个客户端非常不同，尤其是在网络带宽方面。我们的 Web 应用程序可以向每个单独的服务发出多个请求，以便在桌面浏览器上呈现 UI，但在手机上，发出较少数量的请求并增加负载响应大小可能会更好.
底线是我们需要介于我们的客户和我们的服务之间的东西，可以为我们的客户提供一个抽象层。出于这个原因，微服务应用程序通常具有客户端使用的所谓“API 网关”。如果我们在我们的示例应用程序中引入一个 API 网关，它会是这样的
在此图中，API 网关还提供客户端代码，但并非必须如此。重要的是 API 网关知道如何与服务对话，随着服务的发展，我们可以避免更改客户端代码，而只让 API 网关知道服务的更改。如果需要，API 网关还可以聚合服务调用以优化对不同类型设备的请求。
虽然使用 API 网关比让客户端直接与服务对话更好，但我们可以做得更好。这是另一个需要考虑的问题，当我们在此架构中扩展服务时会发生什么？
在这张图中，我们已经扩展了会话服务，但是 API 网关不知道新的服务实例，那么它如何利用额外的实例呢？我们必须更改 API 网关，以便它知道第二个实例。借助我们部署到的云平台提供的自动缩放等功能，以及我们可能拥有 100 个或服务的事实，修改 API 网关将无法缩放。
为了解决这个问题，微服务应用程序通常使用服务发现应用程序，它允许所有微服务自行注册，然后将它们的存在广播到应用程序中的其他服务。这是它的样子。
现在部署了我们的服务发现应用程序，每个服务实例都将自己注册到服务发现应用程序，然后还查询服务发现应用程序以了解还有哪些其他服务可供它使用。这解决了我们 API 网关的扩展问题。当我们启动更多的 XYZ 服务实例时，它们都将自己注册到服务发现应用程序，API 网关将定期查询服务发现应用程序以确保它具有更新的服务列表。在服务发现应用程序中注册新实例后，API 网关将获取它们，然后在向服务发出请求时能够利用这些新实例。所有这些都可以动态完成，无需在 API 网关中更改和编写代码，这正是我们想要的。
使用服务发现应用程序还有其他好处。考虑我们在多个数据中心部署相同微服务的情况。每个数据中心都有一个类似于上述架构的部署。每个数据中心中的服务发现应用程序可以相互共享有关该数据中心中运行的服务的数据。这将允许应用程序不受一个数据中心中给定服务完全中断的影响，因为该服务在另一个数据中心中仍然可用。这种类型的功能将使我们的应用程序对故障更具弹性。
在这一点上，我们有一个非常好的基于微服务的架构可用于我们的应用程序。关于此架构需要注意的一件事是，移动部件比我们最初的 3 层架构多得多。
最重要的是，就像您所做的一切一样，您选择的架构也需要权衡取舍。如果您需要云中的弹性，想要加快开发速度，并真正成为一个真正敏捷的组织，那么毫无疑问，微服务可以满足您的需求。但是，您需要权衡这些好处与更复杂的体系结构带来的额外挑战。鉴于云社区成员对微服务的兴趣，很明显有许多组织正面临这些挑战并正在寻找解决方案。同样清楚的是，如果做得好，正如 Netflix、亚马逊和其他公司所证明的那样，微服务可以使您的应用程序和组织变得更好。是否应该在您的应用程序中使用微服务的决定最终取决于您，但我个人认为它对于某一类云应用程序来说是一个很好的解决方案。
现在是这个讨论的后续问题，“是否有可以帮助我构建微服务的工具？”答案是响亮的“是”，我将在以后的帖子中讨论其中的一些工具。