目的驱动的微服务设计

当我开始我的职业生涯时，流行语并不是我所期望的。在那些日子里，大多数科技新闻都出现在以纸质为基础的周刊上，比如 InformationWeek 和 Network World。我记得我在想，“伙计，他们每周一遍又一遍地使用这些相同的词。”

这转化为人们使用流行语......一直。那时，我最喜欢的两个流行语是将互联网称为“万维网”和“信息高速公路”。我一直想知道在某个时候是否会有一条超级高速公路。

然而，最近，我注意到流行语被用作占位符，它们不太有意义。微服务、事件驱动架构、人工智能和机器学习等术语在上下文中使用，这使我得出结论，许多人不太了解这些术语。我也没料到这个……

想象一下这个与一个被误解的问题相关的简单对话：

第一个人：你的航班几点起飞？

人#2：今年晚些时候。

虽然第 2 个人提供了一个不正确的答案，但该回复并没有真正对第 1 个人的询问产生任何价值。

沿着同样的思路，迁移到微服务的追求也经历了类似的挑战。我经常与客户和公司合作，他们的“微服务”设计导致了单一的单一服务。基本上，一个单一的应用程序被一个非常大的 RESTful API 所取代。

对于本出版物，我认为通过一个示例来创建目标驱动的微服务设计会很有趣……正确的方式。

目的驱动的微服务设计

目的驱动的微服务是一种可以独立存在的服务，它可以在需要时包含一个专用的持久性存储。通过以目的为导向，微服务将提供一组集中的信息，并成为相关 API 内管理的数据的记录系统。

通过采用目的驱动的微服务方法，用户可以添加额外的节点并缩减现有节点，以满足该时间点 API 的需求。

例如，专注于所得税方面的目的驱动的微服务可能在今年上半年的使用率最高，而下半年需要运行的实例更少。

让我们通过一个非常简单的示例来专注于创建目标驱动的微服务设计。

创建基于 Docker 的微服务

这中国性别预测器是一个网格系统，用于预测婴儿出生时的性别。这是通过提供受孕月份和受孕时母亲的当前年龄来完成的。

有传言说，清朝皇室也是靠这个格子来甄选儿子的，因为他们可以为家庭提供工作和金钱，也可以继承家族血统。

下面是中国性别预测器网格的图示：

例如，一位 18 岁的母亲在 1 月份怀了孩子，她会生下一个女婴。

在本出版物中，我们将创建一个目标驱动的微服务，它会根据相同的标准返回性别预测。上面示例的结果有效负载将如下所示：

 { "month": 1, "age": 18, "gender": "female", "errorMessage": null }

该微服务将利用 Java 和 Spring Boot，并将使用多阶段 Dockerfile 来编译服务并构建可以托管出生预测 API 的 Docker 映像。

该服务的代码可以在 GitLab 上的以下地址找到：

https://gitlab.com/johnjvester/birth-predictor

使用渲染蓝图创建可重现的模式

我在以下出版物中写过关于 __ Render __platform 的文章：

• 使用 Render PaaS 在 DevOps 上花费零时间
• 完美的云：AWS、GCP 和 Azure 一体化

对于我在 Render 上运行的个人实例，我使用了 Go 编程语言、静态站点和 Postgres 实例。这一次，我用 Java/Spring Boot 编写了服务。虽然尚不存在对 Java 的本机支持，但 Render 平台确实包括对在 Docker 容器中运行的任何内容的支持。

由于出生预测服务包含一个多阶段的 Dockerfile，我想看看在 Render 平台上部署基于 Docker 的服务是多么容易。然而，我注意到蓝图规范并想看看它是如何工作的。

什么是蓝图？

蓝图是 Render 对基础设施即代码 (IaC) 的实现。 IaC 也是我将其组合成一个更大的概念，称为“* as Code”。需要管理多个服务的部署或具有需要大量选项的服务的组织可以将其 Render 基础架构（服务、数据库和环境组）定义为 render.yaml 文件中的代码。

使用渲染蓝图

以提供的蓝图示例为基础这里，我能够快速为通过 Docker 容器运行的 Spring Boot 服务创建蓝图：

 services: - type: web name: restful-api-spring-boot env: docker region: ohio # optional (defaults to oregon) plan: free # optional (defaults to starter) branch: master # optional (uses repo default) numInstances: 1 # optional (defaults to 1) healthCheckPath: /actuator/health envVars: - key: SERVER_PORT value: 443

从那里，我为出生预测器服务定制了 YAML 数据，以更新 name 属性并添加一个 repo 属性，如下所示：

 services: - type: web name: birth-predictor env: docker repo: https://gitlab.com/johnjvester/birth-predictor region: ohio # optional (defaults to oregon) plan: free # optional (defaults to starter) branch: master # optional (uses repo default) numInstances: 1 # optional (defaults to 1) healthCheckPath: /actuator/health envVars: - key: SERVER_PORT value: 443

此信息存储在birth-predictor存储库的根目录中，名为render.yaml的文件中。提交并合并此更改后，服务已准备好在 Render 平台上部署。

从 Render Dashboard 中，我选择了New |蓝图选项：

接下来，我选择了出生预测器存储库，我使用找到的说明将其连接到我的 GitLab 帐户这里.

由于我使用的是蓝图，我所要做的就是为我的新服务提供一个服务组名称：

按下Apply按钮后，部署过程开始：

几分钟后，服务部署完成，没有任何问题：

出生预测器在行动

随着出生预测服务的运行，我可以发出以下 cURL 命令来获得新的预测：

 curl --location --request POST 'https://birth-predictor.onrender.com/predict' \ --header 'Content-Type: application/json' \ --data-raw '{ "conceptionMonth" : 11, "conceptionAge" : 43 }'

生成的响应负载如下所示：

 { "month": 11, "age": 43, "gender": "male", "errorMessage": null }

这些信息恰好与我们的儿子（芬尼）怀孕时我妻子的受孕月份和年龄相匹配。 2017年8月，他来了！

就像他们在清朝所做的那样，我们能够依靠中国性别预测器成功预测我们孩子的性别。

结论

自 2021 年以来，我一直在努力遵循以下使命宣言，我认为它适用于任何 IT 专业人士：

“将时间集中在提供扩展知识产权价值的特性/功能上。将框架、产品和服务用于其他一切。”

- J.维斯特

Render 的蓝图规范符合我的使命宣言，它允许功能和服务团队专注于针对既定目标和目标进行交付，而不用担心任何与 DevOps 相关的事情。

一旦服务、组件或应用程序准备就绪，团队只需将 render.yaml 文件包含在其存储库的根目录中，然后使用 Blueprint 选项在 Render 平台上创建一个新服务。展望未来，连接存储库的任何更新都将在将代码提交到指定分支后的几分钟内自动部署。

Render 平台遵循零 DevOps 的理念，这在蓝图概念的起源中很明显。特性和服务开发人员希望并且应该专注于提供更新和功能，为他们的利益相关者提供最大的价值。 Render 真正了解这个现实。

我确信流行语将永远是技术领域的一部分。但是，我希望技术人员能够理解并采用这些流行语背后的真实意图。

如果您对本出版物的源代码感兴趣，可以在 GitLab 上的以下地址找到它：

https://gitlab.com/johnjvester/birth-predictor

有一个非常棒的一天！