毕业设计网站可以做什么,网站设计中的js,天津建设银行招聘网站,北京自动seo微服务技术发展的现状与展望
人工智能技术与咨询
来源#xff1a;计算机研究与发展#xff0c;作者冯志勇等
摘 要 随着云计算、物联网等技术迅速发展#xff0c;用户对软件系统的需求趋于多样化#xff0c;面向服务的体系架构(service oriented architecture, SOA)需要…微服务技术发展的现状与展望
人工智能技术与咨询
来源计算机研究与发展作者冯志勇等
摘 要 随着云计算、物联网等技术迅速发展用户对软件系统的需求趋于多样化面向服务的体系架构(service oriented architecture, SOA)需要在服务稳定集成与需求灵活适配之间寻求平衡.基于此拥有独立进程、具备独立部署能力的微服务技术应运而生它具有分布式存储、高可用性、可伸缩性、运维智能化等优势能够弥补传统SOA的缺陷.首先,从系统集成角度的出发阐述微服务出现的应用背景利用微服务的核心组件、软件技术发展、架构演化等基础技术以保证微服务基础设施的可用性其次基于微服务体系架构在实际应用中的问题从分布式通信、分布式数据存储、分布式调用链、测试的复杂性等方面分析微服务体系架构具体应用中采用的关键技术并给出具体应用案例以保证微服务的技术可行性最后从基础设施、信息交互、数据安全与网络安全等方面探寻微服务所面临的诸多挑战并分析未来发展趋势分析以期为微服务未来的创新和发展提供有价值的理论与技术参考. 随着云计算、物联网、服务计算等技术快速发展社会生产生活对软件系统的需求量与日俱增用户需求的多样性、个性化趋势日趋凸显.为了满足不断演化的用户需求许多软件企业开放其软件产品线允许上下游相关企业、外部开发者甚至用户参与到软件开发维护工作之中进而有效加快软件产业的垂直分工和水平整合促进了软件生态系统(software ecosystems, SECO)[1]的丰富和完善.
随着软件功能不断扩展、用户负载量逐渐增长等发展问题软件生态系统中模块与组件之间的调用依赖关系也变得越来越复杂.在这种背景下新组件的引入与迭代、数据的快速更新无疑会造成软件生态系统的不稳定、不平衡.为了确保系统满足高可用、高并发的要求系统架构需要根据用户需求合理配置资源以保证资源利用率最大化.具体而言从系统集成的角度软件生态系统的演化过程可以大致分为3个阶段各阶段特点如图1[2]所示.
1) 点对点集成
点对点集成阶段通常产生在系统发展初期其演化和扩展的方式为1对1集成.在企业应用系统个数较少的场景下系统通过提供的对应接口实现系统间的数据传输.当应用系统数量达到一定程度时系统间的接口众多会导致大量重复开发和联调工作接口的开发难易程度和维护成本会随之增大.因此整个软件生态系统的扩展能力较弱其演化方式也显得笨重且僵硬.在此种情况下面向服务体系架构(service-oriented achitecture SOA)[3]的集成理念应运而生.
2) 平台集成
SOA是一种软件系统的设计方法以松耦合的方式将应用系统的不同服务功能进行拆分通过服务之间定义良好的接口实现服务集成.SOA理念[4]的出现使企业开始从整体角度看待IT(information technology)架构的建设更加强调自上至下的整体架构.同时企业服务总线(enterprise service bus ESB)[5]的兴起为服务整合提供行之有效的解决方案ESB在数据集成、应用集成、流程集成、门户集成等方面具有独特的优势可以有效地简化IT系统结构提高系统的灵活性和可扩展能力.
3) 互联网集成
随着移动互联网与互联网的发展原有的SOA体系架构遇到了4个问题①缺乏有效的服务治理服务资产混杂不清没有有效的服务管控手段②业务支撑响应慢系统尾大不掉无法做到实时更新和模块化发布③系统可用性差无法做到7×24 h无间断提供服务④创新业务难以支撑特别是带有互联网特点的创新业务.
基于此开发人员以体系结构优化为出发点提出了基于微服务的SOA体系架构[6]其核心理念是将复杂的应用系统以独立业务单元的形式分解为多个服务每个服务可以采用不同的实现技术以轻量级、更灵活的模式进行独立设计、开发、部署运行于独立的进程中形成高度内聚的自治单元[7]. 具体而言SOA把系统划分成不同的服务使用接口进行数据交互服务之间通过相互依赖、有效整合以达到系统的整体功能[8].而在体系架构方面微服务架构是基于SOA架构基础上的改进并且融入组件化思想与领域建模思想.首先系统被拆分为多个微服务以松耦合的方式被独立部署其次每个微服务仅需高质量地完成本身任务且每个任务代表着一项细粒度业务能力由此各项业务被彻底的组件化和服务化[9]最后提供领域服务能力的模块在底层微服务架构中实现服务的组合和组装.如图2(a)所示整体架构将所有软件功能放在一个进程中由多个服务器共同支持运行计算任务最后将运行结果返还给用户而微服务架构(图2(b))将软件整体功能分解成多个服务分别由不同类别的服务器进行支持然后将数据反馈给数据库用户可以从数据库中获取数据既加快了系统的整体响应速度又满足互联网化环境下前后端分离的业务需求.由此可见微服务体系架构的优势[10]主要体现在分布式(物理部署、服务部署、数据存储)、高可用(分布式架构、集群化部署、服务自动注册)、可伸缩(按需分配资源)、运维智能化等方面.
随着软件系统功能的日益扩展复杂化基于微服务的SOA架构开始日益兴起.具体而言微服务在前台支撑业务的快速响应与个性化是采用面向服务开发的SOD(service-oriented development)具有开发快速、响应及时、易于实现等特点[11]ESB服务总线作为后端支撑各系统、技术、平台的集成而面向服务的基础设施(service-oriented infrastruc-ture, SOI)[12]具有稳定、高度集成等特点.微服务技术与ESB技术二者相辅相成分别在SOA架构中发挥不同的核心作用以期达到软件系统的自服务效果.
本文首先以系统集成角度阐述微服务出现的特定背景并逐渐深入探讨微服务核心组件以及微服务技术与架构发展其次详细介绍近年来微服务系统所采用的关键技术最后对微服务所面临的挑战与未来发展趋势进行了分析.
1 微服务的核心组件
根据Lewis等人[13]的阐述软件架构研讨会(Seminar on Software Architecture)于2014年5月首次定义了“微服务”这一术语用来表示诸多学者一直探索的系统共同架构方法.此前部分学者已经使用不同的方法实现了该框架.例如亚马逊公司Vogels等人[14]将该种架构方法描述为“将直接操作数据的业务逻辑来封装数据通过已发布的服务接口进行唯一访问”Netflix公司Cockcroft[15]将其定义为“松散耦合的面向服务的体系结构与有限制的信息交换”.工业界中相关概念有“fine-grained SOA”和“SOA done right”等方法.
从字面去理解微服务即什么是“微”、什么是“服务”“微”狭义上来讲就是体积小、架构小而服务区别于整体系统的概念是一个或者一组相对较小且独立的功能单元是用户可以感知到的最小功能集每个微服务具有自己的轻量处理和通信机制并且自动化部署在单个或多个服务器上.其中微服务概念来源领域驱动设计(domain-driven design, DDD)[16]即是一种基于模型的开发方法由有限组织环境和持续软件集成等原则进行指导.该设计统一了分析和设计编程使得软件能够更灵活快速跟随需求变化.解决了分布式Web规模应用程序(FacebookSpotify等)中存在的挑战以及大型科技公司面临的组织问题.
微服务为分布式软件系统提供了良好的解决方案.与传统面向服务体系结构的实施方案相比微服务体系结构除了提供服务注册与发现服务组合等基本组件外还加入了负载均衡、服务网关和容错机制等同时对已有模块进行了扩展和优化图3是对微服务框架相关元素[17]及元素内容的具体展示.将结合图3从5个方面介绍微服务核心组件. 1.1 服务发现机制与注册中心
微服务遵循轻量级通信原则单个微服务一般部署在轻量级容器如Docker中.然而在运行过程中服务实例随时可能被销毁、克隆或者重新定位由此服务实例在动态变化中创建一种服务发现机制有利于服务之间感知彼此的存在.其中服务注册中心[18]是服务发现机制中重要的一环即服务启动时会将自身的网络地址与数据提交到注册中心并订阅自己需要消费的服务.
服务注册中心是服务发现的核心必须具有高可用性和实时更新功能主要存储服务提供者和消费者的统一资源定位器(uniform resoure locator URL)地址及路由转发信息实现服务注册、发布、健康检查和故障检测等功能.表1对目前较为流行的服务注册中心进行了分析与归纳.其中在Key-ValueKubernetesCloud Foundry等应用平台中使用的Etcd具有分布式、高可用性以及强一致性特征适合于少量数据的情形.而由Google公司开发和维护注册中心Consul功能更为全面作为一个用于发现和配置的工具Consul提供了允许客户端注册和发现服务的API而其提供的服务健康检查可以帮助确定服务可用性.此外具有高协调能力的Zookeeper在分布式系统中应用较为广泛[19]通过提供统一命名服务、集群管理、状态同步、分布式应用配置与管理等功能解决了分布式系统中数据一致性问题.
Table 1 Service Registry Comparisons 表1 服务注册中心比较 1.2 负载均衡
为了保证服务具有高度可用性微服务需要部署多个服务实例来提供业务支持当请求面对同一服务的多个实例如何合理选择服务实例以减少业务等待时间成为一个亟待解决的问题由此负载均衡可以分为客户端负载均衡与服务端负载均衡以选择合理的服务负载均衡策略.
负载均衡具有多种实现算法其中应用最广泛来自著名的Round Robin算法即轮询法[20]其基本思想是将多个可用服务实例组织成一个循环队列然后根据实例顺序轮流分配给内部的服务器从1到N(N个服务器)依次循环该方法适用于基本配置相同的服务且服务平均请求相对均衡的情境然而在面临性能方面差异较大的服务实例时一般采用加权轮询法[21],即根据服务器的不同处理能力给每个服务器分配不同权重响应具有相应权值数的服务请求该均衡算法可以提升高性能服务器的利用率降低低性能服务器负载过重的概率避免负载不均衡的情况.但在实际应用中客户端每一次请求服务服务器响应时间都具有较大差异因此若采用简单轮询或随机均衡算法并不能达到真正的负载均衡.鉴于这一缺点可采用最小连接数算法(least connections scheduling, LCS)[22]该算法记录当前服务器可负载实例数量以及该服务器正在处理的进程数量具体而言当产生新服务连接请求时将把当前请求分配给连接数最少的服务器以提升服务实例利用率以及服务器负载能力.
微服务架构均支持以上负载均衡算法.与传统整体架构负载均衡不同的是传统整体架构使用负载均衡器分发高并发的网络请求[23].在微服务架构中,服务端的软件模块维护一个可用的服务端清单客户端节点也需维护本身所访问的服务端清单而这份服务端清单来自于(微服务架构中独有)服务注册中心例如Eureka服务注册中心同时客户端需要维护服务端清单的健康性也需与服务注册中心配合完成[24].其中SpringCloud Ribbon是微服务架构中基于客户端的负载均衡工具将面向服务的REST(representational state transfer)模板请求自动转换成客户端负载均衡的微服务调用[25].
此外微服务架构支持的负载均衡算法还包括随机分配服务器算法、生成请求源IP Hash值方式精确找到服务器的IP Hash算法等相关算法.这里不再一一赘述.
1.3 服务容错
容错即将系统错误产生的影响限制在一定边界内.在微服务体系结构中调用集群服务时若单个微服务调用异常产生如连接超时、请求失败、流量突增或负载过高等问题则需要制定容错策略进行容错处理使微服务具有自我恢复功能.
服务容错分为2种情况1)若产生超时异常可采用超时重试机制[26]通过设置服务请求超时响应时间或者服务的响应时间和次数进而决定是否采用超时重试机制.2)若服务因负载过高引起异常可采用限流和熔断器2种容错策略.其中限流是以限制服务的最大访问量或者访问速率的方式对服务进行容错处理熔断器会记录和监测服务执行情况若监测到某个服务实例超过阈值可拒绝接收服务请求将其直接返回.目前微服务框架支持的容错策略还有控制并发、线程隔离等策略如果连续失败多次则直接熔断不再发起调用避免单个服务异常影响系统中整体服务的运行.
1.4 服务网关
服务网关(service gateway)作为微服务架构中的重要组件其关键思想是将轻量级网关作为所有客户端/消费者的主要入口点并在Gateway(网关)级别实现常见的非功能需求.服务网关的基本功能有统一接入、安全防护、协议适配、流量管控、长短链接支持、系统容错能力等.目前已有许多成功的应用案例.例如由Netflix公司开发的Netflix Zuul[27]是目前较通用的服务网关组件其主要作用是协调客户端与微服务的中间层提供权限验证、压力测试、负载分配、审查监控等较为全面的服务网关功能.其中Zuul主要负责处理RESTful的服务请求及调用.然而在部分微服务业务场景下,仍存在“外部客户端是RESTful的接口请求,而内部服务之间却是RPC通信”的情况.因此产生同一系统具有2套不同类型的API接口无疑增加了通信的复杂度.由此GRPC Gateway通过读取GRPC服务请求并为其生成反向代理服务器,将RESTful的HTTP/JSON API接口转化为内部GRPC的形式,从而解决了服务内外接口不兼容这一问题[28].其他网关解决方案这里不再赘述.
1.5 服务部署和服务通信
作为微服务框架核心部件之一微服务部署和服务通信具有至关重要的作用.微服务部署中关键问题之一是如何做到独立于其他微服务部署使每个微服务级别都可以进行部署与扩展.从而在单个微服务的故障不影响任何其他服务前提下快速构建和部署微服务Docker[29]作为一种开源应用容器引擎以应用打包以及依赖包到一个可移植容器中的方式达到上述功能需求.其具体理念是将每个服务实例部署为容器微服务作为Docker容器镜像打包根据容器实例数量变化进行缩放.在Docker容器部署过程中使用Kubernetes应用平台组件将一组Linux容器作为单个系统进行管理在多个主机上管理和运行Docker容器根据容器的部署位置进行服务发现和复制控制等机制以期对Docker功能进行扩展与伸缩.基于此种方式构建、部署和启动微服务的速度将会大大提升.其中Kubernetes技术为Docker容器部署微服务提供了强有力的支持. 服务通信是指网络传输过程中服务之间进行信息交互或消息传递.其关键是保证具有良好的通信机制实现准确、高效的信息交换.在微服务框架中微服务通信方式分为同步和异步2种模式.在同步通信模式下客户端发出请求服务器即时响应.这种通信模式实现较为简单没有中间件做代理一般采用REST和Thrift两种协议.其缺点是通信机制较为单一制约了进程的速度在一定程度上降低了系统的可用性.在异步通信模式中客户端请求不会阻塞进程服务端中响应可以是非即时.其优点是实现了客户端与服务器之间的松耦合通过中间件进行消息缓冲实现灵活交互提高了系统可用性缺点是基于请求/响应交互模式的复杂性大大提高为开发人员带来大量额外工作.在主流系统框架中一般采用同步、异步混合通信模式以提高系统可伸缩性以及系统可用性.
2 微服务技术的发展过程
从微服务最初定义到逐步被软件系统平台应用微服务技术在不断发展进步以适应平台中数据量大、更新迭代快的特点.下面以微服务软件技术发展与微服务架构发展2个方面揭示微服务技术的不断演变.
2.1 微服务软件技术发展
早期微服务应用程序受到新一代软件开发、部署和管理工具的影响较大.然而随着微服务架构应用越来越广泛管理工具不断发展创新目前微服务可以支持更庞大、更加多样化的用户数据群.图4显示了10种“waves”软件技术发展的时间表[30]其中包括应用较为广泛的工具这些工具在过去10年中极大地影响了微服务应用程序开发、部署和运行等方面.
在“微服务”概念提出之前业界已经诞生5次相关新技术[30].
1) 轻量级容器(lightweight container engine)技术(例如LXC和Docker)允许在系统运行时有效地对各个服务打包、部署和管理.
2) 服务发现(service discovery)技术(例如Eureka和Consul)允许服务彼此通信而无需明确地参考服务网络位置.
3) 监控(monitoring)技术(例如Graphite和Sensu)能够在不同层次程度上监控和分析微服务资源的行为.
4) 容器编排(container orchestration)技术(例如Mesos和Kubernetes)自动化分配容器和管理任务开发人员从底层架构中抽象出底层物理或虚拟基础架构为开发人员提供一个抽象层以确定应用程序部署在服务器以及数据中心中.
5) 建立延迟和容错(default tolerance)通信库(例如Finagle和Hystrix)使服务进行更有效地执行更可靠地通信.
后5次系统软件管理方法的提出为微服务系统实施提供了底层技术支撑.
6) 包括持续交付(continuous delivery)技术(例如Ansible和Drone)即指通过软件自动化的方式快速迭代发布软件允许团队频繁地交付快速更新的软件产品.其特征是持续整合、内置测试、持续监控和分析反馈.为系统提供了通用集成的解决方案[31]并且在Web级微服务生产环境中已经进行DevOps实践.
7) 混沌工程(chaos engineering)技术(例如Simian Army和Chaos Toolkit)[32]可自动解决系统中出现的故障具有高可靠性与高可用性等特性.
8) 边车(sidecar)技术(例如Prana和Envoy)[33]封装与通信相关的功能.例如服务发现以及特定协议和容错通信库的使用功能使服务开发人员快速获得通信消息.
9) 包括“无服务器”计算(serverless computing)技术(例如AWS Lambda,OpenWhisk,Amazon Web Services)[34]实现了“功能即服务”(functions as a service FaaS)云模型.这种模式允许云用户开发、部署及交付更精细的服务功能而无需创建和管理(如应对不一致的流量模式)复杂基础模块执行所需的资源.
10) 服务网格(service mesh)技术(例如Linkerd和Istio)[35]以边车技术为基础提供完全集成的服务通信监控.
图4中大部分工具都源于工业应用领域.作为开源项目提供给用户下载与应用.其中表2给出了每个工具的URL网址[30].
Table 2 The Web Site of the Microservice Tool in Figure 4 表2 在图4中微服务工具的网址(URLs) 2.2 微服务架构的发展
在工业应用中一个完整的微服务架构由多个元素构成它具有独立的生态圈不但需要基础设施配合还需生产环节部门共同协作不但在系统运行时进行管理控制而且还要具有安全保障的服务治理.其中微服务治理从4个步骤[36]进行1)请求网关.常用有Zuul,Spring Cloud Gateway等组件.2)信息采集.具有服务注册发现、服务日志、链路追踪等功能.3)信息分析.具有时序性统计、监控平台以及监控报警等功能.4)治理策略.具有负载均衡、请求限流、服务容错与服务配置等功能.在传统微服务架构中可能需要链接不同的容器和主机以使多个微服务共同协作[37]完成一项业务.在此种架构中若使用传统的日志定位出现问题的容器和主机不仅会耗费大量的人力与物力而且可能导致系统运行失误.
在此种情境下需要在技术层面提供分布式调用链跟踪能力以能够快速定位出现问题的节点.同样在微服务架构中原来整体式系统分解成多个微服务在此种情况下传统的逐步式部署方式已不再适合.自动化部署方式成为软件系统所面临的必然选择.此外出于服务治理和系统安全考虑需要对分散的微服务进行集中管控,因此服务网关也是必不可少的组件.这些组件构成是由微服务特点所决定的.具体而言微服务架构生态图[38]如图5所示.同时由图5中微服务相关技术逐步发展这些技术革新的影响在微服务应用程序架构发展中有明显体现. 图6概括了4代微服务体系架构[30].其中在第1代结构中如图6(a)所示使用轻量级容器技术(如LXC)打包每个服务然后使用容器编排工具(如Mesos)在运行时进行部署和管理.每个服务都负责跟踪其他服务的位置并且根据特定的通信协议调用其他服务任何故障处理机制(例如重试和回退)都直接在服务的源代码中产生深远的影响.随着应用程序中服务数量的增加应对不同执行环境中部署和重新部署服务日益增长的需求调用正确的服务实例成为一个难题.此外新服务的实现语言不尽相同因此重用现有代码以及快速有效地处理故障变得愈加困难.
为解决上述问题第2代引入了服务和可重复利用的容错通信库如图6(b)所示服务使用公共发现服务(例如Consul)来注册其提供的功能.客户端服务可以动态发现和调用这些功能而无需明确被调用服务的位置.在服务调用期间所有特定协议和故障处理功能被委托给相对应通信库例如Finagle该策略不仅简化了服务实现和测试还允许跨服务重复利用的样板通信代码.
然而随着通信库功能愈加复杂利用不同编程语言对通信功能重新实现变得越来越困难.开发人员经常被迫使用当前程序编程语言来实现新服务无疑增加服务接口的难度.由此微服务可以使开发人员自由编写程序开发人员可以自主选择任何编程语言或以适合特定服务的需求选择相对应开发编程语言这是之前技术所不具备的优点.
因此第3代引入标准服务代理或sidecars边车模式如图6(c)所示例如Envoy作为可检测的服务中间体.基本思想是通过边车封装所有服务发现和通信功能从而提高软件可重用性.由于每个边车都是一个独立的服务因此该策略将现有容错通信库的优势带到新的编程语言从而大大提高了自主开发性.
当作为网络中介时边车成为监控微服务应用程序中所有服务信息交互行为的场所.这些工具扩展自包含边车理念以提供更加集成的服务通信解决方案.应用运营商可以集中控制平面动态监控和管理多个分布式边车的行为.基于此种方式运营商可以对各种服务及服务通信功能进行更加细粒度的控制包括服务发现、负载平衡、容错、消息路由和安全性等功能.
第4代旨在将微服务应用程序引入一个全新的应用领域如图6(d)所示基本思想是利用最新的FaaS技术和无中断计算技术简化微服务底层开发和持续交付[39]操作.这种无服务器架构其基本思想是将微服务应用程序变成“短暂”函数的集合每个函数根据特定需求进行快速、创建、更新、替换和删除等操作从而极大地提高微服务的运行、部署等操作效率.当然这种无服务器架构仍然需要以通信为中心的技术,例如边车技术和服务网格.现有FaaS平台并未提供融合2种技术的通信和流量管理功能.因此若在无服务器应用程序中创建函数到函数的交互一个具有更全面控制功能的服务(或功能)网格应被创建以便监控和管理这些边车功能的行为.
3 微服务关键技术
微服务强调服务功能的大小但在实际应用中并没有统一标准.一个功能相对简单的微服务在实际需求与扩展中会变得更加复杂并且同一业务由多个微服务共同协作完成.由此微服务存在3个问题1)在分布式协作方面存在微服务之间通信、分布式数据存储一致性等问题2)在微服务定位方面如何快速定位出现的性能瓶颈.3)在测试方面众多的微服务如何协调一致保证测试的准确性.基于这3个问题微服务的顺畅运行主要采用一些关键技术.
3.1 微服务分布式通信
首先在功能相互依赖的大型网络系统中服务之间的实时通信显得尤为重要.在微服务架构中每1个服务都是1个进程使用进程间通信(inter-process communication IPC)技术以实现进程间信息交互.IPC将进程间的交互模式分为2种1)1对1交互模式与1对多交互模式.简而言之1对1模式即是单个客户端向服务器端发出请求客户端期望此响应即时到达然而在线程应用中请求传送过程可能造成线程阻塞.2)1对多交互模式即是一个客户端发出多个通知被多个相关联服务消费模式.进程间的通信统分为以上2种模式而在实际技术应用层面不同编程语言对应着不同的通信技术.以Java底层编程语言为基础的微服务架构通信为例阐述相关技术及协议的应用.在早期分布式初步通信时采用RPC(remote produce call)即远程过程调用协议[40]是基于客户端/服务器(Client/Server C/S)模式调用机制客户端向服务器端发送调用请求等待服务器应答是一种典型的请求应答机制其基本过程是本地分布式对象向本机发出请求不用开发人员编写底层通信代码直接向服务器发送请求服务器对象接受请求信息后经过计算将处理后的结果返还回客户端.然而由于RPC不支持面向对象使用的场景大幅度降低进而促进远程方法调用(remote method invocation, RMI)协议[41]的发展RMI协议支持面向对象采用客户机(stubs)和框架(skeletons)进行远程对象(remote object)的通信.stubs模拟成远程对象的客户端代理具有与远程对象相同的远程接口远程对象调用操作实际是通过调用该对象的客户端代理对象stub来完成实现效果与调用本地对象相同.其优点是支持分布式对象、跨平台高速率的数据传输缺点是不能跨越编程语言进行数据传输.
随着微服务的架构广泛应用相对应的通信协议也在成熟发展以适应层次不同的通信要求如JMS(Java message service),Web Service等通信标准已被较为成熟地应用.
3.2 分布式的数据存储一致性
传统整体架构是基于数据库提供的事务一致性[42]标准即通过数据库提供的提交以及回滚机制中相关操作的原子性、一致性、隔离性、持久性(atomicity,consistency,isolation,durability, ACID)保证数据库中的数据一致性.在微服务架构中每个微服务具有独立的数据库以保证微服务进程独立演进、独立开发.然而在分布式环境中每个服务访问数据是相互分隔服务之间不能依靠传统数据库中ACID保证事务一致性.由此基于对微服务分布数据一致性要求开发人员在初始阶段采用2阶段2PC(two phase commit)提交协调机制该机制为分布式事务提供了强一致保障.然而该机制存在隔离性互斥的特点.在事务执行过程中所有的资源都是被锁定的该机制只适合执行时间确定的短事务并降低了系统的吞吐率.基于此种情况开发人员通过业务逻辑将互斥锁操作从资源层面移到业务层面即提出TCC(try,confirm,cancel)方式.通过Try(尝试执行业务)、Confirm(确认执行业务)及Cancel(取消业务)三种操作方式达到数据最终一致性以提高系统整体性能.但是TCC方式中微小事务变动牵动整个业务逻辑复杂性较高.Saga事务[43]正好弥补该缺点.Saga事务就是一个长期运行在线的事务由多个本地事务所组成每个本地事务具有相应的执行模块和补偿模块.当Saga事务中任意一个本地事务出错可以通过调用相关事务对应的补偿方法进行恢复达到事务最终一致性目标.然而Saga只提供ACD(atomicity,consistency,durability)不能保证事务的隔离性.由此产生诸如2个Saga事务同时操作一个资源出现语义不一致、2个Saga事务操作同一个订单出现更新丢失等问题但可以采用在应用层面加入逻辑锁逻辑或者在Session层面隔离来保证串行化等操作以实现数据分布一致性.Saga的实现方式可以分布2种:1)集中式实现方式即协调器负责服务调用以及事务协调.2)分布式实现方式即以事件驱动的底层方法进行事务协调.在2017年5月Saga模式在华为开源微服务框架[44]中已被应用并且在不断地发展进步.
在微服务分布式数据存储一致性方面不同系统具有不同性能、环境以及对事务协调一致性的要求采用不同模式事务分布机制以达到分布式数据存储一致性的要求.
3.3 分布式调用链
在微服务架构下服务按照不同维度进行拆分.由此一次业务请求需要调用到多个微服务.系统应用构建在不同软件模块中存在不同模块由不同的团队、编程语言实现.同时可能部署在几千台服务器横跨成百个不同的数据中心.因此亟需理解系统行为、用于分析性能问题的工具以便发生故障时能够快速定位和解决问题.分布式调用链应运而生即可以监控那些横跨不同应用、不同服务器之间的关联动作进而快速定位与解决故障.
Google公司首先开发其分布式跟踪系统并且发表相关论文[45]Twitter参照该论文设计思想开发zipkin分布式跟踪系统以期为微服务架构提供参考.zipkin通过采集跟踪数据从而使开发人员深入了解在分布式系统中某一个特定请求如何执行.例如存在一个用户请求超时跟踪系统可以将这个超时的请求调用链展示在UI当中.开发人员可以快速定位出现故障的服务具体可定位到服务中导致超时的具体位置.同时通过服务调用链路能够快速定位并解决系统的性能瓶颈.同时针对不同的应用系统存在其他的应用程序性能管理(application performance management APM)工具如Pinpoint是一款针对Java编程语言大规模分布式系统的APM工具通过JavaAgent机制字节码代码植入实现加入traceid和抓取性能数据目标Central Application Tracking是由国内大众点评网开源出来的追踪系统已被成熟应用[46].
在分布式调用链方面不同的系统平台根据其特有的功能属性开发符合其特点的追踪系统以及调用链.
3.4 测试方面的复杂性
随着平台系统开发模式逐渐从传统的整体式产品向快节奏的微服务架构迁移软件测试人员也必须相应地调整测试方法和工具才能快速便捷地提高测试覆盖率.传统整体应用只需测试单一的REST API(application programming interface)测试需要启动相关联所有其他服务使得测试复杂性较高.在开发-测试-部署方面业界已经具备一套较为成熟的解决方案.然而微服务架构是一种演进式架构系统最初划分独立服务的数量可能极少随着业务复杂功能分解与扩展微服务数量不可避免地增加.同时微服务数量众多功能相对独立在执行业务过程中难免需要跨服务调用.如何保证跨服务调用的可靠性以及不同阶段的开发测试
在微服务测试方面系统被分解成独立的微服务即每个微服务都是一个功能完整的小型系统.首先需要保证服务自身业务功能的正确性即通过单元测试保证每个微型系统正确执行.其次由众多微服务构成完整的系统需要集成测试来保证整体系统的良好质量.然而在一个微服务架构中微服务的个数达到一定阈值时开发团队面临如网络环境不稳定、运行速度慢、反馈周期长等问题因此对集成测试望而却步.进而开发人员采用Pair集成测试即将集成范围缩小保证两两微服务集成的可靠性.但是这种Pair测试方法存在模拟(Mock)其他服务反复测试已经测试过的服务等问题增加了额外的工作量.由此引入Contract概念的集成测试[47]即前端与后端开发人员基于业务共同定义API协议(Contract)该协议以JSON文件形式存储于代码库的测试资源目录中.前端在开发过程中以JSON文件作为测试正确依据后端开发人员则参照该协议编程实现相关API.这种方式具有环境简单、运行快等优点.但是若存在任意一方修改协议内容测试便会失败缺乏自动化监控机制[48]以及不能提前发现问题等缺点.在基于Contract概念的基础之上消费者驱动契约测试(consumer-driven contract testing)将Contract契约中JSON文件转换成可工作软件时文档的细微修改便会导致任意一方测试失败并且通过可工作测试套件保证契约一致性与实时性.由此成为双方共同遵守的契约.
3.5 微服务应用案例
在现代企业中微服务所具有的高可用性、容错性、可管理性、可替代性[49]等优点满足企业用户的主要业务诉求由此越来越多的软件架构采用微服务架构.基于微服务以上关键技术以教育网站的部分功能为案例[50]讲解微服务技术架构的具体应用.
教育网站具有3部分功能1)用户可以登陆注册、获取用户基本信息的功能2)向用户发送邮件、短信的功能3)可以查看课程列表和对课程的基本增加、读取、更新、删除等功能.如图7所示展示教育网站部分功能整体架构. 网站采用Java为底层基础语言部署在轻量级容器Docker中进行实现.根据教育网站部分功能的划定与分析进而将整体架构进行分解为登录注册微服务、用户信息微服务、邮件短信微服务以及课程微服务等部分.对于微服务之间的通信从通信协议角度采用RPC协议该框架具有系统可扩展性、持续交付能力与高可用性等优点[51].常用的RPC框架有Dubbo,Motan,Thrifty,GRPC等,采用Dubbo框架实现教育网站中部分功能的通信功能.如图8所示展示Dubbo框架的架构[52].其中短虚线表示系统启动过程中的初始化阶段长虚线表示异步通信模式实线表示同步通信模式.在注册服务部分服务提供者向注册中心注册所提供的服务在订阅服务部分服务消费者向注册中心订阅所需的服务在通知部分注册中心返还服务提供者地址列表给消费者在调用部分采用同步通信基于负载均衡算法服务消费者从提供列表中选择一台提供者进行调用若调用失败则重新选择.
在微服务架构方面SpringCloud是一系列框架的有序集合具有服务发现与注册功能的Netflix Eureka、客服端负载均衡功能的Netflix Ribbon、服务网关功能的Netflix Zuul与分布式配置功能的Spring Cloud Config等核心组件.网站中的服务网关采用具有易于认证、易于监控的Netflix Zuul组件.如图9[50]所示客户端请求服务调用通过API Gateway转发到后端微服务的REST API以期调用网站中各个微服务每个微服务具有独立的数据库进而查询每个微服务基本信息实现用户所需功能. SpringCloud框架是具有高质量、稳定性与持续性等特性的一系列核心组件可以完成以Java编程语言为基础的微服务架构的核心功能这里不再一一赘述.
基于对微服务核心组件与关键技术的介绍微服务架构具有4个优势1)整体式应用分解为具有独立功能的微服务提供多种服务方法解决系统整体功能复杂性问题2)每个微服务可以由专有团队开发对编程语言具有宽泛的选择性3)每个微服务可以独立部署提升系统部署的效率4)由于每个微服务具有独立性易于在原有微服务基础上进行功能扩展提升系统的整体可扩展性.然而微服务应用采用的分布式架构具有其固有的复杂性因此面临以下挑战.
4 微服务面临的挑战
虽然微服务相关技术在逐步发展创新但由于微服务相当于是相对独立的小型软件系统在一个具有多种功能、多样性复杂的大型系统平台中如何在一定人力物力成本中快速部署微服务以及大量底层应用组件使其具有自动化部署功能微服务之间如何迅速准确地通信以满足用户快速响应的需求如何在正常通信中保证用户的数据信息安全在数量众多的微服务中如何保证数据传输中的网络安全.基于这些问题微服务面临4种挑战.
4.1 基础设施
随着分布式系统中应用程序需求迅速增长传统依赖于客户端向服务器处理端发起请求的整体体系结构开始发生转变这种体系结构不足以应付不断增长的快速请求面向服务的体系结构发展成为客户端-服务器体系结构中最成功表示形式之一然而从功能角度SOA架构中服务之间通过相互依赖最终形成一系列的功能服务组件大小既可以是小型应用程序服务也可以是大型企业应用程序部分组件可以实现多项功能由此SOA仍然属于整体式系统不能达到客户在弹性、可扩展性、快速软件交付等方面的期望由此微服务体系结构利用其本身灵活性、占用更少资源等特性满足了商业系统自身特性发展的需要[53].Newman[54]从服务平台的角度阐述了微服务架构存在必要性系统可以通过微服务使用不同的技术、不同编程语言进而满足不同的应用需求与此同时微服务之间相互独立与更新可以通过大型虚拟机运行如使用VMW和AWS(amazon Web services)等虚拟技术然而一方面配置大型虚拟机耗费较长时间另一方面管理程序层具有很大的运载负荷基于此容器技术被提出如Linux Containers[55]容器技术为程序提供了分割的空间而不需要管理程序层控制整个虚拟机.随着容器技术的发展Docker创建了轻量级容器技术具有将服务及其依赖项打包成单个映像的特性使其具有代码移植性[56].每个微服务都位于本身容器内因此需使用调度程序协调微服务之间事务一致性由此产生“集群管理器”其基本任务是确认主机与之相对应的容器[57].同时微服务分布在不同容器内使之只能使用轻量级通信.利用其HTTP特性REST API成为最适合微服务的消息交换机制可以使用多种语言格式如XML与JSON[58].
在网格和集群计算时代通用监控工具只能关注监控性能与数据中心资源级别的层次但不能监控到微服务层次如Amazon EC2容器的监控技术框架并不能监控到微服务级别的服务表现.由此收集、整合所有微服务和数据中心资源的整体技术作为新课题被提出[59-60].另一方面在部署阶段跟踪通过网关的微服务请求流增加了监控成本[61].Kang等人[62]基于对容器中管理服务状态面临挑战的研究对于容器服务管理和监控则需动态服务发现和注册等组件.
追根究底微服务目的是使系统在水平扩缩容和弹性伸缩方面更加敏捷、迅速但前提是仍需基础设施自动化如何实现微服务基础设施自动化就目前发展来看是微服务发展过程中不可避免的挑战.
4.2 信息交互
在微服务信息交互方面若单个服务由攻击者掌控该服务可能会恶意影响系统其他服务.由此微服务架构应该验证微服务之间信息交流的真实性与正确性.从微服务信息交互的认证权限角度Gegick等人[63]只将最低和必要权限分配给相对应的用户并且在最短时间生效.通过谨慎授权访问权限方式限制攻击者破坏系统.从授权协议的角度出发轻量级目录访问协议(lightweight directory access protocol, LDAP)[64]是在SaaS应用程序中常用的认证协议;通过LDAP服务可以存储相对静态授权信息适合于一次记录多次读取的应用场景.在数据结构方面基于树结构的LDAP有效、清晰地描述组织的结构信息简化了目录访问协议(directory access protocol, DAP)以提供基于TCP/IP网络的轻量级协议降低管理维护成本.
针对系统内部的共享资源一些学者认为授权策略应该以层次结构方式构建以实现可伸缩性与可表达性.为达到层次性访问控制网格安全基础设施(grid security infrastructure, GSI)[65]被广泛应用其包括私钥保护和通信加密等步骤.与传统的授权系统相比基于分布式管理机制的社区授权服务(community authorization service, CAS)模型[66]允许资源提供者授予部分权限既可以对社区细粒度访问控制进行维护又对资源保持最大控制提高系统的可扩展性与灵活性.Patanjali等人[67]提出了基于模块化的微服务架构通过动态评级、计费模式为云服务提供商验证相关接口.基于对服务提供商在整个应用程序生命周期中权限安全性要求Thanh等人[68]利用包含网络功能虚拟化等新兴技术的微服务框架DevOps[69]该框架具有2个重要的安全优势:1)是虚拟化安全功能/服务框架为用户选择和集成多个供应商提供安全解决方案2)对于网络层访问控制利用防火墙即服务(firewall as a service, FWaaS)[70]技术使用户对进入和离开应用程序的网络流量采取不同访问控制策略.Li等人[71]采用微服务框架OAuth保证相关权限的安全性OAuth框架授权第三方访问用户帐户以及用户身份但是第三方网站可以以访问用户帐户临时密钥方式得到访问用户身份信息由此产生用户私有信息泄露问题.Cheung等人[72]基于微服务的框架采用第2版本的OAuth修复用户信息漏洞等问题采用HTTPS协议并简单化授权验证过程但上述问题仍然存在.在信息交互方面微服务框架与对应接口认证权限仍需不断地扩展、改进.以适应大数据时代下用户需求以及隐私信息保护需求.
在微服务信息交互层面仍存在其他问题如信息交互用时较长、信息交互准确率较低等问题.基于以上阐述微服务信息交互在信息安全性、网络稳定性等方面仍面临巨大挑战.
4.3 数据安全
在微服务数据安全方面微服务架构在云环境中应用越来越广泛微服务中分布式数据隐私信息保护以及保密性越来越被重视.部分学者采用密码学中传统加密方式对数据进行加密.基于密码学的加密技术可以分为对称与非对称方法[73-76].对称加密技术即是通过加密密钥对原始数据进行加密反之亦然.非对称技术即是通过公有/私有密钥对原始数据加密只有相对应私有/公有密钥才能进行解密.一般来说,加密密钥越长加密后的数据也更加安全.然而这表示在加密与解密过程中产生更大性能开销[77].基于此考虑到微服务模型中数据具体应用场景与对部分敏感信息的保护学者们力求在计算复杂度与数据安全保护取得平衡.Shah等人[78]从提高数据安全性角度利用第三方审计协议允许用户评估风险并提高降低风险的效率同时还提出了支持在线存储内部服务和外部审计的数据隐私方法.审计目的是监控服务器和网络中用户详细行为信息记录一旦发现违反安全策略相关行为信息立即向管理员报告.Wang等人[79]仅从数据加密角度出发并没有考虑对审计协议的设计由此并不能保证数据不会被泄露给第三方平台.
微服务是分布式的即拥有众多不同的数据服务平台由此需对不同数据来源加以保护.Callegati等人[80]从数据可靠性、完整性和真实性角度出发采取4个步骤进行保护数据源:1)提出一个具有可验证性、可问责性和可生产性的数据源管理系统,可验证性是指管理体系应能够验证与操作有关的参与者(或服务)的数据源,可问责性即是指管理系统应能够让参与者(或服务)对其在数据源中的行为负责,可生产性是指管理系统应能够在数据源上生产过程2)为数据流认证创建一个私有和公共密钥系统3)使用基于密码学出处验证方法确认数据源主机数据属性与完整性4)将数据元数据传播与密钥分发传播管理相结合确保数据源管理系统的可靠性.基于以上4个步骤既可以有效地进行微服务架构信息交流又可以对数据来源进行有效保护.Subashini等人[81]从企业数据安全的角度建议对数据供应商采取额外的安全检查以确保数据源安全并防止应用程序中安全漏洞.企业数据定期备份使用强加密方案便于在发生紧急情况时快速进行数据恢复.Saad等人[82]以对数据源全方位保护角度建立保障数据源存储与访问事务处理安全的信任模型提高了服务之间信任度.
基于以上阐述在微服务分布式结构中如何有效保证数据源信息的安全以及对第三方平台数据有效认证是十分值得思考的问题.
4.4 网络安全
在微服务网络安全方面首先数量众多的微服务带来网络复杂性增加监控整个应用程序安全性的难度.其次微服务通常被设计成彼此完全信任因此单个微服务的失误可能会导致整个应用程序崩溃.Sun等人[83]从微服务增加了监控整个应用程序安全性的难度与单一微服务失败会导致整个应用程序崩溃的角度提出了基于微服务云应用安全即服务(security-as-a-service SaaS)设计方案.通过为网络管理程序添加一个新的API原语流TAP进而为网络流量构建了灵活地监控和策略强制基础设施以保护云应用程序的安全.基于对监控数据中心网络流量和安全威胁模型、方法和设备的描述Ahuja等人[84]扩展了安全系统中微服务的层次结构.具体而言创建第1层次结构的新微服务以配置第1层与第2层次结构中微服务之间的数据平面连接配置第1层与第3层次结构微服务同时将新加入的微服务包括在第1个层次结构的负载平衡决策中以提高微服务网络安全性.Ross等人[85]研发分布式微服务中提供漏洞扫描系统.该系统包括多个微分段环境既与云数据中心服务器相关联又与云环境的多个微分段环境耦合.云数据中心服务器具有安全控制器与主动探测控制器前者为每一个微分段环境提供安全策略后者为主动探测微分段环境设备并执行漏洞扫描策略.Yarygina等人[86]基于对目前技术仅对微服务系统特定安全问题的研究提供微服务安全分类进而评估微服务架构的安全性最后提出相关合理解决方案并对Docker Swarm和Netflix的安全决策进行分析.
一方面微服务安全是一个多方应用结合的问题目前没有系统的分层安全解决方案另一方面如果这些安全挑战得到解决微服务体系结构的安全性将会大大提高.
5 总结与展望
目前国内外学者对基于微服务技术的SOA架构及其实现机制的研究进展十分重视微服务具有独立进程、轻量级通信和独立部署环境等显著的特性将系统整体功能分解到单个微服务中以实现对系统的解耦这种方式不仅可以降低系统的耦合性提升系统的内聚性而且减少服务交互的成本提供更加灵活的服务支持.本文从微服务概念、核心组件与技术发展过程、面临挑战3个方面进行了分析
1) 论述了微服务体系结构的产生背景、相关概念指出传统整体架构不足及微服务体系结构发展背景及优势.
2) 论述了微服务的核心组件与技术发展前者在服务发现机制、服务容错等层面进行研究后者在技术发展方面从微服务软件技术层面以及微服务架构层面2个方面进行概述.
3) 基于对核心组件的介绍进而对微服务关键技术进行分析提出微服务在基础设施层面、信息交互层面、数据安全层面、网络安全面临的四大挑战以及发展趋势.
与传统开发模型相同选择合适的未来开发平台对于微服务十分重要.微服务如何与2个主要的新兴平台进行集成即云平台[87]和物联网[88].随着科技新兴技术与数据时代的到来两个平台很可能在互联网行业中占主导地位.由于微服务本身具有移植性和可伸缩性等特性在物联网上运行存在部分难题若在云平台中运行微服务似乎是恰当的选择.但从系统安全性角度出发存在部分功能具有低计算能力且具有较高风险的缺点.因此微服务与具体应用平台相结合解决微服务与平台相集成的特定实施方案以及安全方案需求变得更加迫切.
