学不动了古典、SOA、传统、K8S、ServiceMesh( 四 ) _SOA

K8S让资源调度变得自由，但微服务调度不是其所长也不应该由它深入实现
以Istio为代表的ServiceMesh做了K8S少的，但是微服务又必须的那块工作
Istio的设计方面和K8S极其相似，低耦合，抽象的很好，两者结合的也很好，我非常喜欢和赞同Agent+统一的资源管理配置下发的方式（K8S的Agent就是KubeProxy和Kubelet，Istio的Agent就是Sidecar Proxy），这是松耦合和高性能的平衡
在复杂的异构环境下，多协议的内部通讯，跨平台跨语言的内部通讯很常见，如果采用传统方式，框架太胖太重，把这部分工作从内部剥离出来好处多多

但是，可以看到目前ServiceMesh还不算非常成熟，Istio在不断优化中，Linkerd 2.x也想再和Istio拼一下，到底谁会胜出还难以知晓，经过之前Dubbo vs Spring Cloud的折腾，Mesos vs K8S的折腾，VM vs Docker的折腾，是否还能经得起折腾Istio vs Linkerd 2呢？我建议还是再看一看，再等一等。
7、畅想Everything Mesh模式？

文章插图

之前看到过ShardingSphere受到ServiceMesh的理念影响提出了DB Mesh的架构。其实DB Proxy的中间件已经存在很多年了（集中化的Proxy类似服务总线的方式），DB Mesh把Proxy也变为轻量的Sidecar方式，DB的访问也都走本地代理。那么这里我也在想，是不是有可能所有东西都有本地的代理呢？
作为应用服务本身而言，只需要和本地代理做通讯调用外部服务、缓存、数据库、消息队列，不需要关心服务和资源所在何地，以及背后的实际服务的组件形态。当然，这只是一个畅想了，对于有状态的资源，Mesh的难度很大，对于类似DB这样的资源因为调用层次并不复杂，也不太会存在异构场景，Mesh的意义不大，综合起来看Everything Mesh的投入产出比相比Service Mesh还是小很多。
8、Spring Cloud、K8S和ServiceMesh的关系如果搞JAVA微服务的话，Spring Boot是离不开的，但是是否要用Spring Cloud呢？我的观点是，在目前阶段如果没有什么更好的选择，还是应该先用。Spring Cloud和K8S首先并不是矛盾的东西，K8S是偏运维的，主要做资源整合和管理，如果彻底没有服务治理框架纯靠K8S的话会很累，而且功能不完整。开发和架构可以在Spring Cloud方面深耕，运维可以在容器和K8S方面发力，两套体系可以协作形成目前来说比较好的微服务基石。至于K8S的推行，这一定是一个正确的方向，而且和软件架构方面的改进工作一点不矛盾，毕竟K8S是脱离于具体语言和平台的。
至于Service Mesh，它做的事情和Spring Cloud是有很多重复的，在将来Istio如果发展的更好的情况下，应该可以替代Spring Cloud，开发人员只需要用Spring Boot开发微服务即可，客户端方面也可以很瘦，不需要过多关心服务如何通讯和路由，服务的安全、通讯、治理、控制都由Service Mesh进行（但是，是否有了Sidecar，客户端真的完全不需要SDK了呢？我认为可能还是需要的，对于Tracing，如果没有客户端部分显然是不完整的，虽然Sidecar是localhost但是还是跨进程了）。
Spring Cloud目前虽然针对K8S和Istio做了一些整合，但是并没看到一套针对ServiceMesh的最佳实践出来，是否将来Spring Cloud会在微服务这方面做退化给ServiceMesh让步还不得而知。总的来说，长期我看好Spring Boot + K8S + Istio的组合，短期我认为还是Spring Boot + K8S + Spring Cloud这么用着。
9、总结本文总结了各种微服务落地的形态，由于技术多样，各种理念层出不穷，造成了微服务的落地方式真的很难找到两家相同的公司，本文中我们介绍了：

客户端写死地址+F5代理的方式
客户端把地址配置在配置服务+Nginx代理的方式
SOA+集中式ESB的方式
传统的具有注册中心的服务框架SDK形式
服务框架+K8S方式
K8S Service Iptables路由方式
ServiceMesh代理3跳转发方式

当然，可能还会有更多的方式：

内部DNS方式（直接DNS轮询）
K8S内部服务走Ingress方式（内部服务也走Ingress，类似所有服务Nginx代理的方式）
ServiceMesh代理2跳转发方式（可以根据需要跳过远端的Sidecar来提高性能等等）
瘦服务框架SDK+ServiceMesh方式（也就是还是有一个小的SDK来对接ServiceMesh的Sidecar，而不是让应用程序自己发挥Http Client，这个方式的好处在于更灵活，这个SDK可以在这一层再做一次路由，甚至在Sidecar出问题的时候直接把流量切换出去，切换为直连远端或统一的Global Proxy）

也可能很多公司在混用各种方式，具有N套服务注册中心，正在做容器化迁移，想想就头痛，微服务的理念层出不穷伴随着巨头之间的技术战役，苦的还是架构和开发，当然，运维可能也苦