容器化平台带来了更加弹性的底层平台架构，更好的支撑了微服务本身对平台敏捷性的要求，使得企业更加愿意进行微服务化改造，但是微服务不是银弹，分布式的服务使得服务单元间的调用更加复杂，服务与服务之间的治理变得更加重要，应用中访问中，大量的服务，每个服务大量的实例，使得服务间调用路径及关系变得复杂，弹性扩展平台的时刻动态性使得访问路径时刻处在变化当中，监控，日志收集，问题排错回溯都变得异常困难。应用开发人员要做好局部服务失败的熔断处理，避免一个服务不可用而影响整个应用。微服务虽然使得应用发布频率更快，但是复杂的调用关系使得错误的升级带来的连锁问题变得更加难以预估，应用关系的复杂性需要更好的方法跟踪监控应用关系以及性能。分布式架构下需要解决的问题在微服务环境下被成倍的放大：

• 服务发现 

• 负载均衡 

• 路由 

• 流量控制 

• 通信可靠性 

• 弹性 

• 安全 

• 监控/日志 

       如何解决这些问题，较早实践微服务的企业往往采用开发一系列公共库的方式来解决这些问题，例如Spring Cloud, Dubbo等，这些都是基于特定语言的开发框架，使得微服务中的服务必须依赖于这些库，这与微服务容许使用任何开发语言这一优点相违背，同时基于库的方式多少都要浸入到代码当中，并不是一个友好的方式。在这样的背景下Service Mesh概念应用而生，帮助解决微服务环境下的这一系列问题，Service Mesh是一个基础设施层服务，它帮助更加可靠的传输复杂拓扑中的服务请求，Service Mesh通常是一组与应用一起部署，但对应用透明的轻量级网络代理，它通常由data plane构成，其中所有服务通过sidecar代理进行服务通信（所有代理相互连接形成一个Mesh，Service Mesh由此得名），同时包含一个Control plane——可以将所有独立的sidecar代理连接到一个分布式网络中，设置控制策略、安全验证、metric遥感等工作。

       Service Mesh概念的提出时间并不长，但它确是眼下最火的技术趋势，F5于2017年正式开始Service Mesh项目 Aspen Mesh，目前Aspen Mesh已成为CNCF银牌会员，详细内容可查询Aspen Mesh网站：http://aspenmesh.io

       2018年8月1日，Service Mesh的代表产品Istio发布了1.0版本，意味着这是一个可以推向生产的版本，相信SM将会在未来变得更加火热和可落地。

       F5 Aspen Mesh基于Istio，为企业提供更加稳定的企业级SM产品，它在Istio基础上对可视化、诊断、安全等方面做了诸多增强，与Istio，linkerd的对比如下：

注：Aspen Mesh产品目前尚未正式发布，了解更多请咨询销售代表

       Nginx支持Fabric模型Service Mesh，同时Nginx Unit作为跨语言动态应用服务器在支持相关ADC功能后可实现支持Service Mesh能力。