目的驱动的微服务规划

创立目的驱动的微服务应该始终是一个方针。了解Render Blueprints怎么供给可重复的微服务策略。

在我开始职业生涯的时分，流行语并不是我所期待的东西。在那些日子里，大部分的技术新闻都是在纸质的周刊上发布的，比方《信息周刊》和《网络世界》。我记住我在想，”店员，他们每周都在重复运用这些相同的词”。

这就意味着人们一向在运用流行语……。那时，我最喜欢的两个流行语是把互联网称为 “万维网 “和 “信息高速路”。我一向在想，是否在某个时分会有一条超级大高速公路。

但是，最近，我注意到流行语被用作不彻底有意义的地方的占位符。像微服务、工作驱动架构、人工智能和ML这样的术语被用在一些场合，这让我得出定论，许多人并不彻底了解这些术语。我也没有想到会这样……

幻想一下与一个被误解的问题有关的这个简略对话：

1号人物：你的航班什么时分起飞？

2号人:本年晚些时分。

尽管2号人物供给了一个并不过错的答案，但这个回答对1号人物的询问并没有真实发生任何价值。

依照相同的思路，在寻求向微服务迁移的进程中也阅历了类似的挑战。我经常与客户和公司协作，他们的 “微服务 “规划导致了单一的单体服务。基本上，一个单体运用被替换成了一个真实大的RESTful API。

在本出版物中，我以为经过一个创立目的驱动的微服务规划的比如会很风趣……正确的方法。

目的驱动的微服务规划

目的驱动的微服务是一个可以独立存在的服务，它可以在需要时包含一个专门的持久性存储。经过目的驱动，微服务将供给一套会集的信息，并成为相关API中管理的数据的记载体系。

经过选用目的驱动的微服务方法，用户可以增加额外的节点和缩小现有的节点，以满足该时间点的API的需求。

举例来说，一个专心于所得税某一方面的目的驱动的微服务可能会在一年的上半年看到最高的运用率，而在下半年则需要较少的实例运转。

让咱们经过一个非常简略的比如来重视目的驱动型微服务规划的创立。

创立一个基于Docker的微服务

我国的性别猜测器是一个网格体系，用于猜测婴儿出世时的性别。这是经过供给受孕月份和母亲受孕时的当前年龄来实现的。

据传闻，清朝皇室也是依托这种网格来挑选儿子的性别，因为他们可以为家庭供给工作和金钱，也可以承继宗族的血统，所以遭到喜爱。

下面是我国性别猜测网的插图。

举例来说，一个18岁的母亲在1月怀上孩子，会生出一个女婴。

关于这个出版物，咱们将创立一个目的驱动的微服务，根据相同的标准返回性别猜测。上述比如的成果有效载荷将如下所示。

JSON

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

该微服务将利用Java和Spring Boot，并将选用一个多阶段的Dockerfile来编译该服务，并建立一个可以承载出世猜测器API的Docker镜像。

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

gitlab.com/johnjvester…

运用Render Blueprints创立可仿制的形式

我在以下出版物中写过关于Render渠道的文章:

  • 初次运用Render和Go

  • 引擎盖下：Render一致云

关于我在Render上运转的个人实例，我运用了Go编程言语、静态网站和一个Postgres实例。这一次，我用Java/Spring Boot编写服务。尽管对Java的本地支撑还不存在，但Render渠道确实包含对任安在Docker容器中运转的东西的支撑。

因为出世猜测器服务包含一个多阶段的Docker文件，我想看看在Render渠道上布置一个基于Docker的服务有多容易。但是，我注意到蓝图（Blueprint）标准，也想看看它是怎么运作的。

什么是 “蓝图”？

蓝图是Render对基础设施即代码（IaC）的实现。IaC也是我将其归入一个更大的概念，称为 “*为代码”。需要管理几个服务的布置，或者有需要许多选项的服务的组织，可以在render.yaml文件中把他们的Render基础设施（服务、数据库和环境组）界说为代码。

运用Render Blueprint

在这儿供给的蓝图比如的基础上，我可以为我的经过Docker容器运转的Spring Boot服务快速创立一个蓝图。

渲染蓝图(YAML)

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数据，以更新名称特点并增加repo特点，如下所述:

YAML

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仪表板上，我挑选了 “新建|蓝图“选项。

接下来，我挑选了birth-predictor 库房，用这儿的说明将其衔接到我的GitLab账户。

因为我运用的是蓝图，我所要做的就是为我的新服务供给一个服务组名称。

按下 “运用“按钮后，布置进程开始了。

几分钟后，该服务被布置，没有任何问题。

运转中的出世猜测器

跟着出世猜测器服务的运转，我可以发出以下cURL命令来获得新的猜测成果。

JSON

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

由此发生的呼应有效载荷看起来像这样。

JSON

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

这些信息恰好与咱们的儿子（Finny）受孕时的受孕月份和我妻子的年龄相符。2017年8月，他来到了!

就像他们在清朝时相同，咱们可以依托我国的性别猜测器成功地猜测出咱们孩子的性别。

定论

自2021年以来，我一向在尽力遵循以下任务宣言，我觉得它可以适用于任何IT专业人士:

“把你的时间会集在供给特性/功用上，以扩大你的知识产权的价值。充分利用框架、产品和服务来处理其他工作。

– J. Vester

Render公司的蓝图标准坚持了我的任务宣言，允许功用和服务团队专心于依照既定的方针和指标进行交给，而不必担心任何与DevOps有关的工作。

一旦服务、组件或运用程序准备好了，团队只需要在他们的资源库的根中包含render.yaml文件，然后运用蓝图选项在Render渠道上创立一个新的服务。今后，任何对衔接库房的更新都会在提交代码到指定分支后几分钟自动布置。

Render渠道以 “零开发 “的心态生存，这在 “蓝图 “概念的起源中是很明显的。功用和服务开发者期望–而且应该–专心于供给更新和功用，为他们的利益相关者供给最大的价值。Render真实了解这一实际。

我坚信，流行语将永远是技术领域的一部分。但是，了解和选用这些流行语背面的真实目的，是我期望技术专家可以寻求的。