微服务架构体系的深度治理 什么是架构体系?( 六 )


以上就是针对微服务线上体系的治理 , 实际上 , 这些能力都是微服务的通用能力 , 很多微服务框架都具备 , 我这里只是重点介绍了我们的使用经验及心得 。 接下来我们来讨论一些更加硬核一点的内容 , 来看看微服务的线下体系的治理 。

【微服务整体架构治理】首先看一下针对微服务的整体架构的治理 。
先看第一个图 , 这个图是线上微服务集群服务间的调用关系总图 , 这个图可以通过动态调用链的汇总来获取 , 目前大部分公司都是这么干的;除此之外 , 还可以基于我前面介绍的静态调用链(调用矩阵)来获得 , 这个图只是静态调用矩阵的一个子集 , 通过静态调用链获取到的这个图中的调用关系会比动态调用链更多 , 有了这个微服务间的整体调用关系之后 , 我们就可以对微服务的调用质量进行深入的分析 。
服务是分层的 , 好的服务调用关系一定也是分层的 , 层层往下推进 , 最终形成一个有向无环图(DAG) 。 因此 , 可以对调用关系图进行闭环检测 , 如果检测到如图上G点到B点这样的回环调用的话 , 说明调用关系是有问题的 , 需要进行优化 , 这种回环调用也许现在无感 , 但难保未来哪天就会由于一条旁路逻辑导致死循环 。
还可以对整个调用网络进行遍历计算 , 找出所有调用深度最深的调用链 , 如图上红色标注出来的调用链 , 我们知道 , 对跨网络的调用访问 , 涉及到的网络节点越多 , 它的稳定性越差 , 可以将所有调用链路最深的这些链路找出来 , 并按调用深度进行topN排序 , 重点对排在头部的这些调用链分析它的必要性及合理性 , 看是否可以对调用深度进行缩减和优化 。
还可以找出整个网络中被调用最多的这些服务节点 , 比如图上的F节点 , 从调用关系上来说 , 它是被依赖最多的节点 , 自然是最重要的节点 , 作为枢纽节点 , 在运维等级上需要重点保障 。 当然 , 实际应用中 , 我们还会加上调用量这个权重来综合判定服务节点的重要性 。
随着架构的不断演讲 , 可能有些服务节点再不会有调用关系了 , 比如图上绿色的L节点 , 这些节点再不会去调用别的服务节点 , 别的服务节点也不会来调用它 。 这类被找出来的“孤零零”的节点 , 可以考虑对它进行下线处理 , 以释放资源 。
以上所有的度量和治理都是在这个调用关系图的基础上进行的 , 所用的算法也是图计算(图论)中的常用算法 , 包括BFS、DFS、PageRank等等 , 大家如果嫌麻烦 , 可以找个图数据库 , 比如neo4j , 这些算法已经集成在它的基本查询能力中 。
【单个微服务架构治理】微服务之所以被称为“微” , 一方面是它承载的业务比较单一 , 另外一方面 , 它在架构上也要尽量的做到自洽和内敛 , 也就是说 , 它的设计要尽量的遵循“迪米特法则” , 要尽量少的和外部的系统或者服务发生交互 。
可以通过调用链对微服务的对外调用关系进行梳理和分析 , 如果对外调用关系过多 , 比如说 , 如(页面中)上图所示 , 它如果调用了3个外部的系统或者服务 , 可能是正常的 , 但如果它对外调用了30个服务 , 那就要好好分析一下它承载的业务是否太多 , 是否不够纯粹 , 是否需要对它进行拆分 , 拆成多个服务 。
另外 , 既然同时具有动态调用链和静态调用链 , 完全可以将这两种调用链进行叠加 , 如(页面中)下图所示 , 红色部分是被动态调用链覆盖到的逻辑 , 非红色部分则是没有被触发的代码调用逻辑 , 这部分未触发逻辑中 , 有一部分是异常处理逻辑和旁路逻辑 , 可能是正常的 , 另外一部分则可能是版本兼容代码 。 比如说 , 线上APP有很多的版本 , 某个版本一旦下线 , 后台服务中针对此版本的兼容代码就成了冗余代码 , 需要进行清理 。 通过动态调用链和静态调用链的叠加 , 就可以相对方便的定期找出冗余代码进行清理 , 这样可以保证微服务的体量不会膨胀 。

【微服务开发质量度量及治理】
针对代码质量的管理 , 常规的做法除了代码的codereview外 , 一般还会使用Checkstyle , FindBugs , Jtest这类静态代码扫描工具来做代码的缺陷扫描 。 其实我们还可以做的更深入和更广一些 , 基于前面介绍的自定义代码扫描的技术 , 结合代码的调用关系 , 我们完全可以做到对跨类和跨方法的调用缺陷进行扫描 , 比如跨方法的多层循环嵌套 , 这类缺陷通过常规的代码扫描工具是扫不出来的 ,
除了代码质量之外 , 还可以结合线上bug的种类和数量 , 来综合评估开发人员的开发质量 , 因为 , 代码是人写的 , bug也是人制造出来的 , 通过结合开发人员开发的代码的质量 , 及他的产出物产生的异常等级(类型及数量) , 就可以对开发人员的开发质量进行综合的度量 。 当然 , 实际中还会结合其它的指标 , 但这两个是最主要的指标之一 。 通过这两个核心指标 , 可以生成研发人员开发质量综合评估报告 。

推荐阅读