2018-11-06集中式的方式就类似esb模式了，缺点就是：
1、本地调用变成了远程调用，开销变大。
2、无法采用iptables这样的拦截技术实现对服务的透明无感知的调用和转发。
3、集中后可能存在网络和性能瓶颈。
但这样做也不是一无是处，在一些对微服务治理平台的资源占用要求不能太多，且需要对微服务集中管控的情况下，是不是也可以尝试啊。展开作者回复: 确实，对一些规模较小的服务调用可以尝试，这时候有点类似nginx和slb的角色
1 5
2018-11-06sidecar代理模式本身定义就是作为轻量级代理，其一般是不支持高可用特性的。
部署方式也是和应用程序一起部署在父容器中，提供一些支撑性 服务。作者回复: 嗯
3
2019-03-11一个sidecar有单点故障问题。那一个cp还是有单点故障问题啊？这个作者是怎么考虑的？ 2
2019-02-26在现有的Istio模型中，sidecar是与服务共享网络配置，每个服务有一个单独的sidecar。那是否可能将side car部署为一个单一的pod，但是与服务处于同一node上，这样是否可以多个service 共享一个sidecar（并且由于处于同一node上网络延迟不会有明显增加）？请问一下为什么没有选择这种方案？ 1
2018-11-12Control Plane是一个集中式的处理单元，所有side car 共享他？每次调用都需要cp来做决断？作者回复: 监控、配额控制、安全都需要经过cp
1
2019-06-18集中部署起来风险太高，集中部署也就回到原来都老路上面去了，无法解决可用性问题
2019-01-16有点类似区块链的本地簿记功能。每个单体解决各自的问题。- 2018-11-12Control Plane的作用怎么和企业服务总线这么相似？企业服务总线多了一个流量流转，而Service Mesh中请求是先通过CP选择后，由Sidecar自己调用，这点不同？
作者回复: ESB吗？两者的作用差别很大啊
2018-11-07就像大家所说的，一个sidecar有单点问题。同时sidecar与服务一同部署可以减去网络开销，如果都调用同一个sidecar增加了网络开销。作者回复: 确实
2018-11-06第一点，是单点故障，第二点是为了实现负载均衡（个人猜想）第三点多个实例可以用来定位每一个服务？第四点不同实例可以针对性为该服务定制请求，第五点让不同系统不同的标准统一，方便调用。作者回复: 主要是因为单点故障和单点可能成为瓶颈
2018-11-06回答老师的问题:1.有单点问题 2.多一跳有性能开销 3.配置麻烦作者回复: 正确
2018-11-06老师你看了github的事故说明后，有什么感想呢？作者回复: 数据库自动切主是个非常高危的操作，在生产环境中使用要非常谨慎
2018-11-06一个sidercar存在单点故障隐患
有时候需要对服务提供者或服务提供者进行个性化配置，一个sidercar不如多个sidercar方便
集中部署sidercar更有可能出现性能瓶颈，如单个服务流量或者访问量巨大时会不会拖慢整体
暂时只能想到这些不知道对不对的点作者回复: 是要考虑的几个因素
2018-11-06service mesh是长连接的吗作者回复: sidecar之间通信可以保持长链接
2018-11-06集中起来不就成了网关了嘛……
不对，网关只关心入请求不能对发出的请求加工作者回复: 也有混合功能的网关，比如现在的openresty
2018-11-06Service mesh要求sidecar是轻量级的代理，这表示sidecar不具备高可用特性，如果一个sidecar代理多个实例，就会出现单点问题，尤其在流量高峰期，一旦sidecar挂了，一群服务都不能用了。作者回复: 这是很重要的一个原因
2018-11-06老师想问下Service mesh做负载均衡具体是如何实现的？如何保证每个pod链接是均衡的。是不是需要通过部署ingress给每个pod里的sidecar做负载均衡？作者回复: 通过sidecar发出请求时使用负载均衡算法
2018-11-06唯品会的service mesh实践也很优秀作者回复: 前几天看了江南白衣写的文章，也很不错