1、SpringCloud的微服务落地姿势
一般会通过编写FeignClient接口来实现微服务之间的调用，而其底层的逻辑则是通过Feign所集成的Ribbon组件去注册中心中获取目标服务的服务地址列表，之后Ribbon根据服务地址列表进行负载均衡调用。至于服务与注册中心之间如何保证连接有效性，则依赖于服务注册中心与其SDK之间的协作机制。
而高级一点，服务之间的调用除了实现负载均衡，还要实现熔断限流、那么此时可以通过部署服务网关组件（例如Zuul/Spring Cloud GateWay）来实现微服务入口的熔断限流、内部服务之间的限流熔断则通过集成Hystrix或Sentinel组件，以客户端本地配置或远程配置中心的方式来实现。
2、Spring Cloud为代表的传统微服务体系的弊端：
1、框架/SDK太多，后续升级维护困难
2、多语言微服务SDK维护成本高
3、服务治理策略难以统一控制
4、服务治理逻辑嵌入业务应用，占有业务服务资源
3、Service Mesh容器化部署
在Service Mesh中，当我们将一个服务部署在Kubernetes之后，安装在Kubernetes中的Service Mesh组件（例如Istio）就会自动在该微服务的同一个Pod之中启动一个与之对应的代理进程（例如istio-proxy），这个保姆式的代理进程会代替微服务本身去实现原先在Spring Cloud体系中需要微服务自身完成的服务注册、负载均衡、熔断限流等微服务治理功能。并且，这些代理进程并不是孤军奋战，而是会通过像xDS协议（Service Mesh中数据面与控制面通信的通用协议）与Service Mesh控制组件保持连接。
Service Mesh最核心的设计逻辑——通过Sidecar的方式代理微服务进行服务治理逻辑（数据面），通过控制面感知外界环境的变化并通过xDS协议支持各种微服务治理策略规则的集中管理和下发，而这里的控制面和数据面都会被融合进像Kubernetes这样的基础架构环境中，对于普通微服务的开发，研发人员要做的只是将一个应用以编排的方式部署进k8s集群即可！而所有与微服务治理相关的逻辑都由代理数据面与控制面协作完成。
image.png
4、官网
https://mosn.io/docs/
https://mosn.io/layotto/#/zh/README
5、下一代微服务：多运行时架构 Multi-Runtime
Layotto(/leɪˈɒtəʊ/) 是一款使用 Golang 开发的应用运行时, 旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。它为应用提供了各种分布式能力，比如状态管理，配置管理，事件发布订阅等能力，以简化应用的开发。
Layotto 以开源的 MOSN 为底座，在提供分布式能力以外，提供了 Service Mesh 对于流量的管控能力。
Multi-Runtime 是一种服务端架构思路，如果用一句话来概括，就是把应用里的所有中间件挪到 Sidecar 里，使得“业务运行时”和“技术运行时”分离开。
Dapr、Layotto
19年微软开源了 Dapr 项目
2020年，Bilgin Ibryam 提出了 Multi-Runtime 的理念，对基于 sidecar 模式的各种产品形态进行了实践总结和理论升华。
首先我们介绍一下 Bilgin Ibryam 同学，他是 “Kubernetes Patterns” 一书的作者，Apache Camel 项目的 committer，目前工作于 redhat 。
2020年初，Bilgin Ibryam 发表文章 “Multi-Runtime Microservices Architecture” ，正式提出了多运行时微服务架构（别名Mecha/机甲，非常帅气的名字）。
Multi-Runtime的本质是面向云原生应用的 分布式能力抽象层
网友评论