背景 接上一篇,放弃了 asp.net core + gRPC 的方案后,我灵光一闪,为什么不用 web api 呢?不也是 asp.net core 的吗?虽然 RESTful 不是强约束,客户端写起来也麻烦,但还是可以满足基本需求,避免大幅修改旧有的业务逻辑代码. 在网上找到相当多的文章,比较 gRPC 和 RESTful 的优缺点,结论都是 gRPC 推荐用作内部系统间调用, RESTful 推荐用作对外开放接口. 选择 RESTful 另一个最重要的原因是,gRPC 的底层框架需要HTT

使用protobuf-net.Grpc将WCF服务迁移到gRPC非常简单.在这篇博文中,我们将看看它到底有多简单.微软关于将WCF服务迁移到gRPC的官方指南只提到了Gooogle.Protobuf方式,如果你有很多数据契约需要迁移到.proto格式,这可能会很耗时.然而,通过使用protobuf-net.Grpc我们能够重用旧的WCF数据契约和服务契约,而只需要做最小的代码更改. 迁移数据契约和服务契约 在本节中,我们将使用一个简单的请求响应的组合服务,它可以让你下载给定交易者的单个投资组合或

浅议Grpc传输机制和WCF中的回调机制的代码迁移 一.引子 如您所知,gRPC是目前比较常见的rpc框架,可以方便的作为服务与服务之间的通信基础设施,为构建微服务体系提供非常强有力的支持. 而基于.NET Core的gRPC.NET 组件截至2019年11月30日的最新版本为2.25.0,该版本基于.netstrandard2.1进行,能够在.NET Core3.0上非常方便的实现,而且还能方便的迁移到基于.NET Core的windows桌面端开发体系. 在本文中参考微软官方文档的示例,实现

一个月前,公司的运行WCF的windows服务器down掉了,由于 AWS 没有通知,没有能第一时间发现问题. 所以,客户提出将WCF服务由C#改为JAVA,在Linux上面运行:一方面,AWS对Linux有较多的监控措施,另一方面,假如出现问题,可以设置自动重启等服务. 老旧的WCF服务 目前WCF服务,主要提供windows桌面软件的数据接口,应该有五六年的历史了.我进入公司后,WCF服务的代码,一直由我一个人来维护.存在很多历史遗留问题,也有不同版本的共存. 如果java重写的话,其中的业

翻译:使用 CoreWCF 升级 WCF 服务到 .NET 6 原文地址:https://devblogs.microsoft.com/dotnet/upgrading-a-wcf-service-to-dotnet-6/ 大约在 3 年之前,我发布过一篇将一个 WPF 应用迁移到 .NET Core 3 演练过程的博客.这是一个被称为 Bean Trader 的简单商用交易示例程序.当时,我只能迁移示例解决方案的一部分.这个 Bean Trader 解决方案包括一个 WPF 客户端应用和一个客

有人说.NET在国内的氛围越来越不行了,看博客园文章的浏览量也起不来.是不是要转Java呢? 没有必要扯起语言的纷争,Java也好C#都只是语言是工具,各有各的使用场景.以前是C#非开源以及不能在Linux上使用,没有被互联网公司考虑,但它仍然有它的用途.这几年国内互联网公司进入蓬勃发展时期,所有才有这样的趋势.但并不代表C#不能做互联网应用,可以说在接下来的一年内.net core将会成为一个很好的趋势,结合容器以及微服务架构会成为互联网公司另一个比较好的选择. 作为现在在用.NET的公司,如

  向ASP.NET Core迁移   有人说.NET在国内的氛围越来越不行了,看博客园文章的浏览量也起不来.是不是要转Java呢? 没有必要扯起语言的纷争,Java也好C#都只是语言是工具,各有各的使用场景.以前是C#非开源以及不能在Linux上使用,没有被互联网公司考虑,但它仍然有它的用途.这几年国内互联网公司进入蓬勃发展时期,所有才有这样的趋势.但并不代表C#不能做互联网应用,可以说在接下来的一年内.net core将会成为一个很好的趋势,结合容器以及微服务架构会成为互联网公司另一个比较好

.NET Core love gRPC 千呼万唤的 .NET Core 3.0 终于在 9 月份正式发布,在它的众多新特性中,除了性能得到了大大提高,比较受关注的应该是 ASP.NET Core 3.0 对 gRPC 的集成了. 它的源码托管在 grpc-dotnet 这个 Github 库中,由微软 .NET 团队与谷歌 gRPC 团队共同维护. .NET Core 对 gRPC 的支持在 grpc 官方仓库早已有实现(grpc/csharp),但服务端没有很好地与 ASP.NET Core

记得当时往wcf迁移了部分service以后,tester发现有时候系统会没有任何反应,cpu占用倒是没有问题,可就是做不了事情. 感觉是哪里死锁了,但也不是每次都能再现,后来发现如果把callback关了,这个问题就不出现了,那就可以确定是callback的问题. 再深入调查,就发现原来callback是在client的主线程被调用,即使wcf在非主线程发出请求,如果有callback的话,都会导致这个结果,这是和某个属性联系的,默认就是用主线程调用,当时觉得很不合逻辑啊,因为这样是很容易引起

本文转自:http://www.servicemesh.cn/?/article/41 作者:MIKE WHITE 翻译:姚炳雄 原文:Using Envoy to Load Balance gRPC Traffic 针对 Bugsnag(一款bug自动检测工具),我们最近启动了一个专门用来跟踪软件发布健康状况的发布仪表板项目. 这是个大任务,当我们在构建后台时,特别关注了它的性能.其中的关键领域之一是和后端服务调用相关的延迟,在最后,我们决定用 Google 的超级快速的 gRPC 框架替换R

