本文的微信链接为：https://mp.weixin.qq.com/s/rFSLG8KY9yX6-EpwCkFm4g
微服务架构演进，可以从很多方面去解读。本文从网络进化的模式角度去看待微服务架构的演进。为何要从这个角度来解读呢？
整个微服务架构的演进，其实是和整个网络的演进是类似的。之所以这么说，其中最关键的部分在于单体服务被拆分为多个微服务之后，多个服务之间的通信和治理，于是乎变得非常的重要。而这与互联网的演进的及其类似的。
那么就从最初的开始。
在计算机刚出现的很长一段时间，计算机都是以单机应用为主，那个年代，出现过纸带编程。所有的计算，资源等等都是在单机内。
而对于服务来说，单体程序可以看做是最简单，最初始的状态。
在这个时期，多个计算机，进行一一对应的联网，这个时候交换机和路由器并未出现。一一通信模式，能够简单的将计算机进行配合协作完成一些工作。
对应的服务架构，我们将单体程序，拆分成几个部分，但还是部署在同一台机器上，各个程序之间，通过ipc通信进行协作。在这里由于是同一个主机，就不存在所谓的分布式服务之间的很多缺陷。但其本身的缺陷在于单机资源毕竟是有限的。
对网络的要求不再满足单机一对一的通信模式，于是交换机和路由器出现了。这下就简化了。
而对于微服务，如何将这些组织起来。Api gateway，可以解决服务之间的访问，也可以解决对外用户的访问问题。
这里面还有一些服务发现，治理等。那么对应的是什么呢？dns服务，可以对应于服务发现。而服务治理，可以看做是路由器上的一部分功能，比如限流等
那么到这里就完了吗？
并没有，网络的发展还在继续。
最新型的sdwan出现了
控制与转发分离模式，在现有的物理网络上面，构建一个全新的网络。网关只做数据转发，而sdwan控制器，用于控制网关的数据路由，实现控制与转发的分离。
那么我们看看最新的service mesh
service mesh与sdwan类似，控制与转发做到了分离。
Service Mesh由data plane构成，服务通过sidecar代理进行服务通信。（所有代理相互连接形成一个Mesh，Service Mesh由此得名）网格同时包含一个control plane——可以将所有独立的sidecar代理连接到一个分布式网络中，并设置网格还包括一个控制平面——它将所有独立的sidecar代理连接到一个分布式网络中，并设置由data plane指定的策略。
那么到这里就完了吗？
那么对于api gateway与service mesh我们该如何处理？我觉得是可以将其两者进行整合的。
我们从网络的角度看下。sdwan目前解决的问题是什么？当前用的最多的在于，分布在全球各地的企业，进行企业内部打通通信的场景。
而当我们需要访问一个网站的时候，需要的还是dns和普通物理网下的路由器转发。
那么对于service mesh与api gateway。我认为是类似的。
api gateway可以解决对外暴露的服务整合问题。
而对于service mesh，可以用于内部大量服务之间通信，服务治理等问题。
当然api gateway也好，service mesh也好，都不是银弹。如何使用，还得看待具体的场景。
以上只是个人的一些简单看法。有很多方方面面无法全部覆盖。如果有什么想交流的，可以找我。
龚浩华
月牙寂道长
QQ 29185807
2018年08月15日
如果你觉得本文对你有帮助，可以转到你的朋友圈，让更多人一起学习。
第一时间获取文章，可以关注本人公众号：月牙寂道长，也可以扫码关注
