作为业内首个全托管Istio兼容的阿里云服务网格产品ASM，一开始从架构上就保持了与社区、业界趋势的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM产品是基于社区Istio定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了Istio组件与所管理的K8s集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。从2022年4月1日起，阿里云服务网格ASM正式推出商业化版本, 提供了更丰富的能力、更大的规模支持及更完善的技术保障，更好地满足客户的不同需求场景，详情可进入阿里云官方网站 - 搜索服务网格ASM。
网格拓扑是服务网格基于非侵入式的可观测指标方案提供的重要功能，网格拓扑可以为您梳理网格中服务之间相互调用的拓扑信息，帮助您实时观测流量状态、验证流量规则生效情况，以及实现流量重放等可观测高级能力。对于社区服务网格Istio来说，对应的开源项目kiali能够为服务网格Istio提供网格拓扑的展示能力。而在阿里云服务网格ASM中，同样也提供了对应的ASM网格拓扑能力，帮助您对网格的整体状况进行直观的观测。
在实际使用中，我们往往遇到网格拓扑的展示与预期不符，可读性较低的情况，比如：
- 本应连续的链路在中途中断
- 拓扑图中出现奇怪的unknown节点
- 一些服务没有展示出边或入边
- ……
发生上述情况，一般是由于网格中的Prometheus监控指标上报出现了一些不符合服务网格预期的情况，这可能是由于应用的一些不符合标准的配置、导致网格中的应用并未被可观测系统正确识别，或是网格中的一些配置导致指标未经上报、或上报信息有误所致。
我们以阿里云服务网格ASM为例，简单总结一下在ASM网格拓扑之中，采取何种之措施能够帮助提高网格拓扑的可读性。
1、服务网格中的应用程序应满足istio应用程序要求，参见：https://istio.io/latest/zh/docs/ops/deployment/requirements/
其中与指标上报最相关的部分：
带有 app 和 version 标签（label）的 pod：我们建议显式地给 Deployment 加上 app 和 version 标签。给使用 Kubernetes Deployment 部署的 Pod 部署配置中增加这些标签，可以给 Istio 收集的指标和遥测信息中增加上下文信息。
- app 标签：每个部署配置应该有一个不同的 app 标签并且该标签的值应该有一定意义。app label 用于在分布式追踪中添加上下文信息。
- version 标签：这个标签用于在特定方式部署的应用中表示版本。
2、保证应用的协议能够被正确选择，最保险的方法是显式为每个应用的服务端口进行命名，应用协议的选择对于网格拓扑等可观测能力展示正确的流量类型和流量信息至关重要，参考《协议选择》：https://istio.io/latest/zh/docs/ops/configuration/traffic-management/protocol-selection/#explicit-protocol-selection
3、打开所有指标监控。网格拓扑的加载主要依赖于SERVER侧指标的上报，但部分详细信息的展示依赖于CLIENT侧指标的上报。在服务网格ASM中，为减少客户资金消耗，默认不开启CLIENT侧指标的上报，如果希望展示所有可能的信息，则需要将所有指标的上报都打开。
注意：打开所有指标上报会增加指标量，可能造成ARMS Prometheus产品产生更多计费。
如何自定义监控指标上报，可以参考：https://help.aliyun.com/document_detail/389053.html?spm=a2c4g.147365.0.i1
4、为所有网格内工作负载注入Sidecar，并确保没有配置Sidecar不拦截某些入口或出口流量。流量必须被Sidecar正确拦截才能被识别并上报指标。
5、减少非业务请求对拓扑图的干扰。某些请求可能并非需要关注的业务请求，但仍然被Sidecar拦截到并上报了流量（比如健康检查请求、服务注册请求等）。由于网格拓扑无法识别哪些是业务请求，这可能会导致拓扑图被污染，比如流量的比例不正确/误判将流量定义为降级或错误。
建议：对于健康检查，开启健康检查重写，防止健康检查请求被拦截并上报指标，参考https://help.aliyun.com/document_detail/425532.html?spm=a2c4g.389053.0.i5。其它一些非业务请求的情况，则可能需要配置对于满足某些特征的流量不进行拦截，参考https://help.aliyun.com/document_detail/610989.html?spm=a2c4g.425532.0.0.7e3658648I3nid#p-dq9-4xa-kf7
6、检查服务网格实例中应用的Sidecar资源（Sidecar）或Envoy过滤器资源（EnvoyFilter），它们可能改变默认的指标上报规则，使实际上报的指标发生变化。例如，Sidecar资源可能将部分服务排除在Sidecar代理的服务发现范围之，导致服务之间调用的拓扑关系无法建立。EnvoyFilter可能改变原有的stats filter、或者修改路由过程中的filter配置，导致指标不会上报或者指标上报内容发生改变。
7、为集群外服务创建ServiceEntry，这将能够帮助网格识别发往集群外的流量的目标，引导网格为发往集群外服务的流量上报正确的指标，参考https://help.aliyun.com/document_detail/157264.html?spm=a2c4g.147516.0.i2