从编程开发的角度来说,Apache Dubbo (以下简称 Dubbo)首先是一款 RPC 服务框架,它最大的优势在于提供了面向接口代理的服务编程模型,对开发者屏蔽了底层的远程通信细节.同时 Dubbo 也是一款服务治理框架,它为分布式部署的微服务提供了服务发现.流量调度等服务治理解决方案. 在这篇文章中,我们将以以上基础能力为背景,尝试突破 Dubbo 体系自身,探索如何利用 Dubbo 对多协议.多服务发现模型的支持,来实现异构微服务体系间的互联互通.在实际业务场景中,这可以用来解决异构技术

Dapr 相关的文章我已经写了20多篇了[1] . 当向其他人推荐Dapr 的时候,需要回答的一个问题就是: Dapr 似乎并不是特别令人印象深刻.它提供了一组"构建块",解决了与构建微服务相关的几个挑战.这些构建基块包括服务到服务调用.发布订阅消息传递.状态管理.可观察性.机密管理和Actor 编程模型. 但是,我们不是已经有了所有这些的解决方案吗? 是的 任何构建微服务应用程序的人都已经不得不处理所有这些问题,我们看到这些人 提到的工具和框架对于减轻痛苦有很长的路要走. 我认为Da

文章转载自:https://i4t.com/5451.html 背景 Kubernetes 1.24新特性 从kubelet中移除dockershim,自1.20版本被弃用之后,dockershim组件终于在1.24的kubelet中被删除.从1.24开始,大家需要使用其他受到支持的运行时选项(例如containerd或CRI-O):如果您选择Docker Engine作为运行时,则需要使用cri-dockerd. 对于kubelet和containerd重要提示 在升级至1.24之前,请确认c

Windows10 1809版本开始,微软又对UWP开放了新的Capability:AllowElevation. 通过这个新的Capability,UWP APP能够在运行时向用户请求Admin权限,配合Windows 1607版本就引入的RunFullTrust Capability(参考<迁移桌面程序到MS Store(9)——APPX With Desktop Extension >),我们可以让MS Store中的APP拥有无限接近传统桌面程序的能力.本篇提到的Sample工程位于全

长期以来在wcf客户端库 https://github.com/dotnet/wcf 里反应最强烈的就是.NET Core的服务端支持 https://github.com/dotnet/wcf/issues/2695 ,在build 2019 大会上微软明确说明在将WinForms,WPF和Entity Framework 6添加到.NET Core 3.0后,不打算再将.NET Framework中的技术添加到.NET Core中.这意味着微软不会向.NET Core添加ASP.NET We

CoreWCF 1.0 正式发布,支持 .NET Core 和 .NET 5+ 的 WCF https://devblogs.microsoft.com/dotnet/corewcf-v1-released/ CoreWCF 项目组正式发布 1.0 版本的 CoreWCF, 这是面向 .NET Core 平台的 WCF 移植版本.它支持 SOAP.NetTCP 和 WSDL 的相同实现.在代码中的使用方式于 WCF 相同,但是升级到使用 ASP.NET Core 作为服务宿主,并工作在 .NET

原文链接 https://devblogs.microsoft.com/dotnet/bing-ads-campaign-platform-journey-to-dotnet-6/ 广告组件平台对于微软搜索平台能给用户提供好的用户体验至关重要,这个平台支持超过450000个广告商允许他们创建广告. 在一秒钟内,该平台处理数千个web请求,而且时延不超过100毫秒. 支撑这个平台的是几十个分布式服务,现在这些服务都要构建在.net 6 之上,运行在微软自己的AKS云服务的Linux容器中. 要实现

一.写在最前 由于本人的技术水平有限,难免会出现错误.本文对任何一个人有帮助都是我莫大的荣幸,任何一个大神对我的点拨,我都会感激不尽. 二.技术选型 在2013年8月低的时候,公司中了XXX市场监督局肉品配送车辆监控的项目.整个系统软件部分需要实现的功能不难,最大的难点就是服务器的系统要求是Linux的,其次就是10月底系统能够初步成型.由于之前做的车辆监控系统都基于Windows的,要在短时间内完成这个项目,于是Mono就成了我的首选.张善友的博客,也成了我经常光顾的地方,后来通过跟张哥的一番

Google的ProtoBuf序列化器性能的牛逼已经有目共睹了,可以把它应用到Socket通讯,队列,Wcf中,身为dotnet程序员一边期待着不久后Grpc对dotnet core的支持更期待着Wcf有一天能在Linux平台上闪瞎所有人.现在简单表述下Wcf中应用ProtoBuf替代默认的序列化器. 准备: 首先,新建一套Wcf的解决方案,包含服务,宿主外加两个客户端用来测试调用: Wcf_ProtoBufSample.ClientViaMetaData会通过添加服务引用的方式调用服务,Wcf

Google 刚刚开源了grpc,  一个基于HTTP2 和 Protobuf 的高性能.开源.通用的RPC框架.Protobuf 本身虽然提供了RPC  的定义语法,但是一直以来,Google 只开源了Protobuf 序列化反序列化的代码,而没有开源RPC 的实现,于是存在着众多良莠不齐的第三方RPC 实现,不过我在项目中采用WCF搭配Protobuf是一个很不错的RPC实现,Google这个框架是是基于HTTP2的,这是他有特色的地方,带来诸如双向流.流控.头部压缩.单TCP连接上的多复用