net平台能用dubbo吗？
我们说.NET平台生态体系差并不是凭感觉而言的，现实情况就是其生态体系远比不上Java。就目前而言，不管是国外还是国内，知名的一些开源方案基本上都不会考虑.NET平台，换言之，.NET平台想使用这些成熟的开源组件也很难。Dubbo是什么？Dubbo是由阿里开源的一款轻量级、高性能的分布式服务框架，采用Java语言开发。
它主要是为了解决服务治理而生的，提供功能有：远程方法调用、负载均衡、服务注册也发现等。因为整个Dubbo是由Java开发的，.NET平台默认是无法使用Dubbo的，但并不是说.NET就无法接入Dubbo。.NET平台接入Dubbo的方案对于层构系统的通信，有一个非常不错的中间件：Thrift，它是由Facebook开源的一款高效RPC框架，最大特性就是对于平台支持度好，比如Java、C#、C 、PHP、Python、NodeJS等都支持。
而Dubbo支持多种协议，如：HTTP、RMI、Thrift，这样一来就使得.NET平台可以采用Thrift来和Dubbo进行通信了。综合起来看，事实就是这样，Java基本上不需要做太多工作就能调用Dubbo，而.NET要历经折腾才能勉强接入Dubbo，看到这里.NET程序员朋友们是不是有话要说呢？ 以上就是我的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流 ~ 我是科技领域创作者，十年互联网从业经验，欢迎关注我了解更多科技知识！。
大家知道淘宝是用什么语言开发的吗？
淘宝的技术架构一直在变的，分几个阶段：V1.0：小而快（2003.5 – 2004.5）2003年淘宝诞生，用的是LAMP经典架构（linux apache mysql php），后端用的是php语言V2.0：多层次结构，开始做自己的软件（2004.2 – 2008.3）2004年在淘宝业务发展的推动下，淘宝开发参考了电信运营商、银行等的一些企业解决方案，将LAMP架构改造为Oracle IBM小型机的数据库架构和EMC存储方式。
为了配合Oracle，php也彻底被替换为java。V3.0：产品化思维及服务导向框架（2007.10-2009.11）2007年，淘宝全年的交易额超过400亿元，平均近1亿多一天，每天有100多万笔交易被创建。淘宝被改造成分布式架构，引入缓存，分布式存储和分布式搜索引擎。这时候应用服务器使用的是JBoss，数据库又从Oracle变成了MySQL，语言还是java。
V4.0：系统化、智能化、专业化（2009.8-）从2010年开始，淘宝网重点着眼于统一架构体系，从整体系统层面考虑开发效率、运维标准化、高性能、高可扩展性、高可用、低成本方面的要求，底层的基础架构统一采用了阿里云计算平台。这时候的web后端语言没变，还是java。顺便说一下，上图的中间件也是java开发的，java语言在阿里应用非常广，大约90%以上的系统是由Java技术构建。
阿里的dubbo到底是用来干什么的？
阿里发布的Dubbo是一款分布式RPC服务框架，基于Java开发，主要用于各个系统间的相互调用。Dubbo是啥？Dubbo最早是由阿里巴巴开发的一款高性能、轻量级的Java RPC框架，目前已经贡献给Apache了，所以也被称为：Apache Dubbo。传言在早期Dubbo是没有开源的，后来某个工程师离职后把Dubbo带出来了，所以Dubbo开始进入大众视线，随着使用者越来越多，它也就开源了。
Dubbo它是一整套解决方案，致力于提供高性能的RPC远程服务调用方案及SOA服务治理方案。Dubbo的作用1、远程方法调用基于Dubbo可轻松实现透明化的远程方法调用，我们可以像调用本地方法一样调用远程方法，而且是无侵入式的，维护成本低。2、服务注册与发现Dubbo同时也是一款服务治理框架，各个服务统一向注册中心进行注册，代码中不需要写死服务方地址，随时随地上下线服务，动态扩容方便。
如何看待阿里的dubbo项目的“复活”？
2018年1月8日夜间，Dubbo 创始人之一梁飞在 Dubbo 交流群里透露了 Dubbo 3.0 正在动工的消息。百度百科上说：Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。知乎上的答友说：1. Dubbo负载均衡是对外提供一个公共地址，请求过来时通过轮询、随机等，路由到不同server。
目的分摊压力。失效备援是发现一台server挂了，就让另外一台去服务了。跟餐馆换个服务员继续招待你一样；2. Dubbo是Java下的一套RPC框架(soa思想)，作用就是统一管理配置，各个系统服务间的调用。dubbo在淘宝也是解决他们实际问题的，不一定适合其他。 另外各家公司也都有大同小异的实现，所以没多少人用、也就没多少介绍。
原理就是： A系统调用B系统接口服务， 后面就是怎么把这个流程，动态化(zookeeper通知)、权限化、配置化、低耦合化、自动化。总之：Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求。
据了解，新的 Dubbo 内核与 Dubbo 2.0 完全不同，但它兼容 2.0。Dubbo 3.0 将以 Streaming 为内核，而不再是 2.0 时代的 RPC，但是 RPC 会在 3.0 中变成远程 Streaming 对接的一种可选形态。梁飞给出了一个内核接口：Streaming docking(Streaming），他说一切服务治理将围绕这个内核接口进行扩展。
而 Streaming 通道与 gRPC 类似，支持 HTTP/2，同时 REST 接口也会受到一等公民支持，但是梁飞也表示此次在通讯上的改动并不大，重点是在服务治理和编程模型上。说到编程模型的革新，梁飞透露，此次 Dubbo 3.0 能够开工，主要也是因为新特性将去掉一切阻塞，以“一切同步”为第一目标，在对 IO 密集业务的处理上，它能够提高机器利用率，使得一半机器的成本被节省下来。
他还表示，其实 Dubbo 3.0 技术选型重大变更的驱动因素，也就是降低成本，因为在将系统服务化后，全业务线的机器都在等待返回数据，负载压不上去，机器浪费严重。这个去阻塞化的模式，其实就是使用了“反应式编程”模式（Reactive Programming），梁飞介绍，在 Dubbo 3.0 中，reactive 将成为核心，会做到客户端、服务端、缓存和数据库，全程无阻塞。
在数据库上，JDBC 驱动将进行更改，同时，为了性能，还会配合使用阿里毕玄对 JVM 协程的改造。更为重要的是，这个重大变更，不仅体现在 Dubbo 上，它也将影响到阿里 10 年来积累的中间件。群里有人问到是否会采用 Service Mesh，梁飞表示，Dubbo 3.0 将支持可选 mesh，多加一层 IPC，这主要是为了兼容老系统；而内部则会优先尝试内嵌模式。
他说代理模式 Ops 可独立升级框架，减少业务侵入，而内嵌模式可以带业务测试、部署节点少、稳定性检测方便。同时，可以将 Dubbo 3.0 启动为独立进程，由 dubbo-mesh 进行 IPC，路由、负载均衡和熔断机制将由独立进程控制。据说，目前Dubbo 3.0 已正式投入全职开发梯队，初步 Runtime 已在验证，3 月底将在线上应用投入使用。
自去年11月份阿里公开宣布重启维护Dubbo 之后，大家一直在关注着Dubbo 的进展。今天这样一个小道消息的爆出，让大家很是兴奋，希望Dubbo真正完成涅磐重生！Dubbo GitHub地址：https://github.com/alibaba/dubbo（本资讯同步发布于：https://mp.weixin.qq.com/s/PpH9xoj0FZAbjKHkA57AAw，http://www.52im.net/article-282-1.html）。
spring cloud和dubbo哪个会被淘汰？
事实上，很多系统根本就没必要用什么所谓微服务。目前过度设计已经泛滥，明明是一个用户数量有限，功能并不复杂的系统，也要套用所谓的微服务架构，或者要大搞所谓中台，既浪费时间，又浪费金钱，最后系统运维还比较复杂，需要持续投入运维。以服务调用的方式，固然可以有更好的复用性，也可以解耦复杂系统。但实际上，我认为微服务也仅仅是组件化的一种实现方式。
对于组件化，广义的讲，有多种实现方式：第一种，最原始的方式就是以静态函数库或者包的形式存在。这种形式优点是开发方式简单，调用效率高，数据以参数方式进行传递，但耦合度也高，底层组件函数一旦发生变化，则需要重新编译整个工程。通常对于不经常发生变化的基础函数库，可以用这种形式进行开发，形成所谓的公共函数库，供大家使用。
第二种，称之为动态函数库，在windows环境下以dll形式存在，linux环境下以so形式存在。动态函数库相对于静态函数库，优势在于可以在运行时动态加载，可以在不用重新启动整个应用的情况下进行更新。缺点是动态函数不能共享原应用程序的存储空间，导致动态函数调用有时需要传递大量参数，导致一些不便。动态函数库也具有一定耦合度，函数名和参数必须严格按照约定调用，否则会报错。
在早期单体架构下，动态函数库还是有大量使用的。第三种，就是目前所谓的微服务架构了。微服务事实上也是可以看作是一种函数调用方式，提供基于RPC和restful远程调用方式。调用时需要传递调用的服务名称及数据报文。这种方式耦合度自然是比较低一些的，但是调用效率肯定低于函数调用方式，主要是数据传输和报文解析方面消耗的时间。
此外还需要考虑通讯流量控制，超时机制，服务寻址，服务可用性等方面的问题。因而降低耦合度，事实上是以增加了系统的整体复杂度和降低调用效率为代价的。个人认为不应该过度解耦，或者仅仅强调可复用性。要知道，任何事情都是有代价的，必须要充分评估这种代价是否值得。第四种，就更进一步，即以独立的系统存在，该系统具有独立性和完备性，可以不过于依赖其他外部系统独立运行，对外部以服务或api的形式进行交互。
例如，单点登录系统，信贷系统，核心系统等。因而，在系统架构设计和建设过程中，必须认真进行评估，不应该过分侧重于某一方面特性的实现，否则就是过犹不及，最后导致整体出现问题。个人认为，目前大部分所谓基于微服务的中台系统就是陷入了过于强调解耦的误区，导致过度的解耦设计，而忽略了由此带来的弊端，最后陷入了泥潭。
