微服务开发平台 net平台有什么好的微服务框架？

net平台有什么好的微服务框架？

你需要自己考虑一下。关键取决于你想开发什么系统，公司技术人员的能力，以及公司的性质。迪斯科、金福瑞、丽源信息、浦源等在中国比较好。梨园信息可以更好，没有后期收费，开发过程中遇到的问题可以随时解决。

微服务调用为啥用RPC框架，http不更简单吗？

简单一点，HTTP是协议，RPC是概念！RPC可以基于HTTP协议（feign）、TCP协议（netty）、RMI协议（soap）和web服务（XML-RPC）框架实现。在传输过程中，由于序列化方法的不同，也出现了一些框架和协议，如Dubbo中的Dubbo协议、grpc protobuf序列化协议等。实际上，它们都是基于远程调用的概念。什么是远程呼叫？

关键是RPC是远程调用。远程调用是客户端通过上述协议向服务器发送接口、参数、参数类型、方法、返回值、返回值类型等（称为方法签名），通知服务器要调用的接口方法。这个过程就是RPC的实现过程！HTTP和RPC是两码事

！在性能方面，HTTP本身是基于TCP协议的，属于应用层协议，所以HTTP协议本身在实现过程中会占用大量的资源（内存、带宽等）。在性能方面，它肯定不如直接通过TCP实现的RPC协议快。不管HTTP有多优化，它绝对没有TCP那么快！另一方面，TCP依赖于字节码。目前常用的是将客户端调用的接口信息以序列化的方式发送到服务器端。序列化框架包括许多内容（Hession、protobuf、kryo等）。Kryo具有最高的序列化性能，protobuf具有序列化后最小的字节码）。序列化后的字节码越小，占用的带宽越小，序列化时间越长，线程IO延迟越短，线程IO延迟越小。因此，在具体的应用层，有很多技术可以讨论。您可以根据自己的硬件能力选择相应的技术

！欢迎热爱科技的人们来探索

微服务在Docker k8s下如何部署？

最近，这些技术已在项目中使用。让我介绍一些有价值的想法。

首先，结论如下：

1。K8s是一款非常好的技术，非常稳定。如果发现正在运行的pod数量不等于用户设置的期望值，k8s将自动创建或删除pod，直到它们相等为止。这不仅确保了服务的不间断运行，而且还动态地扩展了服务规范。用户只需要调整pod的复制次数，剩下的留给k8s，这很容易让人担心。

2. 使用Jenkins集成命令行操作，虽然我个人比较喜欢使用命令行，但我不得不承认，使用Jenkins集成命令行操作将大大提高工作效率。

实现步骤如下：（本文以Azure平台为例）

1。写dockerfile

2。在Jenkins中创建任务并执行包含以下命令的脚本

2.1 git将源代码拉到本地

2.2 docker build命令生成映像文件

2.3 docker定义映像文件版本号并上载到Azure平台

2.4 kubectl命令创建k8s部署和服务。

每个版本2.5update，可以调用update image来编译新的镜像版本并提供给k8s

注意，在创建k8s的部署和服务时，需要用yaml格式编写配置文件。部署配置包括名称、映像文件地址、最大和最小CPU分配值、最大和最小内存分配值等。服务配置文件包括名称、引用的部署名称以及是否使用负载平衡器。

有关更多详细信息，请参阅我的wikihttps://github.com/FamingHou/MyWiki

Net Core已经开源好几年了, 为什么不像JVM那样很多人研究和调优其GC算法？

我们已经推出了几个。Net核心项目，基本上是docker。净核心2/3。说实话。netcore的GC非常好。基本上，你不需要像Java那样做很多优化。所以没有多少研究是正常的。换句话说，如果一个GC需要做很多优化，那么它肯定不是一个好的GC。当然，平时编程、常用的非托管对象处理等都必须掌握。

系统软件架构中，现在很流行微服务，那么使用微服务就一定好么？微服务有哪些缺点呢？

软件的主要话题应该听说过“没有银弹”吧？如果有一个软件可以解决所有的问题，为什么有这么多的软件开发人员？如果有人说是，他们要么没有在软件行业工作，要么在做广告。

“微服务”不是万能的，它不能解决所有的问题，它有自己的适应场景。我大致总结了以下几种场景：

相对而言，简单的业务需要快速实施，不适合微服务，后期的维护成本远远大于成本。

例如，大型超市有多个收银机，而小型超市也有多个收银机。营业额不足以支付员工的工资。

～

微服务开发平台 service mesh和微服务 微服务架构

版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。