构建本机可扩展的微服务
介绍
几乎所有熟悉微服务架构的人都听说过扩展 。 扩展是通过运行服务（容器）的多个实例来实现负载平衡的过程。
在任何现有的业务流程平台中，缩放都可以自动或手动完成。 但是，这两种方法都需要某种管理方式来决定何时需要扩展微服务。 本文介绍了一种由OS系统调用驱动的自主缩放方法，而无需外部干扰。
动机
自治是微服务架构的主要原则之一，对于构建敏捷生态系统至关重要。 在敏捷的生态系统中，随着开发的敏捷性，微服务要求权威立即对操作条件做出反应-高工作量就是其中之一。 当微服务承受高负载时，通过复制自身来减少工作量将更加方便快捷。
这有点类似于人体细胞的行为。 当细胞生长时，在某个时候，它可能会经历分裂阶段，该分裂阶段会将细胞分裂为两个较小的细胞。
通常允许微服务使用一小部分系统资源。 将增长定义为与总可用资源相关的资源消耗量，当增长达到一定限制时，就该复制微服务了。
通过分叉复制
同样，使用这种方法，出于高可用性的考虑，无需在发生故障时重新创建微服务，因为新一代微服务将自动取代其位置。 但是，需要最少数量的副本才能防止由于早期故障而导致的突然死亡。
实作
微服务通常实现为单个OS进程。 操作系统中进程的复制被称为分叉 。 fork系统调用将创建一个子进程作为该调用进程的精确副本。 下面是使用fork函数在C中进行复制的示例实现：
在上面的代码中， fork创建一个新的子进程，并在父函数及其子进程中返回，由函数的结果确定。 稍后，在子进程中，必须执行execv函数调用才能从其父进程中分离和隐藏子进程。 否则，当孩子死亡时，它将变成僵尸进程，直到父母等待还是死亡之前，都不会清理僵尸进程。
缺点
请注意，本文介绍的复制方法不会消除对业务流程的需求。 仍然需要编排平台来播种微服务（即，首次实例化），并通过推动允许的副本数限制来控制系统资源利用率。
另一方面，并非所有编程语言都可以与OS系统调用进行交互，而出于安全性考虑，某些其他语言可能会阻止它们。 但是，有一些方法可以解决此问题，例如，通过直接执行程序或使用帮助服务来创建新流程。
同样显然，分叉仅在容器内可用，而不能实例化新容器。 这与当前的业务流程平台如何扩展微服务形成对比。 但是，仍然可以通过在新的群集节点上播种微服务来支持群集。
阅读更多
这是用于实施称为“有机服务体系结构”的创新微服务体系结构的想法。 您可以在此处阅读有关此思想和体系结构的更多信息 。
