一篇讲解“服务调用”的良心之作( 四 )


多语言也不是问题了,因为都是通过网络调用完成的 RPC 通信,而不是进程内使用 RPC 库 。
然而这个方案并不是什么问题都没有的,最大的问题在于,多了这一层的调用之后,势必有影响原来的响应时间 。
截止目前(2019 年 6 月),Service Mesh 仍然还是一个概念大于实际的产品 。
从上面的演进历史可以看到,所谓的“中间层理论”,即“Any problem in computer science can be solved by another layer of indirection(计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决)”在这个过程中被广泛使用 。
比如为了解决 IP 地址难于记忆的问题,引入了域名系统,比如为了解决负载均衡问题引入了网关,等等 。
然而每引入一个中间层,势必带来另外的影响,比如 Service Mesh 多一次到 Proxy 的调用,如何权衡又是另外的问题了 。
另外,回到最开始的服务三要素中,可以看到整个演化的历史也是逐渐屏蔽了下层组件的流程,比如:
域名的出现屏蔽了 IP 地址 。服务发现系统屏蔽协议及端口号 。PB 类序列化库屏蔽了使用者自己对协议的解析 。可以看到,演进流程让业务开发者更加专注在业务逻辑上,这类的演进流程不只发生在今天,也不会仅仅发生在今天,未来类似的演进也将再次发生 。
作者:codedump
简介:多年从事互联网服务器后台开发工作 。可访问作者博客:/,阅读更多文章 。
作者:codedump来源:高可用架构

推荐阅读