时间总是给你意外，在使用微服务架构吗？还在考虑使用哪种微服务架构呢？要准备大干一场，学习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的意义：
- 灰度发布
- 路由功能，在需要发布时，热备一台gameserver，让proxy切换到热备机器
- 限流，在来不及开服时，可以先限流，保证高可用；当然一般来讲，开服时都有充足的预备机器，不太需要；在有大型活动时，可以用来分流
- 如果是世界服，这个proxy更有意义
sidecar-proxy
为什么需要这个proxy？
可以先设想一下，没有这个proxy，game-server在连接跨服时需要些什么？
- 建立连接，序列化/反序列化
- 路由功能，业务规则连接哪台跨服
- 负载均衡，跨服流量均衡
- 服务发现，增减跨服时，需要动态发现
如果想更新一下负载均衡算法，怎么办？想增加一些跨服治理的功能，怎么办？
只能等待发版时，跟随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！
