服务调用方：使用RPC库进行服务寻址，实时从服务发现系统那边获取最新的服务调度策略 。
文章插图
有了这套服务发现系统以及搭配使用的RPC库之后，来看看现在的服务调用是什么样的 。
- 写业务逻辑的，再也不用
文章插图
ServiceMesh
架构发展到上面的程度，实际上已经能够解决大部分的问题了 。这两年又出现了一个很火的概念：ServiceMesh，中文翻译为“服务网格”，来看看它又能解决什么问题 。
前面的服务发现系统中，需要一个与之配套的RPC库 ， 然而这又会有如下的问题：
- 如果需要支持多语言，该怎么做？每个语言实现一个对应的RPC库吗？
- 库的升级很麻烦，比如RPC库本身出了安全漏洞，比如需要升级版本 ， 一般推动业务方去做这个升级是很难的，尤其是系统做大了之后 。
文章插图
在服务mesh化之前，服务调用方实例通过自己内部的RPC库来与服务提供方实例进行通信 。
在服务mesh化之后，会与服务调用方同机部署一个local Proxy也就是ServiceMesh的proxy，此时服务调用的流量会先走到这个proxy ， 再由它完成原先RPC库响应的工作 。至于如何实现这个流量的劫持，答案是采用iptables，将特定端口的流量转发到proxy上面即可 。
有了这一层的分拆，将业务服务与负责RPC库作用的Proxy分开来 ， 上面的两个痛点问题就变成了对每台物理机上面的mesh proxy的升级维护问题，多语言也不是问题了 ， 因为都是通过网络调用完成的RPC通信，而不是进程内使用RPC库 。
然而这个方案并不是什么问题都没有的，最大的问题在于，多了这一层的调用之后，势必有影响原来的响应时间 。
截止目前（2019.6月），ServiceMesh仍然还是一个概念大于实际的产品 。
从上面的演进历史可以看到，所谓的“中间层理论” ， 即“Any problem in computer science can be solved by another layer of indirection（计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决）”在这个过程中被广泛使用，比如为了解决IP地址难于记忆的问题，引入了域名系统 ， 比如为了解决负载均衡问题引入了网关，等等 。然而每引入一个中间层，势必带来另外的影响，比如ServiceMesh多一次到Proxy的调用，如何权衡又是另外的问题了 。
另外 ， 回到最开始的服务三要素中，可以看到整个演化的历史也是逐渐屏蔽了下层组件的流程，比如：
- 域名的出现屏蔽了IP地址 。
- 服务发现系统屏蔽协议及端口号 。
- PB类序列化库屏蔽了使用者自己对协议的解析 。
改变互联网的构建方式
推荐阅读
- 烧结工艺流程 烧结工艺
- 酒店针对高考期间的服务 酒店疫情期间高考该做什么
- 做包子的方法与步骤，开店做包子的流程？
- 个人咨询服务如何缴税
- 蜜丸的制作方法 蜜丸的制作方法与流程
- 曝二字影帝出轨，在KTV卫生间与嫩模亲热，被服务员撞见一丝不挂
- 乌龟的养殖方法 乌龟的养殖方法与流程
- 特殊病种门诊报销办理方法流程 特殊病种门诊怎么报销?特殊病种门诊报销比例是多少
- 免费dns解析服务器地址
- 失能老人补贴怎么申请流程 失能老人补贴怎么申请
- 如果需要支持多语言，该怎么做？每个语言实现一个对应的RPC库吗？
![[北京日报客户端]人气回暖！北京市购物中心等实体商业客流回暖率接近50%](https://imgcdn.toutiaoyule.com/20200505/20200505235931858447a_t.jpeg)
![[爆笑影视江小虾]二货夫妻笑话很有味](https://imgcdn.toutiaoyule.com/20200405/20200405203033257911a_t.jpeg)
