Service Mesh之Sidecar

时间总是给你意外，在使用微服务架构吗？还在考虑使用哪种微服务架构呢？要准备大干一场，学习spring cloud吗？

还在纠结这些问题时，这些技术都将要被淘汰了，下一代微服务Service Mesh出现了

Service Mesh

简单介绍一下

这个词最早使用由开发Linkerd的Buoyant公司提出，并在内部使用。2016年9月29日第一次公开使用这个术语。2017年的时候随着Linkerd的传入，Service Mesh进入国内技术社区的视野。最早翻译为“服务啮合层”，这个词比较拗口。用了几个月之后改成了服务网格

定义

首先服务网格是一个基础设施层，功能在于处理服务间通信，职责是负责实现请求的可靠传递。在实践中，服务网格通常实现为轻量级网络代理，通常与应用程序部署在一起，但是对应用程序透明。

为什么

为什么需要这个呢？

当年EJB怎么下岗的，繁重，程序员压力山大

看看现在，如果要使用微服务架构，要关注哪些呢？

• 服务发现
• 负载均衡
• 路由
• 流量控制
• 通信可靠性
• 弹性
• 安全
• 监控/日志

对应spring cloud

如果去掌握每一个模块，是不是压力山大，留给业务的时间能有多少

而程序员真正需要关心什么呢？

serviceA --> serviceB

对应代码

//serviceA，让serviceB执行一下methodB,完成某件事

serviceB.methodB()

仅此而已，可却要花费很大的精力去关注上面的一大串

未来

再也不用关心那些基础设施，只关注服务调用

可能真的就像TCP一样

第一代网络计算机系统，最早的时候开发人员需要在自己的代码里处理网络通讯的细节问题，比如说数据包顺序、流量控制等等，导致网络逻辑和业务逻辑混杂在一起，这样是不行的。接下来出现了TCP/IP技术，解决了流量控制问题，从右边的图上可以看到，功能其实没发生变化：所有的功能都在，代码还是要写。但是，最重要的事情，流程控制，已经从应用程序里面抽出来了。对比左右两边的图，抽出来之后被做成了操作系统网络层的一部分，这就是TCP/IP，这样的话应用的结构就简单了

Sidecar

Sidecar这个东西出现的时间挺长的，它在原有的客户端和服务端之间加多了一个代理

Sidecar扮演的角色和代理很像，但是功能就齐全很多，基本上原来微服务框架在客户端实现的功能都会对应实现。

架构改造

sidecar模式到底好不好，可能还没有清晰轮廓，可以通过一个改造的过程再深刻体会一下

之前在《游戏灰度发布》中表述了在gateway与gameserver之间加一层proxy，以适应灰度发布的需要

现在再加上sidecar-proxy，整体的逻辑架构图就是这样的

proxy

这个proxy的意义：

1. 灰度发布
2. 路由功能，在需要发布时，热备一台gameserver，让proxy切换到热备机器
3. 限流，在来不及开服时，可以先限流，保证高可用；当然一般来讲，开服时都有充足的预备机器，不太需要；在有大型活动时，可以用来分流
4. 如果是世界服，这个proxy更有意义

sidecar-proxy

为什么需要这个proxy？

可以先设想一下，没有这个proxy，game-server在连接跨服时需要些什么？

1. 建立连接，序列化/反序列化
2. 路由功能，业务规则连接哪台跨服
3. 负载均衡，跨服流量均衡
4. 服务发现，增减跨服时，需要动态发现

如果想更新一下负载均衡算法，怎么办？想增加一些跨服治理的功能，怎么办？

只能等待发版时，跟随game-server升级更新

而且game-server会越来越臃肿，混合了大量服务治理的功能

有了sidecar-proxy，就可以把服务治理相关功能抽离出来，简化game-server,升级服务治理功能也及时方便

在《游戏灰度发布》也提到高可用时

如果ha-proxy挂了，怎么办？就算game-server正常运行，也不能再提供服务，自己坑了自己

所以这儿需要一个proxy-cluster，当sidecar-proxy不能正常工作时，需要无缝切到proxy-cluster

每台物理机上可以放一台sidecar-proxy，当不能正常工作时，会切到cluster；当sidecar-proxy正常时，再切回来。

具体实现细节，下回分解，show you the code！

参考资料

Service Mesh: 下一代微服务 - 视频

Service Mesh：下一代微服务 - 文字

VIP_OSP--基于Thrift的RPC框架的基本原理