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