Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.Exceptionless极简介绍 Exceptionless 是一个开源的实时的日志收集框架,它可以应用在基于 ASP.NET,ASP.NET Core,Web API,Web Forms,WPF,Console,ASP.NET MVC 等技术开发的应用程序中,并且提供了REST接口可以应用在 Javascript,Node.js 中.它将日志收集变得简单易用并且不需要了解太多的相关技术细节及配置,对于微服务架构的应用程序来说,

原文:.net core 微服务之日志落盘设计 目录 1.设计目标 2.日志流程 3.串联请求事务 3.1 请求ID 3.2 处理服务器.服务 3.3 处理接口名 3.4 日志的发生时间 3.5 接口返回状态码 4.记录结构 5.RabbitMq队列 6.落盘 7.性能优化 8.简单统计 引用链接 1.设计目标 对各个微服务的访问进行请求追踪,注重排查开发.线上问题 消息队列发送.多服务落盘,事后分析 日志分析 性能优化 2.日志流程 前端Api网关MQXX微服务api请求1条代理层访问时间日志

参考资料: 1 .Logstash中文官网 2. 阿里云Elasticsearch> 最佳实践 > logstash部署 3. logstash.elasticsearch.kibana搭建日志平台(CSDN) 4.ELK(ElasticSearch, Logstash, Kibana)搭建实时日志分析平台 (CSDN) 4. elasticsearch5.x安装中一些问题的解决办法 5. centos7虚拟机安装elasticsearch5.0.x-安装篇 一 ELK平台简介 开源实时日志分

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.什么是Tracing? 微服务的特点决定了功能模块的部署是分布式的,以往在单应用环境下,所有的业务都在同一个服务器上,如果服务器出现错误和异常,我们只要盯住一个点,就可以快速定位和处理问题,但是在微服务的架构下,大部分功能模块都是单独部署运行的,彼此通过总线交互,都是无状态的服务,这种架构下,前后台的业务流会经过很多个微服务的处理和传递,我们会面临以下问题: 分散在各个服务器上的日志怎么处理? 如果业务流出现了错误和异常,如何定位

Tip: 此篇已加入.NET Core微服务基础系列文章索引 =>  Steeltoe目录快速导航: 1. 基于Steeltoe使用Spring Cloud Eureka 2. 基于Steeltoe使用Spring Cloud Zuul 3. 基于Steeltoe使用Spring Cloud Hystrix 4. 基于Steeltoe使用Spring Cloud Config 5. 基于Steeltoe使用Zipkin 一.关于Spring Cloud Sleuth与Zipkin 在 Sprin

最近比较忙,好久没更新了.这次我们来聊一聊分布式事务. 在微服务体系下,我们的应用被分割成多个服务,每个服务都配置一个数据库.如果我们的服务划分的不够完美,那么为了完成业务会出现非常多的跨库事务.即使按照 DDD 的原则来切分服务还是免不了有的业务场景需要多个业务同时提交成功或者同时回滚的场景.比如会员使用积分下订单这个场景,那么会员服务的积分扣减需要跟订单下单成功同时完成.如果下单成功,但是扣减积分接口失败,那么就会造成数据的不一致性.这个时候我们就需要使用分布式事务来保证数据的一致性. 由于

上一次我们讲解了分布式事务的 2PC.3PC .那么这次我们来理一下 TCC 事务.本次还是讲解 TCC 的原理跟 .NET 其实没有关系. TCC Try 准备阶段,尝试执行业务 Confirm 完成业务 Cancel 回滚准备阶段的业务 TCC 事务其实是 2PC 的一个扩展.上一次我们说了 2PC ,在二阶段进行事务提交.因为 2PC 基本上是利用数据库的 事务能力进行 commit ,其实这里还有可能出现一种 rollback 情况. TCC 就是把 2PC 的二阶段细化了,拆分成了 C

前面我们讲了分布式事务的2PC.3PC , TCC 的原理.这些事务其实都在尽力的模拟数据库的事务,我们可以简单的认为他们是一个同步行的事务.特别是 2PC,3PC 他们完全利用数据库的事务能力,在一阶段开始事务后不进提交会严重影响应用程序的并发性能.TCC 一阶段虽然不会阻塞数据库,但是它同样是在尽力追求同时成功同时失败的一致性要求.但是在很多时候,我们的应用程序的核心业务为了追求更高的性能.更高的可用性,可以允许在一段时间内的数据不一致性,只需要在最终时刻数据是一致就可以了.基于以上场景我们

前言 日志,一直以来都是开发人员和运维人员最关心的问题.开发人员可通过日志记录来协助问题定位,运维人员可通过日志发现系统隐患,故障等定位问题.如果你的系统中没有日志,就像一个断了线的风筝,你永远不知道它会的落脚点(故障点)在什么地方.当然,你说你不用日志,非要用调试模式来一个一个的排查和验证问题,那这将是非常疯狂的. 微服务架构日渐火热,在享受微服务带来的种种好处的同事,也要承担她所带来的各种困扰.因为系统不再是一个独立的个体,而是分部到不同地方.不同宿主.不同区段单独的服务个体(节点),他散落

