计算机测量与控制．２０２１．２９（１２）　犆狅犿狆
狌狋犲狉犕犲犪狊狌狉犲犿犲狀狋牔犆狅狀狋狉狅犾
　·２２０　·
收稿日期：２０２１１０２６；　修回日期：
２０２１１１０３。作者简介：赵媛心（１９８９）
，女，安徽阜阳人，硕士，工程师，主要从事航天软件研制方向的研究。引用格式：赵媛心，王　毅，纪祖 ，等．基于Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ改进的微服务技术研究［Ｊ］．计算机测量与控制，２０２１，２９（１２）：２２０２２５．
文章编号：１６７１４５９８（２０２１）１２０２２００６  ＤＯＩ：１０．１６５２６／ｊ
．ｃｎｋｉ．１１－４７６２／ｔｐ．２０２１．１２．０４０  中图分类号：Ｖ１文献标识码：Ａ
基于犜犺狉犻犳狋－犈狌狉犲犽犪改进的微服务技术研究
赵媛心，王　毅，纪祖 ，赵俊翔，刘　萍
（北京临近空间飞行器系统工程研究所，北京　１０００７６
）摘要：首先介绍了航天型号软件开发框架遇到的问题，分析了航天型号垂直应用框架和微服务框架的优缺点，着重介绍了目
前互联网领域流行的微服务框架Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ［１２］
和Ｄｕｂｂｏ
；接着描述了互联网领域的微服务框架适配航天型号软件领域遇到的问题；然后基于微服务框架思想和Ｄｕｂｂｏ微服务框架，提出了一种适用于航天型号软件领域的微服务框架；该服务框架有两种使用模式，一种适用于包含数据库的型号软件系统；另一种适用于不包含数据库的型号软件系统；针对有数据库的型号软件系统，利用数据库系统来实现微服务框架的注册中心功能；针对没有数据库的型号软件系统，利用广播协议、本地日志来实现微服务框架注册中心功能。
关键词：垂直应用框架；微服务框架；Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ；Ｄｕｂｂｏ
犚犲狊犲犪狉犮犺狅狀犐犿狆狉狅狏犲犱犕犻犮狉狅狊犲狉狏犻犮犲犜犲犮犺狀狅犾狅犵狔犅
犪狊犲犱狅狀犜犺狉犻犳狋－犈狌狉犲犽犪ＺＨＡＯＹｕａｎｘｉｎ，ＷＡＮＧＹｉ，ＪＩＺｕｂｉ，ＺＨＡＯＪｕｎｘｉａｎｇ，ＬＩＵＰｉｎｇ
（ＢｅｉｊｉｎｇＩｎｓｔｉｔｕｔｅｏｆＮｅａｒｓｐａｃｅＶｅｈｉｃｌｅ ｓＳｙｓｔｅｍｓＥｎｇｉｎｅｅｒｉｎｇ，Ｂｅｉｊｉｎｇ
　１０００７６，Ｃｈｉｎａ）犃犫狊狋狉犪犮狋：Ｔｈｉｓａｒｔｉｃｌｅｆｉｒｓｔｉｎｔｒｏｄｕｃｅｓｔｈｅｐｒｏｂｌｅｍｓｅｎｃｏｕｎｔｅｒｅｄｂｙｕｓｉｎｇｔｈｅａｅｒｏｓｐａｃｅｍｏｄｅｌｓｏｆｔｗａｒｅｄｅｖｅｌｏｐ
ｍｅｎｔｆｒａｍｅｗｏｒｋ．ａｎａｌｙｚｅｄｔｈｅａｄｖａｎｔａｇｅｓａｎｄｄｉｓａｄｖａｎｔａｇｅｓｏｆｖｅｒｔｉｃａｌａｐｐｌｉｃａｔｉｏｎｆｒａｍｅｗｏｒｋａｎｄｍｉｃｒｏｓｅｒｖｉｃｅｆｒａｍｅｗｏｒｋ，ｆｏｃｕｓｅｄｏｎｔｈｅｃｕｒｒｅｎｔｐｏｐ ｕｌａｒｍｉｃｒｏｓｅｒｖｉｃｅｆｒａｍｅｗｏｒｋｓＴｈｒｉｆｔ－ＥｕｒｅｋａａｎｄＤｕｂｂｏｉｎｔｈｅＩｎｔｅｒｎｅｔｆｉｅｌｄ．Ｔｈｅｎｂａｓｅｄｏｎｔｈｅｉｄｅａｏｆｍｉｃｒｏｓｅｒｖｉｃｅｆｒａｍｅｗｏｒｋａｎｄ
Ｄｕｂｂｏｍｉｃｒｏｓｅｒｖｉｃｅｆｒａｍｅｗｏｒｋ，ａｍｉｃｒｏｓｅｒｖｉｃｅｆｒａｍｅｗｏｒｋｓｕｉｔａｂｌｅｆｏｒａｅｒｏｓｐａｃｅｍｏｄｅｌｓｏｆｔｗａｒｅｆｉｅｌｄｉ
ｓｐｒｏｐｏｓｅｄ．Ｔｈｅｓｅｒｖｉｃｅｆｒａｍｅ ｗｏｒｋｈａｓｔｗｏｕｓａｇｅｍｏｄｅｓ，Ｏｎｅｉｓｓｕｉｔａｂｌｅｆｏｒａｍｏｄｅｌｓｏｆｔｗａｒｅｓｙｓｔｅｍｔｈａｔｃｏｎｔａｉｎｓａｄａｔａｂａｓｅ，ａｎｄｏｎｅｉｓｓｕｉｔａｂｌｅｆｏｒａｍｏｄｅｌｓｏｆｔ ｗａｒｅｓｙ
ｓｔｅｍｔｈａｔｄｏｅｓｎｏｔｃｏｎｔａｉｎａｄａｔａｂａｓｅ．犓犲狔
狑狅狉犱狊：ｖｅｒｔｉｃａｌａｐｐｌｉｃａｔｉｏｎｆｒａｍｅｗｏｒｋ；ｍｉｃｒｏｓｅｒｖｉｃｅｆｒａｍｅｗｏｒｋ；Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ；Ｄｕｂｂｏ０　引言
航天领域是国家安全基石的重要组成部分，是多学科综合、多专业耦合、多领域覆盖的系统工程，其中的型号软件具有技术水平高、复杂度高、覆盖范围广的特点。同时，组织也在发挥型号软件中积攒的技术和管理优势，逐步扩大产品化、市场化软件的研制和推广。随着航天控制软件规模越来越大，涉及的单位越来越多，分工也越来越细化。在这种场景下所有功能在一个软件中编写实现已经不现实，多个系统、多个软件配合使用已经成为航天控制领域软件的主要模式。随之产生多系统、多软件协同调用问题越来越突出，归纳起来有以下两点：
１
）调用方如何发现被调用方［７８］
；２
）被调用方启用或者关闭如何通知调用方［９１０］
。目前常用的解决方法有以下两种：
１
）静态配置。在数据库或者文件中手动维护被调用方软件地址列表。如果被调用方启用或者关闭，则手动更新数据库或者文件列表。调用方每次调用服务之前，首先读取数据库或者文件，然后再调用服务。
２）引入互联网领域的微服务框架。分布式微服务框架［１２］优点在于：
（１）一个服务对应一项业务能力，做到单一职责［１１１２］
；（２
）服务实现自动注册和发现；（３
）服务之间相互独立，可以实施不同的优化方案［１３］。当前互联网领域比较流行的微服务框架［
３］
有Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ［１２］和Ｄｕｂｂｏ［２
０］
，这些微服务框架的核心原理和组件基本一致，组件包括客户端［
４］
（调用方软件）、服务端（被调用方软件）和注册中心［５６］
，注册中心的主要作用就是维护服务端列表，通过健康检查［１４１５］和消息通知［１６］及时维护服务列表，目前比较常用的注册中心是Ｚｏｏｋｅｅｐ
ｅｒ［１７］
。但是这两种方式在适配航天控制领域软件都遇到了困难。静态配置方式遇到的主要困难是每次软件启用、关闭都需要手动更新数据库或者文件，这就给运维人员提出了很高的要求，尤其是调用关系复杂的情况下，如何及时正确地配置调用关系就成为了系统瓶颈。
互联网领域软件与航天控制领域软件的一个重要区别是物理网络隔离。Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ框架、Ｄｕｂｂｏ比较适用于互联网领域，而不太适合航天控制领域，原因就在于这些框架依赖服务很多，部署复杂。通常航天控制软件需要在多个区域部署试用，而且各个区域的网络是物理隔离无法远程部署服务。如果需要汇报演示软件，航天控制软件自身部署需要１ｈ
，但是微服务框架部署可能需要１ｄ。所以就需要结合互　
投稿网址：
第１２期赵媛心，等：基于Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ
改进的微服务技术研究·２２１　·
联网领域微服务框架思想开发一套适用于航天控制软件领域的微服务框架，其需要具备以下特点：１）易用性高；２）功能丰富；３
）依赖项少，部署简单。１　犜犺狉犻犳狋－犈狌狉犲犽犪微服务架构及原理
１ １　犜
犺狉犻犳狋－犈狌狉犲犽犪框架介绍Ｆａｃｅｂｏｏｋ作为全球１０大巨头互联网公司之一，其内部包含多套软件系统。并且各个软件系统使用的开发语言互不相同，部署环境互不相同。为了打通不同系统之间的信息壁垒，串联各个信息孤岛，构建互联互通的软件系统，其开发了Ｔｈｒｉｆｔ框架。在内部稳定运行一段时间后，Ｆａｃｅ ｂｏｏｋ于２００７年将Ｔｈｒｉｆｔ框架作为一个开源项目
提交给了Ａｐ
ａｃｈｅ基金会。由于创建Ｔｈｒｉｆｔ框架的原由就是解决跨平台通信问题，所以Ｔｈｒｉｆｔ天生支持多种语言通信。既支持流行了很多年的开发语言Ｃ＋＋、ＪＡＶＡ、Ｃ＃等，也支持当前正在流行的Ｅｒｌａｎｇ、Ｐｙｔｈｏｎ、Ｒｕｂｙ等。Ｔｈｒｉｆｔ框架虽然在程序语言支持方面表现优异，但是它的静态编译技术也常常被人诟病。Ｔｈｒｉｆｔ框架需要先定义数据结构，然后使用Ｔｈｒｉｆｔ工具将数据结构转换成ＩＤＬ文件。这就意味着，如果某个数据结构发生了变化，必须重新编译生成ＩＤＬ文件，但是这个弱项并没有阻碍Ｔｈｒｉｆｔ成为流行的微服务通信框架。
完整的Ｔｈｒｉｆｔ框架包括一个客户端和一个服务端，首先用户需要自定义数据结构，然后使用Ｔｈｒｉｆｔ工具自动生成客户端和服务端代码，并且自动生成的代码中包含接口协议字段，以便客户端与服务端进行通信。在通信过程中Ｔｈｒｉｆｔ会将数据信息转换成高效的二进制字节来提高传输效率。服务器端会利用底层多线程、阻塞或者非阻塞协议来接收数据。具体采用哪种协议基于操作系统不同而不同。通过上面介绍可以发现Ｔｈｒｉｆｔ框架是客户端与服务端直接通信的，这就会导致以下问题。
１）服务的端口或者ＩＰ发生变化，调用方需要手动修改ＩＰ或端口；
２
）新启服务无法实现动态发现；３
）服务之间调用关系错综复杂，难以维护。针对以上缺点互联网领域通常将Ｔｈｒｉｆｔ与Ｅｕｒｅｋａ配合使用。Ｅｕｒｅｋａ是Ｎｅｔｆｌｉｘ开发的服务发现框架，本身是一个基于ＲＥＳＴ的服务，以达到负载均衡和中间层服务故障转移的目的。
Ｅｕｒｅｋａ是Ｎｅｔｆｌｉｘ开发的服务发现框架，其有两部分构成，即服务端和客户端。服务端主要提供用户服务注册功能与更新功能，即用户服务启动之后，会将自身服务信息注册到Ｅｕｒｅｋ
ａ的服务端中。每隔３０ｓ用户服务节点会发一次心跳到Ｅｕｒｅｋａ的服务端中，如果Ｅｕｒｅｋａ服务端连续多个心跳周期（一般为３个周期）都没有收到某个服务节点的心跳，那么Ｅｕｒｅｋａ服务端就认为该服务节点不可用，然后将其剔除。通过这样的机制Ｅｕｒｅｋａ的服务端就可以总览所有服务节点信息，并且快速识别可用的服务列表。Ｅｕｒｅｋａ客户端主要提供服务订阅功能和与服务端的连接封装管理
功能。即利用Ｅｕｒｅｋａ客户端上层应用可以使用服务名称与其他应用进行通信，而不用通过配置ＩＰ与其他应用进行通信。Ｅｕｒｅｋａ客户端还内置了轮询算法来实现负载均衡功能。Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ微服务框架如图１所示
。
图１　Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ微服务框架图
由图２所示，Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ框架的调用逻辑分为以下几步：
１
）在注册中心中配置服务端名称，在客户端中配置其需要订阅的服务名称；
２）服务启动之后，服务端将本地ＩＰ和服务信息发送给注册中心；
３）注册中心将服务端ＩＰ和服务发送给客户端；
４）客户端基于注册中心发来的消息，调用服务端的接口
。
图２　Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ框架调用图
１ ２　犇狌犫犫狅框架介绍Ｄｕｂｂｏ最早诞生于阿里巴巴，随后加入Ａｐ
ａｃｈｅ软件基金会，项目从设计之初就是为了解决企业的服务化问题，因此充分考虑了大规模集场景下的服务开发与治理问题，如易用性、性能、流量管理、集可伸缩性等。在Ｄｕｂｂｏ开源的将近１０年时间内，Ｄｕｂｂｏ几乎成为了国内微服务框架的首选框架，尤其受到大规模互联网、ＩＴ企业的认可，可以说作为开源服务框架，Ｄｕｂｂｏ在支持微服务集方面有着非常大的规模与非常久的实践经验积累，是最具有企业规模化微服务实践话语权的框架之一。采用Ｄｕｂｂｏ的企业涵盖互联网、传统ＩＴ、金融、生产制造业多个领域，一些典型用户包括阿里巴巴、携程、工商银行、中国人寿、海尔、金蝶等。
Ｄｕｂｂｏ作为一款微服务开发框架，它提供了远程服务调用与微服务治理两大关键能力。利用Ｄｕｂｂｏ提供的丰富
投稿网址：
  计算机测量与控制　第２９
