认识达内从这里开始

微进程技术应用我们在学习微服务架构开发技术的时候会经常接触到的一个编程开发知识点，而本文我们就通过案例分析来了解一下，微进程架构设计应用优缺点分析。

微进程处理过程主要是将非常大的任务划分为一些较小的任务，然后使用我们的微服务逻辑和架构处理它们。

这个概念并不是什么新鲜事物，并已在其他领域广泛使用，但这种方法将相同的技术应用于微服务架构，给我们带来了很多好处，而缺点却很少。

要实现这种方法，我们有1个进程(可以是计划或手动触发)，其的工作就是收集并触发所有需要处理的作业。这明显要比计算所有信用分数要快，因为分成多个的微进程只需要花费几分钟就能算出分数，而计算所有信用分数则需要几天时间。

很多时候，划分任务的进程非常轻巧，我们可以在一个lambda函数中实现它(请注意lambda函数的处理时间限制为15分钟)，这样我们就不必担心服务器或虚拟机中的crontab配置。

此时，我们的队列中有很多(也许是数百万个)小任务等待处理，因此“真正的工作”尚未完成。

当然，一旦你将所有作业都排在队列中，就有许多方法可以并行执行作业。

传统上，我们可能会有一个带有监督者(或类似对象)的盒子，让多个进程从队列中提取消息，但这意味着我们会有一个盒子不断地运行代码以提取消息和代码等待处理，这就属于微服务了。

即使这种方法(和其他使用相同微服务代码的方法，以及在同一环境中从队列中提取消息的代码)是有效且可行的，我们还是发现有两种不同的环境(具有后台进程和用于实时流量的docker容器的虚拟或物理服务器)会带来很多开销。

在某些配置中(例如一个虚拟盒子)，如果我们要部署，将需要停止监督并等待进程完成，然后再用新代码启动一个新的并销毁前一个，这将大大增加部署的复杂程度，因为我们需要跟踪所有后台进程。

另外，我们不得不想出两种不同的方式来监视我们的应用程序(后台进程和活动端点)，确保我们的日志记录器能够正确跟踪两个不同环境中的所有日志，并确保两处的依赖都正确无误，等等。

请注意，我甚至没有提到有两个不同的代码库负责计算信用评分，一个代码库用于后台进程，另一个代码库用于微服务，所以还得考虑那些不能出现代码复制的禁区。

理想情况下，我们希望：

不要重复代码

没有多个(需要测试)的系统配置

能够监控我们后台进程的健康状况和进度

缩放(例如，在工作时间以外更快地处理)

能够快速部署并尽快使用新版本的代码

部署简单且维护成本低廉

我们提出的用于处理微进程的解决方案是微服务架构的原生方案。我们利用SQS+Lambda创建了一个推送队列，并调用一个微服务端点来执行微进程的任务。

我们在这里更具体地讨论了SQS+lambda方法。

微进程模式架构

这里仅包含以下三个元素：

一个进程将大进程分成多个很小的微进程

推送队列(在我们的示例中使用SQS+Lambda函数实现)

嵌入微服务的端点

我们实现了我们想要的大部分目标。

我们实现了：

不要重复代码(所有代码都驻留在微服务代码库中)

没有多个需要我们测试的系统配置(我们只有微服务基础架构)

能够监视我们后台进程的健康状况和进度(我们可以全程看到队列中有多少待处理消息)

缩放(在实现lambda函数时，我们可以按需缩放，更多信息请参见这里)

能够快速部署并(通过当前的部署)尽快使用新版本的代码

部署简单且维护成本低(我们像往常一样部署，不需要额外的开销)

但是，这一解决方案也有其缺点：

微进程限制为15分钟(如果使用Lambda的话)

实时流量和来自后台作业，到同一基础架构的流量会混淆监视并影响实时流量(后文会列出解决方案)

也许进程无法分割，所以这种方法无济于事

微进程的进程可能比实时流量慢，并且我们要确保可以正确监控两种进程的健康状态。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。