一.前言 至今为止编程开发已经11个年头,从 VB6.0,ASP时代到ASP.NET再到MVC, 从中见证了.NET技术发展,从无畏无知的懵懂少年,到现在的中年大叔,从中的酸甜苦辣也只有本人自知.随着岁月的成长,技术也从原来的三层设计到现在的领域驱动设计,从原来的关系型数据库SQL 2000到现在的NOSQL (mongodb,couchbase,redis),从原来基于SOAP协议的web service到现在基于restful 协议的web api,wcf,再到现在rpc微服务.技术的成长也

一.为啥要总结和收集这个系列? 今年从原来的Team里面被抽出来加入了新的Team,开始做Java微服务的开发工作,接触了Spring Boot, Spring Cloud等技术栈,对微服务这种架构有了一个感性的认识.虽然只做了两个月的开发工作,但是对微服务架构的兴趣却没有结束,又因为自己的.NET背景(虽然对.NET的生态有点恨铁不成钢),想要探索一下在.NET平台下的微服务架构的可行性,也准备一些材料作为分享的素材. 幸运的是,在.NET Core首届在线峰会上,看到了很多前辈的分享,也增强

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.Consul基础介绍 Consul是HashiCorp公司推出的开源工具,用于实现分布式系统的服务发现与配置.与其他分布式服务注册与发现的方案,比如 Airbnb的SmartStack等相比,Consul的方案更“一站式”,内置了服务注册与发现框 架.分布一致性协议实现.健康检查.Key/Value存储.多数据中心方案,不再需要依赖其他工具(比如ZooKeeper等),使用起来也较 为简单. Consul用Golang实现,因此具

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.消息队列与RabbitMQ 1.1 消息队列 “消息”是在两台计算机间传送的数据单位.消息可以非常简单,例如只包含文本字符串:也可以更复杂,可能包含嵌入对象.消息被发送到队列中,“消息队列”是在消息的传输过程中保存消息的容器. 消息队列(Message Queue),是分布式系统中重要的组件,其通用的使用场景可以简单地描述为: 当不需要立即获得结果,但是并发量又需要进行控制的时候,差不多就是需要使用消息队列的时候. 消息队列主要解

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.预备知识:数据一致性 关于数据一致性的文章,园子里已经有很多了,如果你还不了解,那么可以通过以下的几篇文章去快速地了解了解,有个感性认识即可. (1)左正,<保证分布式系统数据一致性的6种方案> (2)成金之路,<分布式系统的数据一致性解决方案> (3)E_Star,<分布式环境下数据一致性的设计总结> (4)Itegel,<分布式事务?No,最终一致性> 必须要了解的点:ACID.CAP.B

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.CAP简介 下面的文字来自CAP的Wiki文档:https://github.com/dotnetcore/CAP/wiki CAP 是一个在分布式系统中(SOA,MicroService)实现事件总线及最终一致性(分布式事务)的一个开源的 C# 库,她具有轻量级,高性能,易使用等特点.我们可以轻松的在基于 .NET Core 技术的分布式系统中引入CAP,包括但限于 ASP.NET Core 和 ASP.NET Core on

Tip: 此篇已加入.NET Core微服务基础系列文章索引 =>  Steeltoe目录快速导航: 1. 基于Steeltoe使用Spring Cloud Eureka 2. 基于Steeltoe使用Spring Cloud Zuul 3. 基于Steeltoe使用Spring Cloud Hystrix 4. 基于Steeltoe使用Spring Cloud Config 5. 基于Steeltoe使用Zipkin 一.关于Steeltoe与Spring Cloud Steeltoe的官方地

今年从原来的Team里面被抽出来加入了新的Team,开始做Java微服务的开发工作,接触了Spring Boot, Spring Cloud等技术栈,对微服务这种架构有了一个感性的认识.虽然只做了两个月的开发工作,但是对微服务架构的兴趣却没有结束,又因为自己的.NET背景(虽然对.NET的生态有点恨铁不成钢),想要探索一下在.NET平台下的微服务架构的可行性,也准备一些材料作为分享的素材. 幸运的是,在.NET Core首届在线峰会上,看到了很多前辈的分享,也增强了自己要摸索和实践.NET Co

一.为啥要写这个系列? 今年从原来的Team里面被抽出来加入了新的Team,开始做Java微服务的开发工作,接触了Spring Boot, Spring Cloud等技术栈,对微服务这种架构有了一个感性的认识.虽然只做了两个月的开发工作,但是对微服务架构的兴趣却没有结束,又因为自己的.NET背景(虽然对.NET的生态有点恨铁不成钢),想要探索一下在.NET平台下的微服务架构的可行性,也准备一些材料作为公司内部培训和分享课程的素材.幸运的是,在.NET Core首届在线峰会上,看到了很多前辈的分享

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

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