从网络演进看微服务演进

本文的微信链接为：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日

如果你觉得本文对你有帮助，可以转到你的朋友圈，让更多人一起学习。

第一时间获取文章，可以关注本人公众号：月牙寂道长，也可以扫码关注