两年来，我们将若干复杂的Rails单体应用拆分、迁移到微服务架构， 逻辑用Golang重写，引入了Kubernetes。随着模块越来越多，复杂 的通信带来矛盾日渐突出：流量管理、监控… 最初的尝试：Gateway • 如右图，最初我们尝试用一个自研的 简单Gateway来提供统一的认证、授 权、限流、监控，但问题很快凸显出 来了： • Gateway是一个中心化的反向代 理，成为了微服务中的瓶颈，模 块流量会互相影响 • 配置管理：为C++实现的Proxy接 入k8s的动态配置管理 • Attribute Machine: 授权，Quota ，Tracing，监控的基础 Istio管理下的微服务 • 右图是部署mock1.v1 Pod之后发生的事 情： • Sidecar Injection: 注入initContainer, Sidecar, istio-certs volume • Citadel: 都可以用Istio原生的机制来完成 • 扩展Mixer：选择一部分流量来应用对应的授权逻辑 FreeWheel的Istio实践 • 右图为接入FreeWheel自定义认证和 授权模块的原理图 扩展Sidecar接入认证 • 修改 istio-system/istio-sidecar- injector 这个ConfigMap，加入自定 义反向代理 FreeWheel的Istio实践

127.0.0.1。 • 之后创建与本POD内业务容器的服务端口的Socket连接并完成请求发送。 • 由于请求方向在建立时会保存下游与上游连接的双向对应关系，因此Response匹配的对上游进行L7层过滤器解码、通过Router关联关系找到下游并编码发送 HTTP请求（POD1处理类似）。 • 以上所提到的Envoy L4层网络读取及数据发送为全异步读写模式，采用网络事件触发机制完成响应数据的接收和发送。

MetaProtocol: 响应处理路径 处理流程： 1. Decoder 解析 Upstream 的响应，填充 Metadata 2. Router 根据 connection/stream 对应关系找到响应的 Downstream 连接 3. L7 filter 从 Metadata 获取所需的数据，进行响应方向的业务处理 4. L7 filter 将需要修改的数据放入 Mutation 结构中

标准的istio规范操作，实时反映真实集群状态，告别terminal。 •便捷 一键安装，UI操作，流量策略模板复用，批量设置 •多集群支持，零成本接入 流量视图提供统一的拓扑图界面，让您的视角可以统揽全局 •附加组件 •Jaeger，为SolarMesh提供分布式链路追踪的能力 •Grafana，为SolarMesh提供流量的实时仪表盘 •SLO，为SolarMesh提供服务质量检测的能力