一种基于微服务架构的SaaS应用构建方法与流程

技术领域

本发明属于SaaS应用开发领域，具体涉及一种基于微服务架构的SaaS应用构建方法。

背景技术：

云计算技术拥有强大的计算能力，高效的IT资源整合能力，带来互联网时代软件的开发和使用方式上的变革。SaaS应用开发模式正是在云计算技术广泛发展的背景下产生的一种全新的通过互联网提供软件服务的模式，用户可以根据自身的实际需求使用租用的方式灵活地使用软件。

随着SaaS应用模式的发展，人们日益增长变化的需求导致软件功能需求频繁变化，使得软件的交付和迭代周期逐渐缩短，传统的长周期开发模式已经满足不了互联网时代的软件开发需求。而随着Docker容器技术发展而出现的微服务架构模式则可以很好地应对频繁交付的问题。

微服务架构提倡将应用程序分割为多个独立的小服务，每个服务专注于自己的独立的功能，并运行在各自独立的进程中。服务与服务之间有比较明确的界限，互相之间通过一些比较轻量级的通信机制进行沟通。

微服务的概念和SOA有相似之处，都提倡将复杂的应用程序按照不同的、可重用的功能划分为不同的服务，但是微服务的服务粒度更细，部署在独立进程中运行，并通过轻量级机制进行通讯，更加适合当前需求变更频繁、迭代速度快、交付周期短的互联网应用。因此对构成微服务架构的关键微服务的设计原则、属性模型和部署方法进行研究非常重要，需要明确设计与开发微服务过程中需要遵循的原则，在尽量符合这些原则的情况下进行开发部署可以更好地发挥出该架构所带来的优势。

当开发者在云环境下运用微服务架构开发SaaS应用时，会出现微服务数量急剧增加、实时状态动态更新和节点动态增删等情况，我们需要一种能够有效针对微服务特点的管理方案，以便提高开发者使用微服务架构开发SaaS应用的效率。

技术实现要素：

本发明所要解决的技术问题是根据微服务设计原则和属性模型开发微服务，并使用Docker容器部署多个微服务实例；将微服务实例的元数据实时更新到分布式元数据集群；元数据更新的同时触发负载均衡服务，通过一致性hash算法计算出实例分配情况的变化，并通知到实例的调用者；SaaS应用开发者通过负载均衡服务选取最优的微服务实例，并通过REST接口对微服务实例进行调用。

为解决上述技术问题，本发明提供了一种针对微服务架构的高可用管理方法，其，包括：

（1）微服务的属性模型设计：根据单一功能、独立部署、无状态、轻量级通信等微服务设计原则，制定了可以用来描述微服务的属性，包括名称、位置、版本、实时状态、身份验证信息、支持并发量、提供者信息等属性；

（2）微服务部署：通过Spring Boot框架生成可执行的JAR包，使用基于Linux容器虚拟化技术的Docker容器来部署运行微服务实例；

（3）微服务元数据更新：将实时更新的状态数据更新到Redis内存数据库中，将相对固定的属性数据更新到MySQL关系型数据库中，通过采用不同的存储方案实现不同类型元数据的更新功能；

（4）微服务实例分配：一个微服务可以具有多个运行的实例，并且这些微服务实例可以进行动态的增加和删除，通过负载均衡服务对这些实例进行分配，以达到均匀地分配实例给不同的调用者。

（5）微服务调用：SaaS应用开发者在通过负载均衡服务获取到最优的实例后，可以通过REST接口对微服务进行调用，通过组合不同的最优微服务实现高效地开发SaaS应用。

与现有技术相比，本发明所述的基于微服务架构的SaaS应用构建方法，达到了如下效果：

（1）本发明采用的Spring Boot框架生成可执行JAR包与Docker容器相结合的部署方法，有效实现了微服务实例的独立部署。

（2）本发明实现的以海量微服务元数据统一管理为核心，包括高可用的微服务元数据存储、支持实时更新的读写分离和支持动态变化的负载均衡等一系列方案，有效地解决了开发者在云环境中使用微服务架构开发SaaS应用时遇到的微服务种类和数量急剧增多的问题。

