可以说近两年servicemesh和云原生的概念炒得很火.也确实给用户带来了实实在在的收益.由于近三年在从事serviceMesh相关的工作,之前听过美团/蚂蚁金服/唯品会等一些公司的分享,也在极客时间学了一些课程.因此做一些总结.

一.serviceMesh

1.serviceMesh的发展过程

       以重试功能为例.如果我想在代码里增加重试功能,应该怎么办

1.控制逻辑与业务逻辑耦合.

int retry=3;
for(int i=0;i<retry;i++){
   try{
      http.doGet("http://www.baidu.com");
      break;
   }catch(Exception e){
      continue;
   }
}

2.公共库. 优点:解耦,消除重复 缺点:1.学习成本, 2.公共库的维护,例如升级,3.语言绑定.每个语言都得写一套,4.侵入性,一旦框架有问题,直接gg

3.代理,通过类似nginx做一些管控,例如负载/权重/路由等,但是第一个是配置复杂,第二个是功能简单,满足不了一些复杂需求.

    nginx也曾尝试做过nginx mesh.Envoy相比nginx好处明显：基于API的配置方式，grpc+http2，非常适合作为容器部署.envoy也可以做网关.甚至以不低于nginx的性能可以取代nginx(our-move-to-envoy),很尴尬,然后nginx又开始搞了nginx-unit

We understood we’d have to do a lot of additional work to build a fully-functional traffic management solution. Service discovery, stats management, and finer grained load balancing are critical features of modern infrastructure

4.sidecar模式.每个服务机器上都运行一个附属proxy进程.用来代理网络请求.

5.serviceMesh模式.可以理解为sidecar的网络拓扑组合.

serviceMesh把服务治理细节从sdk中分离出来,也是关注点分离的思想.

2 serviceMesh定位:

A Service Mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the Service Mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

翻译:

服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无感知。

3.serviceMesh提供的功能

1.流量控制.

路由,流量转移,重试,熔断,故障注入,流量镜像.  

2.策略

限流,黑白名单

3.网络安全

授权,身份验证

4.可观察性

指标,日志,调用链路追踪

 

4.serviceMesh的组成

4.1 数据面

envoy,mosn等

4.2 控制面

pilot,主要用来下发规则.

 

 

5.serviceMesh和k8s的关系

k8s本质上是调度器,用来做容器编排和调度

serviceMesh本质是代理,用来解决容器间网络通信

k8s对serviceMesh的部署给予了支持,envoy可以和业务应用部署在同一个pod,不同的容器中.

serviceMesh扩展了k8s的一些网络控制功能,k8s中也有ingress,服务发现,这些功能比较简单,不能满足我们的复杂需求.

 

6.目前的serviceMesh产品

	介绍
(google/ibm/lyft)istio	c++编写,最近有比较稳定版本,刚开始性能一直诟病.
(阿里)sofaMesh	golang编写.pilot是基于pilot
(华为)cesMesh	golang编写.老成持重,先利用现有系统,搞proxy,再搞控制面,先享受技术下沉的好处
(美团)octoMesh	没有找到是基于什么写的?记得分享是说c++
(微博)MotanMesh	golang编写,完全自己实现了一套
(腾讯)TencentMesh	c++,数据面用envoy,控制面基于pilot二次开发,解耦了k8s
(ucloud)ucloudMesh	c++,只使用envoy,以及二次开发的pilot.也是解耦了k8s
(陌陌)momoMesh	java编写

 

proxy的原理其实很简单,还是要从运维/是否开源/开发难度来考虑.c++有一定的开发门槛,如果公司没有c++开发,那么很难进行开发和维护.

第二个,例如是使用iptables进行流量拦截还是使用轻薄的sdk进行代理转发,也需要考虑运维难度,效率,问题排查等等.

而且每个公司都有自己的一些框架,如果用开源的,肯定要想办法将这些框架融合进来.这也是选择开源框架要修改的点.

 

6.云原生

参考文档:https://mp.weixin.qq.com/s/oVH_nny6WT9K8xrkAPoiiQ

 

云原生的概念可以说是 每个人都有每个人的说法

2013	Matt Stine<迁移到云原生架构>	12因素、微服务、自敏捷架构、基于API协作、扛脆弱性
2015	CNCF	容器化封装+自动化管理+面向微服务
2017	Matt Stine	模块化、可观察、可部署、可测试、可替换、可处理
2018	CNCF	容器化封装+自动化管理+面向微服务+服务网格（Service Mesh）和声明式API

可见,云原生不是一个特定的说法,而是一系列技术和方法论的集合.其中涉及到的

12因素：
 

1， 一份基准代码，多份部署
2，显示声明依赖关系
3，在环境中存储配置
4，把后端服务当作附加资源
5，严格分离构建、发布和运行
6，以一个或多个无状态的进程
7，通过端口绑定提供服务
8，通过进程模型进行扩展
9，快速启动和优雅终止
10，开发环境与线上环境等价
11，把日志当作事件流
12，后台管理任务当作一次性进程运行

通过12要素可以:

• 构建水平伸缩的弹性应用架构，更好支撑互联网规模应用。

• 提升研发流程的标准化、自动化水平，提升研发效率。

• 减少开发环境和生产环境的差异，并使用持续交付实施敏捷开发。

• 提升应用的可移植性，适合云化部署，降低资源成本和管理复杂性。

微服务:

系统中的各个服务可被独立开发、独立部署，独立升级，各个服务之间是松耦合的.

一解释就懂,一问就不知,一讨论就打架.可以说很精准了.

 

CNCF- 云原生计算基金会对于“云原生”的定义如下 ：

“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

 

参考文章:

https://skyao.io/talk/201806-service-mesh-explore/