未来已来：云原生（二）

上回书说到后端架构发展历程，还回顾完云计算的历史
本回将继续梳理云原生实现方案 Service Mesh 的发展历程，介绍 Service Mesh 的代表 Istio 的亮眼功能。

什么是原生 Native

在回顾完云计算的历史之后，我们对 Cloud 有更深的认识，接着继续看一下：什么是 Native？
字典的解释是：与生俱来的。
那 Cloud 和 native 和在一起，又该如何理解？

这里我们抛出一个我们自己的理解：云原生代表着原生为云设计。
详细的解释是：应用原生被设计为在云上以最佳方式运行，充分发挥云的优势。

这个理解有点空泛，但是考虑到云原生的定义和特征在这些年间不停的变化，以及完全可以预料到的在未来的必然变化，我们觉得，对云原生的理解似乎也只能回到云原生的出发点，而不是如何具体实现。

Cloud Native 是道，Service Mesh 是术

那在这么一个云原生理解的背景下，我们再来介绍一下对云原生应用的设想，也就是云原生应用应该是什么样子。

在云原生之前，底层平台负责向上提供基本运行资源。而应用需要满足业务需求和非业务需求，为了更好的代码复用，通用型好的非业务需求的实现往往会以类库和开发框架的方式提供，另外在 SOA/ 微服务时代部分功能会以后端服务的方式存在，这样在应用中就被简化为对其客户端的调用代码。

然后应用将这些功能，连同自身的业务实现代码，一起打包。

而云的出现，可以在提供各种资源之外，还提供各种能力，从而帮助应用，使得应用可以专注于业务需求的实现。非业务需求相关的功能都被移到云，或者说基础设施中去了，以及下沉到基础设施的中间件。

以服务间通讯为例：需要实现上面列举的各种功能。

SDK 的思路：在应用层添加一个客户端，在这个客户端中实现各种功能。

Service Mesh 的思路，体现在将 SDK 客户端的功能剥离出来，放到 Sidecar 中。就是把更多的事情下沉，下沉到基础设施中。

在用户看来，应用长这样：

云原生是我们的目标，Service Mesh 交出了自己的答卷，接下来我们可以回到 Service Mesh 这里了。

Service Mesh

其中文译名是服务网格，这个词最早使用由开发Linkerd的Buoyant公司提出，并在内部使用。

定义

服务网格的基本构成

纷争 2017

2017 年年底，当非侵入式的 Service Mesh 技术终于从萌芽到走向了成熟，当 Istio/Conduit 横空出世，人们才惊觉：微服务并非只有侵入式一种玩法，更不是 Spring Cloud 的独角戏！

解读 2017 之 Service Mesh：群雄逐鹿烽烟起

文章总结一下：
创业公司 Buoyant 的产品 Linkerd 开局拿下一血；
Envoy 默默耕耘；
从 Google 和 IBM 联手推出 Istio，Linkerd 急转直下；
2017 年底 Buoyant 推出 Conduit 背水一战；
Nginmesh 与 Kong 低调参与；

百家争鸣 2018

2018 年，Service Mesh 又多了哪些内容呢？在 2018 年，Service Mesh 在国内大热，有多家公司推出自己的 Service Mesh 产品和方案，Service Mesh 更加热闹了。

下一代微服务！Service Mesh 2018 年度总结

文章总结一下：
Service Mesh 在国内大热，有多家公司加入战场；
Istio 发布1.0，成为最受欢迎的 Service Mesh 项目，获得多方支持；
Envoy 继续稳扎稳打，Envoy 被 Istio 直接采用为数据平面，有望成为数据平面标准；
Linkerd1.x 陷入困境，Conduit 小步快跑，但响应平平，Buoyant 公司决定合并产品线，Linkerd1.x + Conduit = Linkerd2.0；
更多的公司参与 Service Mesh，国外有 Nginx、Consul、Kong、AWS等，国内有蚂蚁金服、新浪微博、华为，阿里 Dubbo，腾讯等；