附图说明

图1为微服务元数据统一管理方案架构逻辑示意图。

图2为高可用的元数据存储方案架构示意图。

图3为支持动态变化的负载均衡方案流程图。

具体实施方式

以下结合附图和实例对本发明的实施作进一步说明，但本发明的实施和保护不限于此。

微服务设计原则与属性模型制定

微服务架构作为一种软件开发模式，与传统的SOA面向服务的架构之间有着很多的相同点和不同点，而导致它们之间不同之处的原因关键在于它们所研究的对象的差异。所以对构成微服务架构的关键微服务的设计原则、属性模型进行研究非常重要，需要明确设计与开发微服务过程中需要遵循的原则，在尽量符合这些原则的情况下进行开发部署可以更好地发挥出该架构所带来的优势。

本实例制定的微服务设计原则如下：

（1）单一功能原则：单个微服务所负责处理的业务逻辑专注于某一具体的功能，并且该功能具有设计良好的对外接口，这些接口明确规定了功能之间的界限，规定哪些因素的变化才会导致此功能的变动。

（2）独立部署原则：从物理属性的角度定义每个微服务在开发、测试、构建和部署的整个流程都是在物理上独立的环境中进行的，当对单个微服务进行修改、升级、重新部署运行都对其他微服务的运行没有影响。

（3）无状态原则：微服务在接受处理外界的请求时不需要记录与外界使用者相关的通信信息，这样在某个微服务实例出现故障或者动态的扩展、缩减的时候，可以非常敏捷地添加或者缩减无状态的实例。

（4）轻量级通信原则：采用一些与开发语言和开发平台不相关的机制进行交互。常用的轻量级通信协议有XML和JSON，这些协议具备对复杂信息的表达能力，能够实现跨平台的信息传输。

根据以上设计原则，我们制定了微服务需要具备的属性模型，包括：名称属性、位置属性、版本属性、实时状态属性、身份验证属性、支持容量属性、服务者提供者属性。

微服务元数据统一管理方案

如图1所示，展示了针对海量、动态、实时更新的微服务实例状态进行统一地高可用、高性能管理，其关键特点如下：

（1）多个微服务实例独立部署，海量的状态元数据和属性元数据需要实时更新到元数据集群；

（2）微服务实例可以进行动态地扩展或者缩减，实例的增删变化实时更新到元数据集群；

（3）负载均衡服务以集群的形式进行部署并提供服务，通过读取高可用的元数据集群获取微服务实例的位置信息和状态信息；

（4）实例调用者首次订阅微服务时，访问负载均衡服务，结合微服务的状态信息和预设的负载均衡策略进行微服务实例的最优化选择，并将选择情况记录到调用者本地。

（5）负载均衡服务记录调用者与所使用微服务实例的关系，若实例动态增减则及时通知调用者。

（6）最终实例调用者通过实例提供的REST接口采用直接连接的方式与具体的微服务实例通信。

高可用的元数据存储方案

首先针对实时更新的状态数据，这类数据的特点是每次更新的数据量不大，并不需要很大的存储空间来处理单个更新的数据，但是其更新的频率较快而且更新的总体次数较多，所以需要一种相对较为简单并能够提供较高的数据读取性能的存储机制，选择Redis内存数据存储方案。

利用Redis提供的丰富数据类型来设计状态数据的数据结构以便于分类存储和快速检索。比如微服务实例的状态属性的键的形式可以设置为字符串“microservice:instance:state:instanceId”，微服务实例实时的位置信息则可以设置为字符串“service_id:instance_id:url”。这种通过多个字段和符号间隔而组成键的模式具备良好的结构性，非常方便系统使用者对Redis中数据进行分类和查找。

