微服务和分布式的区别 net平台有什么好的微服务框架？
net平台有什么好的微服务框架？
谢谢邀请。目前.net平台某款微服务要说很红很好好像真的都谈不上，不像Java的Spring Cloud这样有比较高的人气，但据说可使用Spring Cloud来开发.Net Core应用（.NET Core就是专门针对模块化的微服务架构而设计）。但针对.Net平台的微服务项目也还不少，只是均不太具有多高的人气，相对来说可能Azure Service Fabric算得上比较好的吧。下面是相关.net微服务的部分列表：
1、SteelToe OSS
2、Azure Service Fabric：这款主要是微软构建，而且Service Fabric将开源。
3、.Net China Foundation：这里有多个一微服务为导向的开源项目。
4、Microdot Framework
5、其它还有Xigadee、Apworks frameword、Cronus、NancyFx、GRPC等。
微服务架构主要是在云中部署应用和服务，这一概念提出也并不久，处于快速发展阶段，应用也越来越多越来越广泛。
微服务调用为啥用RPC框架，http不更简单吗？
简单点，HTTP是协议，RPC是概念！实现RPC可以基于HTTP协议（Feign），TCP协议(Netty)，RMI协议（Soap），WebService（XML—RPC）框架。传输过程中，也因为序列化方式的不同，又有一些框架和协议，比如Dubbo中的Dubbo协议，gRpc—Protobuf序列化协议等等。其实，都是基于远程调用的概念，何为远程调用？
重点是，RPC就是远程调用，远程调用就是客户端把调用的接口，参数，参数类型，方法，返回值，返回值类型等（这些称为方法签名），通过如上的协议，发送给服务端，告知服务端需要调用的接口方法，这个过程就是RPC的实现过程！HTTP和RPC是不同层面的两个东西！
性能方面，HTTP本身是基于TCP协议的，属于应用层协议，所以HTTP协议本身在实现过程中就会占用大量的资源（内存，带宽等），性能上肯定没有通过TCP直接实现RPC协议快，不管HTTP如何优化肯定的是不如TCP的！而TCP则是依靠字节码，现在普遍采用的是将客户端调用的接口信息，序列化的方式发送给服务端，序列化框架又包含很多（Hession，Protobuf，Kryo等等，序列化性能最高的是Kryo，序列化后字节码最小的是Protobuf），序列化后的字节码越小，占用带宽越少，序列化时间越短，线程IO等待时间就会越小。所以，在具体应用层面有很多可探讨的技术，可以根据自己的硬件能力来选择相应的技术就可以了！
欢迎热爱技术的人来探讨！
谈谈微服务架构是一个怎样的存在？
微服务是近些年被广泛提及的一个概念，微服务架构可以理解为一个轻量级的服务治理方案，也就是将系统的功能，通过服务的形式发布到服务器上，对服务进行组合调用，实现具体的功能，解决实际业务问题的架构风格。
微服务产生于单体应用的扩大化，随着信息化不断发展，企业对软件功能的要求越来越具体，也愈发的细致，如果通过应用程序来实现，必然是一个极其复杂而又痛苦的过程，由此诞生了微服务的概念。就是将功能发布成服务，应用程序通过调用不同的服务来实现业务，这种设计架构称之为微服务。
微服务架构的优点在于每个服务可以有独立的团队开发，服务之间互不干涉，保障了系统的稳定性。由于功能被拆分到更细的粒度，有效的降低了程序的复杂程度，对硬件的需求也随之降低，但是微服务也有一些不足，比如服务调用带来的系统复杂性，服务间的依赖关系也是难以管理的，如何构建合理的服务依赖是考验架构师能力的重要依据；最后，微服务架构的部署以及跟踪也是很难的。总之，微服务架构有着自身的应用场景以及特点，了解哪些场景适合微服务比掌握微服务的具体技术更为重要，适当的技术用在适当的场景，才能发挥合适的价值。
数通畅联 专注于企业IT架构、SOA综合集成、数据治理分析领域，感谢您的阅读与关注！
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
