本文节选自《实时流计算系统设计与实现》一书。
当一个服务模块的输入和输出都是流的时候，我们称其为流服务。流服务的好处在于其可以直观地描述业务执行流程。
流服务使用 DAG 来描述执行流程，DAG 的每个节点代表一个业务单元，每个业务单元负责一定的业务逻辑。
在业务单元中，经常会用到一些具有特定功能的辅助性服务，如 IP 分析、GPS 解析、第三方征信服务等。将实现这些辅助性功能的代码直接放入流计算应用的业务代码里，或许是一个好方法，特别是在我们非常在乎性能的时候。
毕竟将这些辅助性功能的逻辑集成到流应用里，会减少相当多的 I/O 操作，确保了流应用的性能。但是这样做并不优雅。
考虑下，如果流计算任务需要用到很多辅助性功能（这种情况其实相当常见），而且这些辅助性功能中的某些内部逻辑甚至相当复杂，那么将这些功能的实现代码全都放到业务流程的实现中，势必会造成业务逻辑和技术细节纵横交错、程序执行流程杂乱无章。
一种折中的方案是将辅助性功能抽取为独立的源码项目，将它们编译为库后再链接进流计算应用。
这样一方面能够保证流计算应用的性能，另一方面避免了流计算应用的代码过于杂乱。这样做不失为一个比较好的办法，并且在性能优先的情况下可能是最优选择。
但这样做也存在问题，即每次对辅助性功能服务做更改或升级时，流计算应用必须重新构建、测试和发布。
从服务治理的角度而言，我们还是应该将辅助性功能剥离出去，让它们成为单独的服务，对外提供 REST 或 RPC 的访问接口。
下图描述了这种将辅助性功能剥离为单独微服务，由流服务调用接口访问的架构。
这样，流计算应用负责整体的业务逻辑，而辅助性功能被封装在一个个独立的微服务内并对外提供友好的使用界面，整个流计算系统架构清晰，在将来需要调整时也更加灵活。本文节选自《实时流计算系统设计与实现》一书。
当一个服务模块的输入和输出都是流的时候，我们称其为流服务。流服务的好处在于其可以直观地描述业务执行流程。
流服务使用 DAG 来描述执行流程，DAG 的每个节点代表一个业务单元，每个业务单元负责一定的业务逻辑。
在业务单元中，经常会用到一些具有特定功能的辅助性服务，如 IP 分析、GPS 解析、第三方征信服务等。将实现这些辅助性功能的代码直接放入流计算应用的业务代码里，或许是一个好方法，特别是在我们非常在乎性能的时候。
毕竟将这些辅助性功能的逻辑集成到流应用里，会减少相当多的 I/O 操作，确保了流应用的性能。但是这样做并不优雅。
考虑下，如果流计算任务需要用到很多辅助性功能（这种情况其实相当常见），而且这些辅助性功能中的某些内部逻辑甚至相当复杂，那么将这些功能的实现代码全都放到业务流程的实现中，势必会造成业务逻辑和技术细节纵横交错、程序执行流程杂乱无章。
一种折中的方案是将辅助性功能抽取为独立的源码项目，将它们编译为库后再链接进流计算应用。
这样一方面能够保证流计算应用的性能，另一方面避免了流计算应用的代码过于杂乱。这样做不失为一个比较好的办法，并且在性能优先的情况下可能是最优选择。
但这样做也存在问题，即每次对辅助性功能服务做更改或升级时，流计算应用必须重新构建、测试和发布。
从服务治理的角度而言，我们还是应该将辅助性功能剥离出去，让它们成为单独的服务，对外提供 REST 或 RPC 的访问接口。
下图描述了这种将辅助性功能剥离为单独微服务，由流服务调用接口访问的架构。
这样，流计算应用负责整体的业务逻辑，而辅助性功能被封装在一个个独立的微服务内并对外提供友好的使用界面，整个流计算系统架构清晰，在将来需要调整时也更加灵活。
在流服务中调用外部的微服务也存在一个问题，即性能问题。
在状态存储时，我们建议使用本地数据存储方案替代远程数据存储方案，原因在于远程数据存储方案可能会极大地降低流服务的性能。与此类似，在流服务中调用外部微服务时也涉及网络 I/O，这同样会比较显著地降低流服务的性能。所以，我们要针对微服务的调用过程做优化。
一方面，要小心谨慎地设计微服务，确保微服务能够快速地返回，不管是成功还是失败，都必须在给定的时间内快速返回。另一方面，流服务在调用微服务时，可以采取异步 I/O 的方式，这样能够保证流服务在处理事件时不会让 CPU 阻塞在等待微服务请求返回，从而提升流服务的吞吐能力。
另外，必须强调的是，在流计算中使用微服务最好采用只读方式，或者至少应该是幂等的。因为，如果流服务访问微服务时造成了外部状态的改变，就有可能破坏流计算应用整体的可靠性保证机制。
关于出现这个问题的原因，我们在前文讨论各种开源流计算框架的消息传达可靠性保证机制时已有所分析，这里不再赘述。
相比流服务，微服务是一种更加为大众所知的服务组织架构。
从形式上，微服务和流服务最大的区别在于，微服务是请求并响应的模式，而流服务则是事件驱动的模式。微服务系统架构将复杂软件系统按业务功能划分为一个个独立的服务模块，每个服务模块独立开发、独立部署、独立提供服务，各独立服务模块之间天然是一种松耦合的状态。
微服务确实有助于我们分解复杂的系统，但与之而来的问题是，它会让业务系统变得复杂。
相比流服务有一个提纲挈领的 DAG 代表了完整的业务流程，微服务系统如果没有额外的设计文档进行解释，那么我们是很难一下就弄清楚业务系统的完整执行流程的。
相比微服务而言，流服务的服务治理方案是“与生俱来”的，原因有以下几点。
第一，大部分流计算框架是构建在诸如YARN这样的分布式操作系统上的，所以它们所运行的环境已经云化。这意味着基于这些流计算框架构建的应用是可以自由横向伸缩的。
第二，大部分流计算框架或多或少地提供了管理界面，这让我们能够非常方便地监测和追踪运行在系统中的应用的状况。
第三，大部分流计算框架具备一定的容错机制，并且可在服务失败时自动完成服务恢复，不需要我们外部干预。但是微服务就不一样了。
微服务系统架构和服务治理还是有较大距离的，甚至可以说，服务治理的概念最初正是为了更好地管理微服务系统而提出的。
针对微服务系统的服务治理方案多种多样，从 Apache Dubbo 和 Spring Cloud，到 Docker Swarm 和Kubernetes，再到如今的 Service Mesh 等，各种微服务治理方案可谓方兴未艾，它们正在快速地发展和演进过程中。
虽然像诸如 Kubernetes 和 Service Mesh 等前沿、新颖的微服务治理方案确实非常有趣，但限于本书的主题，我们不展开讨论它们，强烈建议感兴趣的读者自行查阅相关资料。
笔者只在这里斗胆做一个预言，在诸如 Kubernetes 和 Service Mesh 等基于资源云化技术和服务编排技术的服务治理平台更加成熟和普及时，未来微服务和流服务之间的边界将越来越模糊，直接基于这些服务治理平台开发流计算框架也未尝不是一件有趣的事。
本文节选自《实时流计算系统设计与实现》一书。作者：周爽
本书高度抽象出实时流计算系统的技术支撑、架构模式、编程模式、系统实现与协同系统，并从零编写一个分布式实时流计算系统。
网友评论