登录

  • 登录
  • 忘记密码?点击找回

注册

  • 获取手机验证码 60
  • 注册

找回密码

  • 获取手机验证码60
  • 找回
毕业论文网 > 开题报告 > 计算机类 > 软件工程 > 正文

基于thrift rpc的微服务自测平台开题报告

 2020-02-10 11:02  

1. 研究目的与意义(文献综述)

“微服务”架构是近期软件应用领域非常热门的概念。在这种架构风格中,一个大型复杂软件应用会被分解为多个微服务。系统中的每个微服务一般都通过一个进程实现,仅需关注于完成一件任务并很好地完成该任务。在这种架构中,一方面由于微服务之间是松耦合的,使得开发人员可以专注于某个微服务而不是整个系统,有效降低了开发成本,另外一方面由于每个微服务都体量较小,可独立部署,使得可以实现快速开发测试部署上线,从而达到随着业务变化产品快速迭代的目的。

要想合理利用微服务架构,微服务之间的有效可靠通信是个必须解决的问题。当不同的微服务位于不同的机器时,基于 tcp/ip 的网络通信是微服务之间进行有效可靠通信的唯一途径,但每一个微服务都独立实现基于 tcp 的应用层协议一是会增加开发难度,二是无法保证可靠性,因此目前的互联网公司在使用微服务架构时,都会使用一些成熟的 rpc 框架来用作微服务之间的通信机制。常用的 rpc 框架主要有 facebook 开源的 thrift rpc 与 google 开源的 grpc 。

thrift rpc 是由 facebook 开发的,后托管到 apache 软件基金会的一个开源项目。 在实际的生产环境中,使用 thrift rpc 作为通信机制开发完一个微服务之后,需要先进行本机自测,然后提交到 qa 进行统一测试,然后才开始逐步上线。在自测阶段,通常的解决方法是:对于每一个下游依赖服务,实现出一个服务器,并 mock 出每一个 rpc 调用的返回数据,作为一个测试用例;对于当前微服务,实现一个客户端,用来调用当前服务,并根据是否出错与返回数据对当前微服务进行测试。在自测阶段主要存在两个问题。问题一:是对于每一个微服务,都需要为所有的下游依赖服务实现一个服务器,这一方面增加了开发成本并无法保证可靠性,另一方面由于在同一个系统中两个不同的微服务有很大概率依赖同一个下游服务,所以这实际上会造成重复开发。问题二:由于自测阶段是开发人员自己 mock 出测试数据,因此很难进行测试用例的管理与维护,就会造成测试不够充分的问题,从而丧失了测试原本的意义。

剩余内容已隐藏,您需要先支付后才能查看该篇文章全部内容!

2. 研究的基本内容与方案


基本内容:

1、通过阅读文献,理解 thrift rpc 的实现机制,学习其各层协议栈的实现原理及各层协议之间的通信方式,学习 thrift rpc 代码生成器根据 idl 文件生成代码的过程与原理。根据以上学习研究动态解析 idl 文件生成 thrift 客户端或服务器并载入程序自动启动的解决方案。

2、在深刻理解需求的前提下,研究微服务维度的测试用例的维护与管理方案。包含用于展示给用户的视图模型,用于处理业务的逻辑模型,用于持久化的存储逻辑。并结合 redis 提出可以显著提高性能的存储解决方案。

剩余内容已隐藏,您需要先支付后才能查看该篇文章全部内容!

3. 研究计划与安排

第一阶段(第1周—第3周):阅读相关参考文献,完成外文资料翻译及文献摘要撰写,并交予指导教师检查。

第二阶段(第4周—第6周):研究 thrift 服务器与客户端的动态生成加载启动机制,实现系统的服务器与客户端管理维护模块。

第三阶段(第7周—第9周):研究微服务维度的测试用例管理方案,实现系统的测试用例管理模块与用户管理模块。

剩余内容已隐藏,您需要先支付后才能查看该篇文章全部内容!

4. 参考文献(12篇以上)

[1]slee, mark amp; agarwal, aditya amp; kwiatkowski, marc. (2019). thrift: scalable cross-language services implementation.

[2]游双. linux高性能服务器编程[m].北京:机械工业出版社,2013.06:123-145

[3]thrift document[eb]. apache thrift: https://thrift.apache.org/docs/, 2017年

剩余内容已隐藏,您需要先支付 10元 才能查看该篇文章全部内容!立即支付

企业微信

Copyright © 2010-2022 毕业论文网 站点地图