卷
·２２２　·服务治理能力，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时Ｄｕｂｂｏ是高度可扩展的，用户几乎可以在任意功能点去定制自己的实现，以改变框架的默认行为来满足自己的业务需求，Ｄｕｂｂｏ框架如图３所示
。
图３　Ｄｕｂｂｏ框架调用图
自开源以来，Ｄｕｂｂｏ就被一众大规模互联网、ＩＴ公司选型，经过多年企业实践积累了大量经验。因此，Ｄｕｂｂｏ在解决业务落地与规模化实践方面有着无可比拟的优势：１）易用性高，如Ｊａｖａ版本的面向接口代理特性能实现
本地透明调用；
２
）功能丰富，基于原生库或轻量扩展即可实现绝大多数的微服务治理能力；
３
）高性能的跨进程通信协议；４）地址发现、流量治理层面，轻松支持百万规模集实例。
微服务注册中心有哪些
Ｄｕｂｂｏ提供了从服务定义、服务发现、服务通信到流量管控等几乎所有的服务治理能力，并且尝试从使用上对用户屏蔽底层细节，以提供更好的易用性。定义服务在Ｄｕｂｂｏ中非常简单与直观，可以选择使用与某种语言绑定的方式（如Ｊａｖａ中可直接定义Ｉｎｔｅｒｆａｃｅ），也可以使用ＰｒｏｔｏｂｕｆＩＤＬ语言中立的方式。无论选择哪种方式，站在服务消费方的视角，都可以通过Ｄｕｂｂｏ提供的透明代理直接编码。
点对点的服务通信是Ｄｕｂｂｏ提供的一项基本能力，
Ｄｕｂｂｏ以远程服务调用的方式将请求数据（Ｒｅｑ
ｕｅｓｔ）发送给后端服务，并接收服务端返回的计算结果（Ｒｅｓｐｏｎｓｅ）。远程服务调用对用户来说是完全透明的，使用者无需关心请求是如何发出去的、发到了哪里，每次调用只需要拿到正确的调用结果就行。同步的Ｒｅｑｕｅｓｔ－Ｒｅｓｐｏｎｓｅ是默认的通信模型，它最简单但却不能覆盖所有的场景，因此，Ｄｕｂｂｏ提供更丰富的通信模型：
１）客户端异步请求（ＣｌｉｅｎｔＳｉｄｅＡｓｙｎｃｈｒｏｎｏｕｓＲｅ ｑｕｅｓｔ－Ｒｅｓｐ
ｏｎｓｅ）；２）服务端异步执行（ＳｅｒｖｅｒＳｉｄｅＡｓｙ
ｎｃｈｒｏｎｏｕｓＲｅ ｑｕｅｓｔ－Ｒｅｓｐ
ｏｎｓｅ）；３）客户端请求流（ＲｅｑｕｅｓｔＳｔｒｅａｍｉｎｇ
）；４）服务端响应流（ＲｅｓｐｏｎｓｅＳｔｒｅａｍｉｎｇ
）；５）双向流式通信（ＢｉｄｉｒｅｃｔｉｏｎａｌＳｔｒｅａｍｉｎｇ
）
。Ｄｕｂｂｏ的服务发现机制，让微服务组件之间可以独立演进并任意部署，客户端可以在无需感知对端部署位置与ＩＰ地址的情况下完成通信。Ｄｕｂｂｏ提供的是Ｃｌｉｅｎｔ－Ｂａｓｅｄ的服务发现机制，使用者可以使用Ｚｏｏｋｅｅｐｅｒ作为服务发现组件。
Ｄｕｂｂｏ提供了包括负载均衡、流量路由、请求超时、流量降级、重试等策略，基于这些基础能力可以轻松的实现更多场景化的路由方案，包括金丝雀发布、Ａ／Ｂ测试、权重路由、同区域优先等。Ｄｕｂｂｏ强大的服务治理能力不仅体现在核心框架上，还包括其优秀的扩展能力以及周边配套设施的支持。
１ ３　犜
犺狉犻犳狋－犈狌狉犲犽犪框架与犇狌犫犫狅框架对比Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ需要使用ＡＰＩ（接口定义语言）定义一个文件，然后通过Ｔｈｒｉｆｔ来生成对应的各种语言的代码，
服务的提供者和消费者都需要把这个代码引入进去，服务端负责接口的实现，消费者使用ＡＰＩ的存根去直接调用提供者。目前Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ支持的语言比较多，比如常见的Ｃ＋＋、Ｊａｖａ、Ｐｙｔｈｏｎ、Ｒｕｂｙ、Ｃ＃、ＰＨＰ等。Ｔｈｒｉｆｔ属于Ｃ／Ｓ模式，它通过代码生成工具将接口定义的文件生成服务器端和客户端的代码，当然，服务端和客户端可以是不同语言的，从而实现了客户端和服务端之间跨语言的支持。传输的序列化也支持很多种，比如：二进制模式、压
缩模式、ＪＳＯＮ模式以及Ｄｅｂｕｇ模式，可以在开发的过程中使用Ｄｅｂｕｇ模式和ＪＳＯＮ模式来方便的看到传输的数据，在正式环境使用二进制模式或压缩模式来提升性能。在通讯模式上也支持很多种，它支持阻塞的Ｉ／Ｏ和ＮＩＯ，还有专门用来传输文件的传输方式。在线程模型上，它也支持很多种，比如简单的单线程模式、线程池模式、多线程使用非阻塞Ｉ／Ｏ模式。这样可以在不同的业务场景中使用更适合的技术来实现微服务调用。Ｔｈｒｉｆｔ并没有服务治理相关的功能，消费者只能使用服务提供者ＩＰ和端口号来进行访问，而Ｅｕｒｅｋａ具有服务注册与发现功能，需要将Ｔｈｒｉｆｔ和Ｅｕｒｅｋａ配合使用，来作为一个完整的微服务框架。Ｄｕｂｂｏ的消费者和提供者以及注册中心之间使用的是长连接，服务的消费者和提供者会在内存中累计服务调用的次数，并且定时将调用的信息发送到监控中心；消费者和提供者之间通信采用的是非阻塞Ｉ／Ｏ（即ＮＩＯ）；Ｄｕｂｂｏ的序列化使用的是阿里修改过的ｈｅｓｓｉｏｎ序列化方式，Ｄｕｂ ｂｏ是基于Ｊａｖａ来进行开发的，所以也支持ｊａｖａ的客户端和服务端。Ｄｕｂｂｏ具备完善的服务注册、服务订阅、通知以及监控功能。
总体而言，Ｄｕｂｂｏ作为一个完善的微服务框架，具备丰富的工具。但是它的缺点在于只支持Ｊａｖａ语言。Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ搭配使用也能作为一个完善的微服务框架，其具备的工具集合满足航天型号软件使用需求，而且其支持的语言非常丰富。综合比较下来，系统选择改造Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ微服务框架来适配航天型号软件。
投稿网址：
第１２期赵媛心，等：基于Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ
改进的微服务技术研究·２２３　·
２　犜犺狉犻犳狋－犈狌狉犲犽犪改进的微服务架构
结合引言中介绍的航天型号软件使用场景，即经常需要在不同场地进行试用，并且各个场地之间网络不通。如果型号软件部署需要１小时，但是微服务框架部署需要１天，那就是本末倒置了。针对这种情况，微服务框架改造的重点在于不增加使用难度的情况下，缩短部署时间。２ １　含有数据库的航天型号系统
结合上文中提到的改造目标，如果能够将注册中心和监控中心的功能进行转移，并且将客户端软件和服务端软件做成依赖包的形式嵌入型号软件中，那么就达到了在不增加使用难度的情况下，减少部署时间的目标。目前Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ的客户端软件和服务端软件可以作为依赖包嵌入型号软件。再分析一下注册中心和监控中心的功能，注册中心的功能主要是服务注册、服务更新通知和服务发现，监控中心的主要功能是客户端指标收集和服务端指标收集。１）服务注册：服务提供方将自身服务地址写入注册中心；
２）服务更新通知：当服务提供方ＩＰ或者端口发生变化后，及时通知客户端更新服务列表；
３
）服务发现：客户端读取注册中心中的服务列表；４
）客户端指标收集：客户端将调用成功次数、失败次数及耗时情况写入监控中心；
５
）服务端指标收集：服务端将调用成功次数、失败次数及耗时情况写入监控中心。
在原有数据库的基础上增加两张数据库表，就可以来承载注册中心和监控中心的职责，如图４所示
。
图４　包含数据库型号软件微服务框架
根据图４可知，包含数据库的型号软件微服务架构原理概述如下：
首先在原有数据库的基础上增加两张表，分别为服务注册表和服务健康统计表。服务注册表主要包括
服务提供方ＩＰ、端口、最近更新时间。服务健康统计表主要包括机器ＩＰ、端口、服务名称、调用次数、失败次数、类型（服务端、客户端）等。
然后修改服务端的服务注册逻辑，每隔３０ｓ更新一次服务注册表中的服务信息。
再次在原有客户端的基础上，基于ｇｕａｖａ的Ｌｏｃａｌｃａｃｈｅ构建一套本地缓存，每隔３０ｓ从数据库中获取一次服务提供方列表，并且将更新时间超过９０ｓ的服务剔除。并且基于客户端缓存的服务列表来实现负载均衡、流量路由、重试等策略等功能。
最后客户端和服务端都将服务统计数据上传到服务健康统计表中。
对照Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ的注册中心和监控中心，重新梳理了以下功能：
１）服务注册：服务提供方每隔３０ｓ将自身服务地址和服务器时间更新到服务注册表；
２）服务更新通知：客户端通过本地缓存每隔３０ｓ拉取一次服务注册表信息，来达到服务更新通知的目标；
３
）服务发现：客户端读取本地缓存的服务列表；４
）客户端指标收集：客户端将调用成功次数、失败次数及耗时情况写入服务健康统计表；
５
）服务端指标收集：服务端将调用成功次数、失败次数及耗时情况写入服务健康统计表。
２ ２　不包含数据库的航天型号系统
上一章节介绍了如何基于数据库改造Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ，下面介绍不利用数据库改造微服务框架的方法。即可以通过服务端发送广播本地服务消息的方式来实现注册中心的功能，客户端发送广播获取服务消息的方式来实现服务发现的功能，如图５所示
。
图５　不包含数据库型号软件微服务框架
根据图５所示，不包含数据库的微服务架构原理概述如下：首先服务端启动之后，在局域网内广播本地服务地
址和服务信息，其他服务器收到消息之后，判断该消息包含的服务信息是否是自己订阅的。如果是自
己订阅的，则更新本地服务列表。如果不是自己订阅的，则忽略这条广播消息。然后服务端每隔３ｍｉｎ广播一次本地服务地址和服务消息，其他服务器收到消息后处理逻辑与第一次收到消息处理逻辑一致。
然后客户端启动，在局域网内广播自己需要的服务地址，其他服务器收到消息之后，判断该消息包含的服务信息是否是自己提供的。如果是自己提供的，则将本地服务地址和服务信息发送给客户端。如果不是自己提供的，则忽略这条广播消息。
投稿网址：
  计算机测量与控制　第２９
