search

servicemesher / gitalk

Website comments register
5 stars 0 forks source link

蚂蚁金服开源的 SOFAMesh 的通用协议扩展解析 · Service Mesh|服务网格中文社区 #167

Open rootsongjc opened 5 years ago

rootsongjc commented 5 years ago

https://www.servicemesher.com/blog/ant-financial-sofamesh-common-protocol-extension/

本文作者是蚂蚁金服中间件团队的高级技术专家邵俊雄（熊啸），主要负责 SOFAMesh 的开发工作。本文是基于作者在 Service Mesh Meetup #3 深圳的主题分享《SOFAMesh的通用协议扩展》部分内容所整理，完整内容见文末的直播回放。

wjliuh007 commented 5 years ago

直播回放被外星人抓走了，

rootsongjc commented 5 years ago

@wjliuh007 直播回放被外星人抓走了，

时间太久远了，之前用的那个直播供应商不维护了。

liyork commented 4 years ago

您好，咨询一下，您的意思是不是，基于目前已有的框架，如dubbo，暂时先兼容一个进程多个interface的情况，每个server启动时先动态修改所在pod上的label，将此业务container的interface都贴上，然后在client端所在pod，用coredns建立interface到clusterip的关系，这样就能基本复用k8s的语义了，后期再推动k8s上的微服务化，即一个pod一个服务，这样pod上的label也就只有一个了。

liyork commented 4 years ago

还想请教下，感觉基于k8s的一个pod一个服务一个进程的概念，似乎有些不太符合领域模型或者微服务的高内聚设计， 是不是中间件要下沉到基础层，但是对于service可能另有定义，而且像sofa-registry这种大规模的已验证的方案，也完全通过扩展方式adapter注入，这样各司其职，也挺好，不一定非得按照k8s的固定模式走，是么。提出了可扩展，可能就是为了各方面的要求，我之前看敖小剑老师分享的，中间件充分下沉，还有看到有说充分利用地层容器的资源，感觉对于这个服务发现以及注册方面，反倒是用扩展好一些呢，求指教，谢谢您。

junxiong commented 4 years ago

@liyork 还想请教下，感觉基于k8s的一个pod一个服务一个进程的概念，似乎有些不太符合领域模型或者微服务的高内聚设计， 是不是中间件要下沉到基础层，但是对于service可能另有定义，而且像sofa-registry这种大规模的已验证的方案，也完全通过扩展方式adapter注入，这样各司其职，也挺好，不一定非得按照k8s的固定模式走，是么。提出了可扩展，可能就是为了各方面的要求，我之前看敖小剑老师分享的，中间件充分下沉，还有看到有说充分利用地层容器的资源，感觉对于这个服务发现以及注册方面，反倒是用扩展好一些呢，求指教，谢谢您。

这是我们之前尝试的方案。 你的想法很好，不过我们现在的想法会比社区更进一步，MCP 协议将会扮演关键角色，我们会在 MCP 协议上增加对服务发现的支持，Pilot 将会从 MCP 服务，比如 Galley 获取服务发现数据，不再直接 watch / list kubernetes api server。

我们会推动注册中心向 MCP Server 的方向演进，nacos，sofaregistry 都将会具备 支持 MCP 协议的能力，成为 Pilot 的数据源。当 Pilot 通过 MCP 协议从注册中心获取服务发现数据时，服务的粒度将会是接口级别。

对于不支持 MCP 的注册中心，需要和社区一同开发适配用的 MCP adapter 独立进程，使其成为 Pilot 的合法数据源，比如 zk 或者 consul。

开源版下半年会逐步把这些能力都开放出来的。

欢迎给 sofamesh，sofa registry 以及 nacos 等项目贡献 MCP 相关的代码。

liyork commented 4 years ago

我先整理下，思路好像您的说法和本身云原生的利用k8s的思路有些冲突，先谢谢您回头我整理下再向您请教，sofa-registry有过了解，有些笔记，只不过很散乱，登不上大唐哈哈