1 架构现状
当前互联网时代后台架构在持续演化中，每当一种新架构的产生对普通业务开发人员来说都是一种沉重的负担，业务开发人员需要需要去学习新的架构的研发方式、部署方式、运维方式、甚至是新旧架构迁移都将带来巨大成本。因此架构师门提出Service Mesh,将架构下沉，采用Sidecar模式，将架构与业务分离，研发人员不在关注架构实现，将更多精力花在业务上，真正的帮助业务，助力数字化转型。
2 Service Mesh架构
当下最火的Service Mesh架构当属istio，简单介绍下istio，istio分为data plane 和 controll plane 两大部分
data plane
Envoy
Envoy 是istio被部署的sidecar,提供了动态服务发现、负载均衡、TLS , HTTP/2 及gRPC 代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能
controll plane
pilot
控制面中负责流量管理的组件为Pilot，为 Envoy sidecar 提供服务发现功能，为智能路由（例如 A/B 测试、金丝雀部署等）和弹性（超时、重试、熔断器等）提供流量管理功能
Mixer
Mixer是一个独立于平台的组件，负责在服务网格上执行访问控制和使用策略，并从 Envoy 代理和其他服务收集遥测数据。
Citadel
citadel 是Istio 的核心安全组件，提供了自动生成、分发、轮换与撤销密钥和证书功能。
传统证券行业对Service Mesh思考
传统证券行业技术现状是依然依赖IOE，K8S容器化没有大范围使用，厂商依赖严重，自主研发能力不强，注重业务而非技术。在这样的现状下，证券技术对于下一代架构Service Mesh研发引入会很谨慎。这里我阐述下我对引入Service Mesh的思考：
1、可以将架构下沉，减轻业务研发人员学习新架构以及新老架构迁移的压力，让业务开发人员更加关注业务，实现业务的数字化转型；
2、可以打通供应商系统与自研系统的技术壁垒，内部新老、厂商自研服务间的复用成为可能 ，实现敏捷开发；
3、厂商系统及老系统采用Sidecar模式，可以享有更加先进的监控、运维体系，保持系统先进性；
传统证券行业如何实施Service Mesh
虽然现在istio很火，但是传统券商基于Istio进行个性化研发service mesh架构基本不现实，一方面Istio非工业级产品稳定性、性能等多方面还未经受过实际考验、另一方面Istio复杂度太高，自定义改造难度巨大。
所以比较好的方案是先有类库和框架，然后加proxy，proxy打通了之后再慢慢的开始添加控制平面。这条路是最安全的：每一步都是基于现有的产品，很快就可以到下一个里程碑，然后每个里程碑都可以解决一些实际问题，可以直接得到一些红利，这个方案是比较比较稳妥的。比如说第一步是把proxy做进去，有了这个切入口之后，就在第一时间获取跨语言的红利，还有技术栈下沉的好处。然后控制平面的创新，可以在这个基础上慢慢往前做。
