[发明专利]一种面向微服务系统的跨容器通信框架设计方法

说明书

本发明公开了一种微服务跨容器通信框架的设计方法，针对部署在Kubernetes集群中的容器，通过采用新建中间转发节点的方式，实现集群外部与集群中节点的通信。与现有通信方法相比，本发明方法具有无需重启容器、可在转发时进行负载均衡以及可定制转发策略等优点。本发明还包括一种通过对以上通信框架采集到的日志的兼容性格式转换方法，能够帮助分析出容器中运行程序的轨迹，该方案实现分发请求的负载均衡以及安全传输日志等功能，方便对用户感兴趣的容器进行统一的管理和操作。

技术领域

本发明属于软件工程中的构件框架方法领域，尤其涉及一种面向微服务系统的框架通信设计方法。

背景技术

近年来，现有的多种容器集群管理平台功能已经较为完善，主要体现在：1)专注于对平台中部署的容器进行统一管理，保证容器能稳定的运行。2)平台能对各个容器以及服务进行监控，能根据目前的运行状态以及负载情况进行多种指标的动态伸缩，保证各种情况都能满足性能的需求。3)能对容器的整个生命周期进行管控，方便的进行项目的上线、测试、下线等管理。被广泛使用的Kubernetes还自带可视化组件，方便运维人员对服务进行管理。

由于集群管理系统的目的为管控整个容器集群，因此都着重于管理、部署整个集群系统，对于单种容器的关注度较少，而在某些情况下，对于某一容器中运行的web程序却恰好是用户所关注的。如动态轨迹验证时，用户需要根据该容器中运行的web程序所产生的日志信息，提取到平台外部，并进行分析，从而确定web程序是否按照正常的流程运行。这种情况下，Kubernetes平台就很难给出一种好的策略来处理这个问题，除此之外，由于容器网络已经被Kubernetes所管理，想要在容器内部部署新的web程序监听外部请求以及收集该web程序的日志存在困难，所以迫切的需要一种针对目标容器进行通信的工具。

在解决上述问题上，通常有以下几种做法。第一种方法是先手动找到容器ip，然后使用iptables增加转发链，转发请求到单个容器。但这种做法不适用于部署到Kubernetes平台的容器，因为在Kubernetes管理的平台上由于网络请求都被服务管理，因此请求也无法到达目标容器。第二种方法是重新创建docker容器，并在配置文件中添加开放多个端口。由于该方案需要重启容器修改配置文件，因此也不可行。以动态轨迹验证的应用场景为例，采用第一种方式，无法完成一般的功能需求，插桩请求无法传输到目标容器中。采用第二种方式时，能满足插桩需求，但却需要销毁容器并重新创建目标容器，这就违背了对程序进行动态验证的初衷——不能对被验证程序的正常使用造成影响。由此在许多实际应用中迫切的需要一种工具，能解决上述的问题，并且不对容器中的正常程序运行造成干扰。

发明内容

本发明的目的是设计并开发出一个微服务跨容器通信框架，使得外部能通过该工具转发与部署在Kubernetes集群中的容器进行通信，并具有管理容器生命周期、实现分发请求的负载均衡以及安全传输日志等功能，方便对用户感兴趣的容器进行统一的管理和操作。

为了实现上述目的，本发明的模块组成如下：一种面向微服务系统的跨容器通信框架设计方法，其特征在于，所述方法包括如下功能模块：容器监视与通信模块、请求分发负载均衡模块、传输信息加密模块、文件传输模块以及文件格式转换模块。

其中容器监视与通信模块，通信指的是平台外部能通过工具转发http请求到目标容器，实现监视目标容器运行状态等功能。在与目标容器通信时，能做到用户在直接跟容器通信一般。通信是一切其他功能的基础；

请求分发负载均衡模块，该工具在访问多个容器的服务时，可以根据设置的负载均衡策略(轮询、随机选择等)选择一个容器发送请求；

传输信息加密模块，该工具能对传输的关键内容(如日志信息)进行加密以及解密，保证客户端与容器间通信的安全性。

文件传输模块，该工具能将在目标容器中收集到的日志信息通过转发容器转发到本地，进行分析。