一种软件架构优化方法、装置和存储介质与流程

1.本发明涉及软件开发技术领域，具体涉及一种软件架构优化方法、装置和存储介质。


背景技术：

2.随着互联网技术的不断发展，传统的单体应用架构模式已经无法满足爆炸式增长的网络访问流量，具有更高吞吐量的分布式微服务架构解决了单体应用架构的吞吐量低、单个应用过于庞大、团队工作互相干扰大等问题。
3.而为了保证在软件架构的复杂性不断增加的情况下，使软件系统保持持续稳定的运行和更新的能力，现在亟需能够对软件架构进行更加快速客观调整的优化方法。


技术实现要素：

4.为了解决现有技术存在的优化速度慢、能力低的问题，本发明提供了一种软件架构优化方法、装置和存储介质，其具有优化能力更强、速度更快、不依赖于人工经验等特点
5.根据本发明具体实施方式提供的一种软件架构优化方法，包括：
6.基于分布式架构中每个服务组件和其他服务组件间的调用关系，构建静态调用关系网络；
7.基于代码库的代码提交记录构建第一二分网络；
8.将所述第一二分网络向开发人员方向上进行单模映射，得到表征各开发人员间协作关系的团队分工结构；
9.将所述第一二分网络向所述代码库方向上进行单模映射，得到表征各服务间修改关系的服务联动修改关系网络；
10.基于所述开发人员之间的沟通信息构建所述沟通信息对应的沟通方式和所述开发人员之间的第二二分网络；
11.将所述第二二分网络向所述开发人员方向上进行单模映射，得到用于表征所述开发人员间沟通紧密程度的沟通结构；
12.生成架构优化的参考信息，所述参考信息是软件架构优化的基础，所述参考信息至少包括：所述静态调用关系网络、所述服务联动修改关系网络、所述团队分工结构和所述沟通结构。
13.进一步地，所述参考信息还包括：动态调用关系网络，所述动态调用关系网络的构建过程包括：
14.获取分布式架构运行时的调用链追踪数据；
15.基于所述调用链追踪数据构建所述服务组件在运行时的动态调用关系网络。
16.进一步地，所述基于分布式架构中每个服务组件和其他服务组件间的调用关系，构建静态调用关系网络，包括：
17.对分布式架构的源代码构造语法树；
18.对所述语法树进行解析，得到服务组件对外提供的接口资源以及与其他服务组件的调用关系；
19.将每个服务组件的接口资源通过所述调用关系与其他服务组件连接，构成所述静态调用关系网络。
20.进一步地，所述基于所述调用链追踪数据构建所述服务组件的动态调用关系网络，包括：
21.确定调用链追踪数据中追踪标签的类型；
22.基于所述追踪标签的类型确定调用关系的调用方和被调用方；
23.将所述调用方与所述被调用方作为节点，所述追踪标签作为关联关系，相应的调用链追踪数据的标识作为所述关联关系的属性构成调用关系图。
24.进一步地，所述基于所述调用链追踪数据构建所述服务组件的动态调用关系网络，还包括：
25.对参与实现微服务功能的调用链进行聚合，若两个调用链追踪数据的标识不相同，但都具有相同的微服务参与节点且所述参与节点的调用顺序相同，则将两个调用链合并为一个路径。
26.进一步地，所述将所述第一二分网络向开发人员方向上进行单模映射，得到表征各开发人员间协作关系的团队分工结构，包括：
27.若所述第一二分网络为连通图，则将得到的连通图向所述开发人员方向上进行单模映射，得到连通图的单模映射图；
28.若所述第一二分网络为非连通图，则获取非连通图的所有子图，对每一个子图进行开发人员方向上的单模映射；
29.对非连通子图产生的单模映射图进行合并，得到非连通图的单模映射图；
30.基于预设社区发现算法对所述连通图的单模映射图和所述非连通图的单模映射图进行聚类，得到所述团队分工结构。
31.进一步地，所述参考信息还包括：所述静态调用关系网络、所述服务联动修改关系网络、所述团队分工结构和所述沟通结构之间的相似度。
32.根据本发明具体实施方式提供的一种软件架构优化装置，包括：
33.静态调用关系网络模块，用于基于分布式架构中每个服务组件和其他服务组件间的调用关系，构建静态调用关系网络；
34.第一二分网络构建模块，用于基于代码库的代码提交记录构建第一二分网络；
35.团队分工结构模块，用于将所述第一二分网络向开发人员方向上进行单模映射，得到表征各开发人员间协作关系的团队分工结构；
36.服务联动修改关系网络模块，用于将所述第一二分网络向所述代码库方向上进行单模映射，得到表征各服务间修改关系的服务联动修改关系网络；
37.第二二分网络构建模块，用于基于所述开发人员之间的沟通信息构建所述沟通信息对应的沟通方式和所述开发人员之间的第二二分网络；
38.沟通结构模块，用于将所述第二二分网络向所述开发人员方向上进行单模映射，得到用于表征所述开发人员间交互方式的沟通结构；以及
39.参考信息生成模块，用于生成架构优化的参考信息，所述参考信息是软件架构优
化的基础，所述参考信息至少包括：所述静态调用关系网络、所述服务联动修改关系网络、所述团队分工结构和所述沟通结构。、
40.进一步地，所述软件架构优化装置还包括：
41.动态调用关系网络模块，用于基于分布式架构运行时的调用链追踪数据构建所述服务组件的动态调用关系网络。
42.根据本发明具体实施方式提供的一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现如上所述的软件架构优化方法的各个步骤。
43.本发明所提供的软件架构优化方法，从软件架构从开发到运行的整个过程出发，基于分布式架构中每个服务组件和其他服务组件间的调用关系，构建静态调用关系网络。基于代码库的代码提交记录构建第一二分网络，然后普将第一二分网络向开发人员方向上进行单模映射，得到表征各开发人员间协作关系的团队分工结构。将第一二分网络向代码库方向上进行单模映射，得到表征各服务间修改关系的服务联动修改关系网络。再基于开发人员之间的沟通信息构建沟通信息对应的沟通方式和开发人员之间的第二二分网络。将第二二分网络向开发人员方向上进行单模映射，得到用于表征开发人员间沟通紧密程度的沟通结构。最后以静态调用关系网络、服务联动修改关系网络、团队分工结构和沟通结构作为软件架构优化的基础对软件架构进行优化。本发明提供的软件架构优化方法基于多维度数据源和图论建模构建软件架构本身的拓扑图，相较于传统的架构治理更加的全面和可靠，并且因为是对架构本身所产生的数据进行的建模，架构整个生命周期中均可进行建模和治理，不会受到人员变动、经验等非技术因素的影响，使得架构的优化治理更加的客观可靠。
附图说明
44.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
45.图1是根据一示例性实施例提供的软件架构优化方法的流程图；
46.图2是根据一示例性实施例提供的动态调用关系网络的构建过程图；
47.图3是根据一示例性实施例提供的静态调用关系网络的构建过程图；
48.图4是根据一示例性实施例提供的动态调用关系网络的另一具体构建过程图；
49.图5是根据一示例性实施例提供的团队分工结构的构建过程图；
50.图6是根据一示例性实施例提供的沟通结构的构建过程图；
51.图7是根据一示例性实施例提供的软件架构优化装置的结构图。
具体实施方式
52.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
53.参照图1所示，本发明的实施例提供了一种软件架构优化方法，该方法可包括以下步骤：
54.101、基于分布式架构中每个服务组件和其他服务组件间的调用关系，构建静态调用关系网络。
55.静态调用关系网络模型是指从代码调用形成的依赖关系角度对软件架构建立模型。其中静态调用关系网络模型的主要数据来源由两部分组成，其中分布式架构下的所有代码库源码，代码库中的代码在接口层和对外接口调用层符合代码规范，从而更加便于进行解析。通过对代码中接口露层和外部调用层构造语法树，确定每个服务组件对外暴露的资源(连接接口)，以及每个服务组件通过调用对其他服务组件形成的依赖情况。对分布式架构中每个服务组件均进行以上的操作，将每一个服务组件连接起来，形成基于接口调用的静态调用关系网络。从提取开发提交记录形成的关于修改的服务密集程度，能够发现在实际需求实现的时候所呈现的紧密联合的关系，将形成的开发人员的二分网络在服务组件的方向进行投影，能够形成从需求实现角度的服务聚合接口。从而形成了表征分布式架构静态结构的静态调用关系网络，通过对软件架构的代码层面进行建模，从代码结构的角度对架构进行分析，不依赖于运行环境和运行数据，能够在代码层面进行建模，只要在代码层面发生了调用关系转变，就可以反映到静态调用关系网络中。
56.102、基于代码库的代码提交记录构建第一二分网络。
57.开发软件系统的团队一般由不同角色、不同技能的成员组成，团队在进行软件需求的变更时，会由于任务编排或者分工模式在团队内产生不同的聚集度更好的小群体。即团队中不同成员的组合以及不同组合之间在系统开发层面形成的互相依赖和制约的关系。从团队所有开发人员的代码提交记录，建立开发人员和代码库之间的拓扑结构。在形成的二分网络中只存在两种类型的节点，一类代表开发人员，另一类为代码库，且关联关系仅存在于不同类型的节点之间。
58.103、将第一二分网络向开发人员方向上进行单模映射，得到表征各开发人员间协作关系的团队分工结构。
59.将得到的第一二分网络向开发人员方向上的开发人员进行投影映射，得到代码库相对于开发人员的无向图，基于图的基本特征值，如度数和度数分布即可对代码库的操作关系进行认定。可用于帮助团队管理人员对代码库的操作进行分工协作。
60.104、将第一二分网络向代码库方向上进行单模映射，得到表征各服务间修改关系的服务联动修改关系网络。
61.将得到的第一二分网络向代码提交方向上的开发人员进行投影映射，得到开发人员相对于代码提交方的无向图，基于图的基本特征值，如度数和度数分布即可对开发人员的重要程度进行认定。可用于帮助团队管理人员重新定义团队结构和调整分工内容。
62.105、基于开发人员之间的沟通信息构建沟通信息对应的沟通方式和开发人员之间的第二二分网络。
63.软件开发团队的沟通效率很大程度上决定了团队工作的时效性。对开发人员来说在以编码为主要内容之外的开会、邮件、及时消息等占据了绝大部分的时间，提取能够反映沟通信息和沟通结构的数据，来可视化分析团队的沟通结构。能够判断团队的沟通结构。
64.106、将第二二分网络向所述开发人员方向上进行单模映射，得到用于表征所述开
发人员间沟通紧密程度的沟通结构。
65.向参与开发的团队人员的方向进行投影映射，即可得到表征团队人员之间沟通关系的示意图，在该示意图上应用聚类算法进行聚类，可得到工作内容相关的群体，从而能够辅助管理者对形成的小群体进行管理。
66.107、生成架构优化的参考信息，参考信息是软件架构优化的基础，参考信息至少包括：静态调用关系网络、服务联动修改关系网络、团队分工结构和沟通结构。
67.以得到的参考信息为参考，通过四种图结构的特性表征的软件架构的架构特性，能够对软件架构进行更加客观和科学的治理。在具体实施时可依据康威定律以及康威逆定律，在软件系统的团队结构，沟通结构和软件静态架构的边界上出现不一致的情况，则会出现更多的无效沟通以及信息传递的错误。因此可通过四种拓扑结构的相似度，来对软件进行优化。参考图同构的基础理论，可通过对比四种拓扑结构中节点数目，节点的出入度等依据相似度的大小进行判断。例如通过判断对拓扑结构进行聚类后的数量是否一致；团队结构的聚类和沟通结构的聚类，团队结构的聚类与沟通结构的聚类，是否包含同样的代表提交方的节点；团队结构和软件架构的聚类，团队结构的聚类与软件架构的聚类，团队结构的聚类是否与软件架构的聚类之间有对应关系，如团队结构中划分为3个聚类a、b、c，软件架构静态架构的划分也是三个聚类d、e、f，如果a所负责的代码库正好都出现在d中，则满足权责关系，当三个聚类分别对应一致时，则结构的相似度高，说明软件的架构更加的合理。
68.本发明所提供的软件架构优化方法通过对代码结构以及对研发过程中产生的数据进行图论建模、分析和可视化呈现，解决了传统架构强依赖于个人能力、缺少统一认知的架构设计原则和方法等问题，并且对架构的优良指标有了更加客观、更加科学的判断，对软件架构的优化更加的合理准确。
69.为进一步优化该技术方案，在本发明的另一具体实施例中，参考信息还包括：动态调用关系网络，参照图2所示，动态调用关系网络的构建过程可以包括以下步骤：
70.201、获取分布式架构运行时的调用链追踪数据。
71.202、基于调用链追踪数据构建服务组件的动态调用关系网络。
72.其中，参照图4所示，基于调用链追踪数据构建服务组件的动态调用关系网络，可包括以下步骤：
73.401、确定调用链追踪数据中追踪标签的类型。
74.402、基于追踪标签的类型确定调用关系的调用方和被调用方。
75.403、将调用方与所述被调用方作为节点，追踪标签作为关联关系，相应的调用链追踪数据的标识作为关联关系的属性构成调用关系图。
76.其中，对参与实现微服务功能的调用链进行聚合，若两个调用链追踪数据的标识不相同，但都具有相同的微服务参与节点且所述参与节点的调用顺序相同，则将两个调用链合并为一个路径。
77.具体的，软件架构的动态调用关系网络图是从软件系统运行时的调用链追踪数据，调用链追踪数据形成的分布式组件关系图。对于分布式架构的调用链追踪数据的获取以jaeger工具输出的内容最为常见，其数据格式符合opentracing协议。首先根据调用链追踪数据每条span(追踪标签)记录的信息，确定标签的类型，如db查询、http调用、异步调用、rpc调用等。然后根据不同的标签类型，确定调用关系的调用方和被调用方。最后将调用方
和被调用方作为节点，相应的标签作为关联关系，相应的traceid(追踪标识)作为关系上的属性，映射成动态调用关系网络。
78.其中根据标签的相关信息如日志中的核心字段、实例数、实例ip对网络图中节点的属性进行补充。通过每个标签上所携带的引用信息，构建各个调用关系间的引用。例如spanb携带childof：spana的引用信息，则构建spanb.upstream:spana的关系，进而将拓扑结构映射成关联关系的拓扑结构。
79.对各个节点间的调用关系进行聚合，得到调用链路。其中对于任意两个不同的追踪标识的请求，如果都拥有完全相同的微服务参与节点，完全相同的微服务间调用顺序，则认为两个调用关系属于同一个调用链。
80.具体的，对于系统中的每一次调用，仅保留核心的调用序号、调用方和被调用方，进而构建调用顺序模型，调用顺序模型可描述为：
81.《调用顺序》：(调用方)，(被调用方)；
82.创建一个模型池对所有的调用顺序模型进行存储，模型池是一个哈希键值对字典，模型的字符串为键，模型具体信息为值，使用字符串进行匹配搜索，如果模型池中不存在对应的模型，则向模型池添加新模型键值对，否则则对模型进行合并。
83.若任意两个调用链路构建的调用顺序模型完全相同，则认为他们属于同一个调用聚合，对其进行合并依次进行：合并调用链路，增加调用链路的调用次数作为权重，添加原始数据的追踪标识作为参考。直至所用的调用均被处理。然后以起点为调用方，终点为被调用方，以调用方和被调用方间连接线的粗细表示调用次数(线形越粗则调用次数越多)，进行连接得到动态调用关系网络图。然后可基于图的指标对架构进行优化，其中：
84.度数：描述网络中节点最重要的参数。节点度数越高，在架构中位置越重要。对于不同度数的服务节点，结合其他局部指标，对网络中出现的所有分布式服务进行分级，制定不同的运维策略以及架构治理计划。还可通过合理的拆分节点，降低服务的度数，从而消除架构瓶颈。
85.度数分布：度数分布可以用于定义一个网络的特性。度数分布刻画了网络中节点的连通性，重用度和复杂度，也可以用于衡量系统的不平均结构。
86.模块度：评价聚类算法的结构化程度。
87.边数：图网络中的边数综合。
88.平均路径长度：图网络的有效尺寸。应用于评估系统消息传递的设计与优化、对象间通信代价的评估与控制、系统响应能力的改进等方面。对于平均路径长度非常长的网络，意味着分布式架构下调用深度过深，链路太长可能导致响应时间过长，链路上的每个节点都有可能成为影响架构稳定性的因素。可以以降低路径长度为目标，对网络结构进行调整。
89.中心性：反映网络中各节点的相对重要性。
90.介数：被“经过”的重要程度。介数可以分析任意一个组件和组件之间的关系在被删除或失效时对整个系统的影响，提供系统单点瓶颈的量化判断依据，指导改进。对于节点负载分布差异非长常大的网络，制约其稳定的瓶颈就是节点的最大介数。
91.对于介数较大的服务节点，可以通过服务拆分，职责转移的办法，降低核心节点的介数值，达到全局的优化。
92.聚类系数：网络有多“紧密”。反映了系统中不同的组件的内聚程度以及系统组织
分层(层次化)的趋势。
93.度度相关性：实际图网络中，节点度数与相邻节点度数存在相关性。用于判断网络结构是同构或者异构。
94.连通度：用于评估一个网络的连通性，连通度越大则连通程度越好。
95.通过上述指标可对软件架构的动态结构性能进行准确的衡量，划分业务边界，用于后续做架构治理的多图的结构性对比。
96.作为上述实施例可行的实现方式，参照图3所示静态调用关系网络的构建过程可以包括以下步骤：
97.301、对分布式架构的源代码构造语法树。
98.将输入的代码文件列表进行解析得到java代码，将代码转换为dst语法树，对树形结构中的代码对外部提供接口和调用第三方服务接口的代码进行识别，然后在得到的class类注释寻找服务地址作为服务标识，寻找调用方领域对象，建立外部调用对应关系模型，将外部调用对应关系模型写入neo4j(图形数据库)。
99.302、对语法树进行解析，得到服务组件对外提供的接口资源以及与其他服务组件的调用关系。
100.在图形数据库中对上述识别出的代码通过唯一标识进行关联。
101.303、将每个服务组件的接口资源通过调用关系与其他服务组件连接，构成静态调用关系网络。
102.通过唯一标识对服务组件进行连接得到调用关系的网络图。
103.在具体实施时，静态调用关系网络数据来源主要为代码提交记录，提交记录中至少要包括提交人员的名称，邮箱，时间，提交的代码库等信息。按照时间窗口切分所有代码提交记录，高频次的提交可以为以天为单位设置为时间窗口。由于开发者需要在不同服务间进行提交，所携带的隐性知识构成了系统的复杂度，也行成了子系统间的关系，以服务和开发人员为节点，关系从开发人员到代码库按照提交记录信息构建一条代表提交的关系。在分布式架构所包含的多个服务上同时工作的开发团队就形成了项目间的连接关系。将构建出来的包含开发人员和服务两类节点的网络即二分网络向服务节点类型上进行投影，得到基于修改关系的关联关系图。
104.基于静态调用关系网络的优化，主要包括：
105.服务范围：每一个服务组件具体向外暴露哪些资源或者服务组件通过接口提供哪些功能。通过分析每个服务节点的服务范围，可以识别服务节点间重叠的服务范围部分，进而消除重叠部分，使得每一个服务节点拥有一个高度内聚并且不与其他节点重叠的服务范围，提高架构内聚性，减少新增需求时代码的“散弹式修改”。
106.服务间耦合度：通过对服务间api调用关系的多与少，可以一定程度判断出不同微服务之间的耦合关系，识别关系紧密的服务节点群。此时可以从业务和技术两方面考虑
107.服务合并：采取服务合并的措施后，可使得架构调用结构简化，服务间耦合度降低。
108.功能边界：对形成的服务组件依赖关系网络中，提取服务节点，筛选掉资源节点。在新的服务组件节点构成的网络上应用聚类算法，形成社团划分。确定静态模型的边界。对于不同的社群，可以采取不同的运营和开发方式；而对于社群间的边界可以指定相关的交
互策略，以规范社群间的沟通模式。
109.服务度数：服务在架构中的重要程度。服务度数越高，说明该服务在架构中越重要。
110.对于度数高的服务可以进一步分析其原因，如果业务和技术允许，对节点进行拆分，
111.降低服务节点的度数，进而消除架构瓶颈；对于不能拆分的服务节点，指定测试策略，保证该节点在架构中的高可用性。
112.参照图5所示，将第一二分网络向开发人员方向上进行单模映射，得到表征各开发人员间协作关系的团队分工结构的过程可包括以下步骤：
113.501、若第一二分网络为连通图，则将得到的连通图向开发人员方向上进行单模映射，得到连通图的单模映射图。
114.502、若第一二分网络为非连通图，则获取非连通图的所有子图，对每一个子图进行开发人员方向上的单模映射。
115.503、对非连通子图产生的单模映射图进行合并，得到非连通图的单模映射图。
116.504、基于预设社区发现算法对连通图的单模映射图和非连通图的单模映射图进行聚类，得到团队分工结构。
117.具体的，在得到代码提交记录csv文件后，按照配置的迭代周期拆分数据，为每个迭代准备一个数组进行存储，对代码提交日期小于配置的结束周期内的数据进行处理，计算该数据位于迭代的位置，然后提取提交目的代码库信息、开发人员名称信息，在数组的相应位置中创建代表开发人员的节点和代码库节点，以及两个节点的提交关系。对图数组进行二分网络判断和连通图的判断，获取非连通图的所有子图，遍历所有子图，对每一个子图做单模映射。合并非连通子图产生的单模映射图。最后合并图数组中所有单模映射的图，应用louvain算法分别形成关于开发人员和代码库的聚类结果。计算开发人员和代码库两个图的度数、平均度数以及度数累积分布。
118.在投影的开发人员方向上形成的图为无向图，代表开发人员的节点与节点之间的关联关系没有方向含义，所以整个图为无向图。对该无向图使用图论中的基于模块度的社区发现算法，该算法的优点是在较短时间内实现大规模网络以不同粒度的社区划分，无需指定社区数量。返回计算能力范围内最大模块度的值。模块度的值范围在[-0.5，1]之间。模块度值在0.3-07之间，认为该团队结构内聚度较好，分工明确。
[0119]
根据开发人员关联关系的无向图，可以计算图的基本特征值。主要关注度数和度数分布。开发人员的度数越大，认为该人员在团队中的位置越重要。重要主要意味着两种可能性，第一是该人员承担了核心内容，是该团队中能力最好的人。第二则该人员工作内容分散不聚焦，打杂性质的任务居多。这种情况下，一般伴随着社区发现算法的模块度值较低的情况一起发生。可用于帮助团队管理者重新定义团队结构和调整分工内容。
[0120]
参照图6所示，在本发明的一些具体是实施例中，将第二二分网络向开发人员方向上进行单模映射，得到用于表征开发人员间沟通紧密程度的沟通结构，可包括以下步骤：
[0121]
601、若第二二分网络为连通图，则对开发人员进行单模映射，得到沟通结构。
[0122]
602、若第二二分网络为非连通图，则对非连通图的子图中的开发人员进行单模映射。
[0123]
603、对非连通图的子图的单模映射图进行合并，并基于预设社区发现算法对合并得到的单模映射图进行聚类，得到沟通结构。
[0124]
具体的，以参加的会议为例，对包含会议信息的csv数据进行记录条数的提取，从中提取出当前会议主题、日期和参会人员，将参会人员作为数组，以会议主题和日期作为名称创建节点，遍历参会人员数组，创建参会人节点，根据会议主题确定节点间的关联关系。若得到的图进行二分网络图和连通图的判定，获取非连通图的所有子图，遍历所有子图对每一个子图进行参会人员的单模映射，合并非连通子图产生单模映射图，应用louvain算法进行聚类，得到沟通结构的划分。
[0125]
基于同样的设计思路参照图7所示，本发明的实施例还提供了一种软件架构优化装置，该装置可以执行上述实施例所述的软件架构优化方法的各个步骤，该装置可以包括以下模块：
[0126]
静态调用关系网络模块701，用于基于分布式架构中每个服务组件和其他服务组件间的调用关系，构建静态调用关系网络。
[0127]
第一二分网络模块702，用于基于代码库的代码提交记录构建第一二分网络。
[0128]
团队分工结构模块703，用于将第一二分网络向开发人员方向上进行单模映射，得到表征各开发人员间协作关系的团队分工结构。
[0129]
服务联动修改关系网络模块704，用于将第一二分网络向所述代码库方向上进行单模映射，得到表征各服务间修改关系的服务联动修改关系网络。
[0130]
第二二分网络模块705，用于基于开发人员之间的沟通信息构建沟通信息对应的沟通方式和开发人员之间的第二二分网络。
[0131]
沟通结构模块706，用于将第二二分网络向所述开发人员方向上进行单模映射，得到用于表征开发人员间沟通紧密程度的沟通结构。
[0132]
参考信息生成模块707，用于生成架构优化的参考信息，其中参考信息是软件架构优化的基础，参考信息至少包括：静态调用关系网络、服务联动修改关系网络、团队分工结构和沟通结构。以及
[0133]
动态调用关系网络模块708，用于获取分布式架构运行时的调用链追踪数据；
[0134]
并基于调用链追踪数据构建所述服务组件的动态调用关系网络。
[0135]
该软件架构优化装置在运行时，具有和上述软件优化方法相同的有益效果，其具体实现方式可参照上述实施例所述的软件优化方法，本发明在此不再赘述。
[0136]
本发明的实施例还提供了一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时，实现如上实施例所述的软件架构优化方法的各个步骤。
[0137]
本发明上述实施例所提供的软件架构优化方法、装置和存储介质，对软件架构的优化治理相较传统的架构治理更加全面和广泛，并能够辅助解决传统架构治理无法覆盖的问题域，如架构模拟、架构智能预测等。并且由于本发明所需处理的数据源来自软件研发过程本身，故在软件迭代的整个生命周期中，均可对架构进行建模、诊断和治理，不会收到人员变动、人员经验和团队关系等非技术性因素的影响。
[0138]
对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描
述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
[0139]
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0140]
本发明各实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减，各实施例中记载的技术特征可以进行替换或者组合。
[0141]
本发明各实施例种装置及终端中的模块和子模块可以根据实际需要进行合并、划分和删减。
[0142]
本发明所提供的几个实施例中，应该理解到，所揭露的终端，装置和方法，可以通过其它的方式实现。例如，以上所描述的终端实施例仅仅是示意性的，例如，模块或子模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个子模块或模块可以结合或者可以集成到另一个模块，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0143]
作为分离部件说明的模块或子模块可以是或者也可以不是物理上分开的，作为模块或子模块的部件可以是或者也可以不是物理模块或子模块，即可以位于一个地方，或者也可以分布到多个网络模块或子模块上。可以根据实际的需要选择其中的部分或者全部模块或子模块来实现本实施例方案的目的。
[0144]
另外，在本发明各个实施例中的各功能模块或子模块可以集成在一个处理模块中，也可以是各个模块或子模块单独物理存在，也可以两个或两个以上模块或子模块集成在一个模块中。上述集成的模块或子模块既可以采用硬件的形式实现，也可以采用软件功能模块或子模块的形式实现。
[0145]
专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
[0146]
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件单元，或者二者的结合来实施。软件单元可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。
[0147]
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排
除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0148]
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。