正文
Q3: Service Mesh 落地最大挑战是什么？目前进展如何？
敖小剑:
目前我们的 Service Mesh 落地的一个基本条件是要在蚂蚁金服主站这样一个规模场景下落地。所以我们的关注点可能就会跟开源社区不太一样：必须要考虑到在这样的规模下，我们能够真真切切地落地下来。最大的挑战在性能方面。目前，Service Mesh（比如像典型的 Istio）的性能表现不是特别理想。如果直接落到蚂蚁金服上的话，在性能上很难承受我们这样的规模。
然后，涉及到另外的实际场景，比如我们内部现有的一些非常成熟而且基本上已经铺开的框架，比如 SOFARPC。这些框架在迁移到 Service Mesh 的过程中，就会有平滑过渡的要求。因为我们必须要保证我们这些海量应用，它们的迁移过程在业务上必须是平滑的，而且期间的工作量、改动量最好不要太大。这对我们是一个比较大的挑战。
另外还会涉及到平台的问题。比如说现在的 Istio，其实它比较关注的是 K8S 这样一个比较理想化的平台，确实 K8S 的支持会让 Istio 的很多事情变得比较轻松。但是落地的实际情况是, 蚂蚁金服目前在 K8S 上还没有完全普及，还有一部分应用暂时还在非 K8S 的环境中运行。在这种情况下，需要在往 Service Mesh 技术的迁移过程中，可以提供对非 K8S 环境的支持，以便完成过渡。
再有就是私有协议支持，比如我们的 SOFARPC，这个已经在内部大规模使用，那么我们需要在标准的 Service Mesh 解决方案里加入这些协议的支持。
这是目前几个比较大的挑战。
大家可能比较关心现在内部的进度。目前我们 Mesh 最基本的 Proxy 部分基本上已经开发完成，我们会用它来替换原有的一些多语言客户端，比如说 C++ 的客服端、nodejs 的客户端。这样，我们会先完成最基本的对多语言的支持。
在这个基础上，我们目前正在实现对 Envoy 的 XDSAPI 的支持，为后面对接 Istio 做准备，这个工作正在开发过程中。后面我们也正在做一些私有协议的支持，包括特殊场景的支持。比如说我们对 Pilot 的改造，这些目前都正在开发当中。
曾彬：
我来补充一下，其实集团现在在 Service Mesh 有挺多团队，都是在一个探索的过程。UC 的特点就是 K8S 做的相对早一些，所以 K8S 落地相对比较完整，应用往上迁移的程度也是比较高的。然后在成本或在效率上拿到了一些红利，也从社区、CNCF、项目里看到了未来我们可能的一些方向。所以我们很看好 Service Mesh 这个方向，这算是一个背景吧。
Q4: 几位老师一直提到 K8S，那可以具体聊聊 K8S 和 Service Mesh 两种技术之间的关系吗？
曾彬：
首先，先从复杂度层面来说，我觉得 Service Mesh 由于有 Sidecar 的引入，肯定会带来运维上的复杂度。K8S 的 Pod 作为一种基础设施，里面可以天然地支持多个 Container，来支持这种 Sidecar 技术，对运维是非常大的帮助。然后再加上它对资源细粒度的控制，比如说 CPU、内存资源的控制，以及像权限控制 RBAC 方面的一些功能，我们觉得这些都对简化复杂度有很大的帮助。
第二点就比较通用一点，原来的应用程序如果没有跑在 K8S 的话，它的元数据信息对整个外部系统是不可见的。如果把这个程序放到 Pod 里面之后，因为 Pod 是在 K8S 上运行，本身是带有元数据的，比如说 label，如果我们把这些元数据对外部可见，让它开放了，这样不仅对于 Service Mesh，而是面向整个上层的 K8S 生态开放了，应用本身能拿到更多的红利，这是我的两点看法。
敖小剑：
我稍微补充一下，昨天晚上我们夜话活动的时候，讨论到 Service Mesh，当时有很多同学也谈到这个问题，就是说——上 Service Mesh 之前，是不是一定要先上 K8S？这个话题当时有过讨论，大家的一致想法是：从技术上讲是不限制的，因为 Service Mesh 从理论上讲，底下可以不是 K8S。但是从长期的发展上说，K8S 可以给 Service Mesh 提供非常大的支持。所以，从远景上说，K8S 跟 Service Mesh 未来长期的发展路线是必然结合着使用的。
Q5：那 K8S 在落地的过程中，有什么问题和挑战吗？
毛小云：
这个我来回答一下，刚刚小剑和曾彬也提到了，K8S 是支持 Service Mesh 比较理想的方案。但是落地 K8S 会有比较多的问题跟挑战，我就分享一下蚂蚁在这方面的一些经验。
要落地 K8S，比如说蚂蚁在 Docker 化之前，其实蚂蚁内部的虚拟化技术基本上可以分成两种。一种是基于 VM 的或者是基于 LXC 这种形式的，然后基于这种 LXC 和 VM 的形式，我们也建立了一整套相应的运维体系。我们面临的一个比较明显的挑战是，我们原有的这些运维体系，如何比较平滑地迁移到这种容器化的体系上来。在迁移到容器化体系的过程中，我们会遇到各种各样的问题，比如像类似于镜像的问题。还有比如一些有状态的应用，Dockerfile 的问题，Dockerfile 的运维模式，其实跟我们原有的运维模式是相冲突的。蚂蚁金服在这方面，比如镜像方面，做了蛮多的工作。比如说有一些 P2P 的加速方案，以及有一些做了镜像云化的这种能力，去加速镜像。在这个 Dockerfile 的运维上面，我们也做了一些适配，能够降低研发成本的复杂度，这是第一个阶段的挑战，相当于是容器化的挑战。
