畅远数码|先要对微服务进行度量,进行微服务治理( 四 )


如果一个方法类的结构比较复杂 , 例如它有IF…ELSE关系或者FOR循环等嵌套调用关系 , 也可以用JDT识别 , 将这种关系在调用线条上列出 。 这样就能清楚地知道这是一种分支调用关系还是一种循环调用关系 。
由于扫描的是所有相关工程的代码 , 一张图上就包含了所有层级的服务或系统之间的RPC调用关系 。 通过包名来对不同的业务层级(前台、中台、后台)进行识别 , 并为不同包名的图形单元赋予不同的颜色 , 通过颜色的区分可以清楚地知道一个方法的调用究竟涉及多少个系统 , 在每个系统中的入口是什么、出口又是什么等 。
这里存在一个问题 , 就是如何将源码扫描获取到的类方法(微服务的API)与需求/开发任务管理系统中的UserStory和Task关联上?可以强制要求在微服务API入口方法(或者微服务类声明)的注解(例如JavaDoc)上标注UserStory和Task的ID , 扫描源码时通过对注解的解析即可将方法和需求或任务进行关联 。 不用担心开发人员不标注或者忘了标注 , 因为我们可以通过比对需求列表和源码的映射关系来监控开发人员是否贯彻了注解标注规范 , 如果有需求没有找到对应的方法或API入口 , 即可自动通知相应的开发人员及时修改 。
有了以上信息 , 通过对最终构建出来的大调用矩阵不同维度的分析 , 可以获得很多微服务的开发及设计质量方面的度量信息 , 包括请求的调用链深度、服务间的依赖程度、服务的粒度等 。 这些度量信息将会作为微服务治理的度量及判定依据 。
作者:李鑫本文节选自《微服务治理:体系、架构及实践》一书


推荐阅读