微软的Azure Service Fabric的官方博客在2017.3.24日发布了一篇博客 Service Fabric .NET SDK goes open source ，介绍了社区呼声最高的Service Fabric开源的情况以及当前的情况，当时开源了Service Fabric的.NET SDK部分，社区一直在期盼着Service Fabric的正式开源，经过了一年漫长的等待，2018年3月14日微软终于开源了Service Fabric，而且是以MIT许可下开放源代码，在官方博客宣布 https://blogs.msdn.microsoft.com/azureservicefabric/2018/03/14/service-fabric-is-going-open-source/。
目前微软在Github上的开源地址是 https://github.com/Microsoft/service-fabric ，目前的代码构建适用于Linux的Service Fabric，运行基本测试，有问题可以在上面提交issue和PR了，Windows构建环境以及完整的CI环境还没有迁移过来，看到代码还是3个小时前初始化的。Windows内部为Service Fabric开发了将近十年的内部服务，其中大部分时间都是微软内部平台，比如Office365，Azure Stack平台等，这意味着我们有近十年的内部微软工具可以在迁移之前完成迁移和流程细化，逐步全部开源，以后全部开发都在开源模式下进行开发工作。
微软去年漫长的一年时间里也开放了非常多的代码，包括包括Reliable Services，Reliable Actors和http://ASP.NET Core集成库，Azure基础架构服务以及Azure SQL DB，Azure Cosmos DB和Cortana等大型解决方案都在使用Service Fabric构建。
Dubbo和Spring cloud、Istio对比 - 分享 - Istio 中文社区
第三代微服务框架
Service Mesh（服务网格）
istio是开源的Service Mesh（服务网格），Service Mesh翻译成中文就是服务网格下面会带领大家了解到底什么是istio？
微服务框架对比分析
参考：https://istio.cn/t/topic/33
主流微服务框架：SpringCloud、Dubbo
后起之秀的微服务框架：istio
1、框架背景对比
（1）Spring Cloud，来源于Spring Source ，具有 Spring 社区的强大背书外，还有 Netflix 强大的后盾与技术输出。Netflix 作为一家成功实践微服务架构的互联网公司，在几年前就把几乎整个微服务框架栈开源贡献给了社区，这些框架开源的整套微服务架构套件是 Spring Cloud的核心，核心部分包含如下：
Eureka: 服务注册发现框架；
Zuul: 服务网关；
Karyon: 服务端框架；
Ribbon: 客户端框架；
Hystrix: 服务容错组件；
Archaius: 服务配置组件；
Servo: Metrics组件；
Blitz4j: 日志组件。
（2）Dubbo 是一个分布式服务框架，是国内互联网公司开源做的比较不错的阿里开放的微服务化治理框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。其核心部分包含如下（官网）:
远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模 型，序列化，以及“请求-响应”模式的信息交换方式；
集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持；
自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
Dubbo也是采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用 Spring加载Dubbo的配置即可，Dubbo 基于Spring的Schema扩展进行加载。当然也支持官方不推荐的 API 调用方式。
（3）istio 作为用于微服务服务聚合层管理的新锐项目，是 Google、IBM、Lyft（海外共享出行公司、Uber劲敌） 首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。目前是针对Kubernetes环境的，社区宣称在未来几个月内会为虚拟机和Cloud Foundry等其他环境增加支持。istio将流量管理添加到微服务中，并为增值功能（如安全性，监控，路由，连接管理和策略）创造了基础，具有如下功能
HTTP、gRPC 和 TCP 网络流量的自动负载均衡；
提供了丰富的路由规则，实现细粒度的网络流量行为控制；
流量加密、服务间认证，以及强身份声明；
全范围（Fleet-wide）的策略执行；
深度遥测和报告。
2、开源社区活跃度对比
开源社区情况：现如今企业在采用云计算首选开源，而选择一个开源框架，社区的活跃度将作为重要参考选项。
查看下在Github上的更新时间
Spring Cloud ：Spring Cloud · GitHub → 所有项目均更新于『1 小时』内。
Dubbo ：Dubbo · GitHub → 核心项目最近更新于『一个月乃至数月』前。
istio：istio · GitHub → 所有项目均更新于『30 分钟』内。
可见，项目在社区活跃度上，istio > Spring Cloud > Dubbo，结合稳定性来看，对于使用 Java 系开发业务较多的企业，Spring Cloud 是相对更优的选择，对于更多企业来说，与语言几乎无绑定的Istio也是可以好好期待一下其在社区的发展。
总结：结合项目背景、提供功能、社区更新活跃度，SpringCloud是目前阶段最为稳妥的可执行微服务框架方案，istio作为支持对于Kubernetes的优先支持来讲，也是一个值得关注的方案。目前对比来看，Dubbo则显得稍逊下来。
————————————————
版权声明：本文为CSDN博主「韩先超」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_38320674/article/details/105697733