PaaS中微服务建设方式？

据我了解，目前 spring cloud，dubbo偏主流， Istio偏新锐，关注的人也越来越多，关于关于本质的区别，其实比较好划分，springcloud和dubbo是同一个类型，springcloud是dubbo的爸爸， 两者使用同样的配置方式，透明化接入应用，对应用没有任何 API 侵入，属于微服务分布式调用框架。而 Istio 更侧重于服务聚合层管理，核心亮点是对语言几乎无绑定。
从项目背景、提供功能、社区更新活跃度三个方面来说，SpringCloud 是目前阶段最为稳妥的可执行微服务框架方案，Istio 作为支持对于 Kubernetes 的优先支持来讲，也是一个值得关注的方案。目前对比来看，Dubbo 则显得不如上述两个。

     spring cloud和Dubbo在技术上有许多相似之处，都是基于非中心化的微服务机构，基于spring boot，实现的语言是Java。但两者也有很大的不同，在技术上主要区别有：
    Dubbo基于TCP之上自定义的dubbo-RPC协议，相比springcloud 是http协议传输 ，spring cloud使用JSON字符报文 ，dubbo由于是基于二进制的序列化方式传输，占用带宽会更少；
    基于两者的技术发展，spring cloud和dubbo的主要区别已经不在于传输协议，序列方式等纯技术上的选型区别，实际上，在技术上两者有互相融合的趋势。
      两者本质的区别还是在于对于生态圈的建设方式。我们经常提到“相比spring cloud，dubbo的开发难度较大 ”，这是因为，符合spring cloud框架规范有大量的组件可以选择，这些组件囊括了链路跟踪，服务监控，任务调度，网关控制，服务注册发现，服务配置等等，用户只要选择这些兼容性组件直接使用即可，不用做兼容性测试和适配。可能是因为很多开源组件和框架是国外公司主导的缘故，Dubbo这方面有点力不从心。

  Istio是微服务技术发展的必然结果。Dubbo和spring cloud的一个很大的弊病是对已成型系统改造能力差，而且它们绑定了Java，绑定了Spring boot技术体系。也就是说，它们对业务应用系统是有侵入性的，虽然SC和dubbo的SDK以jar包形式注入到应用系统中，但其实应用系统在开发时就必须要意识到这种架构，升级时还要考虑到与SDK的兼容性。SC和Dubbo必须是开发人员可以玩得起的新技术。
  而Istio作为ServiceMesh技术的代表，相比前一代的SC和Dubbo，它是真正做到业务系统无关，通过sidecar的模式支持已有的业务应用系统，支持各种语言开发的系统。也只有使用istio，运维人员才算可以真正介入到微服务架构的系统维护当中来。
  但由于Istio完全无侵入，与业务系统耦合性过于松散，因此它有很多能力没法做到像SC和Dubbo那样完美，比如性能上，虽然目前的istio版本有很大的提升，但是跟Dubbo等还是有很大的差距，比如一些熔断，降级，任务调度等方面，istio还是非常的弱。另外，istio与K8S耦合很紧，对非容器化的业务系统支持较弱。
  所以，就目前趋势来看，spring cloud，dubbo和istio还会有很长一段时间共存。我们要做的是以业务系统的需要为驱动力选用相应的技术，而不是盲目追求最新最火的技术。