概述
微服务架构作为当前最流行的架构体系，它所集成的服务大都是轻量级的(这也是为什么叫微服务)。单个微服务内部实现逻辑简单，处理客户请求时间短，经常做一些数据的增删改查操作。一般来说2到3千行代码就可以实现一个微服务。
与轻量级的微服务对应的是重量级的算法服务。如何定义重量级服务呢？首先服务请求处理时间很长，一般在几分钟到几个小时都有可能，视处理的数据量大小而定；其次，算法的输入参数和输出结果的数据量都很大。由于以上两个原因，一般算法服务的并发能力都很弱(很多时候只允许同时处理一个请求，或者认为它并发量就是1).
在微服务框架中如何集成这类算法服务呢？ 我认为需要考虑三个方面： 1. 算法服务自动发现和任务调度。 2 .算法服务的输入参数和计算结果数据传递。 3. 算法服务和任务状态监控。
整体架构图
算法调度服务
由于算法服务资源是有限的，算法服务的并发能力也很差或者说没有并发能力。我们需要一个算法调度服务来分配资源。算法服务部署后通过心跳注册(IP地址、服务状态等信息)，算法调度服务就拿到了所有算法服务的状态和数量。
Client应用从算法调度服务申请计算任务，新任务添加到任务队列里面(可以放到内存也可以放到数据库，推荐放到数据库，重启服务数据不丢失)。
算法调度服务检测从算法服务上报的心跳，发现有算法服务空闲了，就从任务队列中取出一个任务交给它去执行。
FTP服务器
由于算法服务是重型化的，它需要的输入参数和计算后的结果 数据量都很大，直接通过restful接口传递不是特别合适。这里提供一种思路：采用文件的方式传递。输入参数和计算结果都通过JSON串的形式保存到文件，通过FTP上传和下载。
监控进程
监控进程实际上是算法服务的守护进程，和算法服务部署到同一个虚拟机或者docker容器里面。监控服务启动后就开始周期性的向调度服务发送心跳。
这个监控进程不是必须的，如果算法服务本身实现了心跳上报的功能，就不需要了。但是如果要实现对算法服务的启停功能(kill进程，启动进程)，那还是需要的。
上报心跳
上报心跳单独拿出来说，上报心跳实现了很多功能：算法服务注册，申请新任务，上报任务执行进度等。如果调度服务长时间收不到某个算法服务的心跳，会认为它已经掉线了，会通知运维人员定位问题。