拥抱开源，聊一聊下一代微服务Service Mesh

微服务架构近年来一直是互联网技术圈的热点，诸多新技术如 Docker、Kubernetes、DevOps、持续交付、Service Mesh 等背后都有微服务架构的影子。

微服务架构已经不是一个新概念，很多业界前沿互联网公司的实践表明，微服务作为一种渐进式的演进架构，是企业应对业务复杂性，支持大规模持续创新行之有效的架构手段。

在过去几年中，有大量的互联网公司包括很多做技术转型的传统企业，都在着手落地微服务架构。但在搭建微服务架构体系过程中，他们通常都会面临相同的疑问：为什么要选择微服务架构？

今天我们就深入浅出，为大家解析：

微服务的优势及架构特点

新一代微服务架构之Service Mesh

微服务架构

2014年马丁福勒提出了微服务架构设计模式，微服务架构最核心的设计有两点：第一，把单体服务拆分成一系列小服务；第二，拆分后的这些小服务是去中心化的，即每个服务都可以使用不同的编程语言，也可以使用不同的数据库和缓存存储数据。

微服务架构的设计，主要就是在协助解决软件世界里面快速叠代、快速交付所面临的问题。

微服务架构的优势

导入微服架构体现出许多优势，包括更快的上线时间、灵活性、弹性、一致性以及相对更低的成本。

●解耦、低耦合。解耦的构架可以让各个功能模块在更新的时候，完全不受到彼此的影响，更可以因为小粒度的模块化，而可以被集成，模块就能有重复被利用的效果。

●更好的维护性。当微服务依照业务逻辑切割，便能切割成更小的粒度，让开发团队自行开发、运维与更新布署。

●降低系统容错率。由于以前单体式的系统架构是整包的概念，当这个整包的功能服务系统挂掉的时候，整个系统就完全无法对外营运，而微服务的模式则是只会影响单一微服务模块，并且可以达到快速重启，来降低系统错误造成的巨大风险。

●低技术依赖性。由于解耦的特性，各个微服务可以各自标明合适的开发语言和套件，不会像单体式构架，必须完全受限于既有系统的框架。

下一代微服务Service Mesh

微服务架构1.0继续演进，就变成了微服务架构2.0，即Service Mesh架构（Service Mesh）。

Service mesh的概念最早在2016年由开发Linkerd的Buoyant公司提出，之后就吸引了众多开发者社群的注意，包括了Google、IBM、Redhat，或像Pivotal这样的产业大咖，让Service mesh被视为是下一代微服务构架。

研华WISE-PaaS将工业物联网应用解耦，让开发者能够集成、重构的概念，也是源自于Service Mesh。

Service Mesh

Service Mesh是一个基础设施层，用于处理服务间交互。云原生应用有着复杂的服务拓扑，Service Mesh负责在这些拓扑中实现请求的可靠传递。在线上实践中，Service Mesh通常实现为一组轻量级的网络代理，它们与应用程序部署在一起，并且对应用程序透明。

Service Mesh的概念是将微服务的控制层和数据流的设计考察区分开来，在每个受管理的运用服务中注入一个Proxy，这个Proxy也常常被称为Sidecar。Sidecar管理所有导向它所依附的微服务的API请求，并将和应用逻辑不相关的决策程序导向其他Service Mesh框架下的服务。

举例来说，开发者或许希望能够依据公有或私有情境，分别管理处于不同环境下的微服务调用。这些管理的Policies对应用来说可能是不可见的，但是透过Sidecar的机制，它就能代替环境套用这些Policies到微服务的调用行为中。