目的驱动的微服务设计
创建目的驱动的微服务应该始终是一个目标。了解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上找到，地址如下:
使用Render Blueprints创建可复制的模式
我在以下出版物中写过关于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真正理解这一现实。
我确信，流行语将永远是技术领域的一部分。然而，理解和采用这些流行语背后的真正意图，是我希望技术专家能够追求的。