Docker&k8S&ServiceMesh与Dubbo&SpringCloud微服务框架思考
声明：如下文字纯属个人想法，不保证适合所有人或企业，也代表任何机构观点！
就微服务框架而言，可以认为出现了两个版本：微服务1.0和微服务2.0
微服务1.0：
代表就是阿里开源的Dubbo和Povital的SpringCloud，相对SpringCloud而言，Dubbo更多的是一种服务治理框架，并不能完全覆盖微服务的各项功能需求。而Spring Cloud一方面是针对微服务而设计，另外一方面Spring Cloud是通过集成各种组件的方式来实现微服务，因此理论上可以集成目前业内的绝大多数的微服务相关组件，从而实现微服务的全部功能。就Dubbo而言，如果一定要应用到微服务的使用场景中的话，则可以通过集成第三方应用和组件的方式来实现，跟Spring Cloud相比主要的缺陷在于集成过程中的便利性和兼容性等问题。
不论是Dubbo还是SpringCloud，都是面向Dev的，并不涉及Ops，同时对开发语言的支持有限制，如SpringCloud仅支持java语言。从一个项目生命周期来看，软件功能开发仅是开始，后续如何运维、扩容都是问题，而无论Dubbo还是SpringCloud，在这方面并不擅长，或者说并未涉及，他们只是提供了把单体应用进行微服务拆分时，以及微服务运行时所需的各种组件以及协议框架，但是如何来控制运行中的应用、通信、安全等，需要运维自己想办法。简单来说，微服务1.0框架并没有实现应用程序（业务逻辑）与控制层面的解耦。业务逻辑的实现和对业务逻辑的控制是揉在一起的。以openstack为例，openstack虽然通过kolla-ansible也实现了微服务架构的理念，从整个集群功能角色来看，也实现了数据面和控制面的分离，但是在微服务层面没有实现功能与控制的分离，或者说宏观上实现了分离，但是微观上并没有，没有的结果就是，服务之间的通信仍然需要消息队列中间件的存在，同时每个功能项目都剥离一个API子项目出来，如nova-api、cinder-api等等，因此在openstack中，应用与通信之间是没有分离的，或者说服务之间的通信对应用程序不透明。
微服务2.0：
Docker+K8S+ServiceMesh，需要指出的是，微服务并不意味着一定要容器化，一定要通过docker才能实现，微服务的本质是对大型单体应用进行拆分，而不是容器化，docker的出现只是让这些拆分后的微服务更好的实现了封装隔离和部署交付。不使用容器，通过SpringCloud也可以实现微服务，只是此时的微服务以传统进程方式部署在宿主机上，暴露在系统中。那么K8S与微服务又是什么关系？从功能覆盖面上来看，K8S与SpringCloud有很多功能是重叠的，比如服务发现、配置管理、服务注册、负载均衡等等，K8S主要实现对Docker容器的编排部署和管理配置等，简单点说，把大型单体应用拆分、Docker封装后，通过K8S就可以对其进行生命周期的管理了。相对于SpringCloud，K8S更侧重于Ops，所以如果是考虑走DevOps路线，docker+K8S会是优先选择。那么ServiceMesh在微服务中又有什么用？
其实用docker+K8S和SpringCloud都可以实现微服务，但是他们有个共同点，就是应用层面（业务逻辑层面）与控制层面没有分离，虽然实现了微服务，但是在微服务这个实体里面程序功能与对功能的控制是合在一起的。ServiceMesh要做的事情就是把应用层和通信层隔离，让微服务之间的通信通过一个独立层来实现，具体地说，就是通过Sidecar来实现，每个微服务在部署时候都对应有个Sidecar，所有Sidecar连接起来，就是服务网格。还是以openstack为例，如果把openstack用SeviceMesh架构改写，那就不需要存在MQ和API了，所有服务之间的通信全部交给服务网格（即Sindecar的实现，如Envoy），服务仅需访问身边的Sidecar即可实现与其他服务的通信，在不需要通过Pub/Sub机制在MQ中传递/获取消息，这种模式最大的好处之一，就是在openstack大规模部署时候，再也不用担心MQ队列拥堵造成服务通信延迟甚至卡死或性能急剧下降了。
目前ServiceMesh实现最成熟的方案就是Istio,Istio有控制层面和数据层面之分，数据层面主要就是负责服务之间的通信，其实现主要是Enovy，而控制层面主要负责控制Enovy如何传递数据，说白了就是数据传输的控制大脑，打个比方，Enovy就是路上的高铁列车，负责运输，控制层面就是高铁控制中心，什么时候发车、开多少码、什么时候停车、停在哪、开车时允许的负载，都是控制中心说了算，这里的控制中心，就是Istio的控制层面。