通信世界网消息（CWW）随着互联网行业发展，微服务架构逐渐被认同为最先进的技术架构模式，各类信息系统无论是否适用，都急于启用微服务架构模式。但在微服务化改造与运行过程中，会发现微服务的天生缺陷，以及目前各类微服务框架，如SpringCloud、Dubbo等，也仅作为过渡模型的事实。
对于现有广泛使用的微服务模型，如SpringCloud、Dubbo等，较为突出的问题主要有以下几方面：一是不适于高度组织化的容器集群，由于容器的部署销毁是由外部K8S等框架实施的，微服务实体运行于容器中同外部隔离，不知道自己的服务地址等环境信息，因此微服务的服务发现必须和K8S做适配才能真正可用，这样就产生了极其不自然的功能重叠和绕道。二是现有微服务框架的跨语言能力极弱：对于现代互联网组织来说，多语言化是无法避免的趋势，在系统开发部署过程中，无论从外购系统、社区支持、人力招聘等方面考虑，都不得不接受多语言系统的存在。三是应用间白盒及全相连，一个应用需要知道并连接某服务提供方所有应用的地址以及存活情况。
产生这些问题的原因主要是当前微服务框架将系统组织、服务发现、路由等功能嵌入了应用中，从而导致了系统组织等原本应处于高视角的功能被拉低到了应用这一层，同时也和应用本身在技术上耦合过密。目前部分解决这一问题的办法是使用API Gateway，但这仅是治标的方案，无法根本解决微服务框架的问题，最终方案是通过Service Mesh来组织系统。
Service Mesh 的工作方式，简单来说，就是将原本嵌入应用的微服务Client独立了出来，作为一个Proxy进程独立运行于每一台应用主机上。应用仅需简单地配置一个本地Proxy地址进行调用，由本机Proxy通过下发的服务路由表寻找一个服务提供方所在主机的Proxy，再发送给服务提供商。典型的工作方式如下图：
图 Service Mesh 的工作方式
Service Mesh的设计类似于现代路由器，将用户、控制平面和数据平面彻底分离，并为控制平面增加了诸多管控和诊断能力，而数据平面的数据流向则是由控制平面下发的策略来决定的，这样带来的优点主要有几点：
（1）应用内部不必再嵌入复杂的微服务Client：应用不再
涉及框架相关的服务发现等功能，每个接口仅需配置一个本地地址进行调用，不必知道集群的情况。
（2）语言无关：由于不需嵌入语言特定的Client，使用标
准协议通信的双方均可由任意语言编写，即使是外采的二进制系统，也可以简单的嵌入集群中。
（3）大量减少应用间连接数：同一主机的调用方所涉及的连接可以被Proxy连接复用，因此应用间连接数可大幅减少。
（4）大量减少数据库连接数：原因同上，可以避免微服务带来的数据库连接数爆炸问题。
（5）提升通信加密的效率：可以将通信加密统一放置于由高运行性能语言编写的Proxy上，而非由运行效率较低的应用来进行。
（6）调用过程的集中诊断：由于请求均通过Proxy进行，可以便利的进行统计并收集日志、报文等。
（7）运维控制的统一认证和调度：由于服务发现和调用路由放置在了独立的系统中，运维可以完全掌控调用的过程，包括设置调用的路径，调用权限等。
（8）容器友好：service mesh框架同K8S等编排系统集成度较高，可无缝协同运行。
（9）实施便利：在mesh部署完成后，应用仅需退回原始的直接调用模式即可使用mesh带来的收益。
因此在当前可以预测的未来基础设施演进过程中，基于service mesh模式在大中型系统组织模型中具备较大的优势。
（本文刊登在《通信世界》2018年8月25日（2018年第23期，总第781期）上）