利用Redis的AOF（Append Only File）方式来进行数据的持久化，以避免由于内存的易失性而造成数据的丢失。利用Redis同步复制的功能来实现多Redis服务器的容灾备份。Redis提供了简单的SLAVEOF命令和slaveof配置属性使得本实例可以将一个Redis服务器设置为另一个Redis服务器的从服务器，这样对主服务器的操作就可以及时地同步更新到从服务器上。

针对高并发的读写需求，采用多台服务器存储数据，分为主服务器和从服务器，服务器与服务器之前通过同步机制来实现数据的拷贝，其中主服务器主要负责对外提供对数据的增加、删除、修改等可能对数据带来变化的操作，而一个或多个从服务器则负责对外提供数据的查询读取的操作。

其次针对一些相对来说比较固定、结构化的数据，可以使用行和列字段的形式，并且便于查询，比较适合使用二维表的数据形式来描述、存储和处理，所以采用传统的关系型数据库MySQL来存储。图2展示了元数据存储方案的整体架构。

支持动态变化的负载均衡方案

微服务的无状态原则使得单个微服务可以自由地扩展出多个可运行的具体实例，每个实例进行独立地部署，实例内部的操作互不影响。在面对这种拥有多个同构的实例同时运行的情况，需要一种可以将多个调用者的请求分发到不同实例进行处理的负载均衡方案。

本实例采用一致性hash算法结合实例的实时负载情况解决实例动态增删的情况。图3所示为负载均衡方案流程图，其中步骤如下：

（1）首先由微服务实例进行自身实时负载状态的监控，例如每次调用的处理时间、实时的并发调用数量等信息。

（2）微服务实例定时将自身状态信息更新到元数据集群、比如实时负载状态和实例增加或者主动删除等。此外元数据集群通过一定的心跳机制来检测实例是否崩溃。

（3）负载均衡服务定时检测各微服务实例状态变化是否为实例增加或者删除，如果是，则采用一致性哈希算法对请求进行重新分配，并通知相关受影响的调用者。

（4）如果不是实例增加或者删除，只是报告实例运行负载状态，则定时判断各微服务实例的负载状态是否达到预设的负载阀值，如果没有则不做请求的调整。

（5）如果检测到某微服务实例的负载已超过其预设的负载阀值，则将该实例的部分请求均匀地分配到其他未超过负载阀值的实例。

（6）最后根据负载均衡后的结果通知受影响的调用者，调用者则修改其本地缓存的微服务地址信息。

在搭建的微服务管理框架数据模型中每个微服务实例都有一个load_threshold属性代表该实例的负载阀值和load_factor属性代表实例的实时负载率，负载阀值代表了一种预警信息，如果实时负载情况超过该阀值时则容易出现实例宕机的情况。

为了降低实例宕机的频率，本实例通过load_threshold属性实现一种“虚拟宕机”的策略，即当实时负载情况超过负载阀值时，提前触发负载均衡服务，以实现在真正的宕机发生之前就将该负载超载实例上的部分请求分配到其他实例，并通过实时通知组件及时地将实例分配变化的情况通知到调用者。这样的预防策略可以减少真正实例宕机的频率，从而提高系统整体的可用性。

本发明针对应用微服务架构开发SaaS应用时出现的微服务数量急剧增加、实时状态动态变化和节点动态增删等情况，设计了一套高可用的微服务元数据管理方案，并分别设计了针对微服务管理的元数据存储方案、状态更新方案和负载均衡方案。使得开发者在使用微服务开发SaaS应用时可以对微服务进行更好地管理和调度，提高开发效率。

可见，本发明采用的Spring Boot框架生成可执行JAR包与Docker容器相结合的部署方法，有效实现了微服务实例的独立部署。本发明实现的以海量微服务元数据统一管理为核心，包括高可用的微服务元数据存储、支持实时更新的读写分离和支持动态变化的负载均衡等一系列方案，有效地解决了开发者在云环境中使用微服务架构开发SaaS应用时遇到的微服务种类和数量急剧增多的问题。

上述说明示出并描述了本发明的若干优选实施例，但如前所述，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述发明构想范围内，通过上述教导或相关领域的技术或知识进行改动。