序 上一篇博客把grpc的概念说了个大概,介绍了proto的数据类型,基本语法,也写了个小demo,是不是没那么难? 今天要从理论到实际,写两个微服务,并利用grpc完成两者之间的通信.只是作为demo写的话会十分简单,毕竟理解为主. 服务端 首先要拿出之前写好的proto文件,然后修改两个属性: Build Action => Protobuf compiler gRpc Stub Classes => Server only 如图: 当然也可以在项目文件里看到它: 然后重新生成项目 ,会自…

前言 当一个APM或一个日志中心实际部署在生产环境中时,是有点力不从心的. 比如如下场景分析的问题: 从APM上说,知道某个节点出现异常,或延迟过过高,却不能及时知道日志反馈情况,总不可能去相应的节点上一个一个的翻日志文件吧. 从日志中心上说(特别是Exceptionless,能及时反馈出异常信息),知道某个节点出现异常日志,可不知道引起异常的源头在哪:或者出现延迟过高日志,却不能及时知道节点问题,还是链路问题:就算诸上问题都能应付,那么一行行的.一个个的日志文件和使用图形化的表述形式,谁会更加…

原文:NET Core微服务之路:实战SkyWalking+Exceptionless体验生产下追踪系统 前言 当一个APM或一个日志中心实际部署在生产环境中时,是有点力不从心的. 比如如下场景分析的问题: 从APM上说,知道某个节点出现异常,或延迟过过高,却不能及时知道日志反馈情况,总不可能去相应的节点上一个一个的翻日志文件吧. 从日志中心上说(特别是Exceptionless,能及时反馈出异常信息),知道某个节点出现异常日志,可不知道引起异常的源头在哪:或者出现延迟过高日志,却不能及时知道节…

如今框架两字已经烂大街了,xx公司架构设计随处可见,不过大多看个热闹,这些框架如何来的,细节又是如何思考的,相互之间的隔离依据又是什么...相信很多朋友应该依然存在自己的疑惑,特别是越来越火热的微服务以及衍生的微服务网关产品,正好最近打算写一个小开源框架OSS.Core,过程中有一点思考,通过这篇文章记录一下,也希望能尽量帮助大家去理解一下,大概围绕以下几个问题: 1. 微服务产生的由来 2. 微服务的设计思路 3. OSS.Core框架的设计和实现 在展开讲述之前,我希望大家首先要明白传统架构…

前言 上一篇[.Net Core微服务入门全纪录(二)--Consul-服务注册与发现(上)]已经成功将我们的服务注册到Consul中,接下来就该客户端通过Consul去做服务发现了. 服务发现 同样Nuget安装一下Consul: 改造一下业务系统的代码: ServiceHelper.cs: public class ServiceHelper : IServiceHelper { private readonly IConfiguration _configuration; public S…

前言 上一篇[.Net Core微服务入门全纪录(四)--Ocelot-API网关(上)]已经完成了Ocelot网关的基本搭建,实现了服务入口的统一.当然,这只是API网关的一个最基本功能,它的进阶功能还有很多很多. 服务发现 首先需要解决的就是服务发现的问题,服务发现的优点之前讲过,就不说了. 上一篇中我们的服务地址都是写在ocelot.json配置文件里,现在我们需要结合之前的Consul来实现服务发现. 改造代码: 首先NuGet安装Ocelot.Provider.Consul: 修改St…

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.REST or RPC ? 1.1 REST & RPC 微服务之间的接口调用通常包含两个部分,序列化和通信协议.常见的序列化协议包括json.xml.hession.protobuf.thrift.text.bytes等:通信比较流行的是http.soap.websockect,RPC通常基于TCP实现,常用框架例如dubbo,netty.mina.thrift. REST:严格意义上说接口很规范,操作对象即为资源,对资源的四种…

ASP.NET Core 微服务初探[1]:服务发现之Consul   在传统单体架构中,由于应用动态性不强,不会频繁的更新和发布,也不会进行自动伸缩,我们通常将所有的服务地址都直接写在项目的配置文件中,发生变化时,手动改一下配置文件,也不会觉得有什么问题.但是在微服务模式下,服务会更细的拆分解耦,微服务会被频繁的更新和发布,根据负载情况进行动态伸缩,以及受资源调度影响而从一台服务器迁移到另一台服务器等等.总而言之,在微服务架构中,微服务实例的网络位置变化是一种常态,服务发现也就成了微服务中的一…

微服务架构,对于从事JAVA架构的童鞋来说,早已不是什么新鲜的事儿,他们有鼎鼎大名的Spring Cloud这样的全家桶框架支撑,包含微服务核心组件如 1. Eureka:实现服务注册与发现. 2. Zuul:实现统一API网关. 3. Hystrix:实现熔断保护与可视化监控. 4. Config:实现统一管理配置. (如还有更多组件,欢迎补充) 都是我们NET程序员梦寐以求的组件,而.NET Core发展至今,也专门是为微服务提供的框架平台,只是目前处于各路神仙各显神通的阶段,没有一个统一的…

接着上一篇说,正好也是最近项目里用到了,正好拿过来整理一下,园子里也有一些文章介绍比我详细. 简单介绍一下绍轻量的故障处理库 Polly  Polly是一个.NET弹性和瞬态故障处理库 允许我们以非常顺畅和线程安全的方式来执行诸如重试.断路器.超时.隔离.缓存.后退等策略, 能为我们在微服务架构提供更稳定的服务.当然,目前的 Service Mesh 显得更高大上,而且更强大,它更偏向从运维层面解决以上问题,不过这还是的看具体项目中怎么去使用和决定了. 在微服务架构下,我们可能会遇到类似以下问题…