Page 62 - 《软件学报》2021年第5期
P. 62

1286                                     Journal of Software  软件学报 Vol.32, No.5,  May 2021

                 1.1   不同类型的微服务化拆分方法
                    当前,在微服务的拆分方面,更多地依赖主观判定和手动实施,缺乏系统化且高效的方法帮助实践者完成整
                              [4]
                 个拆分评估流程 .Newman 主张通过增量式地寻找服务边界进行微服务化拆分,并提出了寻找边界、循序渐进
                                                  [5]
                 地将服务从杂乱依赖中剥离的一系列方法 .微服务倡导的是根据业务能力来确定边界,这一点与 Evans 的领
                                                                                [6]
                 域驱动设计(domain-driven design,简称 DDD)思想相契合,即“围绕业务能力构建” .DDD 中的核心是领域模型,
                 领域(domain)被定义特定范围内的知识、影响或行为,本质上包含问题空间和解决方案空间,与系统的核心业务
                 功能相关.其中:问题空间包括核心域和其他可能的子域;解决方案空间包括一个或者多个限界上下文(bounded
                                                                                [4]
                 context),即一组特定的软件模型.限界上下文对于识别明显的微服务边界很有用 ,Richardson 给出了基于限界
                               [7]
                 上下文的拆分模式 ,即按业务能力拆分、通过领域驱动设计的子域拆分、通过动词或用例拆分、通过名词或
                 资源拆分,其中,前两种模式较为抽象,且需要不同类型的专家,分别是业务架构建模和领域驱动设计专家.这 4
                                                                                  [8]
                 种模式的提出仅停留的概念阶段,缺乏系统化的指导来帮助实践.Kecskemeti 等人 宣称通过对镜像(image)分
                 析对微服务进行拆分,但该研究没有对与微服务相关的拆分原理和方法进行详细介绍,且结果缺乏可靠的验证.
                                                   [9]
                 上述研究均未考虑粒度的问题.Hassan 等人 的研究对微服务的粒度有所关注,对架构中微服务的大小和数量、
                 系统的整体非功能性需求满意度和个人的非功能性需求满意度作出的权衡,以此为依据对微服务进行拆分.其
                 研究成果仅处于自然语言描述阶段,涉及的因素不够详细,划分机制还不够完善.
                    学术领域研究目前针对微服务的拆分问题提出的较为系统的方法主要分为 3 类.
                    1)   基于元数据辅助分析.使用抽象的软件架构描述作为输入数据来分析并进行拆分,例如 UML 图、用例
                        或接口描述、代码版本控制库中的数据以及非功能性需求等内容.Gysel                        [10] 等人提出了一种基于 16
                        种从文献及行业经验中提取出来的耦合标准的微服务化拆分方法——Service Cutter.该方法基于这
                        16 种耦合标准,使用聚类算法得到微服务候选集.该方法中的耦合标准优先级设定是人为设定,具有
                        很大的主观性,不同的优先级设定可能将会产生不同的微服务候选集.Ahmadvand 等人                          [11] 提出了基于
                        软件的安全性与可拓展性需求进行微服务化拆分,他们使用具有安全性评估和可拓展性评估的 UML
                        用例图作为输入,从而计算出微服务候选集.Baresi 等人               [12] 基于 API 规范的语义相似性,计算接口间的
                        语义相似度,从而计算出适合的微服务候选集.Mazlami 等人                 [13] 提出了一种形式化的微服务提取模型,
                        以支持在重构和迁移场景中进行微服务候选集推荐.
                    2)   基于静态源码数据分析.依赖应用程序源码的静态分析来进行拆分.Escobar 等人                        [14] 基于源代码静态
                        分析,通过 Java 注释识别数据类型,使用聚类算法得到微服务候选集.Levcovitz 等人                    [15] 同样基于源代
                        码静态分析,不同的是,他们是基于业务功能之间的关联以及类与类之间的静态关系和数据库表两者
                        之间的依赖构建微服务候选集.
                    3)   基于动态运行数据分析.通过在模块或功能级别上测量软件系统的性能来找到合适的微服务化拆分
                        方案,比如:Hassan 等人   [16] 定义了具有适应性边界的架构元素(环境),使用工作负载数据在运行时调整
                        粒度,得到微服务组合;Klock 等人        [17] 使用遗传算法,基于工作负载计算最佳微服务部署和粒度.
                    综上所述,在单体系统向微服务迁移的过程中,可以立足于不同的视角、通过不同的数据分析方法进行微
                 服务的拆分工作,但现有的方法都有其各自的局限性.基于元数据辅助分析的方法更加适用于软件系统架构设
                 计阶段相关制品比较完善的情况,尤其是新的微服务系统设计,但该类方法的复杂、主观判断不准确等问题有
                 待进一步解决;另一方面,很多遗留系统面临架构设计阶段相关制品不全、只有源码和运行时数据的窘境,这种
                 情况下,基于静态代码分析和负载数据分析的方法更加适合.然而,单一视角下的数据分析无法全面获取系统的
                 实际特征,比如单纯地通过静态源码数据分析无法获得系统运行时的依赖关系,如与多态、依赖注入和控制反
                 转相关的动态特征,也无法真正获取用户使用规律不同而影响的系统模块之间的依赖和耦合关系.而动态分析
                 可能会出现代码覆盖率低的问题,而无法获得应用的全部特征信息.不够全面的数据分析可能会造成微服务识
                 别的偏差,从而影响微服务化拆分结果的质量.当前,在面向微服务的拆分设计问题的挑战,驱动本文探究针对
                 该问题更加系统且有效的解决方案.
   57   58   59   60   61   62   63   64   65   66   67