天津众齐软件股份有限公司 天津 300385
摘要：科技迅猛发展的同时，我国的各行各业的发展也有了进步。系统的可扩展性是构建现代软件系统的一个重要课题，微服务架构通过将功能分解到多个独立的服务，以实现对解决方案或者复杂系统的解耦，该文提供一种基于微服务架构动态扩展软件功能的方法。
关键词：面向；微服务软件开发；方法研究进展
引言
软件测试模式是影响微服务架构使用价值的关键，该文首先对微服务开始之前的软件测试状态进行了研究分析，并且结合优化软件资源使用质量的实际需要，对软件测试模式的优化处理方式进行了分析处理，对有效的优化微服务架构的应用质量，具有十分重要的意义。
1概述
微服务架构（Micro Service Architecture）是近年来软件体系架构领域出现的一个新名词，它通过将功能分解到多个独立的服务，以实现对解决方案或者复杂系统的解耦，其根本理念是将大型、复杂且历时长久的应用在架构上设计为内聚的小服务，这些服务能够随着时间的流逝而演化。
软件在运行时动态扩展功能的方法一般有以下几种方式：
1）插件方式。首先定义统一接口，基于Liskov替换原则，对扩展点进行扩展，然后加载动态库。如Java的OSGI框架和著名的Eclipse IDE都属于此类扩展方式；
2）打补丁的方式。在运行时动态更换指针所指的函数，如C/C++语言在通信产品上，一般采用打热补丁的方式修复系统错误，也是运行时扩展功能的一种方式；
3）语言层级的自然支持，如Erlang语言的Hot Code Swapping特性支持在运行时替换模块代码，从而实现功能扩展；
4）配置文件。通過在运行时修改配置文件，可以在一定程度上扩展软件处理业务的范围，但在功能扩展的范围也被限制在某种可配参数范围内，无法加载其他新功能。
软件扩展功能的方式很多，有些语言（如Go语言）只支持引用静态代码直接编译，不支持链接静态库和生成、加载动态库。这样在运行时就无法通过更换动态库文件来扩展功能。
2传统软件测试模式的局限性
1）AB测试的技术局限性
AB测试的实施在测试工具方面具备一定的特殊性，很多测试工作必须在测试技术方面无法进行软件产品的质量控制，无法保证产品质量的维护工作可以有效地顺应测试技术的发展要求，难以使软件测试技术的发展能够有效的促进工具附带价值的优化。另外，AB测试工作的执行可以在短时间内使用模拟方式进行多种技术性请求的处置，在这样的情况下，模拟访问技术的优化处理可以对AB测试技术实现局限性因素的合理控制，但是，很多访问效率的控制工作难以凭借AB测试的压力特点进行压力访问情况的分析，造成AB测试的局限性问题很难凭借系统资源直接操作的方式完成与命令输出体系的对接，导致AB测试的压力特征很难得到测试工具的简洁性支持，导致一些系统环境的操作工作难以对软件测试的模式进行进一步的推导处理，只能简单的借助输入命令进行测试应用，无法使软件测试技术得到模拟测试资源的支持。
2）Jmeter测试的技术局限性
在进行jmeter测试响应情况分析的过程中，很多测试技术的操作都需要得到响应时间因素的有效支持，如果响应时间难以凭借毫秒的基础性技术基础进行处理，则很难结合单纯的响应时间实现对技术局限性的有效分析。另外，一些单纯的桌面应用技术难以适应开放源代码的特别需求实现对项目工具价值的有效分析，还有一些测试工作对象处理技术难以凭借数据库查询系统的要求实现与jmeter测试技术的应用，并且在术语因素的有效带动之下与技术局限性的优化分析需求保持一致，难以保证数据的概念特征可以在开放源代码的性能研究方面与术语的使用需要相适应，无法有效的保证线程因素可以在测试技术因素的优化配置之下，适应测试技术的优化配置需求，无法保证取样器的技术资源能够在这一过程中与显示器实现技术对接。
3应用措施分析
3.1微服务与容器
在容器技术出现之前，微服务通常需要独自或者共同部署在多台应用服务器或多个虚拟机上，微服务之间通过标准的通信接口实现访问。这样做的好处是当一个微服务出现问题时，并不会影响到其他的服务。而且，微服务可以基于资源的需求进行独立扩展，可以被部署在更小的主机上。各个微服务使用的开发语言也可以不同，只要保持接口协议统一。
然而，不容忽视的是，当微服务部署在多个主机上，大量微服务的管理也成为一个难题。另外，假如微服务是由不同程序语言开发的，那么实际部署时需要加载各自的库，从而增加了部署的复杂性，为了解决这一问题，容器技术应运而生。类似Docker容器技术等借助Namespaces及Cgroup等内核接口，实现了不同容器间的隔离；不同容器还可以共享同一内核。
目前流行的Linux容器主流方案是Docker和Rocket。Docker在实现时有一个libcontainer模块，此模块把相关的库程序、用户交互接口标准化；同时还为所有的容器镜像一个官方的资源库DockerHub。DockerHub类似于GitHub，简化了Docker容器共享和发布的流程。基于Docker的所有容器是部署在同一主机上的，因此避免了不同语言开发环境使用不同库文件的部署问题。另外，借助Docker的DockerFile还能够解决不同开发语言、不同框架以及不同库文件间的依赖性。
将微服务应用放置在容器中，带来了快速与可移植性。从开发、测试、上线，实现了“一次编写，到处运行”。
总之，通过容器、微服务的有效结合应用，最终帮助企业应用演进到互联网架构，实现IT投资和收益的最优化。
3.2基于微服务的终端软件架构
以软件定义终端，所有终端的功能通过容器APP的方式实现，同时智能终端设计可裁剪的统一操作系统，屏蔽硬件的多样化差异，为所有终端提供底层运行环境。操作系统各层级间统一数据接口，使用容器技术对业务功能APP与底层系统的硬件资源做隔离，确保系统整体功能不受影响，同时可根据业务实际进行容器内APP资源权限合理分配，有效控制单一APP故障的影响范围。
使用微服务架构进行设计，将容器分为基础服务容器和高级业务容器。基础服务容器提供终端基础业务功能的抽象，如电表、电力物联网传感器、脉冲量和交采模拟量等数据的高频采集和存储，高级业务容器通过调用基础服务容器提供的服务接口，获取所需数据，从而实现高级业务功能如电能质量监测和分析等。
3.3自动发现服务方式
自动发现服务方式如图4所示，相比人工配置服务方式，自动发现服务增加了“扫描注册”和“全局名字”两个服务。
1）业务功能微服务a和b启动以后，扫描注册服务通过实时扫描消息1和2，发现当前启动的微服务，将其信息通过消息3发给 全局名字服务 缓存；
2）全局名字服务 通过消息4将当前最新的微服务信息发送给 转发代理服务，生成其配置文件；
3）转发代理服务收到功能微服务a发送的请求消息5以后，根据目标服务信息匹配和转发规则，以消息6转发给微服务模块b进行处理；
4）根据业务功能需求形成增强的功能微服务b’，并正常部署启动运行；
5）周期扫描注册服务实时发现新启动的功能微服务b’，并将其信息通过消息8发送给全局名字服务；
6）全局名字服务在收到消息8以后更新本地服务缓存，并通过消息9通知转发代理模块，并更新其配置文件；
7）转发代理模块收到消息10时，可以根据当前的最新目标信息匹配和转发规则，经消息11’将其转发给功能微服务b’，从而实现业务功能自动扩展。
结语
采用本文方法，可以让不支持运行时加载动态库的语言达到动态扩展功能的目的，并且在扩展功能或软件升级过程中不中断原有服务，在提高软件系统可扩展性及可用性上取得明显成效。
参考文献：
[1]王晶晶.基于Android平台的青岛移动渠道经理管理系统的设计与实现[D].济南：山东大学，2015.
[2]李秋雯.基于web的高校技能培训与认证管理系统的设计与实现[D].成都：电子科技大学，2015.