Service Mesh服务网格：是什么和为什么
sidecar模式：下一代微服务架构的关键 - 知乎 https://zhuanlan.zhihu.com/p/40854123
什么是Sidecar模式？
Sidecar模式是一种将应用功能从应用本身剥离出来作为单独进程的方式。该模式允许我们向应用无侵入添加多种功能，避免了为满足第三方组件需求而向应用添加额外的配置代码。
就像边车加装在摩托车上一样，在软件架构中，sidecar附加到主应用，或者叫父应用上，以扩展/增强功能特性，同时Sidecar与主应用是松耦合的。
举个例子，假设现在有6个相互通信的微服务，每个微服务都需要具有可观察性、监控、日志记录、配置、断路器等功能，而所有这些功能都是在微服务中使用一些第三方库实现的。
这样一组服务的实际情况可能会非常复杂，增加了应用的整体复杂性，尤其是当每个微服务用不同的语言编写、使用不同的基于.net、Java、Python等语言的第三方库……
Sidecar模式的好处
- 通过将公用基础设施相关功能抽象到不同的层来降低微服务的代码复杂性
- 由于我们不需要在每个微服务中编写配置代码，因此减少了微服务架构中的代码重复
- P应用和底层平台之间实现了松耦合
Sidecar模式如何工作
Service Mesh层可以位于应用程序侧的Sidecar容器中，同一sidecar的多个副本可以附在每个应用旁。
来自单个服务的所有传入和传出网络流量均通过Sidecar代理，完成微服务之间的流量管理、遥测数据收集以及策略的执行等等。从某种意义上来说，服务对于网络是无感知的，只知道所附加的sidecar代理。这就是Sidecar模式工作的本质，它将网络依赖抽象成了Sidecar。
在Service Mesh中，我们需要了解Data Plane和Control Plane两个概念——
- Data Plane的作用是处理网格内服务间的通信，并完成服务发现、负载均衡、流量管理、健康检查等功能；数据平面的作用是处理网格内服务之间的通信，并负责实现服务发现、负载平衡、流量管理、健康检查等功能；
- Control Plane的作用是管理和配置Sidecar来执行策略并收集遥测（telemetry）；
Service Mesh服务网格：是什么和为什么 - 好雨云帮 CSDN 博客 - CSDN博客 https://blog.csdn.net/zyqduron/article/details/80433995
Service Mesh（服务网格）会是今年微服务生态的主角吗？从趋势来看，众多企业正在将这项理微服务复杂性的技术/工具，搬进他们的IT“火药库”之中。
什么是Service Mesh？
根据Linkerd CEO William Morgan定义，Service Mesh是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中，Service Mesh通常是一组与应用一起部署，但对应用透明的轻量级网络代理。
Service Mesh与传统基础设施层不同之处在于，它形成了一个分布式的互连代理网络，以sidecar形式部署在服务两侧，服务对于代理无感知，且服务间所有通信都由代理进行路由。
为什么需要Service Mesh？
“Smart endpoint and dumb pipes”是微服务架构在集成服务时采用的一个核心理念，这一理念改变了过去臃肿集中的ESB（企业服务总线），无疑是正确方向上的一大进步，但同时也给我们出了一些难题——多智能才不会过于智能，而服务轻重大小的程度如何拿捏？我们应该如何处理微服务系统中服务间交互的复杂性？放在服务内部还是外部？如果是内部，如何处理业务逻辑关系，或者应该与基础设施更为相关？如果是外部，如何避免重蹈ESB的覆辙？
皮的不谈，先来看看处理服务间通信时需要关注的点：
- 服务发现
- 负载均衡
- 路由
- 流量控制
- 通信可靠性
- 弹性
- 安全
- 监控/日志
似乎都是老生常谈，存在于任何需要处理网络的分布式系统之中，区别在于，当所涉及微服务数量呈指数级增加，这些问题也会被相应放大。
一个已经被广泛应用的解决方案是利用api网关来处理服务外部和服务之间的请求，提供例如服务发现、路由、监控、流量控制等。
然而，api网关有一个比较致命的缺陷，它容易出现单点故障并且实践不当很有可能会变得异常臃肿。另一方面，api网关核心是面向用户，也就是说它可以解决从用户到微服务的流量问题，但不能解决所有问题，而我们需要的是一个完整的方案，或者至少是一些能够与api网关互补的方案和工具。
另一种选择是在网络堆栈的较低层级（4/3）进行可靠性、监控、流量控制等方面处理。这种选择的问题是，在较低较低的操作难易满足应用层的问题。联想end-to-end（端到端）的理论，我们前面提到的那几个关注点实际上还是集中在应用层，也只能在应用层成功实现。
像Netflix、Twitter等SOA/微服务的早期采用者，他们通过建立内部库的方式处理这些问题，然后提供给所有服务使用。这种方法的问题在于，把库扩展到成百上千个微服务中难度极高，而且这些库相对来说是比较”脆弱“的，我们很难保证他们可以适应所有的技术堆栈选择。
程度上来说，Service Mesh与这些库很类似，但Service Mesh是与服务相邻的独立进程。服务连接到代理，代理反过来又与其他代理（HTTP1.1/2、GRPC）进行通信。它们是相对独立的进程，在应用层或应用层之下分布和运行，进而解决了上述两个方案存在的缺陷。
Service Mesh架构
Service Mesh由data plane构成，其中所有服务通过sidecar代理进行服务通信。（所有代理相互连接形成一个Mesh，Service Mesh由此得名）网格同时包含一个control plane——可以将所有独立的sidecar代理连接到一个分布式网络中，并设置网格还包括一个控制平面——它将所有独立的sidecar代理连接到一个分布式网络中，并设置由data plane指定的策略。
Control plane定义服务发现、路由、流量控制等策略。这些策略可以是全局的，也可以是限定的。Data plane负责在通信时应用和执行这些策略。
最后
总结来说，Service Mesh是“时间的产物”，Docker、Kubernetes等容器技术直接推进了对于Service Mesh的需求，让复杂的系统可以被轻松部署和管理。
未来Service Mesh将如何发展还未可知，或许会像TCP/IP一样形成标准，或许不同工具和平台会独具一格……但有一点是确认的，Service Mesh对于微服务生态的价值令人难以忽视，能够将繁重的服务治理工作变得简单高效，何乐而不为？
Kubernetes，微服务以及 Service Mesh_Kubernetes中文社区 https://www.kubernetes.org.cn/2737.html
- 社区首页 >
- istio >
- Kubernetes实践分享/开发实战 >
- Kubernetes，微服务以及 Service Mesh
Kubernetes，微服务以及 Service Mesh
作者：Jolestar ，2015年初开始创业，作为技术合伙人，专注于打造一款团队通讯协作工具-Grouk
这是前一段时间在一个微服务的 meetup 上的分享，整理成文章发布出来。
谈微服务之前，先澄清一下概念。微服务这个词的准确定义很难，不同的人有不同的人的看法。比如一个朋友是『微服务原教旨主义者』，坚持微服务一定是无状态的 http API 服务，其他的都是『邪魔歪道』，它和 SOA，RPC，分布式系统之间有明显的分界。而另外也有人认为微服务本身就要求把整体系统当做一个完整的分布式应用来对待，而不是原来那种把各种组件堆积在一起，『拼接』系统的做法。两种说法都有道理，因为如果微服务没有个明确的边界的话，你可能会发现微服务囊括了一切，但如果只是坚持无状态，那微服务相关的一些领域又无法涵盖。我个人对这个问题持开放式的看法，微服务本身代表了一种软件交付以及复用模式的变化，从依赖库到依赖服务，和 SOA 有相通之处，同时它也带来了新的挑战，对研发运维都有影响，所有因为和微服务相关而产生的变化，都可以囊括在大微服务主题下。
微服务带来的变化
微服务主要给我们带来的变化有三点，
- 部署单元 越来越小的粒度，加快交付效率，同时增加运维的复杂度。
- 依赖方式 从依赖库到依赖服务，增加了开发者选择的自由（语言，框架，库），提高了复用效率，同时增加了治理的复杂度。
- 架构模式 从单体应用到微服务架构，架构设计的关注点从分层转向了服务拆分。
##微服务涉及的技术点
- 服务注册与发现 服务目录 服务列表 配置中心
- 进程间通讯 负载均衡
- 服务生命周期管理 部署， 变更，升级，自动化运维
- 服务依赖关系
- 链路跟踪，限流，降级，熔断
- 访问控制
- 日志与监控
- 微服务应用框架
这个是我浏览了众多微服务的话题之后摘要出来的一些技术点，不全面也不权威，不过可以看出，微服务主题涉及的面非常广，那这些问题在微服务之前就不存在么？为什么大家谈到微服务的时候才把这些东西拿出来说。这个需要从软件开发的历史说来。软件开发行业从十多年前开始，出现了一个分流，一部分是企业应用开发，软件要安装到企业客户自己的资源上，客户负责运维（或者通过技术支持），一部分是互联网软件，自己开发运维一套软件通过网络给最终用户使用。这两个领域使用的技术栈也逐渐分化，前者主要关注标准化，框架化（复用），易安装，易运维，后者主要关注高可用，高性能，纵向伸缩。而这两个领域到微服务时代，形成了一个合流，都在搞微服务化。主要原因我认为有两点：
- SaaS 的兴起，使得一些企业应用厂商也开始采用互联网模式，遇到用户规模的问题。同时企业应用很难纯 SaaS 化，面对大客户的时候，势必面临私有部署的问题，所以必须探索一种既能支撑用户规模，同时要能方便私有化部署的架构。
- 随着互联网技术领域为了应对新的业务变化，需要将原来的技术经验沉淀继承过来，开始关注标准化和框架化。
也就是说，这些技术点并不是新问题，但如何将这些技术点从业务逻辑中抽取出来，作为独立的，可复用的框架或者服务，这个是大家探寻的新问题。
为微服务而生的 Kubernetes
- Kubernetes Pod – Sidecar 模式
- Kubernetes 支持微服务的一些特性
- Service Mesh 微服务的中间件层
我这样说，不仅仅是因为这是一个微服务的 meetup，微服务和 Kubernetes 确实是相辅相成的。一方面 Kubernetes 帮助微服务落地，另外一方面微服务促进了对容器和 Kubernetes 的需求。
Kubernetes 的 Pod – Sidecar 模式
我们先从 Kubernetes 的 Pod 机制带来的一种架构模式 — Sidecar 来说。下面这段配置文件是我从 Kubernetes 内置的 dns 的 deployment 中抽取出来的 Pod 描述文件，简化掉了资源限制，端口设置以及健康检查等内容。
apiVersion: v1
kind: Pod
metadata:
name: dnspod
spec:
containers:
- name: kubedns
image: gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.4
args:
- --domain=cluster.local.
- --dns-port=10053
- --config-dir=/kube-dns-config
- --v=2
ports:
- containerPort: 10053
name: dns-local
protocol: UDP
- containerPort: 10053
name: dns-tcp-local
protocol: TCP
- name: dnsmasq
image: gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.4
args:
- -v=2
- -logtostderr
- -configDir=/etc/k8s/dns/dnsmasq-nanny
- -restartDnsmasq=true
- --
- -k
- --cache-size=1000
- --log-facility=-
- --server=/cluster.local/127.0.0.1#10053
- --server=/in-addr.arpa/127.0.0.1#10053
- --server=/ip6.arpa/127.0.0.1#10053
ports:
- containerPort: 53
name: dns
protocol: UDP
- containerPort: 53
name: dns-tcp
protocol: TCP
- name: sidecar
image: gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.4
args:
- --v=2
- --logtostderr
- --