| 失效链接处理 |
|
Service Mesh 入门 PDF 下载
本站整理下载：
提取码：ae1n
相关截图：
主要内容：
spring-cloud-bus
spring-cloud-consul
spring-cloud-config
spring-cloud-netflix:eureka、hystrix、feign、zuul、ribbon等
.....
1.5 服务网格时代
然后微服务时代有了Spring Cloud就完美了吗？不妨想一想会有哪些问题
（1）最初是为了业务而写代码，比如登录功能、支付功能等，到后面会发现要解决网络通信的问题，虽然有
Spring Cloud里面的组件帮我们解决了，但是细想一下它是怎么解决的？引入以来dependency，加注解，写
配置，最后将这些非业务功能的代码打包一起部署，和业务代码在一起，称为“侵入式框架”； （2）微服务中的服务支持不同语言开发，维护不同语言和非业务代码的成本；
（3）业务代码开发者应该把更多的精力投入到业务熟悉度上，而不应该是非业务上，Spring Cloud虽然能解决
微服务领域的很多问题，但是学习成本还是较大的；
（4）对于Spring Cloud而言，并不是微服务领域的所有问题都有对应的解决方案，也就是功能有限，比如
Content Based Routing和Version Based Routing。当然可以将Spring Cloud和Service Mesh结合起来使用，
也就是对SC的补充、扩展和加强等；
（5）互联网公司产品的版本升级是非常频繁的，为了维护各个版本的兼容性、权限、流量等，因为Spring
Cloud是“代码侵入式的框架”，这时候版本的升级就注定要让非业务代码一起，一旦出现问题，再加上多语言之
间的调用，工程师会非常痛苦；
（6）其实大家有没有发现，服务拆分的越细，只是感觉上轻量级解耦了，但是维护成本却越高了，那么怎么
办呢？网络的问题当然还是要交给网络本身来解决
1.5.1 问题解决思路
本质上是要解决服务之间通信的问题，不应该将非业务的代码融合到业务代码中
也就是从客户端发出的请求，要能够顺利到达对应的服务，这中间的网络通信的过程要和业务代码尽量无关
在很早之前的单体架构中，其实通信问题也是需要写在业务代码中的，那时候怎么解决的呢？
那就不妨把这些通信的问题都交给计算机网络模型组织去解决咯？别人肯定不会答应，怎么办？
通信的问题：服务发现、负载均衡、版本控制、蓝绿部署等 把网络通信，流量转发等问题放到了计算机网络模型中的TCP/UDP层，也就是非业务功能代码下沉 咕泡学院 只为更好的你
不妨这样在帮每个服务配置一个代理，所有通信的问题都交给这个代理去做
大家肯定接触过，比如最初Nginx、HaProxy等，其实它们做反向代理把请求转发给其他服务器，也就为
Service Mesh的诞生和完成提供了一个解决思路
1.5.2 一些公司对于代理的探索Sidecar
很多公司借鉴了Proxy模式，推出了Sidecar的产品，比如像14年Netflix的Prana、15年唯品会的local proxy
其实Sidecar模式和Proxy很类似，但是Sidecar功能更全面，也就是Sidecar功能和侵入式框架的功能对应
问题 ：这种Sidecar是为特定的基础设施而设计的，也就是跟公司原有的框架技术绑定在一起，不能成为通用性的产
品，所以还需要继续探索。
1.5.3 Service Mesh之Linkerd
2016年1月，离开Twitter的基础设施工程师William Morgan和Oliver Gould，在github上发布了Linkerd 0.0.7
版本，从而第一个Service Mesh项目由此诞生。并且Linkerd是基于Twitter的Finagle开源项目，实现了通用
性。
后面又出现了Service Mesh的第二个项目Envoy，并且在17年都加入了CNCF项目。
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
