kubernetes和springcloud的发展历程( 三 ) SpringCloud技术体系简介我们通过

举一个现在比较火的产品AmbassadorEdge 。它原生提供了身份验证、分布式追踪、多协议、ratelimit等功能。但在SpringCloud体系里实现这些功能就要做很多事情。SpringCloudGateway的成本相对Ambassador等开源的网关成本要更高一些。
这里举一个例子，比如要用Ambassador构建一个Keyclock的鉴权体系。只要声明几个YMAL文件，就可以快速把整个流程走通。对比起来使用SpringCloudGateway构建时，要花很多时间去研究Keyclock有没有API接口， SpringCloud要如何接入等。类似这种很通用的功能，可以考虑使用开源产品来直接替换。
ServiceMesh
ServiceMesh是另外一个更激动人心的话题，也是现在大家都在研究的前沿方向。传统应用之间的通讯一直是很复杂的问题。比如SpringCloudRibbon做了很多安全、分流的工作，而这些工作其实跟业务本身相关度非常低。那么这些能力可以提取出来吗？社区给出了一个全新的答卷：ServiceMesh 。
ServiceMesh所做的事情是在节点之间通过一个Proxy代理层截获所有流量，节点之间通过特定的网关进行转发。因为所有流量都被劫持了，可以做很多工作，包括loadbalance、根据label做灰度发布等。
SpringCloud原生的默认设置无法实现全链路灰度，需要改loadbalance策略，这样会导致同源数据里的开发工作量增加。但是在云原生体系里， Istio直接配一个virtualservice就能完成。虽然Istio有一些功能还在开发过程中，但使用Istio会更加容易，因为它把跟业务不相关的属性全部剥离出去，不再跟应用绑得那么紧密了。
双向TLS
举例来说，如果要提供双向TLS ，传统做法如果是应用自己来解决这个问题，就要先发个邮件通知要升级双向TLS了，然后每个人都得配一下自己的证书，这个过程非常痛苦。现在有了ServiceMesh ，只要通过一行声明式就可以在不同的Proxy之间强制打开双向验证，保证整个网络安全，至于服务跟Proxy之间的安全则由隔离性来保证。
熔断
对于Spring社区主打的熔断器功能，也可以直接使用Istio提供的destinationRule的能力，只需要简单配置一些参数即可，比如访问的最大可连接数、错误多少次之后会被拒绝、进行Half-Open重试的间隔等。
CentralizedMetrics
Metrics可以通过sidecar获取，无需像传统架构由应用获取。如果应用本身还暴露出来一些业务的Metrics ，通过Prometheus的定制抓取可获得这些数据。但如果只是想知道一些网络吞吐Metrics ，现在应用本身也不需要直接提供，这样又减少了应用业务的负担。
总结与展望
ServiceMesh的出现提出了一个全新的思考方向：我们真的要将那么多中间件功能放在应用本身吗？恰好社区也在思考这个问题。CNCF社区最近有一些新的博文，提出了一个叫做多运行时的架构体系（Multi-RuntimeMicroservicesArchitecture) ，这是一种全新的理念，认为围绕业务我们需要提供四种能力：
生命周期管理：管理应用什么时候启动，什么时候关闭等。包含打包、健康检查、部署、扩展、配置等功能。
网络管理：包括服务发现、A/Btest、灰度发布、熔断、点对点通讯、pub-sub等。
状态管理：包括workflow管理、缓存、应用状态等。
绑定：包含数据传输，协议转换等。
有了这些能力，开发人员只需关注业务逻辑，研发效率将会极大提高。
这些能力基于云原生体系也可以做到。比如生命周期可以基于Kubernetes去做，网络可以基于Istio去做，状态管理可以基于CloudState去做，绑定可以基于Camel去做。将这些东西组合在一起，业务单元就无需再关注这些事情。而SpringCloud为了解决复杂的依赖问题，需要maven依赖，要依赖很多组件。当然这些事情慢慢都可以去掉，我们只要关心业务单元最核心的部分——业务逻辑，因为只有这个部分才是真正动态的逻辑。