文档介绍：Dubbo路由模块设计说明书修改记录版本/状态拟制人/修改人拟制/修改日期更改理由更改内容(写要点即可). 5微应用系统建设背景 5微应用系统建设面临的挑战 7微应用智能路由模块需求分析 9应用路由需求 11服务路由需求 11服务负载均衡 12集群扩展及容错 12服务路由扩展及规则 13多协议支持 13多版本支持 14并发控制需求 14连接控制需求 14令牌验证及权限扩展 1523. 数据路由需求 15微应用智能路由模块设计原则 16微应用智能路由模块设计方案 184・1・ 应用架构设计 18技术架构设计 19软负载均衡设计 19分布式服务框架设计 19分布式数据库框架设计 355. 微应用智能路由系统部署方案 ,每年移动互联网产生的流量增速达到60%,越来越多的业务及应用系统也开始推出支持各种移动终端的版本,而移动应用的增加反过来进一步促进了移动终端数量的快速增长。公司根据移动互联网时代对业务的需求,提出了微应用商店,通过微应用商店提供更精细的业务功能。随着互联网流量从桌面转向移动终端,以及物联网浪潮的兴起,提供适配多种终端的丰富、友好的用户体验对于应用系统提出了更高的要求。传统的基于单一模型的应用系统,虽然在系统设计层面采用了分层架构设计,通常包括前端表现层、业务逻辑层、数据库访问层、应用集成层等,但最终系统打包成一个WAR或者EAR单一文件形式,该文件包含了所有的系统特性及功能,并通过集中部署的方式实现系统运行,通过部署在多台服务器上并结合负载均衡实现业务的高可用性,如图1单一架构应用系统所示。应用系览图1单一架构应用系统这种架构方式随着系统的演进,系统规模越来越庞大,子系统及模块之间的关系也越来越复杂,后续的开发及维护成本也不断提高,已经无法满足移动互联网应用对于系统的快速版本迭代及上线的需求,同时也严重影响了系统开发的效率。针对单一架构应用系统暴露的问题,基于微服务架构的应用系统(以下简称微应用系统)应运而生。微应用系统由一组规模较小的服务构成,每个服务以独立进程的方式单独运行,它们之间通过轻量级的进程间通信机制如RESTAPI进行通信,这些服务根据业务逻辑进行划分,每个服务有自己单独的数据库,通过自动化部署方式每个服务可以独立进行部署。微应IIH应川交付罷WAR・%®%*!TomcatWARTomcatWAR*岛|■林Tomcat业势察合H1 业务IB鈿泉图2微应用系统架构在微应用系统架构中先在业务服务层,每个业务服务以独立进程服务模式运行,实现特定的业务逻辑,并有独立的数据库实现数据存取,与其他业务服务之间通过良好定义的API接口进行交互。业务聚合层负责对业务服务层的服务进行聚合,对服务调用返的数据进行聚合及数据协议转换,对外提供更粗粒度的服务接口。应用交付层负责对外提供系统应用层接口,对服务调用返回的结果根据用户终端进行优化,根据用户行为分析为用户提供定制化的展示方式。12微应用系统建设面临的挑战微应用架构中应用内的各个服务可以独立、动态的进行伸缩,当服务进行伸缩时,其他调用方服务需要能够找到该服务的服务实例,并与之进行通信,使得请求能够分布到所有的服务实例中,从而实现该服务的水平可扩展性。另外在服务调用过程中也需要通过负载均衡策略能够将针对该服务的请求均匀分布到所有的服芻实例。在大规模微应用系统服务化之前应用可以通过RMI或者Hessian等工具,简单的暴露和引用远程服务,通过配置服务的URL地址进行调用,通过F5等硬件进行负载均衡。但随着微应用系统中服务越来越多,系统面临着越来越多的挑战:■当服务越来越多时,服务URL配置管理变得非常困难,F5硬件负载均衡器的单点压力也越来越大。此时需要一个服务注册中心,动态的注册和发现服务,使服务的位置透明。并通过在消费方获取服务提供方地址列表,实现软负载均衡和Failover,降低对F5硬件负载均衡器的依赖,也能减少部分成本。■微应用中由于各个服务的独立性,任何服务的弹性伸缩、版本升级、系统故障等都可能导致该服务的状态发生变化甚至不可用,如何能够让服务使用者不受任何影响;■微应用中每个服务都有自己独立的数据库,因为微应用拆分导致的原来在一个数据库的表被分散到了多个数据库,需要对服务屏蔽分布式数据库带来的复杂操作,为跨多个数据库的操作提供统一的数据访问方法;■随着服务的调用量越来越大,服务的容量及性能问题就暴露出来,系统的扩容及运行优化需要性能监控及参数调整,所以需要监控服务的调用量、响应时间等,作为容量规划的参考指标。其次,要可以动态调整权重,通过调整权重并在过程中记录响应时间的变化,直到响应时间到达阀值,记录此时的访问量,再以此访问量乘以机器数反推总容量。所以服务的动态伸缩