ASM使用体验

篇名叫做使用体验，其实并不准确，目前来看纯粹是吐槽。

并不打算写一个 ASM 使用流程指南，毕竟 https://help.aliyun.com/document_detail/149552.html 才是更为专业的文档。

点击了 服务网格 ASM 的链接之后，映入眼帘的是错误提示

Aliyun API Error: RequestId: 08147C2C-9EE9-XXXXXX Status Code: 404 Code: EntityNotExist. Role Message: The role not exists: acs:ram::931204812349238:role/aliyuncsdefaultrole.

重试了一下，终于进来了，但是整个页面什么都没有：

最后发现服务公测中，还需要独立申请才可以使用，所以没有办法，还是先看一下文档吧。

产品简介

所谓的功能特性，应当和其它的服务网格产品差不多。

都是把服务网格划分为控制平面和数据平面。

ASM的优势在于兼容Istio，估计是在 Istio 的基础上，增加了支持 aliyun PaaS基础架构的内容。

从部署上看，依然是支持了混合云的环境，可以支持 Kubernetes集群、ServerLess集群和ECS虚拟机的混合部署。Proxy 与具体的服务进程在一起分享资源，并代理 Service 的出入流量。

共性的内容就不提了，既然作为公有云的一个主打产品，它的主要贡献应当在与组件的托管，可以通过简单的配置，就可以搭建起一整套服务网格，而不需要用户担心环境和配置的问题。

产品优势

目前来看ASM除了托管之外，其实没有什么额外的优势。相应的功能，包括流量路由、安全、监控都是社区版本已经提供的内容。高稳定性和高可用性，由于该产品本身就是公测版，所以暂且无法证实。

对于中小型厂商来说，没有足够的精力去维持一个团队，专门做一些细节的事情，譬如分5个人的团队来做混沌工程，7个人做可观测性、链路追踪，或者8个人的团队专门做RBAC的维护、mTLS的推进，因此ASM确实还是有一定的吸引力的。

应用场景就是把优势又冗长地说了一遍。

使用限制

有些内容务必在网格实例刚刚创立的时候，就配置好。譬如

变更网格所依赖的 VPC 与虚拟交换机
如果创建时未开启公网暴露 API Server，暂不支持增加公网 SLB 暴露 API Server
如果创建时未开启公网暴露 Istio Pilot，暂不支持增加公网 SLB 暴露 Istio Pilot
变更链路追踪服务配置
这些确实说明，在动态配置方面，PaaS做得还没有足够成熟。

不过这些问题，都可以用时间磨平，并不是太深层次的技术问题。

但是关于配额，目前还是有些夸张。

每个用户的可创建网格实例数：2

每个网格的Envoy代理数：建议200以下，超过 200 可能会造成网格实例的不稳定。

关于这个实例数，确实还是太小了。如果只是为了200个实例，那么确实控制面内部不需要做什么优化，主要是功能性的开发，而不用太关心性能的问题。

而且，适用场景上来看，ASM只能应对中小型企业的使用场景，在这个200个Envoy实例这个量级下，估计接口的QPS无法超过10万，一般只能适用于100万日活跃用户左右的App来使用。要将代理的规模突破一万，甚至一百万，可能还需要很多的努力。

规则修改

根据文档介绍，修改目标规则需要：

在控制平面区域的目标规则页签，找到待修改的目标规则，在操作列中单击YAML。
在编辑实例页面，修改目标规则，单击确定。
从这个介绍来看，控制平面的规则修改没有做到平台化，主要仍是通过配置文件的方式来进行管理。不过由于是社区版本，所以配置文件的格式应当与社区是一致的，这给有社区经验的配置者提供了一定的好处。

定价

公测版目前免费，未来还不确定。

由于 Service Mesh 目前的社区版还主要是面向中小型企业，而且很多都是尝试性地使用，所以估计不会有太高的定价。中小用户使用服务网格更多意义上是一个尝鲜，恐怕把主要业务都移动上来需要很大的勇气，暂时不看好两年以内的服务网格公有云市场。

其他

确实没有更多额外的信息了，等我的公测申请通过了，再来同步吧。