卷
·２２４　·再次在原有客户端的基础上，基于ｇｕａｖａ的Ｌｏｃａｌｃａｃｈｅ构建一套本地缓存，主要存储服务地址和服务更新时间，并且将更新时间超过３ｍｉｎ的服务剔除。并且基于客户端缓存的服务列表来实现负载均衡、流量路由、重试等策略等功能。
最后客户端和服务端都将服务统计数据存储到本地日志中，方便后续定位分析问题。
对照Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ的注册中心，重新梳理了以下功能：１
）服务注册：服务提供方启动之后将自身服务地址和服务器时间广播给局域网内其他机器；
２）服务更新通知：服务提供方每隔３ｍｉｎ将自身服务地址和服务器时间广播给局域网内其他机器；
３
）服务发现：客户端读取本地缓存的服务列表。如果本地缓存列表为空，则广播发送获取服务消息。
２ ３　航天型号系统微服务框架使用模式
基于上述章节，航天型号系统微服务框架内置了两套使用模式。模式一针对包含数据库的型号系统，它具有可靠性高、问题排查方便的特点。模式二针对不包含数据库的型号系统，它具有依赖少，使用范围广泛的特点。系统会判断用户是否设置了使用模式，如果用户有自定义设置，则按照用户要求来使用系统。否则按照如下步骤自动启动框架。２．３．１　连接数据库
判断数据库能否连接成功，如果能连接成功，则跳转步骤２）。否则使用广播模式，如下所示：
１）服务端广播服务信息：服务端每隔３ｍｉｎ将本地服务信息广播给局域网内其他机器。
２
）客户端获取服务信息：客户端判断本地缓存的服务列表是否为空，为空则广播发送获取服务消息。
２．３．２　创建服务注册表
判断数据库中是否已经存在服务注册表。如果存在，则跳过。否则创建服务注册表。
２．３．３　服务端每隔３
０ｓ更新服务注册信息服务端每隔３０ｓ将本地服务地址和服务器时间更新到服务注册表中。
２．３．４　客户端每隔３０ｓ拉取服务注册信息客户端每隔３０ｓ从服务注册表中拉取服务信息，并更新本地缓存。
通过上述步骤可以得出，系统默认优先使用数据库模式，在数据库无法连接的情况则使用广播模式。
３　试验结果与分析
Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ改进的微服务架构主要解决的是航天型
号软件部署维护复杂的问题，为此设计了对照实验来比较原型Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ框架和改进的Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ框架的部署耗时。首先针对某航天型号软件Ａ，分别使用Ｔｈｒｉ
ｆｔ－Ｅｕｒｅｋａ框架构建系统Ｂ，使用改进的Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ框架构建系统Ｃ。
从开发组、测试组和运维组总共抽取了４５名同事，将这４５名同事随机分成５个队，每队９人，包括３名开发、３
名测试和３名运维同事。
每队需要同时部署系统Ａ、系统Ｂ和系统Ｃ。耗时情况如表１所示。
表１　系统部署耗时比较
ｓ
部署耗时实验队１实验队２实验队３实验队４实验队５平均耗时系统Ａ１１．５１．１５２１．７５１．４８系统Ｂ１．５２２２．７５２．５２．１５系统Ｃ
１．０５
１．５
１．２
２
１．８
１．５１
从表１中可以看出部署系统Ａ和系统Ｃ的耗时基本相同，这符合实验预期。因为改进的Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ框架构不需要额外部署软件，实验队员部署系统Ａ和系统Ｃ的步骤基本相同。但是部署系统Ｂ的耗时明显增加，这是因为除了部署基础的型号系统Ａ之外，还需要部署配置Ｔｈｒｉｆｔ
－Ｅｕｒｅｋａ框架。
４　结束语
首先介绍了航天型号软件开发框架遇到的问题，分析了航天型号垂直应用框架和微服务框架的优缺点，着重介绍了目前互联网领域流行的微服务框架Ｔｈｒｉｆｔ－Ｅｕｒｅｋａ和Ｄｕｂｂｏ
。接着描述了互联网领域的微服务框架适配航天型号软件领域遇到的问题。然后基于微服务框架思想和Ｄｕｂｂｏ微服务框架，提出了一种适用于航天型号软件领域的微服务框架。该服务框架有两种使用模式：一种适用于包含数据库的型号软件系统；另一种适用于不包含数据库的型号软件系统。针对
有数据库的型号软件系统，利用数据库系统来实现微服务框架的注册中心功能。针对没有数据库的型号软件系统，利用广播协议、本地日志来实现微服务框架注册中心功能。经在某项目中实践后可见，该方案能够实际解决航天型号软件微服务框架使用的问题。
参考文献：
［１］吴　洲．基于Ｔｈｒｉｆｔ的跨编程语言Ｆｌｅｘ应用框架研究［Ｊ］．计
算机与现代化，２０１３（５）：１８１１８５．
［２］梁明炯．基于Ｔｈｒｉｆｔ框架的数据交换方案［Ｊ］．科技创新与应
用，２０１５（１３）：６６６７．
［３］张　晶，黄小锋，李春阳．微服务框架的设计与实现［Ｊ］．计
算机系统应用，２０１７，２６（６）：２５９２６２．
［４
］洪华军，吴建波，冷文浩．一种基于微服务架构的业务系统设计与实现［Ｊ］．计算机与数字工程，
２０１８，４６（１）：１４９１５４．［５
］龙新征，彭一明，李若淼．基于微服务框架的信息服务平台［Ｊ］．东南大学学报（自然科学版），２０１７，４７（ｚ１）：４８５２．［６］ＣＩＵＦＦＯＬＥＴＴＩ，ＡＵＧＵＳＴＯ．Ａｕｔｏｍａｔｅｄｄｅｐｌｏｙ
ｍｅｎｔｏｆａｍｉ ｃｒｏｓｅｒｖｉｃｅ－ｂａｓｅｄｍｏｎｉｔｏｒｉｎｇｉｎｆｒａｓｔｒｕｃｔｕｒｅ［Ｊ］．ＰｒｏｃｅｄｉａＣｏｍ ｐ
ｕｔｅｒＳｃｉｅｎｃｅ，２０１５，６８：１６３１７２．［７］ＶＩＬＬＡＭＩＺＡＲＭ，ＧＡＲＣＥＳＯ，ＣＡＳＴＲＯＨ，ｅｔａｌ．Ｅｖａｌｕａｔｉｎｇ
ｔｈｅｍｏｎｏｌｉｔｈｉｃａｎｄｔｈｅｍｉｃｒｏｓｅｒｖｉｃｅａｒｃｈｉｔｅｃｔｕｒｅｐａｔｔｅｒｎｔｏｄｅ ｐｌｏｙｗｅｂａｐｐｌｉｃａｔｉｏｎｓｉｎｔｈｅｃｌｏｕｄ［Ｃ］／／ＣｏｍｐｕｔｉｎｇＣｏｌｏｍｂｉａｎＣｏｎｆｅｒｅｎｃｅ，ＩＥＥＥ，２０１５：５８３５９０．
［８］ＳＵＲＹＯＴＲＩＳＯＮＧＫＯＨ，ＪＡＹＡＮＴＯＤＰ，ＴＪＡＨＹＡＮＴＯＡ．
投稿网址：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。