istio大咖秀中百度分享解读
本文内容来自bilibili视频，如有误读或者侵权请联系作者删除
总结如下
1.基于自有组件naming agent进行服务发现，故障时可以自动切换成直连模式
2.基于服务订阅模式进行配置增量更新
3.通过bgrpc优化envoy内核来提升性能
4.修改pilot使其支持私有化协议
5.支持配置的灰度发布
百度服务治理现状时间线
13年探索sidecar模式
16年百度网盘应用sidecar模式
16年9月 service mesh提出，百度开始研发bmesh（go开发）
18年7月 istio1.0的发布
19年 百度内部确定基于istio+envoy模式进行研发
为什么要引入service mesh（什么样的场景适合）
多语言技术栈（语言技术栈单一可以不引入）
更细粒度的服务治理，提供统一的服务治理
产品研发能力不强（通过service mesh提供统一的功能，否则需要独立开发）
百度内部架构方案一
image.png
1.通过envoy直接连接注册中心
2.自主开发mesh logic来和k8s apiserver对接，写入sidecar CRD
3.大幅降低xds推送量，减少了envoy中配置数
4.java agent探针，所以只支持java
百度内部架构方案二
image.png
1.通过naming agent来实现服务发现
2.将envoy地址配置到naming中
3.naming会把包含envoy地址的请求转到envoy上
4.如果没有envoy地址就采用直连模式
5.mesh方案，支持多语言
6.支持link订阅，能够支持xds根据订阅模式进行增量下发
7.istio不支持私有化协议，改造istio使其支持私有化协议
8.改造了envoy内核，使其包含brpc并且能够在envoy内核和brpc内核进行切换，提升性能
mesh带来的好处
1.提高运维管理的能力，机房切换流量，夸机房流量切换
2.提高产品发布能力，通过版本控制，可以回滚，溯源
3.服务网格可编程能力，提高了平台化能力
提问
1. 请问，istio组件，包括数据面和控制面发生故障时，有哪些快速fallback的方案，之前阅读了大佬的相关文章，这块好像没有细讲，谢谢--Heaven
答：百度是通过envoy和naming集成，当遇见故障时，快速切换为直连模式，防止对业务产生影响。
2. 有些服务QoS想设置guaranteed，但是istio的sidecar不是 request和litmit一样的。要guaranteed的话必须sidecar的QoS相关配置也要改。你们是怎么做的？如果改，建议设置为多少？感谢大佬！
答：目前使用的pod的容量是envoy50到200兆左右，cpu为应用cpu的10%左右。具体其实需要实际场景进行qos压测才可以，这只是建议的值。
3. 你好。作为业务方的技术负责人，被中间件团队推动上Istio，目前带来的收益主要是服务治理方向的。从业务迭代效率的角度看，上Istio的增量收益抵不上迁移成本的代价；另外还降低了业务方工作的技术含量。请问有没有实践中，业务方在Mesh化的过程中获得显著收益的例子？
答：迁移确实具有一定的成本，业务mesh化可以带来服务治理时效性增强，可以把不同技术栈统一起来。
4. 为什么没有采用mcp over xds的方案？ 而是独立搭建了api server 和 etcd？
答：目前k8s支持这种单独搭建的方式，比较方便，还是复用istio部署方案。
5. pilot的多业务方案是怎么做的？ 如果是多个pilot的话，那独立的k8s api server和etcd也要多个么？
答：目前百度是用同一套，也是可以独立部署的。
6. envoy 的brpc改造方案，会考虑开源么？ 怎么follow后续社区envoy的最新代码呢
答：brpc本身就是开源的，百度只是把它集成到envoy的内核中了。目前这块需要等istio社区稳定之后会输出到社区。
7. 内部的mesh方案，考虑通过百度云的方式对外输出么？
答：目前已经输出了。
8. 随着istio新版本的不断发布，内部使用的版本是否跟进了开源新版本，跟进社区版本升级有什么经验分享？
答：目前还在等待版本的稳定，继续跟进社区动态，后续输出到社区。
9. envoy filter管理麻烦的话，nshead，dubbo等多协议支持是怎么实现的？在pilot中是如何管理的？
答：通过改造pilot，实现配置化管理，来支持多协议。
10. 引入两个sidecar后问题定位的成本和难度会大福增加，这块有什么经验可以分享
答：根据envoy的configdump和调用连，指标监控来分析和定位问题。
11. sidecar带来的额外成本问题谁来买单？业务认可吗
答：百度业务认可，内部已经推广。
12. sidecar可以使用的的资源配额是怎么分配管理的，动态的还是静态的，有什么经验
答：200兆。cpu是业务应用的10%，但是还需要压测。和前面问题类似。
13. sidecar的监控是怎么做的？ 权限，成本方面可能都有一些疑问
答：
14. Naming这个agent和框架非常不错，请问Naming可以支持负载均衡么， 也就是PodX访问PodY的时候，naming不要返回PodY真实IP，而是返回负载均衡的VIP给PodX; 十分感谢-Ken
答：没采用这种方式，后续可以使用vip方式。
15. 这种架构的话，PodX主动出公网的逻辑是怎样的呢，也是通过ip-masq 做NAT吗？
答：这个和百度的内部网络架构有关系。
16. Naming agent是部署在哪个容器？
答：单机的，host部署一个。
17. Pliot在落地过程中部署模型，大规模envoy注册后，是否存在一些性能瓶颈，有什么优化的经验？
答：百度也做了很多pilot的优化，比如100万行的crd配置，大概10s就能够完成匹配。大规模envoy注册的话，连接数变多了，可以通过pilot水平扩展来解决。
18. 虽然老师不一定有关注这一块，但也提个问题看看吧。 envoy流量劫持是在userSpace还要经TCP协议栈其实损耗非常大的，后续Envoy有考虑byPass Kernel，直接传包给网卡驱动提速么（例如DPDK、SPDK）
答：还未大规模进行落地，不过系统真是的瓶颈其实也不再这块。
19. 流量都经过sidecar后，sidecar在trace这方面是怎么考虑和设计的？
答：原生就是智慧trace的，有traceid，spanid这些，只要进行适配就可以。
20. 对于inbound流量的限流是如何设计的呢？
答：这块原生不支持，是通过envoy filter来实现的。
21. 私有协议如果要变更的时候，是不是要级联更新？
答：题目不明确，未回答。
22. 支持服务治理的配置灰度下发吗？可以简单说下实现方案吗
答：目前百度是支持配置灰度的，这个原生不支持，百度自己实现，后续单独发一篇文章讲一下。
23. 你们 内部对于 istio deployment 里的 version 字段在落地时有大规模使用吗？我们最近在基于 istio 做灰度发布，但是每次灰度都要给他一个版本号，导致完成之后 deployment 名称就从 v1 变成 v2 以此累加，这样还会导致 deployment 本身的回滚功能失效。
答：不用非得使用version，还有其他的label标签可以使用或者自定义。
24. Envoy对于我司来说技术储备其实不是很够， 请问贵司刚上线的时候， Envoy有没有遇到哪些问题。 特别是稳定性和故障方面。 如果能建议一下envoy应该如何监控，那就perfect.
答：主要就是靠识别出envoy故障后，能够快速切换到直连方式来解决。
25. 对于 dubbo 的泛化调用，探针会实时检测调用关系的变化么？如果 sidecar 还没有被生成，这个时候流量请求阻塞怎么处理呢？一直等待还是直接拒绝？如果服务是新的请求呢？
答：naming实现，不会出现这种情况，会在sidecar生成后在进行流量转发，否则流量还是直连模式。
26. link模型解决xDS问题，可以再详细介绍一下整个逻辑链路么？例如consumer和provider的link数据是怎么获得的
答：这是百度自己做的一个产品配置页面，提供服务订阅，然后根据订阅关系进行配置下发。
27. 2ms的Envoy额外消耗，请问是怎么查看的呢? curl endpoint 跟 curl envoy 做一次对比么
答：差不多，基本就是直连和过sidecar请求来进行交叉对比。
28. Envoy注入后业务pod会存在2个container， 那么envoy的配额是怎么限制的呢？ 比如限制4核心可能就是2个容器（1个pod）里面的配额了；
答：前面介绍了。
29. 就是我们在落地的时候，会遇到部分服务有sidecar，部分没有(服务A会被其他10个服务调用)，一般如何去判断配置设置在哪里，是在outbound（其他10个服务部署sidecar）处还是inbound处（服务A部署sidecar）。这个有没有什么比较好的实践
答：还是naming组件实现，如果能匹配到就过envoy，匹配不到就走直连模式
30. Envoy如何实现长连接的动态开关的？
答：通过开发一个listener，通过listener来监听envoy的长连接，当变更的时候进行控制。
